USB hid blocks USB port in 2.6.28rc3

USB hid blocks USB port in 2.6.28rc3

[Andi Kleen]

Hi,

I have a box here which has a couple of USB devices connected.
That includes several HID devices (keyboards, mouse) and a couple
of others including a USB powerswitch driven through a user space
program.

Now what happened is that I changed some of the HID devices
around (moving from a direct port to a hub) and also moved
the USB power switch from one port to another. But after that
the power switch didn't work anymore, just giving a flood 
of

usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1

(sispm is the user space driver)

Kernel is 2.6.28-rc3

Relevant messages from the kernel log (relatively long because
there is a longer history):

...
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci_hcd 0000:00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23
ehci_hcd 0000:00:1d.7: setting latency timer to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
ehci_hcd 0000:00:1d.7: cache line size of 32 is not supported
ehci_hcd 0000:00:1d.7: irq 23, io mem 0xe8304400
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
uhci_hcd: USB Universal Host Controller Interface driver
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
uhci_hcd 0000:00:1d.0: setting latency timer to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 23, io base 0x00004080
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: setting latency timer to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 19, io base 0x00004060
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: setting latency timer to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x00004040
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16
uhci_hcd 0000:00:1d.3: setting latency timer to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 16, io base 0x00004020
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
...
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
...
usb 2-1: new low speed USB device using uhci_hcd and address 2
usb 2-1: configuration #1 chosen from 1 choice
input: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) as /class/input/input2
generic-usb 0003:045E:0039.0001: input: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.0-1/input0
usb 2-2: new low speed USB device using uhci_hcd and address 3
usb 2-2: configuration #1 chosen from 1 choice
ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
input: Silitek Standard USB Keyboard  as /class/input/input3
generic-usb 0003:047B:0011.0002: input: USB HID v1.00 Keyboard [Silitek Standard USB Keyboard ] on usb-0000:00:1d.0-2/input0
usb 3-1: new low speed USB device using uhci_hcd and address 2
/home/lsrc/linux-2.6.28-rc3/drivers/hid/usbhid/hid-core.c: couldn't find an input interrupt endpoint
...
usb 1-5: new high speed USB device using ehci_hcd and address 5
usb 1-5: configuration #1 chosen from 1 choice
usb-storage: probe of 1-5:1.0 failed with error -5
usb-storage: probe of 1-5:1.1 failed with error -5
usb-storage: probe of 1-5:1.2 failed with error -1
usb-storage: probe of 1-5:1.3 failed with error -1
usbcore: registered new interface driver usbserial
USB Serial support registered for generic
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
USB Serial support registered for GSM modem (1-port)
option 1-5:1.0: GSM modem (1-port) converter detected
usb 1-5: GSM modem (1-port) converter now attached to ttyUSB0
option 1-5:1.1: GSM modem (1-port) converter detected
usb 1-5: GSM modem (1-port) converter now attached to ttyUSB1
usbcore: registered new interface driver option
option: v0.7.2:USB Driver for GSM modems
...
usb 1-5: USB disconnect, address 5
option 1-5:1.0: device disconnected
option 1-5:1.1: device disconnected
option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
usb 1-5: new high speed USB device using ehci_hcd and address 6
usb 1-5: configuration #1 chosen from 1 choice
usb-storage: probe of 1-5:1.0 failed with error -1
usb 1-5: USB disconnect, address 6
usb 1-5: new high speed USB device using ehci_hcd and address 7
usb 1-5: configuration #1 chosen from 1 choice
usb-storage: probe of 1-5:1.0 failed with error -5
option 1-5:1.0: GSM modem (1-port) converter detected
usb 1-5: GSM modem (1-port) converter now attached to ttyUSB0
usb-storage: probe of 1-5:1.1 failed with error -5
option 1-5:1.1: GSM modem (1-port) converter detected
usb 1-5: GSM modem (1-port) converter now attached to ttyUSB1
usb-storage: probe of 1-5:1.2 failed with error -1
usb-storage: probe of 1-5:1.3 failed with error -1
PPP generic driver version 2.4.2
PPP BSD Compression module registered
PPP Deflate Compression module registered
usb 1-4: new high speed USB device using ehci_hcd and address 8
usb 1-4: configuration #1 chosen from 1 choice
hub 1-4:1.0: USB hub found
hub 1-4:1.0: 4 ports detected
usb 2-1: USB disconnect, address 2
usb 1-4: reset high speed USB device using ehci_hcd and address 8
usb 1-4.2: new low speed USB device using ehci_hcd and address 9
usb 1-4.2: configuration #1 chosen from 1 choice
input: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) as /class/input/input4
generic-usb 0003:045E:0039.0004: input: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.7-4.2/input0
usb 2-2: USB disconnect, address 3
usb 1-4.3: new low speed USB device using ehci_hcd and address 10
usb 1-4.3: configuration #1 chosen from 1 choice
input: Silitek Standard USB Keyboard  as /class/input/input5
generic-usb 0003:047B:0011.0005: input: USB HID v1.00 Keyboard [Silitek Standard USB Keyboard ] on usb-0000:00:1d.7-4.3/input0
usb 1-4.1: new full speed USB device using ehci_hcd and address 11
usb 1-4.1: configuration #1 chosen from 1 choice
usblp0: USB Bidirectional printer dev 11 if 0 alt 1 proto 2 vid 0x03F0 pid 0x0C17
usbcore: registered new interface driver usblp
usb 1-6: new high speed USB device using ehci_hcd and address 12
usb 1-6: configuration #1 chosen from 1 choice
scsi16 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 12
usb-storage: waiting for device to settle before scanning
scsi 16:0:0:0: Direct-Access     CBM      Flash Disk       4.00 PQ: 0 ANSI: 2
sd 16:0:0:0: [sdc] 255231 512-byte hardware sectors: (130 MB/124 MiB)
sd 16:0:0:0: [sdc] Write Protect is off
sd 16:0:0:0: [sdc] Mode Sense: 00 00 00 00
sd 16:0:0:0: [sdc] Assuming drive cache: write through
sd 16:0:0:0: [sdc] 255231 512-byte hardware sectors: (130 MB/124 MiB)
sd 16:0:0:0: [sdc] Write Protect is off
sd 16:0:0:0: [sdc] Mode Sense: 00 00 00 00
sd 16:0:0:0: [sdc] Assuming drive cache: write through
 sdc: sdc1
