lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B5DDDFB.5020907@iki.fi>
Date:	Mon, 25 Jan 2010 20:07:55 +0200
From:	Antti Palosaari <crope@....fi>
To:	Jiri Slaby <jirislaby@...il.com>
CC:	mchehab@...radead.org, linux-kernel@...r.kernel.org,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	linux-media@...r.kernel.org
Subject: Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