On Wed, 4 Jan 2012 22:36:11 -0800
Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> 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@xxxxxxxxx> 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-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