sd 16:0:0:0: [sdc] Attached SCSI removable disk
sd 16:0:0:0: Attached scsi generic sg3 type 0
usb-storage: device scan complete
usb 1-6: USB disconnect, address 12
usb 1-5: USB disconnect, address 7
option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0
option 1-5:1.0: device disconnected
option 1-5:1.1: device disconnected
option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1
usb 1-5: new high speed USB device using ehci_hcd and address 13
usb 1-5: configuration #1 chosen from 1 choice
usb-storage: probe of 1-5:1.0 failed with error -1
usb 1-5: USB disconnect, address 13
usb 1-5: new high speed USB device using ehci_hcd and address 14
usb 1-5: configuration #1 chosen from 1 choice
usb-storage: probe of 1-5:1.0 failed with error -5
option 1-5:1.0: GSM modem (1-port) converter detected
usb 1-5: GSM modem (1-port) converter now attached to ttyUSB0
usb-storage: probe of 1-5:1.1 failed with error -5
option 1-5:1.1: GSM modem (1-port) converter detected
usb 1-5: GSM modem (1-port) converter now attached to ttyUSB1
usb-storage: probe of 1-5:1.2 failed with error -1
usb-storage: probe of 1-5:1.3 failed with error -1
usb 1-4.1: USB disconnect, address 11
usblp0: removed
usb 1-4.1: new full speed USB device using ehci_hcd and address 15
usb 1-4.1: configuration #1 chosen from 1 choice
usblp0: USB Bidirectional printer dev 15 if 0 alt 1 proto 2 vid 0x03F0 pid 0x0C17
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 3-1: USB disconnect, address 2
usb 1-4: USB disconnect, address 8
usb 1-4.1: USB disconnect, address 15
usblp0: removed
usb 1-4.2: USB disconnect, address 9
usb 1-4.3: USB disconnect, address 10
usb 2-2: new low speed USB device using uhci_hcd and address 4
usb 2-2: configuration #1 chosen from 1 choice
/home/lsrc/linux-2.6.28-rc3/drivers/hid/usbhid/hid-core.c: couldn't find an input interrupt endpoint
usb 1-4: new high speed USB device using ehci_hcd and address 17
usb 1-4: configuration #1 chosen from 1 choice
hub 1-4:1.0: USB hub found
hub 1-4:1.0: 4 ports detected
usb 1-4.1: new full speed USB device using ehci_hcd and address 18
usb 1-4.1: configuration #1 chosen from 1 choice
usblp0: USB Bidirectional printer dev 18 if 0 alt 1 proto 2 vid 0x03F0 pid 0x0C17
usb 1-4.2: new low speed USB device using ehci_hcd and address 19
usb 1-4.2: configuration #1 chosen from 1 choice
input: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) as /class/input/input6
generic-usb 0003:045E:0039.0007: input: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.7-4.2/input0
usb 1-4.3: new low speed USB device using ehci_hcd and address 20
usb 1-4.3: configuration #1 chosen from 1 choice
input: Silitek Standard USB Keyboard  as /class/input/input7
generic-usb 0003:047B:0011.0008: input: USB HID v1.00 Keyboard [Silitek Standard USB Keyboard ] on usb-0000:00:1d.7-4.3/input0
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 1-4: USB disconnect, address 17
usb 1-4.1: USB disconnect, address 18
usblp0: removed
usb 1-4.2: USB disconnect, address 19
usb 1-4.3: USB disconnect, address 20
usb 1-4: new high speed USB device using ehci_hcd and address 21
usb 1-4: configuration #1 chosen from 1 choice
hub 1-4:1.0: USB hub found
hub 1-4:1.0: 4 ports detected
usb 1-4.1: new full speed USB device using ehci_hcd and address 22
usb 1-4.1: configuration #1 chosen from 1 choice
usblp0: USB Bidirectional printer dev 22 if 0 alt 1 proto 2 vid 0x03F0 pid 0x0C17
usb 1-4.2: new low speed USB device using ehci_hcd and address 23
usb 1-4.2: configuration #1 chosen from 1 choice
input: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM) as /class/input/input8
generic-usb 0003:045E:0039.0009: input: USB HID v1.10 Mouse [Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)] on usb-0000:00:1d.7-4.2/input0
usb 1-4.3: new low speed USB device using ehci_hcd and address 24
usb 1-4.3: configuration #1 chosen from 1 choice
input: Silitek Standard USB Keyboard  as /class/input/input9
generic-usb 0003:047B:0011.000A: input: USB HID v1.00 Keyboard [Silitek Standard USB Keyboard ] on usb-0000:00:1d.7-4.3/input0
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
hub 1-4:1.0: port 1 disabled by hub (EMI?), re-enabling...
usb 1-4.1: USB disconnect, address 22
usblp0: removed
usb 1-4.1: new full speed USB device using ehci_hcd and address 25
usb 1-4.1: configuration #1 chosen from 1 choice
usblp0: USB Bidirectional printer dev 25 if 0 alt 1 proto 2 vid 0x03F0 pid 0x0C17
usb 4-2: new low speed USB device using uhci_hcd and address 2
usb 4-2: configuration #1 chosen from 1 choice
input: CHESEN USB Keyboard as /class/input/input10
generic-usb 0003:0A81:0103.000B: input: USB HID v1.10 Keyboard [CHESEN USB Keyboard] on usb-0000:00:1d.2-2/input0
input: CHESEN USB Keyboard as /class/input/input11
generic-usb 0003:0A81:0103.000C: input: USB HID v1.10 Mouse [CHESEN USB Keyboard] on usb-0000:00:1d.2-2/input1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: USB disconnect, address 4
usb 2-2: new low speed USB device using uhci_hcd and address 5
usb 2-2: configuration #1 chosen from 1 choice
/home/lsrc/linux-2.6.28-rc3/drivers/hid/usbhid/hid-core.c: couldn't find an input interrupt endpoint
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
... more messages like this ....

