Re: When enabling usb autosuspend, new usb devices aren't recognized
Hi Bjørn, Those fixes seem to work. I could't reproduce the bug. Autosuspend uses D3cold now instead of D2. Thank for your help everyone. Florian Merz -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: Add Interface Association Descriptor to ECM
On Sat, Sep 8, 2012 at 3:34 AM, Linus Walleij linus.wall...@linaro.org wrote:
On Fri, Sep 7, 2012 at 8:51 PM, Sebastian Andrzej Siewior
sebast...@breakpoint.cc wrote:
On Wed, Jan 25, 2012 at 11:02:03AM +0100, Linus Walleij wrote:
static struct usb_descriptor_header *ecm_fs_function[] = {
/* CDC ECM control descriptors */
+ (struct usb_descriptor_header *) ecm_iad_descriptor,
(struct usb_descriptor_header *) ecm_control_intf,
(struct usb_descriptor_header *) ecm_header_desc,
(struct usb_descriptor_header *) ecm_union_desc,
@@ -247,6 +262,7 @@ static struct usb_endpoint_descriptor
hs_ecm_out_desc = {
static struct usb_descriptor_header *ecm_hs_function[] = {
/* CDC ECM control descriptors */
+ (struct usb_descriptor_header *) ecm_iad_descriptor,
(struct usb_descriptor_header *) ecm_control_intf,
(struct usb_descriptor_header *) ecm_header_desc,
(struct usb_descriptor_header *) ecm_union_desc,
Why did you add this IAD thingy to FS and HS and not SS descriptors? I
don't
see a reason so I would guess you just forgot :)
Argh, Praveena, save me here ... I was being patch secretary
this time, but to my untrained USB-eyes it looks like you're right,
interested in patching it?
This patch was generated based on Kernel 3.0 and then Super Speed was
not fully into gadget framework!
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] - USB3 bluetooth device not working properly?
On 09/07/2012 07:07 PM, Sarah Sharp wrote: Big improvment with the latest patches from for-usb-linus-plus-set-addr branch. My bluetooth device now works as expected, I can suspend and device isn't disconnected after a resume. Although those timeout and not accepting address errors are still present in logs but as far as I could test device now works. I'm attaching dmesg output with debugging enabled. Great! I will queue these for 3.6. I may need to investigate some interesting behavior that your host controller displays. The xHCI driver handles these spurious events fine (by ignoring them), but I'd like to sort out the root cause of warnings like this: [ 74.302671] xhci_hcd :00:14.0: Port Status Change Event for port 3 [ 74.302687] xhci_hcd :00:14.0: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 74.302690] xhci_hcd :00:14.0: @37007540 0c00 03018000 I may need you to run some additional tests later. Thanks. I will gladly test your additional changes for this error. Will those previous changes be in 3.6-rc5 already or some other? -- Best regards, Miroslav -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to handle delays in isochronous transfers?
On Sat, 8 Sep 2012, Peter Chen wrote: If the feedback is supported, the device will know host sends data slowly, it will give speed up feedback information after it receives packet 5 or other packets depends on its interval at descriptor. At this information, it can tell the host to increase the packet size, then the transaction length and transaction numbers at iTD can be increased(Assume it was not maximum). Clemens pointed out that this won't work if the delay is too long. Clements said In such a situation, the delay is much bigger than the device's buffer, so just sending more samples afterwards will not help. before. I don't understand what will not be helped? Maybe Clemens can explain. I have never worked with feedback endpoints. And what will happen when the thing goes to wrong? The isochronous stream will be delayed and the output will not be synchronized with the input. For example, an speaker might produce sounds 50 or 100 ms after receiving the audio data from the microphone. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] How to handle delays in isochronous transfers?
Peter Chen wrote: On Fri, Sep 7, 2012 at 11:44 PM, Alan Stern st...@rowland.harvard.edu wrote: On Fri, 7 Sep 2012, Peter Chen wrote: If the feedback is supported, the device will know host sends data slowly, it will give speed up feedback information after it receives packet 5 or other packets depends on its interval at descriptor. At this information, it can tell the host to increase the packet size, then the transaction length and transaction numbers at iTD can be increased(Assume it was not maximum). Clemens pointed out that this won't work if the delay is too long. Clements said In such a situation, the delay is much bigger than the device's buffer, so just sending more samples afterwards will not help. before. I don't understand what will not be helped? The frequency feedback mechanism is designed to compensate for small differences in the host's and the device's clocks; it is not suitable for situations where the host sends less data than it should (or none at all). Devices have a buffer that is no larger than two or three milliseconds. Furthermore, the maximum packet size usually is only about 10 % larger than needed for the nominal sample rate, so it would in no case be possible to compensate for even a single lost packet. Regards, Clemens -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usbfs: Add a new disconnect-and-claim ioctl (v2)
Apps which deal with devices which also have a kernel driver, need to do
the following:
1) Check which driver is attached, so as to not detach the wrong driver
(ie detaching usbfs while another instance of the app is using the device)
2) Detach the kernel driver
3) Claim the interface
Where moving from one step to the next for both 1-2 and 2-3 consists of
a (small) race window. So currently such apps are racy and people just live
with it.
This patch adds a new ioctl which makes it possible for apps to do this
in a race free manner. For flexibility apps can choose to:
1) Specify the driver to disconnect
2) Specify to disconnect any driver except for the one named by the app
3) Disconnect any driver
Note that if there is no driver attached, the ioctl will just act like the
regular claim-interface ioctl, this is by design, as returning an error for
this condition would open a new bag of race-conditions.
Changes in v2:
-Fix indentation of if blocks where the condition spans multiple lines
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/usb/core/devio.c | 35 +++
include/linux/usbdevice_fs.h | 14 ++
2 files changed, 49 insertions(+)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index ebb8a9d..e0356cb 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1928,6 +1928,38 @@ static int proc_get_capabilities(struct dev_state *ps,
void __user *arg)
return 0;
}
+static int proc_disconnect_claim(struct dev_state *ps, void __user *arg)
+{
+ struct usbdevfs_disconnect_claim dc;
+ struct usb_interface *intf;
+
+ if (copy_from_user(dc, arg, sizeof(dc)))
+ return -EFAULT;
+
+ intf = usb_ifnum_to_if(ps-dev, dc.interface);
+ if (!intf)
+ return -EINVAL;
+
+ if (intf-dev.driver) {
+ struct usb_driver *driver = to_usb_driver(intf-dev.driver);
+
+ if ((dc.flags USBDEVFS_DISCONNECT_CLAIM_IF_DRIVER)
+ strncmp(dc.driver, intf-dev.driver-name,
+ sizeof(dc.driver)) != 0)
+ return -EBUSY;
+
+ if ((dc.flags USBDEVFS_DISCONNECT_CLAIM_EXCEPT_DRIVER)
+ strncmp(dc.driver, intf-dev.driver-name,
+ sizeof(dc.driver)) == 0)
+ return -EBUSY;
+
+ dev_dbg(intf-dev, disconnect by usbfs\n);
+ usb_driver_release_interface(driver, intf);
+ }
+
+ return claimintf(ps, dc.interface);
+}
+
/*
* NOTE: All requests here that have interface numbers as parameters
* are assuming that somehow the configuration has been prevented from
@@ -2101,6 +2133,9 @@ static long usbdev_do_ioctl(struct file *file, unsigned
int cmd,
case USBDEVFS_GET_CAPABILITIES:
ret = proc_get_capabilities(ps, p);
break;
+ case USBDEVFS_DISCONNECT_CLAIM:
+ ret = proc_disconnect_claim(ps, p);
+ break;
}
usb_unlock_device(dev);
if (ret = 0)
diff --git a/include/linux/usbdevice_fs.h b/include/linux/usbdevice_fs.h
index 3b74666..4abe28e 100644
--- a/include/linux/usbdevice_fs.h
+++ b/include/linux/usbdevice_fs.h
@@ -131,6 +131,19 @@ struct usbdevfs_hub_portinfo {
#define USBDEVFS_CAP_NO_PACKET_SIZE_LIM0x04
#define USBDEVFS_CAP_BULK_SCATTER_GATHER 0x08
+/* USBDEVFS_DISCONNECT_CLAIM flags struct */
+
+/* disconnect-and-claim if the driver matches the driver field */
+#define USBDEVFS_DISCONNECT_CLAIM_IF_DRIVER0x01
+/* disconnect-and-claim except when the driver matches the driver field */
+#define USBDEVFS_DISCONNECT_CLAIM_EXCEPT_DRIVER0x02
+
+struct usbdevfs_disconnect_claim {
+ unsigned int interface;
+ unsigned int flags;
+ char driver[USBDEVFS_MAXDRIVERNAME + 1];
+};
+
#ifdef __KERNEL__
#ifdef CONFIG_COMPAT
#include linux/compat.h
@@ -211,5 +224,6 @@ struct usbdevfs_ioctl32 {
#define USBDEVFS_CLAIM_PORT_IOR('U', 24, unsigned int)
#define USBDEVFS_RELEASE_PORT _IOR('U', 25, unsigned int)
#define USBDEVFS_GET_CAPABILITIES _IOR('U', 26, __u32)
+#define USBDEVFS_DISCONNECT_CLAIM _IOR('U', 27, struct
usbdevfs_disconnect_claim)
#endif /* _LINUX_USBDEVICE_FS_H */
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
Hello everybody, I am trying to get a USB IO Board running with Debian on Raspberry PI and other 2.6.+ distributions (e.g. Ubuntu 12.04). The board used to run fine with kernel 2.4.+ (e.g. Ubuntu 10.04) - a Device /dev/ttyACM0 was created and usable. But with newer kernels no device is created and dmesg tells: # dmesg [3.391258] usb 1-1.2: new full-speed USB device number 4 using dwc_otg [8.531474] usb 1-1.2: unable to read config index 0 descriptor/start: -32 [8.531510] usb 1-1.2: chopping to 0 config(s) [8.532305] usb 1-1.2: string descriptor 0 read error: -32 [8.532341] usb 1-1.2: New USB device found, idVendor=04d8, idProduct=000a [8.532359] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [8.532880] usb 1-1.2: no configuration chosen from 0 choices [8.532896] usb 1-1.2: No support over 500mA The problem seems to be in usbcore, because some descriptors cannot be read (-32/-EPIPE). usbmon says on plug-in: # cat /sys/kernel/debug/usb/usbmon/0u | grep 1:008 cd54d940 3612193975 S Ci:1:008:0 s 80 06 0100 0012 18 cd54d940 3612197527 C Ci:1:008:0 0 18 = 12010002 0208 d8040a00 01000102 0001 cd54d940 3612197592 S Ci:1:008:0 s 80 06 0600 000a 10 cd54d940 3617194056 C Ci:1:008:0 -2 0 cd54d940 3617194112 S Ci:1:008:0 s 80 06 0200 0009 9 cd54d940 3617194309 C Ci:1:008:0 -71 0 cd54d940 3617194356 S Ci:1:008:0 s 80 06 0200 0009 9 cd54d940 3617194541 C Ci:1:008:0 -71 0 cd54d940 3617194590 S Ci:1:008:0 s 80 06 0200 0009 9 cd54d940 3617194795 C Ci:1:008:0 -71 0 cd54d940 3617195462 S Ci:1:008:0 s 80 06 0300 00ff 255 cd54d940 3617195674 C Ci:1:008:0 -71 0 cd54d940 3617196101 S Ci:1:008:0 s 80 06 0300 0002 2 cd54d940 3617196305 C Ci:1:008:0 -71 0 The hardware I want to use is: # lsusb -vd 04d8:000a Bus 001 Device 013: ID 04d8:000a Microchip Technology, Inc. CDC RS-232 Emulation Demo Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x04d8 Microchip Technology, Inc. idProduct 0x000a CDC RS-232 Emulation Demo bcdDevice0.01 iManufacturer 1 iProduct2 iSerial 0 bNumConfigurations 0 Device Status: 0x74f8 (Bus Powered) Debug Mode Has anybody an idea how to get this running? Best regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Sat, Sep 08, 2012 at 02:06:19PM -0400, Florian Wöhrl wrote: Hello everybody, I am trying to get a USB IO Board running with Debian on Raspberry PI and other 2.6.+ distributions (e.g. Ubuntu 12.04). The board used to run fine with kernel 2.4.+ (e.g. Ubuntu 10.04) - a Device /dev/ttyACM0 was created and usable. But with newer kernels no device is created and dmesg tells: # dmesg [3.391258] usb 1-1.2: new full-speed USB device number 4 using dwc_otg [8.531474] usb 1-1.2: unable to read config index 0 descriptor/start: -32 [8.531510] usb 1-1.2: chopping to 0 config(s) [8.532305] usb 1-1.2: string descriptor 0 read error: -32 [8.532341] usb 1-1.2: New USB device found, idVendor=04d8, idProduct=000a [8.532359] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [8.532880] usb 1-1.2: no configuration chosen from 0 choices [8.532896] usb 1-1.2: No support over 500mA You are sucking too much power for the device, try plugging a powered hub in and the device into that, and then all should be good. On much older kernels, we didn't keep track of the power accounting, and bad things happened at times. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Sat, 8 Sep 2012, [ISO-8859-1] Florian W�hrl wrote: Hello everybody, I am trying to get a USB IO Board running with Debian on Raspberry PI and other 2.6.+ distributions (e.g. Ubuntu 12.04). The board used to run fine with kernel 2.4.+ (e.g. Ubuntu 10.04) - a Device /dev/ttyACM0 was created and usable. But with newer kernels no device is created and dmesg tells: # dmesg [3.391258] usb 1-1.2: new full-speed USB device number 4 using dwc_otg [8.531474] usb 1-1.2: unable to read config index 0 descriptor/start: -32 [8.531510] usb 1-1.2: chopping to 0 config(s) [8.532305] usb 1-1.2: string descriptor 0 read error: -32 The problem seems to be in usbcore, because some descriptors cannot be read (-32/-EPIPE). Actually this looks more like a hardware/firmware/driver problem. Maybe in the device, maybe in your Raspberry PI. Has anybody an idea how to get this running? Does the device work when plugged into a regular desktop system? Have you tested it recently under a 2.4 kernel to make sure that combination still works? Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
Hi Alan, first I have to apologize - it's not kernel version 2.6.+ that's the begin of the problems, it's 3.2.+ - included in Debian wheezy and Ubuntu 12.04. Up to kernel 2.6. it is currently working correct. I first thought it might be the change in the driver - because in the past 04d8:000a was handled by cdc_acm, now the modalias shows ftdi_sio. But I had contact with Oliver Neukum, the maintainer of cdc_acm. He told me to contact this mailing list as he thinks it is a problem in usbcore. The problem seems to be in usbcore, because some descriptors cannot be read (-32/-EPIPE). Actually this looks more like a hardware/firmware/driver problem. Maybe in the device, maybe in your Raspberry PI. The problem doesn't change on different host system hardware but on the kernel / usbcore version. Firmware is on board - it's not uploaded by the driver - afai see. Has anybody an idea how to get this running? Does the device work when plugged into a regular desktop system? Have you tested it recently under a 2.4 kernel to make sure that combination still works? Alan Stern yes, the device is working perfectly under Windows (7) and in Ubuntu 10.04 with kernel 2.6.+. The cdc_acm driver is loaded and a device /dev/ttyACM0 is created. But starting with kernel 3.2.+ - as in Ubuntu 12.04 or Debian Wheezy - the descriptors cannot be read. @greg k-h: Thanks a lot, but it's not a power problem. Is there any further log or information that I can contribute? Best regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ftdi_sio urn failed to clear flow control
Hi, I have three, 4-port USB-to-Serial adapters connected to a Linux system running kernel 3.3.7-1. These three adapters are connected to the system via a USB hub. The application is a DOS app (point of sale system), running in DOSEMU (DOS emulator), that connects directly to these serial devices. This logs below coincide with a lock-up of the production application. We are using software flow control at 38400 baud, we are not using hardware flow control. Sep 8 13:44:54 prod05 kernel: [25716.429799] ftdi_sio ttyUSB11: urb failed to clear flow control Sep 8 13:46:15 prod05 kernel: [25797.281701] ftdi_sio ttyUSB11: ftdi_set_termios FAILED to set databits/stopbits/parity Sep 8 13:46:16 prod05 kernel: [25798.279805] ftdi_sio ttyUSB11: ftdi_set_termios urb failed to set baudrate Sep 8 13:46:21 prod05 kernel: [25803.270534] ftdi_sio ttyUSB11: urb failed to clear flow control More of these messages are repeated for all the serial ports connected to the 3rd adapter (see below). Here is the exact model I'm using. And again, 3 of these connected to a USB hub. http://www.amazon.com/dp/B004EKI4DC/ref=pe_175190_21431760_M2T1_SC_3p_dp_1 This PRO Grade Adapter is build around FT4232H from FTDI Semiconductors which is the best and most reliable Quad Serial to USB processors on the market it also uses ZT232E RS232 transciever from ZyWyn USA. USB cable is 6ft Total Lenght with Port Identificaiton marks on each of the DB9 Male ends. It's worth noting that this setup is not a one-off. I have two production installations of the same size (12 serial ports) and this is the first I've seen of the issue. The two installations may have different model hubs. Lastly, the installation (prod05) that succumbed to this error was running perfectly for 3 days under load - but this Saturday afternoon was the peak of their business and it failed. Bummer. Does anyone know how to prevent this from happening? Caylan Additional errors on ttyUSB8,9,10,11 only: Sep 8 13:44:54 prod05 kernel: [25716.429799] ftdi_sio ttyUSB11: urb failed to clear flow control Sep 8 13:46:15 prod05 kernel: [25797.281701] ftdi_sio ttyUSB11: ftdi_set_termios FAILED to set databits/stopbits/parity Sep 8 13:46:16 prod05 kernel: [25798.279805] ftdi_sio ttyUSB11: ftdi_set_termios urb failed to set baudrate Sep 8 13:46:21 prod05 kernel: [25803.270534] ftdi_sio ttyUSB11: urb failed to clear flow control Sep 8 13:49:02 prod05 kernel: [25964.004184] ftdi_sio ttyUSB8: ftdi_set_termios urb failed to set baudrate Sep 8 13:49:07 prod05 kernel: [25968.994768] ftdi_sio ttyUSB8: urb failed to clear flow control Sep 8 13:49:12 prod05 kernel: [25973.985461] ftdi_sio ttyUSB8: urb failed to clear flow control Sep 8 13:49:17 prod05 kernel: [25978.976051] ftdi_sio ttyUSB8: error from flowcontrol urb Sep 8 13:49:23 prod05 kernel: [25984.964723] ftdi_sio ttyUSB9: ftdi_set_termios urb failed to set baudrate Sep 8 13:49:28 prod05 kernel: [25989.955322] ftdi_sio ttyUSB9: urb failed to clear flow control Sep 8 13:49:33 prod05 kernel: [25994.945924] ftdi_sio ttyUSB9: urb failed to clear flow control Sep 8 13:49:38 prod05 kernel: [25999.936628] ftdi_sio ttyUSB9: error from flowcontrol urb Sep 8 13:49:44 prod05 kernel: [26005.925307] ftdi_sio ttyUSB10: ftdi_set_termios urb failed to set baudrate Sep 8 13:49:49 prod05 kernel: [26010.915876] ftdi_sio ttyUSB10: urb failed to clear flow control Sep 8 13:49:54 prod05 kernel: [26015.907611] ftdi_sio ttyUSB10: urb failed to clear flow control Sep 8 13:49:59 prod05 kernel: [26020.898192] ftdi_sio ttyUSB10: error from flowcontrol urb Sep 8 13:50:05 prod05 kernel: [26026.887885] ftdi_sio ttyUSB11: ftdi_set_termios urb failed to set baudrate Sep 8 13:50:10 prod05 kernel: [26031.878474] ftdi_sio ttyUSB11: urb failed to clear flow control Sep 8 13:50:15 prod05 kernel: [26036.869139] ftdi_sio ttyUSB11: urb failed to clear flow control Sep 8 13:50:20 prod05 kernel: [26041.859745] ftdi_sio ttyUSB11: error from flowcontrol urb Sep 8 13:49:26 prod05 kernel: [26064.438521] ftdi_sio ttyUSB8: ftdi_set_termios FAILED to set databits/stopbits/parity Sep 8 13:49:27 prod05 kernel: [26065.436636] ftdi_sio ttyUSB8: ftdi_set_termios urb failed to set baudrate Sep 8 13:49:37 prod05 kernel: [26075.417924] ftdi_sio ttyUSB8: urb failed to clear flow control Sep 8 13:49:47 prod05 kernel: [26085.399337] ftdi_sio ttyUSB8: urb failed to clear flow control Sep 8 13:49:52 prod05 kernel: [26090.389917] ftdi_sio ttyUSB8: error from flowcontrol urb Sep 8 13:50:03 prod05 kernel: [26101.447300] ftdi_sio ttyUSB9: ftdi_set_termios FAILED to set databits/stopbits/parity Sep 8 13:50:04 prod05 kernel: [26102.445540] ftdi_sio ttyUSB9: ftdi_set_termios urb failed to set baudrate Sep 8 13:50:14 prod05 kernel: [26112.426702] ftdi_sio ttyUSB9: urb failed to clear flow control Sep 8 13:50:24 prod05 kernel: [26122.408004] ftdi_sio ttyUSB9: urb
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Saturday 08 September 2012 15:56:42 Florian Wöhrl wrote: Hi Alan, first I have to apologize - it's not kernel version 2.6.+ that's the begin of the problems, it's 3.2.+ - included in Debian wheezy and Ubuntu 12.04. Up to kernel 2.6. it is currently working correct. It would be good to know which kernel version is the last to work correctly. @greg k-h: Thanks a lot, but it's not a power problem. Is there any further log or information that I can contribute? It would be good to have a usbmon-trace for a working and a failing kernel. Regards Oliver -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
On Sat, 8 Sep 2012, Florian Wöhrl wrote: Hi Alan, first I have to apologize - it's not kernel version 2.6.+ that's the begin of the problems, it's 3.2.+ - included in Debian wheezy and Ubuntu 12.04. Up to kernel 2.6. it is currently working correct. I first thought it might be the change in the driver - because in the past 04d8:000a was handled by cdc_acm, now the modalias shows ftdi_sio. No, that can't be the reason. The problem occurs before the driver is loaded. But I had contact with Oliver Neukum, the maintainer of cdc_acm. He told me to contact this mailing list as he thinks it is a problem in usbcore. I don't think the problem is in the core. Certainly those -71 errors in your usbmon trace are caused by hardware or firmware issues, not by software. The problem seems to be in usbcore, because some descriptors cannot be read (-32/-EPIPE). Actually this looks more like a hardware/firmware/driver problem. Maybe in the device, maybe in your Raspberry PI. The problem doesn't change on different host system hardware but on the kernel / usbcore version. Firmware is on board - it's not uploaded by the driver - afai see. If you're certain that the problem is associated with the kernel version, you could try using git bisect to pinpoint exactly what change to the kernel caused the problem to start. Has anybody an idea how to get this running? Does the device work when plugged into a regular desktop system? Have you tested it recently under a 2.4 kernel to make sure that combination still works? Alan Stern yes, the device is working perfectly under Windows (7) and in Ubuntu 10.04 with kernel 2.6.+. The cdc_acm driver is loaded and a device /dev/ttyACM0 is created. But starting with kernel 3.2.+ - as in Ubuntu 12.04 or Debian Wheezy - the descriptors cannot be read. Do you mean that the descriptors cannot be read when running Ubuntu 12.04 on a desktop system? @greg k-h: Thanks a lot, but it's not a power problem. Is there any further log or information that I can contribute? Can you provide a comparable usbmon trace from a kernel where the device works? Also, to make sure that nothing important has been omitted, please resend the earlier trace without any grep filtering. And do the same with the new trace. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: Conform with checkpatch -3 warnings, 1 error
Removed 3 checkpatch.sh warnings and 1 error in
drivers/usb/gadget/serial.c.
-sizeof brackets x2
-remove initialise to 0
-pr_warning to pr_warn
Signed-off-by: Ben Minerds puzzled...@gmail.com
---
drivers/usb/gadget/serial.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/serial.c b/drivers/usb/gadget/serial.c
index 665c074..af69cd2 100644
--- a/drivers/usb/gadget/serial.c
+++ b/drivers/usb/gadget/serial.c
@@ -101,9 +101,8 @@ static struct usb_device_descriptor device_desc = {
};
static struct usb_otg_descriptor otg_descriptor = {
- .bLength = sizeof otg_descriptor,
+ .bLength = sizeof(otg_descriptor),
.bDescriptorType = USB_DT_OTG,
-
/* REVISIT SRP-only hardware is possible, although
* it would not be called OTG ...
*/
@@ -127,7 +126,7 @@ static bool use_acm = true;
module_param(use_acm, bool, 0);
MODULE_PARM_DESC(use_acm, Use CDC ACM, default=yes);
-static bool use_obex = false;
+static bool use_obex;
module_param(use_obex, bool, 0);
MODULE_PARM_DESC(use_obex, Use CDC OBEX, default=no);
@@ -175,7 +174,7 @@ static int __init gs_bind(struct usb_composite_dev *cdev)
*/
/* device description: manufacturer, product */
- snprintf(manufacturer, sizeof manufacturer, %s %s with %s,
+ snprintf(manufacturer, sizeof(manufacturer), %s %s with %s,
init_utsname()-sysname, init_utsname()-release,
gadget-name);
status = usb_string_id(cdev);
@@ -212,7 +211,7 @@ static int __init gs_bind(struct usb_composite_dev *cdev)
* things like configuration and altsetting numbering
* can need hardware-specific attention though.
*/
- pr_warning(gs_bind: controller '%s' not recognized\n,
+ pr_warn(gs_bind: controller '%s' not recognized\n,
gadget-name);
device_desc.bcdDevice =
cpu_to_le16(GS_VERSION_NUM | 0x0099);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: usbcore / Linux 2.6.+ / USB IO Board 04d8:000a
Hi Alan, Oliver, Am 08.09.2012 18:04, schrieb Alan Stern: If you're certain that the problem is associated with the kernel version, you could try using git bisect to pinpoint exactly what change to the kernel caused the problem to start. Never used git bisect before, but will give it a try. There might be a lot of changes to relevant modules between 2.6 and 3.2 - don't you think? what modules could be relevant in your opinion? Has anybody an idea how to get this running? Does the device work when plugged into a regular desktop system? Have you tested it recently under a 2.4 kernel to make sure that combination still works? Alan Stern yes, the device is working perfectly under Windows (7) and in Ubuntu 10.04 with kernel 2.6.+. The cdc_acm driver is loaded and a device /dev/ttyACM0 is created. But starting with kernel 3.2.+ - as in Ubuntu 12.04 or Debian Wheezy - the descriptors cannot be read. Do you mean that the descriptors cannot be read when running Ubuntu 12.04 on a desktop system? Yes. Connected the Board to a Ubuntu 12.04 x64 Desktop system: # uname -a Linux desktop01 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # dmesg [20012.271332] usb 1-1.2: new full-speed USB device number 3 using ehci_hcd [20017.357551] usb 1-1.2: unable to read config index 0 descriptor/start: -32 [20017.357557] usb 1-1.2: chopping to 0 config(s) [20017.359046] usb 1-1.2: string descriptor 0 read error: -32 [20017.359207] usb 1-1.2: no configuration chosen from 0 choices @greg k-h: Thanks a lot, but it's not a power problem. Is there any further log or information that I can contribute? Can you provide a comparable usbmon trace from a kernel where the device works? Will deliver tomorrow! Also, to make sure that nothing important has been omitted, please resend the earlier trace without any grep filtering. And do the same with the new trace. Ok, will try that. On the RPI there was a lot of traffic going on in that trace as there's an internal USB hub and a USB GPIO onboard. That's why I used grep. Best regards, Florian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
