Prev: [Bug #14783] Unhandled IRQ on Thinkpad R61i: "irq 16: nobody cared"
Next: media: dvb/af9015, refactor remote setting
From: Antti Palosaari on 24 Jan 2010 18:50
On 01/20/2010 07:19 PM, Jiri Slaby wrote:
> When both remote controller and receiver intfs are handled by
> af9015, .probe do nothing for remote intf, but when .disconnect
> is called for both of them it touches intfdata every time. For
> remote it crashes obviously (as intfdata are unset).
>
> Altough there is test against data being NULL, it is not enough.
> It is because someone before us does not set intf drvdata to
> NULL. (In this case the hid layer.) But we cannot rely on intf
> being NULL anyway.
>
> Fix that by checking bInterfaceNumber in af9015_usb_device_exit
> and do actually nothing if it is not 0.

I was a little bit surprised when saw this error, why it haven't
detected earlier. When I initially added interface check for .probe it
was surely needed, it was creating two instances without that check in
that time. When I now test this patch with debugs enabled I don't see
..probe and .disconnect be called for this HID interface (interface 1) at
all and thus checks not needed. I have Fedora Kernel 2.6.31.12 running
with latest v4l-dvb. Is there now some kind of check added recently
which blocks .probe and disconnect from HID interface?

regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 25 Jan 2010 04:20
On 01/25/2010 12:44 AM, Antti Palosaari wrote:
> When I now test this patch with debugs enabled I don't see
> .probe and .disconnect be called for this HID interface (interface 1) at
> all and thus checks not needed.

What happens if you disable the HID layer? Or at least if you add an
ignore quirk for the device in usbhid?

I forbid usbhid to attach to the device, as the remote kills X with HID
driver. With dvb-usb-remote it works just fine (with remote=2 for af9015
or the 4 patches I've sent).

--
js
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Antti Palosaari on 25 Jan 2010 13:10
On 01/25/2010 11:12 AM, Jiri Slaby wrote:
> On 01/25/2010 12:44 AM, Antti Palosaari wrote:
>> When I now test this patch with debugs enabled I don't see
>> .probe and .disconnect be called for this HID interface (interface 1) at
>> all and thus checks not needed.
>
> What happens if you disable the HID layer? Or at least if you add an
> ignore quirk for the device in usbhid?

Looks like Fedora doesn't have usbhid compiled as module. I looked
hid-quirks.c file and there was only one af9015 device blacklisted
15a4:9016. I have 15a4:9015, 15a4:9016 and 13d3:3237 devices and no
difference.

How can I disable HID layer?

> I forbid usbhid to attach to the device, as the remote kills X with HID
> driver. With dvb-usb-remote it works just fine (with remote=2 for af9015
> or the 4 patches I've sent).

In my understanding the cause of the remote problem is chipset bug which
sets USB2.0 polling interval to 4096ms. Therefore HID remote does not
work at all or starts repeating. It is possible to implement remote as
polling from the driver which works very well. But HID problem still
remains. I have some hacks in my mind to test to kill HID. One is to
configure HID wrongly to see if it stops outputting characters. Other
way is try to read remote codes directly from the chip memory.

But all in all, your patch does not break anything, it is safe to add.
It could be still nice to know if there is better alternatives. And
there is surely few other devices having HID remote - are those also
affected.

regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Kosina on 26 Jan 2010 08:10
On Mon, 25 Jan 2010, Antti Palosaari wrote:

> > What happens if you disable the HID layer? Or at least if you add an
> > ignore quirk for the device in usbhid?
>
> Looks like Fedora doesn't have usbhid compiled as module. I looked
> hid-quirks.c file and there was only one af9015 device blacklisted 15a4:9016.
> I have 15a4:9015, 15a4:9016 and 13d3:3237 devices and no difference.
>
> How can I disable HID layer?

In case usbhid is compiled in, you should still be able to force the
ignore quirk by passing

usbhid.quirks=0x15a4:0x9015:0x04

to kernel boot commandline.

> > I forbid usbhid to attach to the device, as the remote kills X with HID
> > driver. With dvb-usb-remote it works just fine (with remote=2 for af9015
> > or the 4 patches I've sent).
>
> In my understanding the cause of the remote problem is chipset bug which sets
> USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
> or starts repeating. It is possible to implement remote as polling from the
> driver which works very well. But HID problem still remains. I have some hacks
> in my mind to test to kill HID. One is to configure HID wrongly to see if it
> stops outputting characters. Other way is try to read remote codes directly
> from the chip memory.

Yes, Pekka Sarnila has added this workaround to the HID driver, as the
device is apparently broken.

I want to better understand why others are not hitting this with the
DVB remote driver before removing the quirk from HID code completely.

> But all in all, your patch does not break anything, it is safe to add. It
> could be still nice to know if there is better alternatives. And there is
> surely few other devices having HID remote - are those also affected.

--
Jiri Kosina
SUSE Labs, Novell Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 4 Feb 2010 05:40
On 01/26/2010 02:08 PM, Jiri Kosina wrote:
>> In my understanding the cause of the remote problem is chipset bug which sets
>> USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
>> or starts repeating. It is possible to implement remote as polling from the
>> driver which works very well. But HID problem still remains. I have some hacks
>> in my mind to test to kill HID. One is to configure HID wrongly to see if it
>> stops outputting characters. Other way is try to read remote codes directly
>> from the chip memory.
>
> Yes, Pekka Sarnila has added this workaround to the HID driver, as the
> device is apparently broken.
>
> I want to better understand why others are not hitting this with the
> DVB remote driver before removing the quirk from HID code completely.

I think, we should go for a better way. Thanks Pekka for hints, I ended
up with the patch in the attachment. Could you try it whether it works
for you?

I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
disable_rc_polling (a dvb_usb module parameter) must be set to not get
doubled characters now. And then, it works like a charm.

Note that, it's just some kind of proof of concept. A migration of
af9015 devices from dvb-usb-remote needs to be done first.

Ideas, comments?

regards,
--
js
 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [Bug #14783] Unhandled IRQ on Thinkpad R61i: "irq 16: nobody cared"
Next: media: dvb/af9015, refactor remote setting