Re: Problems with 2.6.37, runtime PM, and the TTY layer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 11, 2011 at 11:09:42AM -0500, Alan Stern wrote:
> On Mon, 10 Jan 2011, Dan Williams wrote:
> 
> > > > > What serial driver is getting bound to your interface?  Is it cdc-acm?
> > > > 
> > > > qcaux, which is a thin shim driver over usbserial, much like moto_modem.
> > > > It's basically a driver to expose the Qualcomm DIAG protocol ports on
> > > > devices that present a CDC-ACM interface (for standard AT commands) and
> > > > then a separate Qualcomm DIAG interface.  Thus more than one driver gets
> > > > bound to the device; CDC-ACM for the actual CDC-ACM interface, and qcaux
> > > > for the DIAG interface, and possibly another driver for other protocols
> > > > the device may support on the other interfaces.
> > > 
> > > ... but maybe something's wrong with qcaux.  I'll have a look at it 
> > > tomorrow.
> > 
> > qcaux.c does not have:
> > 
> > #ifdef CONFIG_PM
> > 	.suspend    = usb_serial_suspend,
> > 	.resume     = usb_serial_resume,
> > 	.supports_autosuspend =	1,
> > #endif
> > 
> > but that shouldn't mean that open() fails, I hope.  If the driver
> > doesn't support autosuspend, things should still work...  Regardless,
> > adding that hunk to qcaux causes things to magically work again.
> 
> It isn't needed.
> 
> > What's the criteria for drivers to set supports_autosuspend = 1?  Should
> > everything that uses usb_serial_probe() be audited with an eye towards
> > adding that block?
> 
> No, that's not the problem.  The problem is that qcaux.c does not 
> define the .usb_driver field in its qcaux_device structure.
> 
> Hmm, it looks like the same bug is present for the epic_device 
> structure in io_tables.h, and in iuu_phoenix.c, keyspan.h, 
> moto_modem.c, oti6858.c, siemens_mpi.c, spcp8x5.c, and usb_debug.c.  
> Maybe it would be a good idea to replace the test in 
> usb_serial_register() for this field being non-NULL with a BUG.  That 
> would draw people's attention!

Ick, good point.  I could just change the usb_register() to force the
usb_driver field to be the option to that function, which would force it
to be set.

Would that make it easier or just be a pain?

thanks,

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux