Hi

On Mon, May 13, 2013 at 11:17 PM, Daniel Nicoletti [off-list ref] wrote:

2013/5/13 David Herrmann [off-list ref]:

quoted

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