USB Device Add reading wrong attributes on Linux

[Kay Sievers]

On Wed, Dec 3, 2008 at 22:04, Drew Moseley <dmoseley at mvista.com> wrote:
> Kay Sievers wrote:
>> On Wed, Dec 3, 2008 at 18:21, Drew Moseley <dmoseley at mvista.com> wrote:
>>> I've noticed a case with a USB device on a linux host where some of the
>>> attributes are not being properly initialized.  Specifically the
>>> can_wake_up and is_self_powered fields are incorrect because when HAL
>>> reads the bmAttributes sysfs file it gets a read error.  A restart of
>>> hal usually brings the correct values in.
>>>
>>> In the kernel code for the USB sysfs files there is a comment that
>>> "Unforunately these attributes cannot be created before the uevent is
>>> broadcast".  I do see in the kernel where the sysfs file is being read
>>> by HAL but getting an error.  Has anyone else dealt with this?  Should
>>> there be a retry of some kind in HAL to handle this?
>>
>> Yeah, that's a known issue. Things like this can not work without
>> tight integration with the kernel, which must send an update event for
>> every change. This is just not implemented, not in the kernel and not
>> in HAL. Retry implemented in HAL would only help in some cases.
>>
>> To make it kind of work, all these values could be updated when the
>> child devices are created/removed. This would fix a bunch of different
>> bugs in this area, like when a device is reconfigured, and HAL will
>> not notice it, and exports the wrong values from the initial config.
>> In most cases when child devices come and go, the parent device has,
>> at that time, all values properly populated. So, per example, "usb
>> interface" events could trigger an update of the "usb device" values.
>>
>> Btw, It was a mistake to mirror any such kernel values in a daemon, we
>> didn't know that the time HAL was created. It's really hard to get
>> things like this right, and the pseudo "platform abstraction" at that
>> fine-grained level just doesn't work in reality. DeviceKit, which will
>> replace HAL, will not even try that. It will just use sysfs directly
>> on Linux, without any such caching behavior like HAL has.
>>
>> Thanks,
>> Kay
>
> Thanks for the description.  I think I will just add a retry to handle
> the particular issue I am seeing.  The patch is below in case anyone
> cares.

Looks fine, for the one failure case.

Be aware that these values are still wrong if the device changes it's
configuration. Any driver can request a config change. HAL just does
not cope with that, and the retry does not help here too. Only a
values update, when the interface devices go and come back with the
different config would help here.

Btw, there is a usb kernel fix coming up, which will make these values
properly readable at event time, which will make the retry obsolete,
but the re-config stuff will still be broken.

Kay