-Andi

-- 
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hid blocks USB port in 2.6.28rc3

[Alan Stern]

On Tue, 11 Nov 2008, Andi Kleen wrote:

> Hi,
> 
> I have a box here which has a couple of USB devices connected.
> That includes several HID devices (keyboards, mouse) and a couple
> of others including a USB powerswitch driven through a user space
> program.
> 
> Now what happened is that I changed some of the HID devices
> around (moving from a direct port to a hub) and also moved
> the USB power switch from one port to another. But after that
> the power switch didn't work anymore, just giving a flood 
> of
> 
> usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
> 
> (sispm is the user space driver)
> 
> Kernel is 2.6.28-rc3

This sounds like a userspace problem.  The sispm program should unbind 
usbhid from interface 0 before trying to set the config.

I don't know why it should start showing up now.  Perhaps you need to 
add the power switch to usbhid's blacklist.

At any rate, you should be able to get it working again by unbinding 
usbhid manually:

	echo -n 2-2:1.0 >/sys/bus/usb/drivers/usbhid/unbind

Alan Stern

Re: USB hid blocks USB port in 2.6.28rc3

[Andi Kleen]

On Mon, Nov 10, 2008 at 07:45:28PM -0500, Alan Stern wrote:
> On Tue, 11 Nov 2008, Andi Kleen wrote:
> 
> > Hi,
> > 
> > I have a box here which has a couple of USB devices connected.
> > That includes several HID devices (keyboards, mouse) and a couple
> > of others including a USB powerswitch driven through a user space
> > program.
> > 
> > Now what happened is that I changed some of the HID devices
> > around (moving from a direct port to a hub) and also moved
> > the USB power switch from one port to another. But after that
> > the power switch didn't work anymore, just giving a flood 
> > of
> > 
> > usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
> > 
> > (sispm is the user space driver)
> > 
> > Kernel is 2.6.28-rc3
> 
> This sounds like a userspace problem.  The sispm program should unbind 
> usbhid from interface 0 before trying to set the config.

