Meher | 31 Jan 01:23 2009
Picon

Setup for a composite device

Hi,
   I am working on a USB composite device that has a serial interface,
and a mass storage interface. I added the vendorID and productID to
the generic_device_ids[] in usb serial generic driver
(drivers/usb/serial/generic.c). I also added an entry into the
storage/unusual_devs.h but when I plug-in the device at run time, only
USB serial devices are detected and nonw of the storage devices get
detected. I have to manually do a echo on bind for the storage driver
to bind with this device. Is there a way to do this automatically at
hotplug? Does Linux USB subsystem probe the driver list for the device
until it finds a first match or does it go through all the drivers?
Does this system work differently on a composite device?

--

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

Greg KH | 31 Jan 01:52 2009

Re: Setup for a composite device

On Fri, Jan 30, 2009 at 06:23:36PM -0600, Meher wrote:
> Hi,
>    I am working on a USB composite device that has a serial interface,
> and a mass storage interface. I added the vendorID and productID to
> the generic_device_ids[] in usb serial generic driver
> (drivers/usb/serial/generic.c).

You probably really do not want to use the generic driver, but for
initial testing, that should be fine.

> I also added an entry into the
> storage/unusual_devs.h

Why add an entry here?  Does your device not match the usb-storage spec?

> but when I plug-in the device at run time, only USB serial devices are
> detected and nonw of the storage devices get detected. I have to
> manually do a echo on bind for the storage driver to bind with this
> device. Is there a way to do this automatically at hotplug? Does Linux
> USB subsystem probe the driver list for the device until it finds a
> first match or does it go through all the drivers?  Does this system
> work differently on a composite device?

It should "just work".  What is the output of /proc/bus/usb/devices with
your device plugged in?

thanks,

greg k-h
--
(Continue reading)

Meher | 31 Jan 05:31 2009
Picon

Re: Setup for a composite device

On Fri, Jan 30, 2009 at 6:52 PM, Greg KH <greg@...> wrote:
> On Fri, Jan 30, 2009 at 06:23:36PM -0600, Meher wrote:
>> Hi,
>>    I am working on a USB composite device that has a serial interface,
>> and a mass storage interface. I added the vendorID and productID to
>> the generic_device_ids[] in usb serial generic driver
>> (drivers/usb/serial/generic.c).
>
> You probably really do not want to use the generic driver, but for
> initial testing, that should be fine.
>

any specific reason for not using the generic driver?

>> I also added an entry into the
>> storage/unusual_devs.h
>
> Why add an entry here?  Does your device not match the usb-storage spec?
>

i never written a driver for a mass storage device. Can you explain
what do you mean by matching usb-storage spec? what does the mass
storage class driver look for to determine if the device match the
spec? when I use the new_id approach or the bind method, usb-storage
driver does detect the mass storage interface and enable the
interface. What triggers the auto detection of a mass storage device
by the driver?

>> but when I plug-in the device at run time, only USB serial devices are
>> detected and nonw of the storage devices get detected. I have to
(Continue reading)

Greg KH | 31 Jan 06:07 2009

Re: Setup for a composite device

On Fri, Jan 30, 2009 at 10:31:17PM -0600, Meher wrote:
> On Fri, Jan 30, 2009 at 6:52 PM, Greg KH <greg@...> wrote:
> > On Fri, Jan 30, 2009 at 06:23:36PM -0600, Meher wrote:
> >> Hi,
> >>    I am working on a USB composite device that has a serial interface,
> >> and a mass storage interface. I added the vendorID and productID to
> >> the generic_device_ids[] in usb serial generic driver
> >> (drivers/usb/serial/generic.c).
> >
> > You probably really do not want to use the generic driver, but for
> > initial testing, that should be fine.
> >
> 
> any specific reason for not using the generic driver?

It's not supposed to be a driver for any specific device.

It handles no flow control, and is dirt slow.  It is almost always not
what you want for your device.  If you really do want to use this kind
of connection, then create a tiny "stub" driver like
drivers/usb/serial/funsoft.c with your device id in it.

> >> I also added an entry into the
> >> storage/unusual_devs.h
> >
> > Why add an entry here?  Does your device not match the usb-storage spec?
> >
> 
> i never written a driver for a mass storage device.  Can you explain
> what do you mean by matching usb-storage spec? what does the mass
(Continue reading)

Viral Mehta | 31 Jan 07:38 2009

Re: USB 3.0 gadget stack


> Of course these changes discussed don't even cover the new link power
> management and function suspend for USB 3.0 devices.  Those will both be
> a requirement for USB 3.0 device compliance, but we can discuss those
> after we have an idea of the changes necessary for basic USB 3.0
> gadget-side support.
>
> Can anyone think of any other changes for USB 3.0 gadget side support?
>   
I still do not understand how exactly core and gadget side driver or 
controller or peripheral controller will address
backward/forward compatibility issues.

Like USB3.0 device can be attached to USB2.0 bus and USB2.0 devices can 
be attached to USB3.0 bus.

Ideas?

> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
> Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com
>
>
>   
--

-- 
(Continue reading)

Oliver Neukum | 31 Jan 11:18 2009

Re: Setup for a composite device

Am Saturday 31 January 2009 01:23:36 schrieb Meher:
>   I am working on a USB composite device that has a serial interface,
> and a mass storage interface. I added the vendorID and productID to
> the generic_device_ids[] in usb serial generic driver

Hi,

did you just use USB_DEVICE? If so, the serial driver, if it is loaded
first, will take all interfaces. You need to specify that the serial driver
should only take interfaces of the vendor specific class. You do so
using USB_DEVICE_AND_INTERFACE_INFO. Have a look at
drivers/usb/serial/option.c for examples.

	Regards
		Oliver

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

