[lkml]   [2009]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Export device_add_attributes() so drivers can use it.
On Fri, Feb 20, 2009 at 16:28, Grant Likely <> wrote:
> Thanks for the reply, it clarifies a lot.  It sounds like this really
> should be documented (in Documentation/driver-model/device.txt?).  I'm
> happy to add a blurb to that effect and send a patch, but I want to
> make sure I really understand the model before I do so.  I've got a
> couple more questions below:
> On Thu, Feb 19, 2009 at 4:08 PM, Kay Sievers <> wrote:
> [...]
>> If an attribute is not available at event time, nothing of this can
>> ever work. If you look a the device a second later, you will see the
>> proper looking files and values, and all the test programs will work,
>> but it will always fail at device creation.
> [...]
>> That all might not be needed for your specific setup/driver/device and
>> may work fine for your need. But we don't want to encourage anybody
>> with another new API which creates the usual trouble we need to fix
>> later.
> Fair enough
>> And we need to fix things like this all the time.
> Can you point me at a 'textbook' example of one of these fixups?

Here are a few cases of broken atribute timing, a quick git search has found:;a=commit;h=f7120a4f75168df3c02efacd10403a4ba0bcb29d;a=commit;h=8a89efd18aa15bb832778baa4e6eee3857ecada4;a=commit;h=3b23dd6f8a718e5339de4f7d86ce76a078b5f771;a=commit;h=2e5f10e4f0a9649186d8a8c793822b2e0dae8373;a=commit;h=bfd129445f23c037d9a440ebfa4109e11c220301

Regarding the split of the driver device and the device to bind to:
the platform stuff is kind of "special", because it is often used for
devices/buses which can not be enumerated. With buses which need
enumeration, it's pretty obvious that the enumeration creates their
own devices, which then a driver can bind to, and where the driver
creates its own driver instance for it. Like nobody would expect a
network driver to add the netif properties directly to the pci device,
and so on.

Many platform devices are just static placeholders, and then it is not
obvious that userspace still prefers another device instance while
binding a driver, but in most cases it's worth the effort, because
then all devices, regardless which bus is backing them, can be handled
the same way with a "hotplug handler" like udev.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-02-26 23:31    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean