On Thu, 13 Nov 2008, Andi Kleen wrote:

On Thu, Nov 13, 2008 at 01:30:55PM +0100, Jiri Slaby wrote:

quoted

Andi Kleen napsal(a):

quoted

Which information do you need exactly out of /sys/bus/usb/devices? 

You misread the path, it's one file in /proc. (Make sure usbfs is mounted

There was nothing there, so I checked sysfs.

quoted

there.)

With the power switch connected I have:

...
T:  Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=04b4 ProdID=fd11 Rev= 1.01
S:  Manufacturer=Gembird Electronics
S:  Product=Gembird Silver Shield PM
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=150mA
I:* If#= 0 Alt= 0 #EPs= 0 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbhid

...

It looks like this problem was caused by the introduction of the input 
bus.

When the USB device is detected, the hid_probe routine in usbhid is
called.  It registers the device on the input bus.  This causes the
hid_probe routine in drivers/hid/hid-core.c to be called, and it fails.

But that failure merely means there's no driver bound to the input
device.  It's still registered on the input bus, and the USB device is
still bound to usbhid.  Whereas before, the failure would occur in
usbhid's probe and would leave the USB device unbound.

This suggests that a lot of the work in usbhid_start should be 
performed earlier, before calling hid_add_device.  After all, why 
bother registering a USB device on the input bus if usbhid isn't going 
to be able to drive it?

Alan Stern