Can you please explain in layman's terms why usbhid does not 
unbind itself when it detects the removal of a device? 

Why should sispm need to unbind someone else?

-Andi

-- 
ak@linux.intel.com

Re: USB hid blocks USB port in 2.6.28rc3

[Alan Stern]

On Tue, 11 Nov 2008, Andi Kleen wrote:

> On Mon, Nov 10, 2008 at 07:45:28PM -0500, Alan Stern wrote:
> > On Tue, 11 Nov 2008, Andi Kleen wrote:
> > 
> > > Hi,
> > > 
> > > I have a box here which has a couple of USB devices connected.
> > > That includes several HID devices (keyboards, mouse) and a couple
> > > of others including a USB powerswitch driven through a user space
> > > program.
> > > 
> > > Now what happened is that I changed some of the HID devices
> > > around (moving from a direct port to a hub) and also moved
> > > the USB power switch from one port to another. But after that
> > > the power switch didn't work anymore, just giving a flood 
> > > of
> > > 
> > > usb 2-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1
> > > 
> > > (sispm is the user space driver)
> > > 
> > > Kernel is 2.6.28-rc3
> > 
> > This sounds like a userspace problem.  The sispm program should unbind 
> > usbhid from interface 0 before trying to set the config.
> 
> Can you please explain in layman's terms why usbhid does not 
> unbind itself when it detects the removal of a device? 

It does.  The problem is on the other side: Your power switch presents 
itself as an HID device, so when it is _detected_ it binds to usbhid.

On the other hand, your log contains an error message saying "couldn't 
find an input interrupt endpoint".  That should have caused usbhid's 
probe to fail.  Perhaps the failure occurred on interface 1, leaving 
usbhid still bound to interface 0.

You can find out exactly which drivers are bound to which interfaces by 
looking at /proc/bus/usb/devices.  (Depending on your distribution, you 
may first need to mount /proc/bus/usb as type usbfs.)

> Why should sispm need to unbind someone else?

The usbfs API does not allow user programs to set a device's
configuration if any drivers are bound to the device.  Therefore, if a 
program wants to set a config then it must unbind all the existing 
drivers first.  This is a safety precaution against programs 
interfering with other drivers.

Now in fact, sispm probably doesn't need to set the configuration at 
all.  This is undoubtedly a holdover from a Windows version, because 
Windows does not set device configurations by default whereas Linus 
does.

Alan Stern

Re: USB hid blocks USB port in 2.6.28rc3

[Andi Kleen]

> It does.  The problem is on the other side: Your power switch presents 
> itself as an HID device, so when it is _detected_ it binds to usbhid.

Ok, but it worked in all kernels before. Why has that changed?

Looks like a regression to me. Rafael, can you please add it to the list?

> > Why should sispm need to unbind someone else?
> 
> The usbfs API does not allow user programs to set a device's
> configuration if any drivers are bound to the device.  Therefore, if a 
> program wants to set a config then it must unbind all the existing 
> drivers first.  This is a safety precaution against programs 
> interfering with other drivers.
> 
> Now in fact, sispm probably doesn't need to set the configuration at 
> all.  This is undoubtedly a holdover from a Windows version, because 
> Windows does not set device configurations by default whereas Linus 
> does.

So you're saying that sispm should be changed to not do something?
What something exactly? And it would work then?

And why exactly does what it used to do before not work anymore now?

-Andi
-- 
ak@linux.intel.com

Re: USB hid blocks USB port in 2.6.28rc3

[Alan Stern]

On Tue, 11 Nov 2008, Andi Kleen wrote:

> > It does.  The problem is on the other side: Your power switch presents 
> > itself as an HID device, so when it is _detected_ it binds to usbhid.
> 
> Ok, but it worked in all kernels before. Why has that changed?

I don't know.

> So you're saying that sispm should be changed to not do something?
> What something exactly? And it would work then?

It should be changed either to:

	Not do Set-Configuration, or

	Detach the HID driver before doing the Set-Configuration.

Either of these should allow it to work.

> And why exactly does what it used to do before not work anymore now?

This is a repeat of your first question above.  I still don't know.

If you're interested in finding out the answer, here's what you should
do.  First, as Jiri and I have both suggested, post the contents of
your /proc/bus/usb/devices.  Second, post copies of the full system log
for both old and new kernels with the usbfs_snoop module parameter set.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hid blocks USB port in 2.6.28rc3

[Rafael J. Wysocki]

On Tuesday, 11 of November 2008, Andi Kleen wrote:
> > It does.  The problem is on the other side: Your power switch presents 
> > itself as an HID device, so when it is _detected_ it binds to usbhid.
> 
> Ok, but it worked in all kernels before. Why has that changed?
> 
> Looks like a regression to me. Rafael, can you please add it to the list?

Done.

Thanks,
Rafael

 
> > > Why should sispm need to unbind someone else?
> > 
> > The usbfs API does not allow user programs to set a device's
> > configuration if any drivers are bound to the device.  Therefore, if a 
> > program wants to set a config then it must unbind all the existing 
> > drivers first.  This is a safety precaution against programs 
> > interfering with other drivers.
> > 
> > Now in fact, sispm probably doesn't need to set the configuration at 
> > all.  This is undoubtedly a holdover from a Windows version, because 
> > Windows does not set device configurations by default whereas Linus 
> > does.
> 
> So you're saying that sispm should be changed to not do something?
> What something exactly? And it would work then?
> 
> And why exactly does what it used to do before not work anymore now?

Re: USB hid blocks USB port in 2.6.28rc3

[Jiri Kosina]

On Sun, 16 Nov 2008, Rafael J. Wysocki wrote:

> > Ok, but it worked in all kernels before. Why has that changed?
> > Looks like a regression to me. Rafael, can you please add it to the list?
> Done.

I already have a (verified) fix in my tree (not sent to Linus yet, will 
happen in a day or two hopefully).

-- 
Jiri Kosina
SUSE Labs

Re: USB hid blocks USB port in 2.6.28rc3

[Rafael J. Wysocki]

On Sunday, 16 of November 2008, Jiri Kosina wrote:
> On Sun, 16 Nov 2008, Rafael J. Wysocki wrote:
> 
> > > Ok, but it worked in all kernels before. Why has that changed?
> > > Looks like a regression to me. Rafael, can you please add it to the list?
> > Done.
> 
> I already have a (verified) fix in my tree (not sent to Linus yet, will 
> happen in a day or two hopefully).

OK, thanks for the info.

Jiri has added the patch link to the Bugzilla entry already.

Best,
Rafael



-- 
Everyone knows that debugging is twice as hard as writing a program
in the first place.  So if you're as clever as you can be when you write it,
how will you ever debug it? --- Brian Kernighan

Re: USB hid blocks USB port in 2.6.28rc3

[Andi Kleen]

On Sun, Nov 16, 2008 at 12:54:28AM +0100, Jiri Kosina wrote:
> On Sun, 16 Nov 2008, Rafael J. Wysocki wrote:
> 
> > > Ok, but it worked in all kernels before. Why has that changed?
> > > Looks like a regression to me. Rafael, can you please add it to the list?
> > Done.
> 
> I already have a (verified) fix in my tree (not sent to Linus yet, will 
> happen in a day or two hopefully).

Yes confirmed. Jiri fixed the problem.

-Andi

-- 
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hid blocks USB port in 2.6.28rc3

[Jiri Kosina]

On Tue, 11 Nov 2008, Andi Kleen wrote:

> generic-usb 0003:047B:0011.0002: input: USB HID v1.00 Keyboard [Silitek Standard USB Keyboard ] on usb-0000:00:1d.0-2/input0
> usb 3-1: new low speed USB device using uhci_hcd and address 2
> /home/lsrc/linux-2.6.28-rc3/drivers/hid/usbhid/hid-core.c: couldn't find an input interrupt endpoint

Hmm, I am wondering about this error. This appears when the keyboard gets 
connected, before you do any of the device shuffling, right?

Could you please post /proc/bus/usb/devices before and after you do the 
connection changes?

-- 
Jiri Kosina
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hid blocks USB port in 2.6.28rc3

[Andi Kleen]

On Wed, Nov 12, 2008 at 03:31:41PM +0100, Jiri Kosina wrote:
> On Tue, 11 Nov 2008, Andi Kleen wrote:
> 
> > generic-usb 0003:047B:0011.0002: input: USB HID v1.00 Keyboard [Silitek Standard USB Keyboard ] on usb-0000:00:1d.0-2/input0
> > usb 3-1: new low speed USB device using uhci_hcd and address 2
> > /home/lsrc/linux-2.6.28-rc3/drivers/hid/usbhid/hid-core.c: couldn't find an input interrupt endpoint
> 
> Hmm, I am wondering about this error. This appears when the keyboard gets 
> connected, before you do any of the device shuffling, right?

Yes. The log was over a longer run time and connected and disconnected
several things at different times.
> 
> Could you please post /proc/bus/usb/devices before and after you do the 
> connection changes?

I did some retesting and right now it looks like the power switch
never works with 2.6.28rc4 (not sure how I got to the conclusion
earlier that it was only after reconnect)