Roel Kluin | 31 Jan 12:37 2009
Picon

[PATCH] USB: count reaches -1, tested 0

With a postfix decrement count will reach -1 rather than 0,
so the warning will not be issued.

Signed-off-by: Roel Kluin <roel.kluin@...>
---
diff --git a/drivers/usb/host/pci-quirks.c b/drivers/usb/host/pci-quirks.c
index 75b6984..033c284 100644
--- a/drivers/usb/host/pci-quirks.c
+++ b/drivers/usb/host/pci-quirks.c
 <at>  <at>  -234,7 +234,7  <at>  <at>  static void __devinit quirk_usb_disable_ehci(struct pci_dev *pdev)
 	 */
 	hcc_params = readl(base + EHCI_HCC_PARAMS);
 	offset = (hcc_params >> 8) & 0xff;
-	while (offset && count--) {
+	while (offset && --count) {
 		u32		cap;
 		int		msec;

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

Oliver Neukum | 31 Jan 13:24 2009

Re: USB 3.0 in Linux main stream kernel

Am Saturday 31 January 2009 00:50:00 schrieb Sarah Sharp:

> I think I understand...  You're suggesting one URB per buffer for
> non-sg-capable drivers.  And all URBs that are part of one transfer
> (which may include multiple packets sent in a burst) are chained
> together, correct?

Yes, one URB per buffer. Just that URBs can be united
> 
> Would drivers that currently use usb_sg_init() still use that function,
> or will they have to be re-written to create chained URBs?

usb_sg_init(9 would create chained URBs

> If they continue to use usb_sg_*, what should that function do with that
> scatter gather list if the HCD supports scatter gather?  Turn it into a
> chained URB with one URB per sg list entry?  That way HCDs would just
> have to deal with buffers in chained URBs, rather than chained URBs and
> single URBs with scatter gather lists in them.

Exactly.

> Does usb_sg_init() need to create even more URBs when the sg list entry
> exceeds the wMaxPacketSize buffer length limit?  I think if the USB core
> is submitting a chained URB to a scatter gather capable HCD, it doesn't
> need to honor the wMaxPacketSize buffer length limit.  This rule is new
> to me, so I may be confused.

An URB's buffer length is not limited to wMaxPacketSize right now. I propose
a solution that changes nothing whether URBs are submitted single or as
(Continue reading)

Virgo Pärna | 31 Jan 14:02 2009
Picon

Pentax Optio E50 is not accessible with newer kernels (2.6.26 to 2.6.28.2)

	When I upgraded my laptop from Debian Etch (using kernel 2.6.18) to
Lenny (kernel 2.6.26), I was no longer able to access my Pentax Optio
E50  compact camera. I even tried compiling newer kernels, but it did
not help.
	Camera worked fine with same cable with Etch and it still works fine in
Windows XP.

I have added dmesg log (in the end I disconnected device) - with
2.6.28.2 kernel:

[  167.396135] usb 4-3: new high speed USB device using ehci_hcd and
address 2
[  167.573136] usb 4-3: configuration #1 chosen from 1 choice
[  167.582613] usb 4-3: New USB device found, idVendor=0a17, idProduct=00a7
[  167.582619] usb 4-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[  167.582623] usb 4-3: Product: Optio E50
[  167.582625] usb 4-3: Manufacturer: PENTAX Corporation
[  167.582628] usb 4-3: SerialNumber: 1153315
[  167.690378] Initializing USB Mass Storage driver...
[  167.690438] usb-storage: USB Mass Storage device detected
[  167.693001] usb-storage: -- associate_dev
[  167.693009] usb-storage: Vendor: 0x0a17, Product: 0x00a7, Revision:
0x0100
[  167.693012] usb-storage: Interface Subclass: 0x06, Protocol: 0x50
[  167.693022] usb-storage: Transport: Bulk
[  167.693024] usb-storage: Protocol: Transparent SCSI
[  167.693304] scsi2 : SCSI emulation for USB Mass Storage devices
[  167.693379] usb-storage: *** thread sleeping.
[  167.693604] usbcore: registered new interface driver usb-storage
(Continue reading)

Alexey Klimov | 31 Jan 16:35 2009
Picon

Re: [PATCH]suspend/resume support for option driver

Hello, Oliver

Sorry for asking this question.

On Fri, 2009-01-23 at 12:02 +0100, Oliver Neukum wrote:
> This patch implements suspend and resume methods for the
> option driver. With my hardware I can even suspend the system
> and keep up a connection for a short time.
> 
> Signed-off-by: Oliver Neukum <oneukum@...>
> 
> 	Regards
> 		Oliver
> 
> ---
> 
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
>  <at>  <at>  -62,6 +62,8  <at>  <at>  static int  option_tiocmget(struct tty_struct *tty, struct file *file);
>  static int  option_tiocmset(struct tty_struct *tty, struct file *file,
>  				unsigned int set, unsigned int clear);
>  static int  option_send_setup(struct tty_struct *tty, struct usb_serial_port *port);
> +static int  option_suspend(struct usb_serial *serial, pm_message_t message);
> +static int  option_resume(struct usb_serial *serial);
>  
>  /* Vendor and product IDs */
>  #define OPTION_VENDOR_ID			0x0AF0
>  <at>  <at>  -487,6 +489,8  <at>  <at>  static struct usb_driver option_driver = {
>  	.name       = "option",
>  	.probe      = usb_serial_probe,
(Continue reading)


Gmane