RE: Chipidea usb otg support for IMX/MXS (device functionality)
Peter, I dunno if you are already aware of it, but the USB peripheral mode hangs on MX233. It's easy to replicate for example if you try to run CDC ethernet over the USB peripheral mode, then telnet into the board and run dmesg . This will trigger a larger data transfer which will make the UDC driver hang. This doesn't happen on MX28 so it must be some MX233-specific thing. Marek, Have you tried below? http://marc.info/?l=linux-usbm=136537318510847w=2 It may not the USB itself problem, the mx23's usb is almost the same with mx28's. Best regards, Peter -- 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
Just can't make USB3 works
Hi Guys, i have a zotac vd01 nano pc that has contains 2 USB 3.0 ports. The problem is that i just cant use those ports without my system hanging. If i try to copy anything to any of my external 3.0 USB disks , the copy starts just fine but after a while the whole system starts to slow down until the point where i can only reboot the system to make it usable again. I just upgraded to linux 3.9.7 vanilla to make it sure this problem was still there. (USB3 debug is enabled) # uname -a Linux zotac 3.9.7-amd64 #1 SMP Sat Jun 22 06:58:00 BRT 2013 x86_64 GNU/Linux when the system starts to slow down i get these messages in /var/log/messages Jun 22 09:51:29 zotac kernel: [ 823.868584] 00 00 00 6b c2 00 00 f0 00 Jun 22 09:51:46 zotac kernel: [ 840.949096] 00 00 01 6d a2 00 00 f0 00 Jun 22 09:52:02 zotac kernel: [ 857.699591] 00 00 02 1f 82 00 00 f0 00 and in /var/log/syslog i get lots of : Jun 22 09:38:00 zotac kernel: [ 11.540175] usb-storage: Attempting to get CSW... Jun 22 09:38:00 zotac kernel: [ 11.540182] usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jun 22 09:38:00 zotac kernel: [ 11.540242] usb-storage: Status code 0; transferred 13/13 Jun 22 09:38:00 zotac kernel: [ 11.540248] usb-storage: -- transfer complete Jun 22 09:38:00 zotac kernel: [ 11.540253] usb-storage: Bulk status result = 0 Jun 22 09:38:00 zotac kernel: [ 11.540261] usb-storage: Bulk Status S 0x53425355 T 0x1c8 R 0 Stat 0x0 Jun 22 09:38:00 zotac kernel: [ 11.540269] usb-storage: scsi cmd done, result=0x0 Jun 22 09:38:00 zotac kernel: [ 11.540278] usb-storage: *** thread sleeping. Jun 22 09:38:00 zotac kernel: [ 11.540338] usb-storage: queuecommand_lck called Jun 22 09:38:00 zotac kernel: [ 11.540353] usb-storage: *** thread awakened. Jun 22 09:38:00 zotac kernel: [ 11.540361] usb-storage: Command READ_10 (10 bytes) Jun 22 09:38:00 zotac kernel: [ 11.540366] usb-storage: 28 00 00 00 03 a8 00 00 08 00 Jun 22 09:38:00 zotac kernel: [ 11.540394] usb-storage: Bulk Command S 0x43425355 T 0x1c9 L 4096 F 128 Trg 0 LUN 1 CL 10 Jun 22 09:38:00 zotac kernel: [ 11.540401] usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jun 22 09:38:00 zotac kernel: [ 11.540492] usb-storage: Status code 0; transferred 31/31 Jun 22 09:38:00 zotac kernel: [ 11.540497] usb-storage: -- transfer complete Jun 22 09:38:00 zotac kernel: [ 11.540502] usb-storage: Bulk command transfer result=0 Jun 22 09:38:00 zotac kernel: [ 11.540510] usb-storage: usb_stor_bulk_transfer_sglist: xfer 4096 bytes, 1 entries ... ... ... Jun 22 09:54:26 zotac kernel: [ 1001.092488] usb-storage: Bulk data transfer result 0x0 Jun 22 09:54:26 zotac kernel: [ 1001.092493] usb-storage: Attempting to get CSW... Jun 22 09:54:26 zotac kernel: [ 1001.092498] usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes Jun 22 09:54:26 zotac kernel: [ 1001.113936] usb-storage: Status code 0; transferred 13/13 Jun 22 09:54:26 zotac kernel: [ 1001.113942] usb-storage: -- transfer complete Jun 22 09:54:26 zotac kernel: [ 1001.113948] usb-storage: Bulk status result = 0 Jun 22 09:54:26 zotac kernel: [ 1001.113954] usb-storage: Bulk Status S 0x53425355 T 0x1671 R 0 Stat 0x0 Jun 22 09:54:26 zotac kernel: [ 1001.113960] usb-storage: scsi cmd done, result=0x0 Jun 22 09:54:26 zotac kernel: [ 1001.113969] usb-storage: *** thread sleeping. Jun 22 09:54:26 zotac kernel: [ 1001.114020] usb-storage: queuecommand_lck called Jun 22 09:54:26 zotac kernel: [ 1001.114043] usb-storage: *** thread awakened. Jun 22 09:54:26 zotac kernel: [ 1001.114049] usb-storage: Command WRITE_10 (10 bytes) Jun 22 09:54:26 zotac kernel: [ 1001.114054] usb-storage: 2a 00 00 09 58 02 00 00 f0 00 Jun 22 09:54:26 zotac kernel: [ 1001.114079] usb-storage: Bulk Command S 0x43425355 T 0x1672 L 122880 F 0 Trg 0 LUN 0 CL 10 Jun 22 09:54:26 zotac kernel: [ 1001.114085] usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes Jun 22 09:54:26 zotac kernel: [ 1001.114115] usb-storage: Status code 0; transferred 31/31 Jun 22 09:54:26 zotac kernel: [ 1001.114120] usb-storage: -- transfer complete Jun 22 09:54:26 zotac kernel: [ 1001.114125] usb-storage: Bulk command transfer result=0 Jun 22 09:54:26 zotac kernel: [ 1001.114131] usb-storage: usb_stor_bulk_transfer_sglist: xfer 122880 bytes, 2 entries # lsusb output Bus 004 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011 Bluetooth (no firmware) Bus 005 Device 002: ID 1a40:0201 Terminus Technology Inc. FE 2.1 7-port Hub Bus 005 Device 003: ID 152d:2339 JMicron Technology Corp. / JMicron USA Technology Corp. JM20339 SATA Bridge Bus 006 Device 002: ID 2109:0811 Bus 007 Device 002: ID 0bc2:2332 Seagate RSS LLC Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID
Re: Chipidea usb otg support for IMX/MXS (device functionality)
Hi Peter, Peter, I dunno if you are already aware of it, but the USB peripheral mode hangs on MX233. It's easy to replicate for example if you try to run CDC ethernet over the USB peripheral mode, then telnet into the board and run dmesg . This will trigger a larger data transfer which will make the UDC driver hang. This doesn't happen on MX28 so it must be some MX233-specific thing. Marek, Have you tried below? http://marc.info/?l=linux-usbm=136537318510847w=2 It may not the USB itself problem, the mx23's usb is almost the same with mx28's. This also happens on a different MX23-based board for me. This other board I tried has mDDR DRAM and the DRAM is operating correctly. The 96MHz thing people complained about in the Olimex forum is resolved now. Best regards, Marek Vasut -- 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
[GIT PATCH] USB fixes for 3.10-rc7
The following changes since commit 7d132055814ef17a6c7b69f342244c410a5e000f: Linux 3.10-rc6 (2013-06-15 11:51:07 -1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-3.10-rc6 for you to fetch changes up to 35a2fbc941accd0e9f1bfadd669311786118d874: USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable (2013-06-19 15:54:45 -0700) USB fixes for 3.10-rc7 Here are two USB patches for 3.10. One updates the Kconfig wording for CONFIG_USB_PHY to make it, hopefully, more obvious what this option is (I know you complained about this when it hit the tree.) The other is a new device id for a driver. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Anders Hammarquist (1): USB: serial: ti_usb_3410_5052: new device id for Abbot strip port cable George Spelvin (1): usb: phy: Improve Kconfig help for CONFIG_USB_PHY drivers/usb/phy/Kconfig | 14 ++ drivers/usb/serial/ti_usb_3410_5052.c | 3 ++- drivers/usb/serial/ti_usb_3410_5052.h | 4 +++- 3 files changed, 15 insertions(+), 6 deletions(-) -- 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: [v2] usb: UHCI: fix pkt size in TD for a non-aligned sg element
On Sat, 22 Jun 2013, Ming Lei wrote: Nonsense. Transfers do not have short packets in the middle, only at the end. If the driver wants to have 1512 bytes in a single transfer then there must be 23 packets of length 64 followed one packet of length 40. If the driver wants to send 15 packets of length 64 followed by one packet of length 40 and 8 more packets of length 64, then it must use two transfers. Denis's patch still can't do what you hope(short packet is at the end of the transfer), can it? What I hope is that we can prevent SIGBUS or other memory access errors. The patch will do that. If we only want to prevent this errors, there should be better approach, IMO. Since you mentioned it doesn't make sense to generate short packet in the middle of transfer, also it may not be what the driver/device expected, I suggest to add a check in usb_submit_urb() for this case and returns failure on it simply, because all HCDs shouldn't support this sort of thing. The check in usb_submit_urb() can avoid unnecessary change in HCD. Any comments on the idea? Wireless USB has some strange features, one of which is that the maxpacket sizes for endpoints can be changed. I'm afraid that adding this check in usb_submit_urb() would not work right for wireless USB. See http://marc.info/?l=linux-usbm=136934531624850w=2 That's why, if the check is checked, I feel it should be added to each HCD driver separately. Maybe I'm wrong. But before doing anything, you should check with Thomas Pugliese. He recently added SG support to the wireless USB driver. 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: [PATCH V2 5/6] USB: OHCI: make ohci-at91 a separate driver
On Sun, 23 Jun 2013, Manjunath Goudar wrote: As a general rule, you should never change code that you don't understand. Do you _know_ that it will be safe to call ohci_setup() or ohci_restart() at this point? From David Brownell comment I am understanding,instead of calling ohci_setup() or ohci_restart(),we can use directly below code. ohci-hc_control = OHCI_CTRL_RWC; ohci_writel (ohci, ohci-hc_control, ohci-regs-control); ohci-rh_state = OHCI_RH_HALTED; Of course you can use that code; that's exactly what ohci_usb_reset() does now. the 3rd line code is written by you,I want to know what exactly it is doing. Is it required here? Yes, it is required. ohci-rh_state stores the current state of the root hub. When the controller is reset, the root hub goes into the HALTED state; this line records that fact. It might be a good idea to get in touch with the person who wrote that routine originally and ask why they used ohci_usb_reset(). yes I will. Hi David, As I understood ohci_usb_reset() is calling for to notice disconnect,reconnect, or wakeup without the 48 MHz clock active. After fix power management hanging(869aa98c) issue by Patrice Vilchez,I think ohci_usb_reset() is not required to call. what is your opinion about this. Sadly, David Brownell died in 2011. I can tell you, though, that commit 869aa98c does not eliminate the need to call ohci_usb_reset(). 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: [PATCH 0/2] *** SUBJECT HERE ***
In a message of Fri, 21 Jun 2013 16:56:03 -0700, Greg KH writes:
Please resend this in a format that I can apply it in (i.e. one that
does not require me to edit it by hand...)
After more fighting with git, I belive I now made it spit out what I
wanted. Patch 1/2 ahead.
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] =
{
+static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] =
{
That's a mess, why have it be a static array at all? Just include an
empty one at the end.
Indeed. I'd already had some (failed) thoughts about how to handle it
nicely. Now I've had another think through, and I have something which
deals with it and at least complains if TI_EXTRA_VID_PID_COUNT is changed
without changing the initializer. Patch 2/2
/Anders
--
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 2/2] Remove static sizing of usb_device_id arrays
Signed-off-by: Anders Hammarquist i...@iko.pp.se
---
drivers/usb/serial/ti_usb_3410_5052.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index 26c1161..441c788 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -60,7 +60,20 @@
#define TI_READ_URB_STOPPED2
#define TI_EXTRA_VID_PID_COUNT 5
-
+#define TI_EXTRA_VID_PID_INITALIZER {0}, {0}, {0}, {0}, {0}
+
+/* Check that TI_EXTRA_VID_PID_COUNT and TI_EXTRA_VID_PID_INITALIZER match.
+ On x86, this wastes one byte of __init space to provide a compile-time
+ error if you do not match up the definitions of TI_EXTRA_VID_PID_COUNT and
+ TI_EXTRA_VID_PID_INITIALIZER. Expect space waste up to sizeof(void *) for
+ other architectures. */
+__init void __ti_extra_vid_pid_test(void)
+{
+ struct { char a; } ti_extra_vid_pid_initializer[] =
+ { TI_EXTRA_VID_PID_INITALIZER };
+ BUILD_BUG_ON(ARRAY_SIZE(ti_extra_vid_pid_initializer) !=
+ TI_EXTRA_VID_PID_COUNT);
+}
/* Structures */
@@ -158,7 +171,7 @@ static unsigned int product_5052_count;
/* the array dimension is the number of default entries plus */
/* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
/* null entry */
-static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -175,16 +188,20 @@ static struct usb_device_id
ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
+ TI_EXTRA_VID_PID_INITALIZER, /* space for run-time VID-PID pairs */
+ {0} /* End of array maker */
};
-static struct usb_device_id ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_5052[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_BOOT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5152_BOOT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_EEPROM_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
+ TI_EXTRA_VID_PID_INITALIZER, /* space for run-time VID-PID pairs */
+ {0} /* End of array maker */
};
-static struct usb_device_id
ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_combined[] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -205,7 +222,9 @@ static struct usb_device_id
ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1]
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
{ USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
- { }
+ TI_EXTRA_VID_PID_INITALIZER, /* space for run-time VID-PID pairs */
+ TI_EXTRA_VID_PID_INITALIZER, /* Two needed, combined 3410 and 5052 */
+ {0} /* End of array maker */
};
static struct usb_serial_driver ti_1port_device = {
--
1.7.10.4
--
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 1/2] * Remove unused and overly generic ABBOTT_PRODUCT_ID * Fix sizes of statically sized usb_debvice_id tables
Signed-off-by: Anders Hammarquist i...@iko.pp.se
---
drivers/usb/serial/ti_usb_3410_5052.c | 11 ++-
drivers/usb/serial/ti_usb_3410_5052.h |5 ++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/ti_usb_3410_5052.c
b/drivers/usb/serial/ti_usb_3410_5052.c
index e581c25..26c1161 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.c
+++ b/drivers/usb/serial/ti_usb_3410_5052.c
@@ -158,7 +158,7 @@ static unsigned int product_5052_count;
/* the array dimension is the number of default entries plus */
/* TI_EXTRA_VID_PID_COUNT user defined entries plus 1 terminating */
/* null entry */
-static struct usb_device_id ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id ti_id_table_3410[16+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -172,8 +172,8 @@ static struct usb_device_id
ti_id_table_3410[15+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
};
@@ -184,7 +184,7 @@ static struct usb_device_id
ti_id_table_5052[5+TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_5052_FIRMWARE_PRODUCT_ID) },
};
-static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1] = {
+static struct usb_device_id
ti_id_table_combined[20+2*TI_EXTRA_VID_PID_COUNT+1] = {
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, TI_3410_EZ430_ID) },
{ USB_DEVICE(MTS_VENDOR_ID, MTS_GSM_NO_FW_PRODUCT_ID) },
@@ -202,7 +202,8 @@ static struct usb_device_id
ti_id_table_combined[19+2*TI_EXTRA_VID_PID_COUNT+1]
{ USB_DEVICE(IBM_VENDOR_ID, IBM_4543_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454B_PRODUCT_ID) },
{ USB_DEVICE(IBM_VENDOR_ID, IBM_454C_PRODUCT_ID) },
- { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STEREO_PLUG_PRODUCT_ID) },
+ { USB_DEVICE(ABBOTT_VENDOR_ID, ABBOTT_STRIP_PORT_PRODUCT_ID) },
{ USB_DEVICE(TI_VENDOR_ID, FRI2_PRODUCT_ID) },
{ }
};
diff --git a/drivers/usb/serial/ti_usb_3410_5052.h
b/drivers/usb/serial/ti_usb_3410_5052.h
index 4a2423e..d3ff470 100644
--- a/drivers/usb/serial/ti_usb_3410_5052.h
+++ b/drivers/usb/serial/ti_usb_3410_5052.h
@@ -52,9 +52,8 @@
/* Abbott Diabetics vendor and product ids */
#define ABBOTT_VENDOR_ID 0x1a61
-#define ABBOTT_STEREO_PLUG_ID 0x3410
-#define ABBOTT_PRODUCT_ID ABBOTT_STEREO_PLUG_ID
-#define ABBOTT_STRIP_PORT_ID 0x3420
+#define ABBOTT_STEREO_PLUG_PRODUCT_ID 0x3410
+#define ABBOTT_STRIP_PORT_PRODUCT_ID 0x3420
/* Commands */
#define TI_GET_VERSION 0x01
--
1.7.10.4
--
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 1/1] usbmisc_imx: allow autoloading on according to dt ids
Allow udev to autoload the module when booting with device-tree
Signed-off-by: Arnaud Patard arnaud.pat...@rtp-net.org
Index: linux/drivers/usb/chipidea/usbmisc_imx.c
===
--- linux.orig/drivers/usb/chipidea/usbmisc_imx.c 2013-05-16
00:46:35.0 +0200
+++ linux/drivers/usb/chipidea/usbmisc_imx.c2013-05-16 09:00:12.0
+0200
@@ -175,6 +175,7 @@ static const struct of_device_id usbmisc
},
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
static int usbmisc_imx_probe(struct platform_device *pdev)
{
--
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: [v2] usb: UHCI: fix pkt size in TD for a non-aligned sg element
On Sun, Jun 23, 2013 at 2:58 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 22 Jun 2013, Ming Lei wrote: Nonsense. Transfers do not have short packets in the middle, only at the end. If the driver wants to have 1512 bytes in a single transfer then there must be 23 packets of length 64 followed one packet of length 40. If the driver wants to send 15 packets of length 64 followed by one packet of length 40 and 8 more packets of length 64, then it must use two transfers. Denis's patch still can't do what you hope(short packet is at the end of the transfer), can it? What I hope is that we can prevent SIGBUS or other memory access errors. The patch will do that. If we only want to prevent this errors, there should be better approach, IMO. Since you mentioned it doesn't make sense to generate short packet in the middle of transfer, also it may not be what the driver/device expected, I suggest to add a check in usb_submit_urb() for this case and returns failure on it simply, because all HCDs shouldn't support this sort of thing. The check in usb_submit_urb() can avoid unnecessary change in HCD. Any comments on the idea? Wireless USB has some strange features, one of which is that the maxpacket sizes for endpoints can be changed. I'm afraid that adding this check in usb_submit_urb() would not work right for wireless USB. See http://marc.info/?l=linux-usbm=136934531624850w=2 From the Thomas's last reply in the discussion, looks the device's maxp need to be set as one value which is divided evenly into 4k, so looks the check might be OK for wireless USB too. That's why, if the check is checked, I feel it should be added to each HCD driver separately. Maybe I'm wrong. But before doing anything, you should check with Thomas Pugliese. He recently added SG support to the wireless USB driver. Suppose wireless USB is one exception, it should the only one, so we can rule it out easily by using hcd-wireless, right? Thanks, -- Ming Lei -- 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: [v2] usb: UHCI: fix pkt size in TD for a non-aligned sg element
Sorry for missing CC On Sun, Jun 23, 2013 at 9:42 AM, Ming Lei tom.leim...@gmail.com wrote: On Sun, Jun 23, 2013 at 2:58 AM, Alan Stern st...@rowland.harvard.edu wrote: On Sat, 22 Jun 2013, Ming Lei wrote: Nonsense. Transfers do not have short packets in the middle, only at the end. If the driver wants to have 1512 bytes in a single transfer then there must be 23 packets of length 64 followed one packet of length 40. If the driver wants to send 15 packets of length 64 followed by one packet of length 40 and 8 more packets of length 64, then it must use two transfers. Denis's patch still can't do what you hope(short packet is at the end of the transfer), can it? What I hope is that we can prevent SIGBUS or other memory access errors. The patch will do that. If we only want to prevent this errors, there should be better approach, IMO. Since you mentioned it doesn't make sense to generate short packet in the middle of transfer, also it may not be what the driver/device expected, I suggest to add a check in usb_submit_urb() for this case and returns failure on it simply, because all HCDs shouldn't support this sort of thing. The check in usb_submit_urb() can avoid unnecessary change in HCD. Any comments on the idea? Wireless USB has some strange features, one of which is that the maxpacket sizes for endpoints can be changed. I'm afraid that adding this check in usb_submit_urb() would not work right for wireless USB. See http://marc.info/?l=linux-usbm=136934531624850w=2 From the Thomas's last reply in the discussion, looks the device's maxp need to be set as one value which is divided evenly into 4k, so looks the check might be OK for wireless USB too. That's why, if the check is checked, I feel it should be added to each HCD driver separately. Maybe I'm wrong. But before doing anything, you should check with Thomas Pugliese. He recently added SG support to the wireless USB driver. Suppose wireless USB is one exception, it should the only one, so we can rule it out easily by using hcd-wireless, right? Thomas, there is one question about sg support on wireless USB: - if one middle sg(not last one in the sg list) which size can't be divided by endpoint's max packet size, can the wireless HCD handle it correctly or support it? From USB 1.1/2.0/3.0 spec, the short packet should be the last packet in one transfer, could you help to clarify the wireless USB HCD behaviour in the case? Because other HCDs can't support it correctly, we plan to add check on the case in usb_submit_urb() to avoid passing this kind of sg list to HCD since Denis reported that test 7 of usbtest may do that and cause SIGBUS (in fact it may cause memory corruption). Thanks, -- Ming Lei -- 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