I now always get when I run sispm:

usb 3-2: usbfs: interface 0 claimed by usbhid while 'sispm' sets config #1

On 2.6.27 it works.

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

A simple find on 2.6.28rc4 is:

/sys/bus/usb/devices/
/sys/bus/usb/devices/usb1
/sys/bus/usb/devices/1-0:1.0
/sys/bus/usb/devices/usb2
/sys/bus/usb/devices/2-0:1.0
/sys/bus/usb/devices/usb3
/sys/bus/usb/devices/3-0:1.0
/sys/bus/usb/devices/usb4
/sys/bus/usb/devices/4-0:1.0
/sys/bus/usb/devices/usb5
/sys/bus/usb/devices/5-0:1.0
/sys/bus/usb/devices/1-3
/sys/bus/usb/devices/1-3:1.0
/sys/bus/usb/devices/3-2
/sys/bus/usb/devices/3-2:1.0
/sys/bus/usb/devices/1-3.1
/sys/bus/usb/devices/1-3.1:1.0
/sys/bus/usb/devices/1-3.2
/sys/bus/usb/devices/1-3.2:1.0
/sys/bus/usb/devices/1-3.3
/sys/bus/usb/devices/1-3.3:1.0
/sys/bus/usb/devices/1-3.3:1.1
/sys/bus/usb/devices/1-3.4
/sys/bus/usb/devices/1-3.4:1.0
/sys/bus/usb/devices/1-5
/sys/bus/usb/devices/1-5:1.0
/sys/bus/usb/devices/1-5:1.1
/sys/bus/usb/devices/1-5:1.2
/sys/bus/usb/devices/1-5:1.3

with gembird switch connected.

-Andi
-- 
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hid blocks USB port in 2.6.28rc3

[Jiri Slaby]

Andi Kleen napsal(a):
> 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.)

Re: USB hid blocks USB port in 2.6.28rc3

[Andi Kleen]

On Thu, Nov 13, 2008 at 01:30:55PM +0100, Jiri Slaby wrote:
> Andi Kleen napsal(a):
> > 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.

> 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

...

-Andi
-- 
ak-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB hid blocks USB port in 2.6.28rc3

[Alan Stern]

On Thu, 13 Nov 2008, Andi Kleen wrote:

> On Thu, Nov 13, 2008 at 01:30:55PM +0100, Jiri Slaby wrote:
> > Andi Kleen napsal(a):
> > > 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.
> 
> > 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

[PATCH] HID: don't grab devices with no input

[Jiri Slaby]

Alan Stern wrote:
> 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?

None of the code can be moved to the usbhid probe function, because all
of it depends on the driver's (potential) report_fixup.

However I suggest moving this test to the probe which ensures performing
the test early enough.

Andi, could you test the attached patch?

--

Some devices have no input interrupt endpoint. These won't be handled
by usbhid, but currently they are not refused and reside on hid bus.

Perform this checking earlier so that we refuse to control such
a device early enough (and not pass it to the hid bus at all).

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
 drivers/hid/usbhid/hid-core.c |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index f7e0d71..2c5cb10 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -845,12 +845,6 @@ static int usbhid_start(struct hid_device *hid)
 		}
 	}
 
-	if (!usbhid->urbin) {
-		err_hid("couldn't find an input interrupt endpoint");
-		ret = -ENODEV;
-		goto fail;
-	}
-
 	init_waitqueue_head(&usbhid->wait);
 	INIT_WORK(&usbhid->reset_work, hid_reset);
 	setup_timer(&usbhid->io_retry, hid_retry_timeout, (unsigned long) hid);
