Re: [PATCH] HID: input: return ENODATA if reading battery attrs fails

[David Herrmann <dh.herrmann@gmail.com>]

Hi

On Mon, May 13, 2013 at 11:17 PM, Daniel Nicoletti <dantti12@gmail.com> wrote:
> 2013/5/13 David Herrmann <dh.herrmann@gmail.com>:
>> Anyway, I'd still like to see this patch applied so we have this annoying
>> bug fixed. I'd be willing to change the power_supply core, too, if one of the
>> maintainers agrees on the design (David? Anton?).
>>
>> And, @Daniel, can you check whether this actually fixes the bug? I don't own
>> a device that reports battery-information, but it at least fixes the same bug
>> for the hid-wiimote driver (tested by me).
>
> Yes, it does fixes the bug. Now udevadm properly show add and remove events
> and upower happily get's them.
> But there is around  15 seconds block on the bluetooth stack, in other words
> when connecting a device it seems to probe the device which blocks till
> a timeout, and while that timeout doesn't finish other bluetooth
> devices are also
> blocked. It seems the devices aren't able to be probed so soon, possibly
> because bluetooth didn't finished setting them up. Looking at udevadm output
> I clearly see that it locks for around 3 times.
> My kernel knowledge is rather limited but if you can give me tips or patches to
> test I really want to see this code finally working properly, and sorry for
> not realizing when I sent it that it had this issue...

The block occurs because power_supply core now tries all properties in
a row instead of aborting if the first fails (which is what we want).
However, bluetooth-core didn't allow I/O during probe so the timeout
got quite huge considering 3s for 5 different properties instead of 3s
once (which no-one noticed, yet..)

This is now fixed with the HIDP-patch pending on linux-input and
linux-bluetooth. For usbhid and uhid we already allow I/O during probe
so this does not happen there.

So I hope we can apply this for linux-next (probably after gustavo
applied the HIDP fix)?
Cheers
David