diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2009-06-16 21:57:37 +0200 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2009-06-16 21:57:37 +0200 |
commit | 6fd03301d76bc439382710e449f58efbb233df1b (patch) | |
tree | 3c8a3217aed67319683ffc1debccdb5b3245b16c /Documentation/driver-model/device.txt | |
parent | Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sha... (diff) | |
parent | debugfs: use specified mode to possibly mark files read/write only (diff) | |
download | linux-6fd03301d76bc439382710e449f58efbb233df1b.tar.xz linux-6fd03301d76bc439382710e449f58efbb233df1b.zip |
Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (64 commits)
debugfs: use specified mode to possibly mark files read/write only
debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem.
xen: remove driver_data direct access of struct device from more drivers
usb: gadget: at91_udc: remove driver_data direct access of struct device
uml: remove driver_data direct access of struct device
block/ps3: remove driver_data direct access of struct device
s390: remove driver_data direct access of struct device
parport: remove driver_data direct access of struct device
parisc: remove driver_data direct access of struct device
of_serial: remove driver_data direct access of struct device
mips: remove driver_data direct access of struct device
ipmi: remove driver_data direct access of struct device
infiniband: ehca: remove driver_data direct access of struct device
ibmvscsi: gadget: at91_udc: remove driver_data direct access of struct device
hvcs: remove driver_data direct access of struct device
xen block: remove driver_data direct access of struct device
thermal: remove driver_data direct access of struct device
scsi: remove driver_data direct access of struct device
pcmcia: remove driver_data direct access of struct device
PCIE: remove driver_data direct access of struct device
...
Manually fix up trivial conflicts due to different direct driver_data
direct access fixups in drivers/block/{ps3disk.c,ps3vram.c}
Diffstat (limited to 'Documentation/driver-model/device.txt')
-rw-r--r-- | Documentation/driver-model/device.txt | 32 |
1 files changed, 32 insertions, 0 deletions
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt index a7cbfff40d07..a124f3126b0d 100644 --- a/Documentation/driver-model/device.txt +++ b/Documentation/driver-model/device.txt @@ -162,3 +162,35 @@ device_remove_file(dev,&dev_attr_power); The file name will be 'power' with a mode of 0644 (-rw-r--r--). +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 +strict expectations on when attributes get created. When a new device is +registered in the kernel, a uevent is generated to notify userspace (like +udev) that a new device is available. If attributes are added after the +device is registered, then userspace won't get notified and userspace will +not know about the new attributes. + +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: + create_device(&mydriver_class, dev, chrdev, &private_data, "my_name"); |