@@ -947,15 +941,26 @@ static struct hid_ll_driver usb_hid_driver = {
 
 static int hid_probe(struct usb_interface *intf, const struct usb_device_id *id)
 {
+	struct usb_host_interface *interface = intf->cur_altsetting;
 	struct usb_device *dev = interface_to_usbdev(intf);
 	struct usbhid_device *usbhid;
 	struct hid_device *hid;
+	unsigned int n, has_in = 0;
 	size_t len;
 	int ret;
 
 	dbg_hid("HID probe called for ifnum %d\n",
 			intf->altsetting->desc.bInterfaceNumber);
 
+	for (n = 0; n < interface->desc.bNumEndpoints; n++)
+		if (usb_endpoint_dir_in(&interface->endpoint[n].desc))
+			has_in++;
+	if (!has_in) {
+		dev_err(&intf->dev, "couldn't find an input interrupt "
+				"endpoint");
+		return -ENODEV;
+	}
+
 	hid = hid_allocate_device();
 	if (IS_ERR(hid))
 		return PTR_ERR(hid);
-- 
1.6.0.3

Re: [PATCH] HID: don't grab devices with no input

[Alan Stern]

On Thu, 13 Nov 2008, Jiri Slaby wrote:

> Alan Stern wrote:
> > 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?
> 
> None of the code can be moved to the usbhid probe function, because all
> of it depends on the driver's (potential) report_fixup.
> 
> However I suggest moving this test to the probe which ensures performing
> the test early enough.

That makes sense.  It's the only failure mode in usbhid_start which
isn't a simple out-of-memory error.

> Andi, could you test the attached patch?
> 
> --
> 
> Some devices have no input interrupt endpoint. These won't be handled
> by usbhid, but currently they are not refused and reside on hid bus.
> 
> Perform this checking earlier so that we refuse to control such
> a device early enough (and not pass it to the hid bus at all).
> 
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>

> +	for (n = 0; n < interface->desc.bNumEndpoints; n++)
> +		if (usb_endpoint_dir_in(&interface->endpoint[n].desc))
> +			has_in++;
> +	if (!has_in) {
> +		dev_err(&intf->dev, "couldn't find an input interrupt "
> +				"endpoint");
> +		return -ENODEV;
> +	}
> +

Do you want to use usb_endpoint_is_int_in() instead?  It matches the 
error message more closely.

Alan Stern

Re: [PATCH] HID: don't grab devices with no input

[Jiri Slaby]

On 11/13/2008 10:37 PM, Alan Stern wrote:
>> +	for (n = 0; n < interface->desc.bNumEndpoints; n++)
>> +		if (usb_endpoint_dir_in(&interface->endpoint[n].desc))
>> +			has_in++;
>> +	if (!has_in) {
>> +		dev_err(&intf->dev, "couldn't find an input interrupt "
>> +				"endpoint");
>> +		return -ENODEV;
>> +	}
>> +
> 
> Do you want to use usb_endpoint_is_int_in() instead?  It matches the 
> error message more closely.

Yes, good catch, thanks.

[PATCH 1/1 v2] DRM: fix radeon suspend/resume oops

[Jiri Slaby]

me wrote:
> As the accesses to the mmio member are not protected by anything, they
> seem to be racy with the open/clsoe anyways, setting this down there
> too.

On the second though it should be protected. Updated patch below...

+ added Rafael to cc list

--

When the driver is bound to a device and nobody opens the device node,
it will oops on suspend and resume, since it's not mapped and
dev_priv->mmio is NULL.

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/gpu/drm/radeon/radeon_drv.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
index 71af746..7672310 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -56,6 +56,9 @@ static int radeon_suspend(struct drm_device *dev, pm_message_t state)
 {
 	drm_radeon_private_t *dev_priv = dev->dev_private;
 
+	if (!dev_priv->mmio)
+		return 0;
+
 	/* Disable *all* interrupts */
 	if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690)
 		RADEON_WRITE(R500_DxMODE_INT_MASK, 0);
@@ -67,6 +70,9 @@ static int radeon_resume(struct drm_device *dev)
 {
 	drm_radeon_private_t *dev_priv = dev->dev_private;
 
+	if (!dev_priv->mmio)
+		return 0;
+
 	/* Restore interrupt registers */
 	if ((dev_priv->flags & RADEON_FAMILY_MASK) >= CHIP_RS690)
 		RADEON_WRITE(R500_DxMODE_INT_MASK, dev_priv->r500_disp_irq_reg);
-- 
1.6.0.3

Re: [PATCH 1/1 v2] DRM: fix radeon suspend/resume oops

[Jiri Slaby]

Sorry, wrong patch, wrong destination.

On 11/13/2008 11:09 PM, Jiri Slaby wrote:
> me wrote:
>> As the accesses to the mmio member are not protected by anything, they
>> seem to be racy with the open/clsoe anyways, setting this down there
>> too.
> 
> On the second though it should be protected. Updated patch below...

[PATCH 1/1 v2] HID: don't grab devices with no input

[Jiri Slaby]

Some devices have no input interrupt endpoint. These won't be handled
by usbhid, but currently they are not refused and reside on hid bus.

Perform this checking earlier so that we refuse to control such
a device early enough (and not pass it to the hid bus at all).

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
 drivers/hid/usbhid/hid-core.c |   17 +++++++++++------
 1 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index 05402e9..9c9bd4c 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -850,12 +850,6 @@ static int usbhid_start(struct hid_device *hid)
 		}
 	}
 
-	if (!usbhid->urbin) {
-		err_hid("couldn't find an input interrupt endpoint");
-		ret = -ENODEV;
-		goto fail;
-	}
-
 	init_waitqueue_head(&usbhid->wait);
 	INIT_WORK(&usbhid->reset_work, hid_reset);
 	setup_timer(&usbhid->io_retry, hid_retry_timeout, (unsigned long) hid);
@@ -958,15 +952,26 @@ static struct hid_ll_driver usb_hid_driver = {
 
 static int hid_probe(struct usb_interface *intf, const struct usb_device_id *id)
 {
+	struct usb_host_interface *interface = intf->cur_altsetting;
 	struct usb_device *dev = interface_to_usbdev(intf);
 	struct usbhid_device *usbhid;
 	struct hid_device *hid;
+	unsigned int n, has_in = 0;
 	size_t len;
 	int ret;
 
 	dbg_hid("HID probe called for ifnum %d\n",
 			intf->altsetting->desc.bInterfaceNumber);
 
+	for (n = 0; n < interface->desc.bNumEndpoints; n++)
+		if (usb_endpoint_is_int_in(&interface->endpoint[n].desc))
+			has_in++;
+	if (!has_in) {
+		dev_err(&intf->dev, "couldn't find an input interrupt "
+				"endpoint");
+		return -ENODEV;
+	}
+
 	hid = hid_allocate_device();
 	if (IS_ERR(hid))
 		return PTR_ERR(hid);
-- 
1.6.0.4

Re: [PATCH 1/1 v2] HID: don't grab devices with no input

[Jiri Kosina]

On Thu, 13 Nov 2008, Jiri Slaby wrote:

> Some devices have no input interrupt endpoint. These won't be handled
> by usbhid, but currently they are not refused and reside on hid bus.
> Perform this checking earlier so that we refuse to control such
> a device early enough (and not pass it to the hid bus at all).
> Signed-off-by: Jiri Slaby <jirislaby@gmail.com>

As the patch is obviously correct(tm) :) I have queued it in my tree, but 
Andi, please still report back whether it fixes the issue you are seeing.

Thanks.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 1/1 v2] HID: don't grab devices with no input

[Andi Kleen]

On Fri, Nov 14, 2008 at 12:02:27PM +0100, Jiri Kosina wrote:
> On Thu, 13 Nov 2008, Jiri Slaby wrote:
> 
> > Some devices have no input interrupt endpoint. These won't be handled
> > by usbhid, but currently they are not refused and reside on hid bus.
> > Perform this checking earlier so that we refuse to control such
> > a device early enough (and not pass it to the hid bus at all).
> > Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
> 
> As the patch is obviously correct(tm) :) I have queued it in my tree, but 
> Andi, please still report back whether it fixes the issue you are seeing.

