Merge branch 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

</para></listitem>

<listitem><para>

<varname>unsigned long addr</varname>: Required if the mapping is used.

<varname>phys_addr_t addr</varname>: Required if the mapping is used.

Fill in the address of your memory block. This address is the one that

appears in sysfs.

</para></listitem>

and actually register it with the class, which happens with the

class's register_dev callback.

NOTE: The device class structures and core routines to manipulate them

are not in the mainline kernel, so the discussion is still a bit

speculative. 

Driver

~~~~~~

			 const char *buf, size_t count);

};

Attributes of devices can be exported via drivers using a simple

procfs-like interface. 

Attributes of devices can be exported by a device driver through sysfs.

Please see Documentation/filesystems/sysfs.txt for more information

on how sysfs works.

As explained in Documentation/kobject.txt, device attributes must be be

created before the KOBJ_ADD uevent is generated. The only way to realize

that is by defining an attribute group.

Attributes are declared using a macro called DEVICE_ATTR:

#define DEVICE_ATTR(name,mode,show,store)

Example:

DEVICE_ATTR(power,0644,show_power,store_power);

static DEVICE_ATTR(type, 0444, show_type, NULL);

static DEVICE_ATTR(power, 0644, show_power, store_power);

This declares a structure of type struct device_attribute named

'dev_attr_power'. This can then be added and removed to the device's

directory using:

This declares two structures of type struct device_attribute with respective

names 'dev_attr_type' and 'dev_attr_power'. These two attributes can be

organized as follows into a group:

int device_create_file(struct device *device, struct device_attribute * entry);

void device_remove_file(struct device * dev, struct device_attribute * attr);

static struct attribute *dev_attrs[] = {

	&dev_attr_type.attr,

	&dev_attr_power.attr,

	NULL,

};

Example:

static struct attribute_group dev_attr_group = {

	.attrs = dev_attrs,

};

static const struct attribute_group *dev_attr_groups[] = {

	&dev_attr_group,

	NULL,

};

This array of groups can then be associated with a device by setting the

group pointer in struct device before device_register() is invoked:

device_create_file(dev,&dev_attr_power);

device_remove_file(dev,&dev_attr_power);

      dev->groups = dev_attr_groups;

      device_register(dev);

The file name will be 'power' with a mode of 0644 (-rw-r--r--).

The device_register() function will use the 'groups' pointer to create the

device attributes and the device_unregister() function will use this pointer

to remove the device attributes.

Word of warning:  While the kernel allows device_create_file() and

device_remove_file() to be called on a device at any time, userspace has

This is important for device driver that need to publish additional

attributes for a device at driver probe time.  If the device driver simply

calls device_create_file() on the device structure passed to it, then

userspace will never be notified of the new attributes.  Instead, it should

probably use class_create() and class->dev_attrs to set up a list of

desired attributes in the modules_init function, and then in the .probe()

hook, and then use device_create() to create a new device as a child

of the probed device.  The new device will generate a new uevent and

properly advertise the new attributes to userspace.

For example, if a driver wanted to add the following attributes:

struct device_attribute mydriver_attribs[] = {

	__ATTR(port_count, 0444, port_count_show),

	__ATTR(serial_number, 0444, serial_number_show),

	NULL

};

Then in the module init function is would do:

	mydriver_class = class_create(THIS_MODULE, "my_attrs");

	mydriver_class.dev_attr = mydriver_attribs;

And assuming 'dev' is the struct device passed into the probe hook, the driver

probe function would do something like:

	device_create(&mydriver_class, dev, chrdev, &private_data, "my_name");

userspace will never be notified of the new attributes.

Patrick Mochel	<mochel@osdl.org>

Mike Murphy <mamurph@cs.clemson.edu>

Revised:    15 July 2010

Revised:    16 August 2011

Original:   10 January 2003

void driver_remove_file(struct device_driver *, const struct driver_attribute *);

Documentation

~~~~~~~~~~~~~

The sysfs directory structure and the attributes in each directory define an

ABI between the kernel and user space. As for any ABI, it is important that

this ABI is stable and properly documented. All new sysfs attributes must be

documented in Documentation/ABI. See also Documentation/ABI/README for more

information.

Procedure for submitting patches to the -stable tree:

 - Send the patch, after verifying that it follows the above rules, to

   stable@kernel.org.  You must note the upstream commit ID in the changelog

   of your submission.

   stable@vger.kernel.org.  You must note the upstream commit ID in the

   changelog of your submission.

 - To have the patch automatically included in the stable tree, add the tag

     Cc: stable@kernel.org

     Cc: stable@vger.kernel.org

   in the sign-off area. Once the patch is merged it will be applied to

   the stable tree without anything else needing to be done by the author

   or subsystem maintainer.

   cherry-picked than this can be specified in the following format in

   the sign-off area:

     Cc: <stable@kernel.org> # .32.x: a1f84a3: sched: Check for idle

     Cc: <stable@kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle

     Cc: <stable@kernel.org> # .32.x: fd21073: sched: Fix affinity logic

     Cc: <stable@kernel.org> # .32.x

     Cc: <stable@vger.kernel.org> # .32.x: a1f84a3: sched: Check for idle

     Cc: <stable@vger.kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle

     Cc: <stable@vger.kernel.org> # .32.x: fd21073: sched: Fix affinity logic

     Cc: <stable@vger.kernel.org> # .32.x

    Signed-off-by: Ingo Molnar <mingo@elte.hu>

   The tag sequence has the meaning of: