linux-kernel - Re: [PATCH] input: Synaptics USB device driver

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]

Date:	Thu, 5 Jan 2012 14:22:57 +0000
From:	Jan Steinhoff <mail@...-steinhoff.de>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Oliver Neukum <oneukum@...e.de>, Jiri Kosina <jkosina@...e.cz>,
	Alessandro Rubini <rubini@...vis.unipv.it>,
	linux-input@...r.kernel.org, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] input: Synaptics USB device driver

On Wed, 4 Jan 2012 22:36:11 -0800
Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> On Thu, Jan 05, 2012 at 06:01:38AM +0000, Jan Steinhoff wrote:
> > On Wed, 4 Jan 2012 02:05:53 -0800
> > Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> > > On Wed, Jan 04, 2012 at 10:56:20AM +0100, Oliver Neukum wrote:
> > > > Am Mittwoch, 4. Januar 2012, 10:41:03 schrieb Dmitry Torokhov:
> > > > > +static int synusb_probe(struct usb_interface *intf,
> > > > > +			const struct usb_device_id *id)
> > > > > +{
> > [...]
> > > > > +	synusb->urb = usb_alloc_urb(0, GFP_KERNEL);
> > > > > +	if (!synusb->urb) {
> > > > > +		error = -ENOMEM;
> > > > > +		goto err_free_mem;
> > > > > +	}
> > > > > +
> > > > > +	synusb->data = usb_alloc_coherent(udev,
> > > > > SYNUSB_RECV_SIZE, GFP_KERNEL,
> > > > > +
> > > > > &synusb->urb->transfer_dma);
> > > > > +	if (!synusb->data) {
> > > > > +		error = -ENOMEM;
> > > > > +		goto err_free_urb;
> > > > > +	}
> > > > > +
> > > > > +	usb_fill_int_urb(synusb->urb, udev,
> > > > > +			 usb_rcvintpipe(udev,
> > > > > ep->bEndpointAddress),
> > > > > +			 synusb->data, SYNUSB_RECV_SIZE,
> > > > > +			 synusb_irq, synusb,
> > > > > +			 ep->bInterval);
> > > > > +	synusb->urb->transfer_flags |=
> > > > > URB_NO_TRANSFER_DMA_MAP;
> > > > 
> > > > According to the comment in the original driver you must submit
> > > > the URB. Are you sure not doing so is save?
> > > 
> > > Seems to work here...
> > 
> > Let me comment on this issue in more detail, so you can better judge
> > what is the "right" solution here.
> > 
> > Both ways actually work. But, at least for the cPad, the device will
> > pretend it got reconnected if the int urb is not fetched (while not
> > suspended, of course). This means it would disconnect if no input
> > device is opened (AFAIK most X.org input drivers close the devices
> > when one switches to console) and one touches the pad (actually, a
> > slight breeze of air might be enough, it is very sensitive!).
> > Another annoying side effect in the case of the cPad is that the
> > background light flashes on every reconnect.
> 
> OK, then maybe we should have cPad start transfers immediately and let
> other devices do it in open. There is no reason to do work if nobody
> interested in it...

Given that the devices are very similar, I expect that also the other
devices may behave like this. So this is maybe not only a cPad
related problem. But I have never investigated this for other devices,
so I am not sure.

Regarding the extra amount of work, I thought it is finally less
expensive to run through the callback and drop the 8 bytes of data,
than to let the device trigger a disconnect, probe, and associated
device deletion/creation by udev every 60 sec or so (it maybe even
produces more USB traffic).

> Another option is to move configuring interface to open()?

The reconnect will always happen if the int endpoint is not "in use". So
configuring the device not in probe will not help, will it?

I think the best way would be to immediately suspend the device, if
there is an easy way to trigger this using the driver or usb core. (And
if there is no easy way, it is still possible to do it via sysfs if
someone is annoyed by this minor "reconnect bug".) Further, this should
be fine for all devices, whether they have this "reconnect bug" or not.
--
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/