Hi On Mon, May 13, 2013 at 11:17 PM, Daniel Nicoletti <dantti12@xxxxxxxxx> wrote: > 2013/5/13 David Herrmann <dh.herrmann@xxxxxxxxx>: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