sispm works again with that patch. Thanks.

The only nit I noticed is that the error message seems to miss an \n

-Andi

Re: [PATCH 1/1 v2] HID: don't grab devices with no input

[Jiri Kosina]

On Fri, 14 Nov 2008, Andi Kleen wrote:

> > > Some devices have no input interrupt endpoint. These won't be 
> > > handled by usbhid, but currently they are not refused and reside on 
> > > hid bus. Perform this checking earlier so that we refuse to control 
> > > such a device early enough (and not pass it to the hid bus at all). 
> > > Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
> > As the patch is obviously correct(tm) :) I have queued it in my tree, but 
> > Andi, please still report back whether it fixes the issue you are seeing.
> sispm works again with that patch. Thanks.

Thanks a lot for testing.

> The only nit I noticed is that the error message seems to miss an \n

That I have already fixed in my tree.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] HID: don't grab devices with no input

[Andi Kleen]

On Thu, Nov 13, 2008 at 11:05:09PM +0100, Jiri Slaby wrote:
> On 11/13/2008 10:37 PM, Alan Stern wrote:
> >> +	for (n = 0; n < interface->desc.bNumEndpoints; n++)
> >> +		if (usb_endpoint_dir_in(&interface->endpoint[n].desc))
> >> +			has_in++;
> >> +	if (!has_in) {
> >> +		dev_err(&intf->dev, "couldn't find an input interrupt "
> >> +				"endpoint");
> >> +		return -ENODEV;
> >> +	}
> >> +
> > 
> > Do you want to use usb_endpoint_is_int_in() instead?  It matches the 
> > error message more closely.
> 
> Yes, good catch, thanks.
Should I test it with that change or the original version?

-Andi

-- 
ak@linux.intel.com

Re: [PATCH] HID: don't grab devices with no input

[Jiri Slaby]

On 11/13/2008 11:22 PM, Andi Kleen wrote:
> On Thu, Nov 13, 2008 at 11:05:09PM +0100, Jiri Slaby wrote:
>> On 11/13/2008 10:37 PM, Alan Stern wrote:
>>> Do you want to use usb_endpoint_is_int_in() instead?  It matches the 
>>> error message more closely.
>> Yes, good catch, thanks.
> Should I test it with that change or the original version?

The updated one, please.