RE: [PATCH v3 1/1] USB: EHCI: wait more than 3ms until the device enters full-speed idle
> > > > At my case, the wakeup condition isn't existed before glue layer code > > has run (put the phy enter low power mode). > > > > wakeup condition = bus condition (SE0) + PHY condition (low power mode) > > > > The wakeup condition should not be there, or the system can't enter > > suspend, it is not we expect. If you don't think set > > suspendM and WKDN_E together will not met wakeup condition > > at other systems, we can keep the patch like below, it can work > > for my case. > > Okay, I'll submit this patch. Should I add your "Tested-by"? > I tested your patch manually, it works. You can add my tested-by and reviewed-by if the compile is ok. Peter > > Thanks. > > You're welcome. > > 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
USB disconnect randomly on USB 3.0 port
Hi, The bugreport on Bugzilla is Bug 70361: https://bugzilla.kernel.org/show_bug.cgi?id=70361 I have a Thinkpad OneLink dock, which is a USB dock and has a USB 3.0 hub, a USB 2.0 hub, and ax88179 ethernet. This dock's USB 3.0 hub is disconnected for no reason. This occurs even when the ethernet cable is pulled out from the dock. The port in the following is Bus02-Port 3. $ lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 7: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 8: Dev 4, If 0, Class=Human Interface Device, Driver=wacom, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M |__ Port 3: Dev 38, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 1: Dev 39, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 6, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 7, If 0, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 1: Dev 7, If 1, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 1: Dev 7, If 2, Class=Audio, Driver=snd-usb-audio, 12M |__ Port 1: Dev 7, If 3, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 8, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 9, If 0, Class=Hub, Driver=hub/3p, 480M |__ Port 1: Dev 10, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 4: Dev 17, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 4: Dev 17, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 5: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 6: Dev 5, If 0, Class=Video, Driver=uvcvideo, 480M |__ Port 6: Dev 5, If 1, Class=Video, Driver=uvcvideo, 480M Part of dmesg output: [ +3.072696] xhci_hcd :00:14.0: ep 0x82 - asked for 26624 bytes, 26392 bytes untransferred [ +2.970278] xhci_hcd :00:14.0: ep 0x82 - asked for 26624 bytes, 26392 bytes untransferred [ +3.072701] xhci_hcd :00:14.0: ep 0x82 - asked for 26624 bytes, 26392 bytes untransferred [ +3.072771] xhci_hcd :00:14.0: ep 0x82 - asked for 26624 bytes, 26392 bytes untransferred [ +2.970205] xhci_hcd :00:14.0: ep 0x82 - asked for 26624 bytes, 26392 bytes untransferred [ +3.072695] xhci_hcd :00:14.0: ep 0x82 - asked for 26624 bytes, 26392 bytes untransferred [ +1.739580] xhci_hcd :00:14.0: Port Status Change Event for port 12 [ +0.12] xhci_hcd :00:14.0: handle_port_status: starting port polling. [ +0.84] hub 2-0:1.0: state 7 ports 4 chg evt 0008 [ +0.23] xhci_hcd :00:14.0: get port status, actual port 2 status = 0x4202c0 [ +0.05] xhci_hcd :00:14.0: Get port status returned 0x4102c0 [ +0.78] xhci_hcd :00:14.0: clear port connect change, actual port 2 status = 0x4002c0 [ +0.65] xhci_hcd :00:14.0: clear port link state change, actual port 2 status = 0x2c0 [ +0.34] hub 2-0:1.0: warm reset port 3 [ +0.021287] xhci_hcd :00:14.0: xhci_hub_status_data: stopping port polling. [ +0.029993] xhci_hcd :00:14.0: get port status, actual port 2 status = 0x2d0 [ +0.09] xhci_hcd :00:14.0: Get port status returned 0x2d0 [ +0.68] hub 2-0:1.0: port 3 not warm reset yet, waiting 50ms [ +0.052983] xhci_hcd :00:14.0: Port Status Change Event for port 12 [ +0.12] xhci_hcd :00:14.0: handle_port_status: starting port polling. [ +0.000315] xhci_hcd :00:14.0: get port status, actual port 2 status = 0x2a1203 [ +0.19] xhci_hcd :00:14.0: Get port status returned 0x310203 [ +0.053395] xhci_hcd :00:14.0: clear port reset change, actual port 2 status = 0xa1203 [ +0.82] xhci_hcd :00:14.0: clear port warm(BH) reset change, actual port 2 status = 0x21203 [ +0.72] xhci_hcd :00:14.0: clear port link state change, actual port 2 status = 0x21203 [ +0.72] xhci_hcd :00:14.0: clear port connect change, actual port 2 status = 0x1203 [ +0.72] xhci_hcd :00:14.0: get port status, actual port 2 status = 0x1203 [ +0.08] xhci_hcd :00:14.0: Get port status returned 0x203 [ +0.65] hub 2-0:1.0: port 3, status 02c0, change 0041, 5.0 Gb/s [ +0.12] usb 2-3: USB disconnect, device number 36 [ +0.06] usb 2-3.1: USB disconnect, device number 37 [ +0.04] usb 2-3.1: unregistering device [ +0.05] usb 2-3.1: unregistering interface 2-3.1:1.0 [ +0.000160] usb 2-3.1: Failed to set U1 timeout to 0x0,error code -19 [ +0.07] usb 2-3.1: Hub-initiated U1 disabled at request of driver ax88179_178a [ +0.05] usb 2-3.1: Failed to set U1 timeout to 0xff,error code -19 [ +0.05] usb 2-3.1: Hub-initiated U2 disabled at request of driver ax88179_178a [ +0.04] usb 2-3.1: Failed to set U2 timeout to 0
[PATCH] Fix Default to 'y' for SR9800 Device Driver, setting to 'n'
From: Liu Junliang Signed-off-by: Liu Junliang --- drivers/net/usb/Kconfig |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index 2551bf6..82df7c3 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -295,7 +295,6 @@ config USB_NET_SR9800 tristate "CoreChip-sz SR9800 based USB 2.0 10/100 ethernet devices" depends on USB_USBNET select CRC32 - default y ---help--- Say Y if you want to use one of the following 100Mbps USB Ethernet device based on the CoreChip-sz SR9800 chip. -- 1.7.9.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: Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 DeviceDriver Support
Dear Thierry : For this driver, we can set it as 'n', and There is no rule of thumb as to which should default to y. Thanks for your advice. Thanks again. 2014-02-13 liujunliang_ljl 发件人： Thierry Reding 发送时间： 2014-02-12 18:12:52 收件人： liujunliang_ljl 抄送： davem; horms; joe; romieu; gregkh; netdev; linux-usb; linux-kernel; sunhecheng 主题： Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 DeviceDriver Support On Mon, Feb 10, 2014 at 01:33:39PM +0800, liujunliang_...@163.com wrote: > From: Liu Junliang > > > Signed-off-by: Liu Junliang > --- > drivers/net/usb/Kconfig | 16 + > drivers/net/usb/Makefile |1 + > drivers/net/usb/sr9800.c | 873 > ++ > drivers/net/usb/sr9800.h | 202 +++ > 4 files changed, 1092 insertions(+), 0 deletions(-) > create mode 100644 drivers/net/usb/sr9800.c > create mode 100644 drivers/net/usb/sr9800.h > > diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig > index 47b0f73..2551bf6 100644 > --- a/drivers/net/usb/Kconfig > +++ b/drivers/net/usb/Kconfig > @@ -291,6 +291,22 @@ config USB_NET_SR9700 > This option adds support for CoreChip-sz SR9700 based USB 1.1 > 10/100 Ethernet adapters. > > +config USB_NET_SR9800 > + tristate "CoreChip-sz SR9800 based USB 2.0 10/100 ethernet devices" > + depends on USB_USBNET > + select CRC32 > + default y Why is this selected by default? I can see that some of the other USB network drivers are also selected by default, but not all of them. Is there some rule of thumb as to which should default to y and which shouldn't? Thierry -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJS+0kdAAoJEN0jrNd/PrOhXvwQAJIW4vgv0NkyQVo5jSvzeLY4 9PFCrtd6N1n+O7P99x38JCCD9lWtfdin1EZfj+UicCanup2WzpyBWHeBhdSN4oZA /+C+TgEIuX0+Be11IXeUOGMP9a3k/12HY3oHuz7BA2JjcK6PnfMxaEC7iGGJSjgz q4Goa5kSqjvNgbP8h5bQPTNtMnRdsSytI7PMJbl4t1ho0V7H3pSo9zD7rxaPhmtE v/18VQawGcY83Hr0B0Q18XAnNXaQMLZTvdhVfDUxB5VKT4Xhcri0m4adbAzMI9kR K9CEChkDn68y13drJVILKqUjW+4LMQHAsQV07yl98Sqk7LYOedL9mQOnIL0crjWa OAmLHwLv0ED25W1Hv3UdeSpBdIkO9cD0PCa7vHQnv7lpTlkaDyYelKLQ2D+GXrCw 1L/341ak9QEGiCU1TiOHDblnsN+OtCt0Pt+hijLHFl4TQKw3QIUoZLa4bQuDPM8M juTSV63HRjiDlNGvtjBezlR9GFu5w3SJuNSNsFkZ7ADJwjz9On9JaDwH/Ad7AqmZ ylE+zzbIpOWjyNToMH2dattpeVZkIfGkS02y6PcIx51EGMw5B8l6qKLB9YpkJpwR 7rhMYjpLKIn/6rRGlwmZKYnWYl7p/FdI0yOnVbtMYx406ivUNc+kgvmx5l1mXhT7 b8gKKYYA0pMEMXjgnkK1 =3y7X -END PGP SIGNATURE-
Re: rpi/dwc2 kernel panics
On 02/12/2014 11:52 AM, Andre Heider wrote: > Hi guys, > > I just tried today's Linus' master (45f7fdc2ff) with usb-linus (3635c7e2d5) > merged on top to give the latest dwc2 fixes another try. > Unfortunately I'm getting various crashes on system startup. Kernel boots > fine, dwc2 and the integrated smsc95xx are detected, but somewhere in the > init sequence the system panics. I haven't ever seen crashes like that, when running linux-next. I also merged those two exact commits together and didn't see any issue in 10 boot cycles. FWIW, I am running: * A rev2 Model B * Firmware commit 9c3d7b6 "Add latest linaro gcc toolchain: gcc-linaro-arm-linux-gnueabihf-raspbian-2012.08-20120724_linux" * Upstream U-Boot (very recent) and kernel * Using Ubuntu 13.10's packaged ARM cross-compiler -- 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] staging: usbip: prevent possible buffer overflow reading port records
To avoid buffer overflow while reading a corrupted or possibly
modified port file we validate the length of each part of the port
record to ensure it doesn't exceed the length of the destination
buffer.
https://bugzilla.kernel.org/show_bug.cgi?id=69931
Signed-off-by: Mark Asselstine
---
.../staging/usbip/userspace/libsrc/vhci_driver.c | 51 +++---
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/usbip/userspace/libsrc/vhci_driver.c
b/drivers/staging/usbip/userspace/libsrc/vhci_driver.c
index 209df9b..f4bfefe 100644
--- a/drivers/staging/usbip/userspace/libsrc/vhci_driver.c
+++ b/drivers/staging/usbip/userspace/libsrc/vhci_driver.c
@@ -339,27 +339,67 @@ err:
return -1;
}
-static int read_record(int rhport, char *host, char *port, char *busid)
+/*
+ * Read the given port's record.
+ *
+ * To avoid buffer overflow we will read the entire line and
+ * validate each part's size. The initial buffer is padded by 4 to
+ * accommodate the 2 spaces, 1 newline and an additional character
+ * which is needed to properly validate the 3rd part without it being
+ * truncated to an acceptable length.
+ */
+static int read_record(int rhport, char *host, unsigned long host_len,
+ char *port, unsigned long port_len, char *busid)
+
{
+ int part;
FILE *file;
char path[PATH_MAX+1];
+ char *buffer, *start, *end;
+ char delim[] = {' ', ' ', '\n'};
+ int max_len[] = {(int)host_len, (int)port_len, SYSFS_BUS_ID_SIZE};
+ size_t buffer_len = host_len + port_len + SYSFS_BUS_ID_SIZE + 4;
+
+ buffer = malloc(buffer_len);
+ if (!buffer)
+ return -1;
snprintf(path, PATH_MAX, VHCI_STATE_PATH"/port%d", rhport);
file = fopen(path, "r");
if (!file) {
err("fopen");
+ free(buffer);
return -1;
}
- if (fscanf(file, "%s %s %s\n", host, port, busid) != 3) {
- err("fscanf");
+ if (fgets(buffer, buffer_len, file) == NULL) {
+ err("fgets");
+ free(buffer);
fclose(file);
return -1;
}
-
fclose(file);
+ /* validate the length of each of the 3 parts */
+ start = buffer;
+ for (part = 0; part < 3; part++) {
+ end = strchr(start, delim[part]);
+ if (end == NULL || (end - start) > max_len[part]) {
+ free(buffer);
+ return -1;
+ }
+ start = end + 1;
+ }
+
+ if (sscanf(buffer, "%s %s %s\n", host, port, busid) != 3) {
+ err("sscanf");
+ free(buffer);
+ return -1;
+ }
+
+ free(buffer);
+
return 0;
}
@@ -573,7 +613,8 @@ int usbip_vhci_imported_device_dump(struct
usbip_imported_device *idev)
if (idev->status == VDEV_ST_NULL || idev->status == VDEV_ST_NOTASSIGNED)
return 0;
- ret = read_record(idev->port, host, serv, remote_busid);
+ ret = read_record(idev->port, host, sizeof(host), serv, sizeof(serv),
+ remote_busid);
if (ret) {
err("read_record");
read_record_error = 1;
--
1.8.3.2
--
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: dwc2: fix dereference before NULL check
In a couple of places, we were checking qtd->urb for NULL after
we had already dereferenced it. Fix this by moving the check to
before the dereference.
Signed-off-by: Paul Zimmerman
---
This is not a regression fix, so it should be queued for 3.15.
drivers/usb/dwc2/hcd_intr.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 012f17e..47b9eb5 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -975,8 +975,8 @@ static void dwc2_hc_xfercomp_intr(struct dwc2_hsotg *hsotg,
struct dwc2_qtd *qtd)
{
struct dwc2_hcd_urb *urb = qtd->urb;
- int pipe_type = dwc2_hcd_get_pipe_type(&urb->pipe_info);
enum dwc2_halt_status halt_status = DWC2_HC_XFER_COMPLETE;
+ int pipe_type;
int urb_xfer_done;
if (dbg_hc(chan))
@@ -984,6 +984,11 @@ static void dwc2_hc_xfercomp_intr(struct dwc2_hsotg *hsotg,
"--Host Channel %d Interrupt: Transfer Complete--\n",
chnum);
+ if (!urb)
+ goto handle_xfercomp_done;
+
+ pipe_type = dwc2_hcd_get_pipe_type(&urb->pipe_info);
+
if (hsotg->core_params->dma_desc_enable > 0) {
dwc2_hcd_complete_xfer_ddma(hsotg, chan, chnum, halt_status);
if (pipe_type == USB_ENDPOINT_XFER_ISOC)
@@ -1005,9 +1010,6 @@ static void dwc2_hc_xfercomp_intr(struct dwc2_hsotg
*hsotg,
}
}
- if (!urb)
- goto handle_xfercomp_done;
-
/* Update the QTD and URB states */
switch (pipe_type) {
case USB_ENDPOINT_XFER_CONTROL:
@@ -1105,7 +1107,7 @@ static void dwc2_hc_stall_intr(struct dwc2_hsotg *hsotg,
struct dwc2_qtd *qtd)
{
struct dwc2_hcd_urb *urb = qtd->urb;
- int pipe_type = dwc2_hcd_get_pipe_type(&urb->pipe_info);
+ int pipe_type;
dev_dbg(hsotg->dev, "--Host Channel %d Interrupt: STALL Received--\n",
chnum);
@@ -1119,6 +1121,8 @@ static void dwc2_hc_stall_intr(struct dwc2_hsotg *hsotg,
if (!urb)
goto handle_stall_halt;
+ pipe_type = dwc2_hcd_get_pipe_type(&urb->pipe_info);
+
if (pipe_type == USB_ENDPOINT_XFER_CONTROL)
dwc2_host_complete(hsotg, qtd, -EPIPE);
--
1.8.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
[PATCH] usbnet: remove generic hard_header_len check
This patch removes a generic hard_header_len check from the usbnet
module that is causing dropped packages under certain circumstances
for devices that send rx packets that cross urb boundaries.
One example is the AX88772B which occasionally send rx packets that
cross urb boundaries where the remaining partial packet is sent with
no hardware header. When the buffer with a partial packet is of less
number of octets than the value of hard_header_len the buffer is
discarded by the usbnet module.
With AX88772B this can be reproduced by using ping with a packet
size between 1965-1976.
The bug has been reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=29082
This patch introduces the following changes:
- Removes the generic hard_header_len check in the rx_complete
function in the usbnet module.
- Introduces a ETH_HLEN check for skbs that are not cloned from
within a rx_fixup callback.
- For safety a hard_header_len check is added to each rx_fixup
callback function that could be affected by this change.
These extra checks could possibly be removed by someone
who has the hardware to test.
The changes place full responsibility on the rx_fixup callback
functions that clone skbs to only pass valid skbs to the
usbnet_skb_return function.
Signed-off-by: Emil Goode
Reported-by: Igor Gnatenko
---
An alternative solution is to add the ETH_HLEN check to
usbnet_skb_return() and add short skbs to the skb->done
list to be cleaned up in rx_process().
drivers/net/usb/ax88179_178a.c |4
drivers/net/usb/gl620a.c |4
drivers/net/usb/mcs7830.c |5 +++--
drivers/net/usb/net1080.c |4
drivers/net/usb/qmi_wwan.c |8
drivers/net/usb/rndis_host.c |4
drivers/net/usb/smsc75xx.c |4
drivers/net/usb/smsc95xx.c |4
drivers/net/usb/sr9800.c |4
drivers/net/usb/usbnet.c | 25 ++---
10 files changed, 45 insertions(+), 21 deletions(-)
diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index d6f64da..955df81 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -1118,6 +1118,10 @@ static int ax88179_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
u16 hdr_off;
u32 *pkt_hdr;
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
skb_trim(skb, skb->len - 4);
memcpy(&rx_hdr, skb_tail_pointer(skb), 4);
le32_to_cpus(&rx_hdr);
diff --git a/drivers/net/usb/gl620a.c b/drivers/net/usb/gl620a.c
index e4a8a93..1cc24e6 100644
--- a/drivers/net/usb/gl620a.c
+++ b/drivers/net/usb/gl620a.c
@@ -84,6 +84,10 @@ static int genelink_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
u32 size;
u32 count;
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
header = (struct gl_header *) skb->data;
// get the packet count of the received skb
diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
index a305a7b..82d844a 100644
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -526,8 +526,9 @@ static int mcs7830_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
{
u8 status;
- if (skb->len == 0) {
- dev_err(&dev->udev->dev, "unexpected empty rx frame\n");
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len) {
+ dev_err(&dev->udev->dev, "unexpected tiny rx frame\n");
return 0;
}
diff --git a/drivers/net/usb/net1080.c b/drivers/net/usb/net1080.c
index 0a85d92..4cbdb13 100644
--- a/drivers/net/usb/net1080.c
+++ b/drivers/net/usb/net1080.c
@@ -364,6 +364,10 @@ static int net1080_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
struct nc_trailer *trailer;
u16 hdr_len, packet_len;
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
if (!(skb->len & 0x01)) {
netdev_dbg(dev->net, "rx framesize %d range %d..%d mtu %d\n",
skb->len, dev->net->hard_header_len, dev->hard_mtu,
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index ff5c871..b2e2aee 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -80,10 +80,10 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct
sk_buff *skb)
{
__be16 proto;
- /* usbnet rx_complete guarantees that skb->len is at least
-* hard_header_len, so we can inspect the dest address without
-* checking skb->len
-*/
+ /* This check is no longer done by usbnet */
+ if (skb->len < dev->net->hard_header_len)
+ return 0;
+
swi
Re: MAX3421E Linux driver?
Well, here is a quick-and-dirty proof-of-concept. Warning: it's ugly
and you might go blind. Having said that, the code works well enough
to detect
all USB devices I tried and HID devices as well as USB mass storage
seem to work fine.
I'm not terribly familiar with the details of USB and/or the Linux kernel's
USB implementation so the driver is probably doing a couple of really dumb
things. I marked a couple of places with "XXX" where I'm particularly
interested in feedback.
Also, one thing that seems tricky is NAK-handling: some of the devices we
tested with have large receive buffers and they end up returning NAK for a
long time. So the strategy as implemented is to allow up to 4 NAKs and
after that, it sleeps for 1ms for each NAK. I'm not sure how fancier
OHCDs handle such cases.
--david
On Thu, Jan 30, 2014 at 5:48 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Jan 30, 2014 at 05:34:59PM -0700, David Mosberger wrote:
>> We have a need to graft a USB Host controller onto a SPI bus (never
>> mind the wisdom of doing that, we have little
>> choice in this particular instance).
>>
>> The Cypress CY7C67300 would fit the bill and has a Linux driver, but
>> is probably too complex and definitely
>> too expensive for our needs.
>>
>> The Maxim MAX3421E is the other option, but it has no Linux driver.
>> The chip basically implements OHCI over SPI
>> rather than PCI. Anybody know of any particular reason why there is
>> no Linux driver? Has anyone already written or
>> attempted to write an OHCI-over-SPI driver for MAX3421E?
>
> I don't think anybody has attempted it. If you wanna do it, we're happy
> to review the driver.
>
> cheers
>
> --
> balbi
--
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index f5ed3d7..2e270cc 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_DWC3)+= dwc3/
obj-$(CONFIG_USB_MON) += mon/
obj-$(CONFIG_PCI) += host/
+obj-$(CONFIG_USB_MAX3421_HCD) += host/
obj-$(CONFIG_USB_EHCI_HCD) += host/
obj-$(CONFIG_USB_ISP116X_HCD) += host/
obj-$(CONFIG_USB_OHCI_HCD) += host/
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d6bb128..5b226de 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -4,6 +4,16 @@
comment "USB Host Controller Drivers"
depends on USB
+config USB_MAX3421_HCD
+ tristate "MAX3421 HCD (USB-over-SPI) support"
+ depends on USB
+ help
+ The Maxim MAX3421E Host Controller Interface supports
+standard USB 1.1 high-speed hardware.
+
+ To compile this driver as a module, choose M here: the module will
+be called max3421.
+
config USB_C67X00_HCD
tristate "Cypress C67x00 HCD support"
depends on USB
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 1eb4c30..1dfb836 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -23,6 +23,8 @@ obj-$(CONFIG_USB_WHCI_HCD)+= whci/
obj-$(CONFIG_PCI) += pci-quirks.o
+obj-$(CONFIG_USB_MAX3421_HCD) += max3421.o
+
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
obj-$(CONFIG_USB_EHCI_HCD_PLATFORM)+= ehci-platform.o
diff --git a/drivers/usb/host/max3421.c b/drivers/usb/host/max3421.c
new file mode 100644
index 000..61df0e6
--- /dev/null
+++ b/drivers/usb/host/max3421.c
@@ -0,0 +1,1406 @@
+/*
+ * MAX3421 Host Controller driver for USB.
+ *
+ * Maintainer: David Mosberger-Tang
+ *
+ * (C) Copyright 2014 David Mosberger-Tang
+ *
+ * MAX3421 is a chip implementing a USB 2.0 Full-/Low-Speed host
+ * controller on a SPI bus.
+ *
+ * Based on:
+ * o MAX3421E datasheet
+ * http://datasheets.maximintegrated.com/en/ds/MAX3421E.pdf
+ * o MAX3421E Programming Guide
+ * http://www.hdl.co.jp/ftpdata/utl-001/AN3785.pdf
+ * o gadget/dummy_hcd.c
+ * For USB HCD implementation.
+ * o Arduino MAX3421 driver
+ * https://github.com/felis/USB_Host_Shield_2.0/blob/master/Usb.cpp
+ *
+ * This file is licenced under the GPL.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_DESC"MAX3421 USB Host-Controller Driver"
+#define DRIVER_VERSION "0.0"
+
+#define POWER_BUDGET 500 // in mA; use 8 for low-power port testing
+
+// Port-change mask:
+#define PORT_C_MASK((USB_PORT_STAT_C_CONNECTION | \
+ USB_PORT_STAT_C_ENABLE | \
+ USB_PORT_STAT_C_SUSPEND | \
+ USB_PORT_STAT_C_OVERCURRENT | \
+ USB_PORT_STAT_C_RESET) << 16)
+
+enum max3421_rh_state {
+ MAX3421_RH_RESET,
+ MAX3421_RH_SUSPENDED,
+ MAX3421_RH_RUNNING
+};
+
+struct max3421_hcd {
+ spinlock_t lock;
+
+ struct max3421_hcd *next;
+
+
Re: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
On Wed, 12 Feb 2014, Stefani Seibold wrote:
> > > > >> Okay, the debugging info in your dmesg log indicates the cause of the
> > > > >> problem. It looks like the bug is related to commit 88ed9fd50e57
> > > > >> (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker.
For the benefit of people who haven't seen the log, here is the
important part:
[3.431781] [ INFO: inconsistent lock state ]
[3.431784] 3.13.2 #4 Not tainted
[3.431786] -
[3.431788] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[3.431792] swapper/3/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[3.431794] (&(&ehci->lock)->rlock){?.-...}, at: []
ehci_hrtimer_func+0x21/0xc0
[3.431805] {HARDIRQ-ON-W} state was registered at:
[3.431807] [] __lock_acquire+0x590/0x1bb0
[3.431813] [] lock_acquire+0x7e/0x110
[3.431818] [] _raw_spin_lock+0x3f/0x50
[3.431833] [] ehci_irq+0x27/0x3d0
[3.431835] [] usb_hcd_irq+0x21/0x30
[3.431839] [] irq_forced_thread_fn+0x26/0x50
[3.431842] [] irq_thread+0xfe/0x130
[3.431844] [] kthread+0x9b/0xb0
This says that ehci->lock was acquired by ehci_irq() with interrupts
enabled. Then later on, ehci_hrtimer_func() acquired the same lock
with interrupts disabled. This caused the lockdep violation (and it
eventually caused the system to hang).
The thing is, ehci_irq() is a non-threaded IRQ handler. It's _never_
supposed to run with interrupts enabled. As far as I can see, this
happened because irq_forced_thread_fn() did not disable interrupts
before calling the handler routine.
> > > > >> (Note: As far as I can tell, the commit itself is okay, but it
> > > > >> exposes
> > > > >> a bug somewhere else in the kernel.)
> > > > >>
> > > > >> If you revert that commit from 3.13, does it fix the problem?
> > > > >>
> > > > > Reverting the commit 88ed9fd50e57 solve the problem. Thank you so
> > > > > much.
> > > > Oops, I'll try to reproduce and investigate. Thanks for the
> > > > investigations!!!
> > > >
> > >
> > > I think the problem has maybe to do with the threadirqs kernel
> > > parameter.
> >
> > I don't think threaded irqs work very well with USB, can you try turning
> > that off and seeing if the issue goes away?
There's no reason in principle why the USB stack shouldn't work with
threaded IRQs, as far as I know.
> I use threaded irqs since more than two years without any problem. It
> works with OHCI, UHCI, EHCI and XHCI.
>
> This was the first time that an problem occurred.
I have no idea what might have changed between 3.12 and 3.13 to cause
this problem. Maybe Thomas can figure it out.
> And yes, the issues goes away when no thread irqs are used (with and
> without the patch).
Thomas, there must be some reason why the patch below is wrong, but I
don't know enough about the IRQ subsystem to tell what's really going
on. Can you explain it?
Alan Stern
Index: usb-3.14/kernel/irq/manage.c
===
--- usb-3.14.orig/kernel/irq/manage.c
+++ usb-3.14/kernel/irq/manage.c
@@ -777,9 +777,12 @@ static irqreturn_t
irq_forced_thread_fn(struct irq_desc *desc, struct irqaction *action)
{
irqreturn_t ret;
+ unsigned long flags;
local_bh_disable();
+ local_irq_save(flags);
ret = action->thread_fn(action->irq, action->dev_id);
+ local_irq_restore(flags);
irq_finalize_oneshot(desc, action);
local_bh_enable();
return ret;
--
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] usbhid/quirks: Ignore Riso Kagaku Webmail Notifier
The "Webmail Notifier" is a USB controlled LED that appears as a HID
device. When trying to change the LED via hidraw it returns malformed
reports. As "usbled" supports it, we blacklist it in usbhid.
Signed-off-by: Christian Vogel
---
drivers/hid/hid-core.c | 1 +
drivers/hid/hid-ids.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 253fe23..6888b49 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2273,6 +2273,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP,
USB_DEVICE_ID_1_PHIDGETSERVO_20) },
{ HID_USB_DEVICE(USB_VENDOR_ID_WISEGROUP, USB_DEVICE_ID_8_8_4_IF_KIT) },
{ HID_USB_DEVICE(USB_VENDOR_ID_YEALINK,
USB_DEVICE_ID_YEALINK_P1K_P4K_B2K) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_RISO_KAGAKU,
USB_DEVICE_ID_RI_KA_WEBMAIL) },
{ }
};
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index f9304cb..d936a9d 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -942,4 +942,7 @@
#define USB_VENDOR_ID_SIS 0x0457
#define USB_DEVICE_ID_SIS_TS 0x1013
+#define USB_VENDOR_ID_RISO_KAGAKU 0x1294 /* Riso Kagaku Corp. */
+#define USB_DEVICE_ID_RI_KA_WEBMAIL0x1320 /* Webmail Notifier */
+
#endif
--
1.8.5.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
Updated patch to blacklist the Riso Kagaku Webmail Notifier
Updated patch, moved blacklisted vid/pid from usbhid/hid-quirks.c's hid_blacklist to hid-core.c's hid_ignore_list as proposed by Greg KH. It's supposed to suppress binding of usbhid to a "USB connected LED" supported by usbled. It isn't useful as a input device and produces kernel complaints about bad hid reports when used via hidraw anyway. -- 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
rpi/dwc2 kernel panics
Hi guys, I just tried today's Linus' master (45f7fdc2ff) with usb-linus (3635c7e2d5) merged on top to give the latest dwc2 fixes another try. Unfortunately I'm getting various crashes on system startup. Kernel boots fine, dwc2 and the integrated smsc95xx are detected, but somewhere in the init sequence the system panics. Hard to say when exactly, but it looks like it's happening upon setting up the usb ethernet adapter (with dhcp in my case). It doesn't crash on every boot, maybe 3 in 10 times. And it doesn't seem to crash when booting with "nousb", at least not so far. Do the traces below ring any bell? Thanks, Andre [4.299074] Unable to handle kernel paging request at virtual address e313002c [4.311206] pgd = d7a4c000 [4.318606] [e313002c] *pgd= [4.326872] Internal error: Oops: 5 [#1] ARM [4.335802] CPU: 0 PID: 41 Comm: systemd-cgroups Not tainted 3.14.0-rc2-rpi+ #33 [4.347972] task: d7a24000 ti: d7a1e000 task.ti: d7a1e000 [4.358101] PC is at inode_permission+0x18/0x54 [4.367294] LR is at unix_find_other+0x54/0x1c0 [4.376423] pc : []lr : []psr: 2013 [4.376423] sp : d7a1fe80 ip : d7a1fe90 fp : d7a1fe8c [4.397063] r10: r9 : d7a1e000 r8 : c04fc488 [4.406784] r7 : d7a1ff04 r6 : 0002 r5 : e3130010 r4 : [4.417816] r3 : c00e6c60 r2 : 0004 r1 : 0002 r0 : e3130010 [4.428785] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [4.440448] Control: 00c5387d Table: 17a4c008 DAC: 0015 [4.450734] Process systemd-cgroups (pid: 41, stack limit = 0xd7a1e1b8) [4.461869] Stack: (0xd7a1fe80 to 0xd7a2) [4.470656] fe80: d7a1febc d7a1fe90 c033c1c0 c00e4674 d79fbb40 c02b9d50 c00e538c c00e6c60 [4.483433] fea0: c033d80c d79fbb40 d7558580 001e d7a1fef4 d7a1fec0 c033e904 c033c178 [4.496224] fec0: c000ea24 d7a1fecc c000ea24 001e 001d d7558580 001d c04dc00c [4.509034] fee0: bead9c84 c000ea24 d7a1ffa4 d7a1fef8 c02b7c74 c033e86c d79fbb40 [4.521849] ff00: 722f0001 732f6e75 65747379 6a2f646d 6e72756f 732f6c61 656b636f [4.534715] ff20: c00d0074 c00f4314 fff7 d7a1ff78 d7a1ff7c d7a1ff54 2b00f9de [4.547651] ff40: c00f4314 0001 0004 d7558580 0007 bead9c60 d7a1e000 [4.560624] ff60: d7a1ffa4 d7a1ff70 c02b8118 c02bb9b4 0004 d7a1ff80 [4.573643] ff80: c01df21c 2b00f9de bead9c86 b6f86f10 00016010 011b d7a1ffa8 [4.586697] ffa0: c000e800 c02b7c00 bead9c86 b6f86f10 bead9c84 001d [4.599704] ffc0: bead9c86 b6f86f10 00016010 011b b6f87000 [4.612690] ffe0: bead9c7c a1c4 b6ea07ac 4010 17ffd821 17ffdc21 [4.625747] [] (inode_permission) from [] (unix_find_other+0x54/0x1c0) [4.638971] [] (unix_find_other) from [] (unix_dgram_connect+0xa4/0x1e0) [4.652398] [] (unix_dgram_connect) from [] (SyS_connect+0x80/0xbc) [4.665441] [] (SyS_connect) from [] (ret_fast_syscall+0x0/0x30) [4.678194] Code: e24cb004 e52de004 e8bd4000 e3110002 (e590201c) [4.689255] ---[ end trace 4cdca67b25fe5ac6 ]--- note the corrupt process name on this one: [9.242673] Unable to handle kernel paging request at virtual address e313002c [9.254126] pgd = d7b38000 [9.260862] [e313002c] *pgd= [9.268450] Internal error: Oops: 5 [#1] ARM [9.276689] CPU: 0 PID: 154 Comm: (ystemctl) Not tainted 3.14.0-rc2-rpi+ #33 [9.287829] task: d7b3eec0 ti: d604 task.ti: d604 [9.297317] PC is at inode_permission+0x18/0x54 [9.305991] LR is at unix_find_other+0x54/0x1c0 [9.314686] pc : []lr : []psr: 2013 [9.314686] sp : d6041e68 ip : d6041e78 fp : d6041e74 [9.334610] r10: r9 : 001e r8 : d759b2c0 [9.344132] r7 : 7fff r6 : 0001 r5 : e3130010 r4 : [9.355028] r3 : c00e6c60 r2 : 0004 r1 : 0002 r0 : e3130010 [9.365886] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [9.377401] Control: 00c5387d Table: 17b38008 DAC: 0015 [9.387548] Process (ystemctl) (pid: 154, stack limit = 0xd60401b8) [9.398222] Stack: (0xd6041e68 to 0xd6042000) [9.406954] 1e60: d6041ea4 d6041e78 c033c1c0 c00e4674 7fff d759b2c0 [9.419738] 1e80: c00e538c c00e6c60 c02ba5f4 d7ae2000 d7ae2d20 d7a40300 d6041ef4 d6041ea8 [9.432623] 1ea0: c033db90 c033c178 c04dc00c d6041ec4 c04fc488 d6041efc d6041f04 001d [9.445525] 1ec0: c04dc00c fff4 c000ea24 d759b2c0 001d c04dc00c beda2404 c000ea24 [9.458411] 1ee0: d604 d6041fa4 d6041ef8 c02b7c74 c033daa4 d6041f24 [9.471280] 1f00: 722f0001 732f6e75 65747379 6a2f646d 6e72756f 732f6c61 756f6474 [9.484200] 1f20: c00d0074 c00dd310 c04dce60 d759b2c0 d759b2c0 d6041f7c d6041f48 [9.497087] 1f40: c02b69c0 c00dd430 d780d470 d76433b8
Re: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Mittwoch, den 12.02.2014, 08:28 -0800 schrieb Greg KH: > On Wed, Feb 12, 2014 at 05:20:10PM +0100, Stefani Seibold wrote: > > Am Mittwoch, den 12.02.2014, 16:57 +0100 schrieb Michael Opdenacker: > > > On 02/12/2014 04:47 PM, Stefani Seibold wrote: > > > > Am Mittwoch, den 12.02.2014, 10:37 -0500 schrieb Alan Stern: > > > >> On Wed, 12 Feb 2014, Stefani Seibold wrote: > > > >> > > > >>> Hi, > > > >>> > > > >>> Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: > > > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > > > > >>> I have more information about the bug. I tested with a USB 3.0 > > > >>> Expresscard and this works with 3.13. > > > >>> > > > >>> I also found an old USB 1.1 HUB in my USB gadget box. When i > > > >>> attach the > > > >>> USB flash storage to the USB 1.1 hub there is also no problem. > > > >>> > > > >>> Since the USB 1.1 Hub is attached to the EHCI we can assume that > > > >>> the bug > > > >>> is not in the phy support nor in the USB storage driver. > > > >>> > > > >>> So i thing the bug must be located in the EHCI HC driver. > > > >> Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG > > > >> enabled? > > > >> Maybe some debugging information will show up in the dmesg log and > > > >> provide a clue. > > > >> > > > > I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB > > > > Debug > > > > after the computer freeze. > > > Did anything show up before the freeze? > > > > > > > After a minute i get the attached output. Sorry i was only able to > > > > do screen > > > > shot. > > > It looks like something locked ehci->lock and then never unlocked > > > it. > > > But from the screen shot, I can't tell where this happened. > > > > > > >>> I was able to get the whole kernel messages via netconsole. I also had > > > >>> enable CONFIG_USB_DEBUG and all kinds of lock detection. > > > >>> > > > >>> > > > >>> When i attach the USB flash memory (sdc), the system freeze and the > > > >>> fan's of the machine will get noisy. So i think the CPU is 100 % in > > > >>> use. > > > >>> > > > >>> I attach the dmesg output and the current kernel config. > > > >>> > > > Also, I tried to reproduce this failure on my own computer, using > > > 3.14-rc1, but everything worked correctly. > > > > > > >>> I will try the 3.14 kernel... But it makes me crazy when a bug > > > >>> disappears without an explanation. > > > >> Okay, the debugging info in your dmesg log indicates the cause of the > > > >> problem. It looks like the bug is related to commit 88ed9fd50e57 > > > >> (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. > > > >> > > > >> (Note: As far as I can tell, the commit itself is okay, but it exposes > > > >> a bug somewhere else in the kernel.) > > > >> > > > >> If you revert that commit from 3.13, does it fix the problem? > > > >> > > > > Reverting the commit 88ed9fd50e57 solve the problem. Thank you so much. > > > Oops, I'll try to reproduce and investigate. Thanks for the > > > investigations!!! > > > > > > > I think the problem has maybe to do with the threadirqs kernel > > parameter. > > I don't think threaded irqs work very well with USB, can you try turning > that off and seeing if the issue goes away? > I use threaded irqs since more than two years without any problem. It works with OHCI, UHCI, EHCI and XHCI. This was the first time that an problem occurred. And yes, the issues goes away when no thread irqs are used (with and without the patch). - Stefani -- 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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
On Wed, Feb 12, 2014 at 05:20:10PM +0100, Stefani Seibold wrote: > Am Mittwoch, den 12.02.2014, 16:57 +0100 schrieb Michael Opdenacker: > > On 02/12/2014 04:47 PM, Stefani Seibold wrote: > > > Am Mittwoch, den 12.02.2014, 10:37 -0500 schrieb Alan Stern: > > >> On Wed, 12 Feb 2014, Stefani Seibold wrote: > > >> > > >>> Hi, > > >>> > > >>> Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: > > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > > >>> I have more information about the bug. I tested with a USB 3.0 > > >>> Expresscard and this works with 3.13. > > >>> > > >>> I also found an old USB 1.1 HUB in my USB gadget box. When i attach > > >>> the > > >>> USB flash storage to the USB 1.1 hub there is also no problem. > > >>> > > >>> Since the USB 1.1 Hub is attached to the EHCI we can assume that > > >>> the bug > > >>> is not in the phy support nor in the USB storage driver. > > >>> > > >>> So i thing the bug must be located in the EHCI HC driver. > > >> Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG > > >> enabled? > > >> Maybe some debugging information will show up in the dmesg log and > > >> provide a clue. > > >> > > > I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB > > > Debug > > > after the computer freeze. > > Did anything show up before the freeze? > > > > > After a minute i get the attached output. Sorry i was only able to do > > > screen > > > shot. > > It looks like something locked ehci->lock and then never unlocked it. > > But from the screen shot, I can't tell where this happened. > > > > >>> I was able to get the whole kernel messages via netconsole. I also had > > >>> enable CONFIG_USB_DEBUG and all kinds of lock detection. > > >>> > > >>> > > >>> When i attach the USB flash memory (sdc), the system freeze and the > > >>> fan's of the machine will get noisy. So i think the CPU is 100 % in use. > > >>> > > >>> I attach the dmesg output and the current kernel config. > > >>> > > Also, I tried to reproduce this failure on my own computer, using > > 3.14-rc1, but everything worked correctly. > > > > >>> I will try the 3.14 kernel... But it makes me crazy when a bug > > >>> disappears without an explanation. > > >> Okay, the debugging info in your dmesg log indicates the cause of the > > >> problem. It looks like the bug is related to commit 88ed9fd50e57 > > >> (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. > > >> > > >> (Note: As far as I can tell, the commit itself is okay, but it exposes > > >> a bug somewhere else in the kernel.) > > >> > > >> If you revert that commit from 3.13, does it fix the problem? > > >> > > > Reverting the commit 88ed9fd50e57 solve the problem. Thank you so much. > > Oops, I'll try to reproduce and investigate. Thanks for the > > investigations!!! > > > > I think the problem has maybe to do with the threadirqs kernel > parameter. I don't think threaded irqs work very well with USB, can you try turning that off and seeing if the issue goes away? thanks, 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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Mittwoch, den 12.02.2014, 16:57 +0100 schrieb Michael Opdenacker: > On 02/12/2014 04:47 PM, Stefani Seibold wrote: > > Am Mittwoch, den 12.02.2014, 10:37 -0500 schrieb Alan Stern: > >> On Wed, 12 Feb 2014, Stefani Seibold wrote: > >> > >>> Hi, > >>> > >>> Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > >>> I have more information about the bug. I tested with a USB 3.0 > >>> Expresscard and this works with 3.13. > >>> > >>> I also found an old USB 1.1 HUB in my USB gadget box. When i attach > >>> the > >>> USB flash storage to the USB 1.1 hub there is also no problem. > >>> > >>> Since the USB 1.1 Hub is attached to the EHCI we can assume that the > >>> bug > >>> is not in the phy support nor in the USB storage driver. > >>> > >>> So i thing the bug must be located in the EHCI HC driver. > >> Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG > >> enabled? > >> Maybe some debugging information will show up in the dmesg log and > >> provide a clue. > >> > > I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB > > Debug > > after the computer freeze. > Did anything show up before the freeze? > > > After a minute i get the attached output. Sorry i was only able to do > > screen > > shot. > It looks like something locked ehci->lock and then never unlocked it. > But from the screen shot, I can't tell where this happened. > > >>> I was able to get the whole kernel messages via netconsole. I also had > >>> enable CONFIG_USB_DEBUG and all kinds of lock detection. > >>> > >>> > >>> When i attach the USB flash memory (sdc), the system freeze and the > >>> fan's of the machine will get noisy. So i think the CPU is 100 % in use. > >>> > >>> I attach the dmesg output and the current kernel config. > >>> > Also, I tried to reproduce this failure on my own computer, using > 3.14-rc1, but everything worked correctly. > > >>> I will try the 3.14 kernel... But it makes me crazy when a bug > >>> disappears without an explanation. > >> Okay, the debugging info in your dmesg log indicates the cause of the > >> problem. It looks like the bug is related to commit 88ed9fd50e57 > >> (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. > >> > >> (Note: As far as I can tell, the commit itself is okay, but it exposes > >> a bug somewhere else in the kernel.) > >> > >> If you revert that commit from 3.13, does it fix the problem? > >> > > Reverting the commit 88ed9fd50e57 solve the problem. Thank you so much. > Oops, I'll try to reproduce and investigate. Thanks for the > investigations!!! > I think the problem has maybe to do with the threadirqs kernel parameter. - Stefani -- 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 1 of 1]: musb: fixed a potential NULL pointer dereference.
On Wed, Feb 12, 2014 at 04:35:12PM +0100, Dr. H. Nikolaus Schaller wrote: > > Am 12.02.2014 um 15:29 schrieb Greg Kroah-Hartman: > > > On Wed, Feb 12, 2014 at 11:08:22AM +0100, Dr. H. Nikolaus Schaller wrote: > >> fixed a potential NULL pointer dereference. > >> > >>Rationale: > >>this is the only location in the musb driver where the > >>otg->gadget pointer is dereferenced. Assuming that it > >>is never NULL is not only potentially unsafe but was > >>observed in the wild on a GTA04 (OMAP3/TPS65950 based > >>board) when trying to boot a device tree based 3.14-rc2 > >>kernel with USB cable plugged in. > >> > >>DT boot appears to modify the order in which components > >>(gadget driver) are loaded and linked and therefore > >>an early musb interrupt triggers with a NULL gadget > >>pointer ending in a kernel panic. > >> > >>Since a non-existing gadget can never be "active" we > >>simply use a 0 value for musb->is_active. > >> > >>Signed-off-by: H. Nikolaus Schaller > > > > Please don't attach patches, our tools don't like them at all. > > Sorry. That was by accident. Here is the patch appended. That's better, but we need a "clean" patch to be able to apply it for real :) > > And shouldn't we fix the root problem here, not just gloss over the fact > > that this pointer is NULL at this point in time? Fixing the real issue > > should be the correct solution, right? > > Well, > I must admit that I have no idea what the root cause could be > (because I neither know the musb nor the gadget subsystems) > or if it is intended and just something in the initialization > sequence has changed. > > I have done one more test and it appears to be in a non-device-tree > 3.14-rc1 as well. We did not see it in a 3.12.7 kernel on the same hardware. Ah, can you run 'git bisect' to track down the real problem here? We don't like papering over problems like this, that doesn't help anyone out. thanks, 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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
On 02/12/2014 04:47 PM, Stefani Seibold wrote: > Am Mittwoch, den 12.02.2014, 10:37 -0500 schrieb Alan Stern: >> On Wed, 12 Feb 2014, Stefani Seibold wrote: >> >>> Hi, >>> >>> Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: On Mon, 10 Feb 2014, Stefani Seibold wrote: >>> I have more information about the bug. I tested with a USB 3.0 >>> Expresscard and this works with 3.13. >>> >>> I also found an old USB 1.1 HUB in my USB gadget box. When i attach the >>> USB flash storage to the USB 1.1 hub there is also no problem. >>> >>> Since the USB 1.1 Hub is attached to the EHCI we can assume that the bug >>> is not in the phy support nor in the USB storage driver. >>> >>> So i thing the bug must be located in the EHCI HC driver. >> Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG enabled? >> Maybe some debugging information will show up in the dmesg log and >> provide a clue. >> > I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB Debug > after the computer freeze. Did anything show up before the freeze? > After a minute i get the attached output. Sorry i was only able to do > screen > shot. It looks like something locked ehci->lock and then never unlocked it. But from the screen shot, I can't tell where this happened. >>> I was able to get the whole kernel messages via netconsole. I also had >>> enable CONFIG_USB_DEBUG and all kinds of lock detection. >>> >>> >>> When i attach the USB flash memory (sdc), the system freeze and the >>> fan's of the machine will get noisy. So i think the CPU is 100 % in use. >>> >>> I attach the dmesg output and the current kernel config. >>> Also, I tried to reproduce this failure on my own computer, using 3.14-rc1, but everything worked correctly. >>> I will try the 3.14 kernel... But it makes me crazy when a bug >>> disappears without an explanation. >> Okay, the debugging info in your dmesg log indicates the cause of the >> problem. It looks like the bug is related to commit 88ed9fd50e57 >> (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. >> >> (Note: As far as I can tell, the commit itself is okay, but it exposes >> a bug somewhere else in the kernel.) >> >> If you revert that commit from 3.13, does it fix the problem? >> > Reverting the commit 88ed9fd50e57 solve the problem. Thank you so much. Oops, I'll try to reproduce and investigate. Thanks for the investigations!!! Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 -- 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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
Am Mittwoch, den 12.02.2014, 10:37 -0500 schrieb Alan Stern: > On Wed, 12 Feb 2014, Stefani Seibold wrote: > > > Hi, > > > > Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: > > > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > > > > > > > I have more information about the bug. I tested with a USB 3.0 > > > > > > Expresscard and this works with 3.13. > > > > > > > > > > > > I also found an old USB 1.1 HUB in my USB gadget box. When i attach > > > > > > the > > > > > > USB flash storage to the USB 1.1 hub there is also no problem. > > > > > > > > > > > > Since the USB 1.1 Hub is attached to the EHCI we can assume that > > > > > > the bug > > > > > > is not in the phy support nor in the USB storage driver. > > > > > > > > > > > > So i thing the bug must be located in the EHCI HC driver. > > > > > > > > > > Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG > > > > > enabled? > > > > > Maybe some debugging information will show up in the dmesg log and > > > > > provide a clue. > > > > > > > > > > > > > I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB > > > > Debug > > > > after the computer freeze. > > > > > > Did anything show up before the freeze? > > > > > > > After a minute i get the attached output. Sorry i was only able to do > > > > screen > > > > shot. > > > > > > It looks like something locked ehci->lock and then never unlocked it. > > > But from the screen shot, I can't tell where this happened. > > > > > > > I was able to get the whole kernel messages via netconsole. I also had > > enable CONFIG_USB_DEBUG and all kinds of lock detection. > > > > > > When i attach the USB flash memory (sdc), the system freeze and the > > fan's of the machine will get noisy. So i think the CPU is 100 % in use. > > > > I attach the dmesg output and the current kernel config. > > > > > Also, I tried to reproduce this failure on my own computer, using > > > 3.14-rc1, but everything worked correctly. > > > > > > > I will try the 3.14 kernel... But it makes me crazy when a bug > > disappears without an explanation. > > Okay, the debugging info in your dmesg log indicates the cause of the > problem. It looks like the bug is related to commit 88ed9fd50e57 > (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. > > (Note: As far as I can tell, the commit itself is okay, but it exposes > a bug somewhere else in the kernel.) > > If you revert that commit from 3.13, does it fix the problem? > Reverting the commit 88ed9fd50e57 solve the problem. Thank you so much. - Stefani -- 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: USB storage vanilla kernel 3.13 hang on DELL PRECISION M6400
On Wed, 12 Feb 2014, Stefani Seibold wrote: > Hi, > > Am Dienstag, den 11.02.2014, 11:30 -0500 schrieb Alan Stern: > > On Mon, 10 Feb 2014, Stefani Seibold wrote: > > > > > > > I have more information about the bug. I tested with a USB 3.0 > > > > > Expresscard and this works with 3.13. > > > > > > > > > > I also found an old USB 1.1 HUB in my USB gadget box. When i attach > > > > > the > > > > > USB flash storage to the USB 1.1 hub there is also no problem. > > > > > > > > > > Since the USB 1.1 Hub is attached to the EHCI we can assume that the > > > > > bug > > > > > is not in the phy support nor in the USB storage driver. > > > > > > > > > > So i thing the bug must be located in the EHCI HC driver. > > > > > > > > Yes, it probably is. Can you build 3.13 with CONFIG_USB_DEBUG enabled? > > > > > > > > Maybe some debugging information will show up in the dmesg log and > > > > provide a clue. > > > > > > > > > > I tried the kernel with CONFIG_USB_DEBUG, but i did not get any USB Debug > > > after the computer freeze. > > > > Did anything show up before the freeze? > > > > > After a minute i get the attached output. Sorry i was only able to do > > > screen > > > shot. > > > > It looks like something locked ehci->lock and then never unlocked it. > > But from the screen shot, I can't tell where this happened. > > > > I was able to get the whole kernel messages via netconsole. I also had > enable CONFIG_USB_DEBUG and all kinds of lock detection. > > > When i attach the USB flash memory (sdc), the system freeze and the > fan's of the machine will get noisy. So i think the CPU is 100 % in use. > > I attach the dmesg output and the current kernel config. > > > Also, I tried to reproduce this failure on my own computer, using > > 3.14-rc1, but everything worked correctly. > > > > I will try the 3.14 kernel... But it makes me crazy when a bug > disappears without an explanation. Okay, the debugging info in your dmesg log indicates the cause of the problem. It looks like the bug is related to commit 88ed9fd50e57 (usb/hcd: remove unnecessary local_irq_save) by Michael Opdenacker. (Note: As far as I can tell, the commit itself is okay, but it exposes a bug somewhere else in the kernel.) If you revert that commit from 3.13, does it fix the problem? 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 1 of 1]: musb: fixed a potential NULL pointer dereference.
Am 12.02.2014 um 15:29 schrieb Greg Kroah-Hartman:
> On Wed, Feb 12, 2014 at 11:08:22AM +0100, Dr. H. Nikolaus Schaller wrote:
>> fixed a potential NULL pointer dereference.
>>
>>Rationale:
>>this is the only location in the musb driver where the
>>otg->gadget pointer is dereferenced. Assuming that it
>>is never NULL is not only potentially unsafe but was
>>observed in the wild on a GTA04 (OMAP3/TPS65950 based
>>board) when trying to boot a device tree based 3.14-rc2
>>kernel with USB cable plugged in.
>>
>>DT boot appears to modify the order in which components
>>(gadget driver) are loaded and linked and therefore
>>an early musb interrupt triggers with a NULL gadget
>>pointer ending in a kernel panic.
>>
>>Since a non-existing gadget can never be "active" we
>>simply use a 0 value for musb->is_active.
>>
>>Signed-off-by: H. Nikolaus Schaller
>
> Please don't attach patches, our tools don't like them at all.
Sorry. That was by accident. Here is the patch appended.
>
> And shouldn't we fix the root problem here, not just gloss over the fact
> that this pointer is NULL at this point in time? Fixing the real issue
> should be the correct solution, right?
Well,
I must admit that I have no idea what the root cause could be
(because I neither know the musb nor the gadget subsystems)
or if it is intended and just something in the initialization
sequence has changed.
I have done one more test and it appears to be in a non-device-tree
3.14-rc1 as well. We did not see it in a 3.12.7 kernel on the same hardware.
>
> thanks,
>
> greg k-h
BR,
Nikolaus Schaller
---
drivers/usb/musb/musb_core.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index df3f65d..f68afef 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -653,7 +653,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
int_usb,
break;
case OTG_STATE_B_PERIPHERAL:
musb_g_suspend(musb);
- musb->is_active = otg->gadget->b_hnp_enable;
+ musb->is_active =
+ otg->gadget ? otg->gadget->b_hnp_enable : 0;
if (musb->is_active) {
musb->xceiv->state = OTG_STATE_B_WAIT_ACON;
dev_dbg(musb->controller, "HNP: Setting timer
for b_ase0_brst\n");
--
1.7.7.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
Re: [PATCH] net: qmi_wwan: add support for Cinterion PXS8 and PHS8
Aleksander Morgado writes: > When the PXS8 and PHS8 devices show up with PID 0x0053 they will expose both a > QMI port and a WWAN interface. > > CC: Hans-Christoph Schemmel > CC: Christian Schmiedl > CC: Nicolaus Colberg > CC: David McCullough > Signed-off-by: Aleksander Morgado Acked-by: Bjørn Mork -- 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 v3 1/1] USB: EHCI: wait more than 3ms until the device enters full-speed idle
On Wed, 12 Feb 2014, Peter Chen wrote: > > In your case, the wakeup condition will be present while the bus uses > > high-speed terminations, but when the bus switches over to full-speed > > idle the wakeup condition will go away. Thus, I assume the wakeup > > signal will turn off after a few milliseconds, instead of remaining on > > indefinitely. > > At my case, the wakeup condition isn't existed before glue layer code > has run (put the phy enter low power mode). > > wakeup condition = bus condition (SE0) + PHY condition (low power mode) > > The wakeup condition should not be there, or the system can't enter > suspend, it is not we expect. If you don't think set > suspendM and WKDN_E together will not met wakeup condition > at other systems, we can keep the patch like below, it can work > for my case. Okay, I'll submit this patch. Should I add your "Tested-by"? > Thanks. You're welcome. 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: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8
This interface is to be handled by the qmi_wwan driver.
CC: Hans-Christoph Schemmel
CC: Christian Schmiedl
CC: Nicolaus Colberg
CC: David McCullough
Signed-off-by: Aleksander Morgado
---
drivers/usb/serial/option.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 5c86f57..604948b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1525,7 +1525,8 @@ static const struct usb_device_id option_ids[] = {
/* Cinterion */
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_E) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_EU3_P) },
- { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PH8) },
+ { USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PH8),
+ .driver_info = (kernel_ulong_t)&net_intf4_blacklist },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_AHXX) },
{ USB_DEVICE(CINTERION_VENDOR_ID, CINTERION_PRODUCT_PLXX),
.driver_info = (kernel_ulong_t)&net_intf4_blacklist },
--
1.8.5.3
--
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 2/2] ehci-platform: Change compatible string from usb-ehci to ehci-platform
On Tue, Feb 11, 2014 at 04:26:16PM +0100, Hans de Goede wrote: > > I'm even OK with removing "usb-ehci" and "usb-ohci" compatibles > > from all OMAP dts files since they aren't really compatible with > > the original PPC driver. > > I don't think that is necessary, as your grep has shown there are a > lot of dts files using compatible = "foo", "usb-?hci"; and some may > even have the dts in firmware, so we should simply make sure not to > break such dts. For these devices, we can't do much, but at least for the DT that are in Linux, relying on the fact that there is no driver having a compatible of "usb-ehci" to work looks very fragile. I'd be in favour of removing it from the OMAP DTs, and every affected DTs. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH] net: qmi_wwan: add support for Cinterion PXS8 and PHS8
When the PXS8 and PHS8 devices show up with PID 0x0053 they will expose both a
QMI port and a WWAN interface.
CC: Hans-Christoph Schemmel
CC: Christian Schmiedl
CC: Nicolaus Colberg
CC: David McCullough
Signed-off-by: Aleksander Morgado
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index ff5c871..1eddd43 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -732,6 +732,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1bc7, 0x1201, 2)},/* Telit LE920 */
{QMI_FIXED_INTF(0x0b3c, 0xc005, 6)},/* Olivetti Olicard 200 */
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)},/* Cinterion PLxx */
+ {QMI_FIXED_INTF(0x1e2d, 0x0053, 4)},/* Cinterion PHxx,PXxx */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},/* Acer Gobi Modem Device */
--
1.8.5.3
--
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 1 of 1]: musb: fixed a potential NULL pointer dereference.
On Wed, Feb 12, 2014 at 11:08:22AM +0100, Dr. H. Nikolaus Schaller wrote: > fixed a potential NULL pointer dereference. > > Rationale: > this is the only location in the musb driver where the > otg->gadget pointer is dereferenced. Assuming that it > is never NULL is not only potentially unsafe but was > observed in the wild on a GTA04 (OMAP3/TPS65950 based > board) when trying to boot a device tree based 3.14-rc2 > kernel with USB cable plugged in. > > DT boot appears to modify the order in which components > (gadget driver) are loaded and linked and therefore > an early musb interrupt triggers with a NULL gadget > pointer ending in a kernel panic. > > Since a non-existing gadget can never be "active" we > simply use a 0 value for musb->is_active. > > Signed-off-by: H. Nikolaus Schaller Please don't attach patches, our tools don't like them at all. And shouldn't we fix the root problem here, not just gloss over the fact that this pointer is NULL at this point in time? Fixing the real issue should be the correct solution, right? thanks, 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
[PATCH RESEND] usb: at91-udc: fix irq and iomem resource retrieval
From: Jean-Jacques Hiblot
When using dt resources retrieval (interrupts and reg properties) there is
no predefined order for these resources in the platform dev resource
table. Also don't expect the number of resource to be always 2.
Signed-off-by: Jean-Jacques Hiblot
Acked-by: Boris BREZILLON
Acked-by: Nicolas Ferre
Cc: stable # 3.4
---
drivers/usb/gadget/at91_udc.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/usb/gadget/at91_udc.c b/drivers/usb/gadget/at91_udc.c
index cea8c20a1425..1926925a52a9 100644
--- a/drivers/usb/gadget/at91_udc.c
+++ b/drivers/usb/gadget/at91_udc.c
@@ -1709,16 +1709,6 @@ static int at91udc_probe(struct platform_device *pdev)
return -ENODEV;
}
- if (pdev->num_resources != 2) {
- DBG("invalid num_resources\n");
- return -ENODEV;
- }
- if ((pdev->resource[0].flags != IORESOURCE_MEM)
- || (pdev->resource[1].flags != IORESOURCE_IRQ)) {
- DBG("invalid resource type\n");
- return -ENODEV;
- }
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENXIO;
--
1.8.2.2
--
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 v7 00/12] USB Host support for OMAP5 uEVM
Hi Benoit, Tony & Lee, This patchset brings up USB Host ports and Ethernet port on the OMAP5 uEVM board. Please queue these for -next. Tested on: - OMAP5 uEVM - Pandaboard ES Rev. B1 - Beagleboard-XM Rev C2 - Beagleboard Rev C4. Changelog: v7: - Rebased on 3.14-rc2 - Removed incompatible ids from DT files and examples v6: - Initialized clocks to -ENODEV and split patch 3. v5: - Expose all clocks in the DT binding document for mfd:omap-usb-host and mfd:omap-usb-tll v4: - Updated DT binding document for clock binding v3: - Rebased on top of 3.13-rc7 cheers, -roger -- Roger Quadros (12): mfd: omap-usb-host: Use resource managed clk_get() mfd: omap-usb-host: Get clocks based on hardware revision mfd: omap-usb-host: Use clock names as per function for reference clocks mfd: omap-usb-host: Update DT clock binding information mfd: omap-usb-tll: Update DT clock binding information ARM: dts: omap4: Update omap-usb-host node ARM: dts: omap5: Update omap-usb-host node ARM: dts: omap4-panda: Provide USB PHY clock ARM: dts: omap5-uevm: Provide USB PHY clock ARM: OMAP2+: Remove legacy_init_ehci_clk() ARM: dts: OMAP2+: Get rid of incompatible ids for USB host nodes usb: omap: dts: Update DT binding example usage .../devicetree/bindings/mfd/omap-usb-host.txt | 23 +++ .../devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++ .../devicetree/bindings/usb/ehci-omap.txt | 2 +- .../devicetree/bindings/usb/ohci-omap3.txt | 2 +- arch/arm/boot/dts/omap3.dtsi | 4 +- arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +- arch/arm/boot/dts/omap4.dtsi | 10 +- arch/arm/boot/dts/omap5-uevm.dts | 8 +- arch/arm/boot/dts/omap5.dtsi | 10 +- arch/arm/mach-omap2/pdata-quirks.c | 16 -- drivers/mfd/omap-usb-host.c| 171 ++--- 11 files changed, 136 insertions(+), 128 deletions(-) -- 1.8.3.2 -- 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 v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 60a3bed..ce620a8 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
+ omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
if (IS_ERR(omap->xclk60mhsp1_ck)) {
ret = PTR_ERR(omap->xclk60mhsp1_ck);
dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
goto err_mem;
}
- omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
+ omap->xclk60mhsp2_ck = devm_clk_get(dev, "refclk_60m_ext_p2");
if (IS_ERR(omap->xclk60mhsp2_ck)) {
ret = PTR_ERR(omap->xclk60mhsp2_ck);
dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
goto err_mem;
}
- omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
+ omap->init_60m_fclk = devm_clk_get(dev, "refclk_60m_int");
if (IS_ERR(omap->init_60m_fclk)) {
ret = PTR_ERR(omap->init_60m_fclk);
dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
--
1.8.3.2
--
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 v7 02/12] mfd: omap-usb-host: Get clocks based on hardware revision
Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.
This should avoid un-necessary clk_get failure messages that were
observed earlier.
Be more strict and always fail on clk_get() error.
CC: Lee Jones
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
drivers/mfd/omap-usb-host.c | 92 +++--
1 file changed, 64 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0c3c9a0..60a3bed 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -665,22 +665,41 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap->ehci_logic_fck = omap->init_60m_fclk = ERR_PTR(-ENODEV);
+ omap->utmi_p1_gfclk = omap->utmi_p2_gfclk = ERR_PTR(-ENODEV);
+ omap->xclk60mhsp1_ck = omap->xclk60mhsp2_ck = ERR_PTR(-ENODEV);
+
for (i = 0; i < omap->nports; i++) {
- if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
- is_ehci_hsic_mode(i))
- need_logic_fck |= true;
+ omap->utmi_clk[i] = ERR_PTR(-ENODEV);
+ omap->hsic480m_clk[i] = ERR_PTR(-ENODEV);
+ omap->hsic60m_clk[i] = ERR_PTR(-ENODEV);
}
- omap->ehci_logic_fck = ERR_PTR(-EINVAL);
- if (need_logic_fck) {
- omap->ehci_logic_fck = devm_clk_get(dev, "ehci_logic_fck");
- if (IS_ERR(omap->ehci_logic_fck)) {
- ret = PTR_ERR(omap->ehci_logic_fck);
- dev_dbg(dev, "ehci_logic_fck failed:%d\n", ret);
+ /* for OMAP3 i.e. USBHS REV1 */
+ if (omap->usbhs_rev == OMAP_USBHS_REV1) {
+ need_logic_fck = false;
+ for (i = 0; i < omap->nports; i++) {
+ if (is_ehci_phy_mode(pdata->port_mode[i]) ||
+ is_ehci_tll_mode(pdata->port_mode[i]) ||
+ is_ehci_hsic_mode(pdata->port_mode[i]))
+
+ need_logic_fck |= true;
+ }
+
+ if (need_logic_fck) {
+ omap->ehci_logic_fck = clk_get(dev, "usbhost_120m_fck");
+ if (IS_ERR(omap->ehci_logic_fck)) {
+ ret = PTR_ERR(omap->ehci_logic_fck);
+ dev_err(dev, "usbhost_120m_fck failed:%d\n",
+ ret);
+ goto err_mem;
+ }
}
+ goto initialize;
}
+ /* for OMAP4+ i.e. USBHS REV2+ */
omap->utmi_p1_gfclk = devm_clk_get(dev, "utmi_p1_gfclk");
if (IS_ERR(omap->utmi_p1_gfclk)) {
ret = PTR_ERR(omap->utmi_p1_gfclk);
@@ -728,54 +747,71 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* them
*/
omap->utmi_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->utmi_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->utmi_clk[i]));
+ if (IS_ERR(omap->utmi_clk[i])) {
+ ret = PTR_ERR(omap->utmi_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic480m_p%d_clk", i + 1);
omap->hsic480m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->hsic480m_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->hsic480m_clk[i]));
+ if (IS_ERR(omap->hsic480m_clk[i])) {
+ ret = PTR_ERR(omap->hsic480m_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic60m_p%d_clk", i + 1);
omap->hsic60m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->hsic60m_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->hsic60m_clk[i]));
+ if (IS_ERR(omap->hsic60m_clk[i])) {
+ ret = PTR_ERR(omap->hsic60m_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
}
if (is_ehci_phy_mode(pdata->p
[PATCH v7 01/12] mfd: omap-usb-host: Use resource managed clk_get()
Use devm_clk_get() instead of clk_get().
CC: Lee Jones
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
Acked-by: Lee Jones
---
drivers/mfd/omap-usb-host.c | 81 +
1 file changed, 16 insertions(+), 65 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 90b630c..0c3c9a0 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -674,46 +674,46 @@ static int usbhs_omap_probe(struct platform_device *pdev)
omap->ehci_logic_fck = ERR_PTR(-EINVAL);
if (need_logic_fck) {
- omap->ehci_logic_fck = clk_get(dev, "ehci_logic_fck");
+ omap->ehci_logic_fck = devm_clk_get(dev, "ehci_logic_fck");
if (IS_ERR(omap->ehci_logic_fck)) {
ret = PTR_ERR(omap->ehci_logic_fck);
dev_dbg(dev, "ehci_logic_fck failed:%d\n", ret);
}
}
- omap->utmi_p1_gfclk = clk_get(dev, "utmi_p1_gfclk");
+ omap->utmi_p1_gfclk = devm_clk_get(dev, "utmi_p1_gfclk");
if (IS_ERR(omap->utmi_p1_gfclk)) {
ret = PTR_ERR(omap->utmi_p1_gfclk);
dev_err(dev, "utmi_p1_gfclk failed error:%d\n", ret);
- goto err_p1_gfclk;
+ goto err_mem;
}
- omap->utmi_p2_gfclk = clk_get(dev, "utmi_p2_gfclk");
+ omap->utmi_p2_gfclk = devm_clk_get(dev, "utmi_p2_gfclk");
if (IS_ERR(omap->utmi_p2_gfclk)) {
ret = PTR_ERR(omap->utmi_p2_gfclk);
dev_err(dev, "utmi_p2_gfclk failed error:%d\n", ret);
- goto err_p2_gfclk;
+ goto err_mem;
}
- omap->xclk60mhsp1_ck = clk_get(dev, "xclk60mhsp1_ck");
+ omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
if (IS_ERR(omap->xclk60mhsp1_ck)) {
ret = PTR_ERR(omap->xclk60mhsp1_ck);
dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
- goto err_xclk60mhsp1;
+ goto err_mem;
}
- omap->xclk60mhsp2_ck = clk_get(dev, "xclk60mhsp2_ck");
+ omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
if (IS_ERR(omap->xclk60mhsp2_ck)) {
ret = PTR_ERR(omap->xclk60mhsp2_ck);
dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
- goto err_xclk60mhsp2;
+ goto err_mem;
}
- omap->init_60m_fclk = clk_get(dev, "init_60m_fclk");
+ omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
if (IS_ERR(omap->init_60m_fclk)) {
ret = PTR_ERR(omap->init_60m_fclk);
dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
- goto err_init60m;
+ goto err_mem;
}
for (i = 0; i < omap->nports; i++) {
@@ -727,21 +727,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* platforms have all clocks and we can function without
* them
*/
- omap->utmi_clk[i] = clk_get(dev, clkname);
+ omap->utmi_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap->utmi_clk[i]))
dev_dbg(dev, "Failed to get clock : %s : %ld\n",
clkname, PTR_ERR(omap->utmi_clk[i]));
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic480m_p%d_clk", i + 1);
- omap->hsic480m_clk[i] = clk_get(dev, clkname);
+ omap->hsic480m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap->hsic480m_clk[i]))
dev_dbg(dev, "Failed to get clock : %s : %ld\n",
clkname, PTR_ERR(omap->hsic480m_clk[i]));
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic60m_p%d_clk", i + 1);
- omap->hsic60m_clk[i] = clk_get(dev, clkname);
+ omap->hsic60m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap->hsic60m_clk[i]))
dev_dbg(dev, "Failed to get clock : %s : %ld\n",
clkname, PTR_ERR(omap->hsic60m_clk[i]));
@@ -784,7 +784,7 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "Failed to create DT children: %d\n", ret);
- goto err_alloc;
+ goto err_mem;
}
} else {
@@ -792,40 +792,12 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "omap_usbhs_alloc_children failed: %d\n",
ret);
- goto err_alloc;
+ goto err_mem;
}
}
return 0;
-err_alloc:
- for (i = 0; i < omap->nports; i
[PATCH v7 04/12] mfd: omap-usb-host: Update DT clock binding information
The omap-usb-host driver expects certained named clocks. Add this information to the DT binding document. CC: Lee Jones CC: Samuel Ortiz Signed-off-by: Roger Quadros --- .../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++ 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa6..4721b2d 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,29 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1 +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + +- clock-names: should include: + For OMAP3 + * "usbhost_120m_fck" - 120MHz Functional clock. + + For OMAP4+ + * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux + * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux. + * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux + * "utmi_p1_gfclk" - Port 1 UTMI clock mux. + * "utmi_p2_gfclk" - Port 2 UTMI clock mux. + * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate. + * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate. + * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate. + * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate. + * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate. + * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate. + Required properties if child node exists: - #address-cells: Must be 1 -- 1.8.3.2 -- 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 v7 05/12] mfd: omap-usb-tll: Update DT clock binding information
The omap-usb-tll driver needs one clock for each TLL channel.
Add this information to the DT binding document.
CC: Lee Jones
CC: Samuel Ortiz
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
index 62fe697..c58d704 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -7,6 +7,16 @@ Required properties:
- interrupts : should contain the TLL module's interrupt
- ti,hwmod : must contain "usb_tll_hs"
+Optional properties:
+
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+
+- clock-names: should include:
+ * "usb_tll_hs_usb_ch0_clk" - USB TLL channel 0 clock
+ * "usb_tll_hs_usb_ch1_clk" - USB TLL channel 1 clock
+ * "usb_tll_hs_usb_ch2_clk" - USB TLL channel 2 clock
+
Example:
usbhstll: usbhstll@4a062000 {
--
1.8.3.2
--
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 v7 06/12] ARM: dts: omap4: Update omap-usb-host node
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap4.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..39a05ce 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -697,6 +697,12 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ clocks = <&init_60m_fclk>,
+<&xclk60mhsp1_ck>,
+<&xclk60mhsp2_ck>;
+ clock-names = "refclk_60m_int",
+ "refclk_60m_ext_p1",
+ "refclk_60m_ext_p2";
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
--
1.8.3.2
--
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 v7 07/12] ARM: dts: omap5: Update omap-usb-host node
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..d4dae48 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -775,6 +775,12 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ clocks = <&l3init_60m_fclk>,
+<&xclk60mhsp1_ck>,
+<&xclk60mhsp2_ck>;
+ clock-names = "refclk_60m_int",
+ "refclk_60m_ext_p1",
+ "refclk_60m_ext_p2";
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
--
1.8.3.2
--
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 v7 11/12] ARM: dts: OMAP2+: Get rid of incompatible ids for USB host nodes
The OMAP EHCI and OHCI controllers are not compatible with drivers
other than "ti,ehci-omap" and "ti,ohci-omap3" respectively, so get
rid of the incompatible ids.
CC: Alan Stern
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap3.dtsi | 4 ++--
arch/arm/boot/dts/omap4.dtsi | 4 ++--
arch/arm/boot/dts/omap5.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..8e7de9e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -634,14 +634,14 @@
ranges;
usbhsohci: ohci@48064400 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x48064400 0x400>;
interrupt-parent = <&intc>;
interrupts = <76>;
};
usbhsehci: ehci@48064800 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x48064800 0x400>;
interrupt-parent = <&intc>;
interrupts = <77>;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 39a05ce..ff1b057 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -705,14 +705,14 @@
"refclk_60m_ext_p2";
usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupt-parent = <&gic>;
interrupts = ;
};
usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
interrupt-parent = <&gic>;
interrupts = ;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index d4dae48..f65aa65 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -783,14 +783,14 @@
"refclk_60m_ext_p2";
usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupt-parent = <&gic>;
interrupts = ;
};
usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
interrupt-parent = <&gic>;
interrupts = ;
--
1.8.3.2
--
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 v7 08/12] ARM: dts: omap4-panda: Provide USB PHY clock
The USB PHY gets its clock from AUXCLK3. Provide this information. Signed-off-by: Roger Quadros --- arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi index 88c6a05..50b72966 100644 --- a/arch/arm/boot/dts/omap4-panda-common.dtsi +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi @@ -83,12 +83,8 @@ compatible = "usb-nop-xceiv"; reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>; /* gpio_62 */ vcc-supply = <&hsusb1_power>; - /** -* FIXME: -* put the right clock phandle here when available -* clocks = <&auxclk3>; -* clock-names = "main_clk"; -*/ + clocks = <&auxclk3_ck>; + clock-names = "main_clk"; clock-frequency = <1920>; }; -- 1.8.3.2 -- 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 v7 10/12] ARM: OMAP2+: Remove legacy_init_ehci_clk()
The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.
Signed-off-by: Roger Quadros
---
arch/arm/mach-omap2/pdata-quirks.c | 16
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..f1ecd86 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -31,20 +31,6 @@ struct pdata_init {
struct of_dev_auxdata omap_auxdata_lookup[];
static struct twl4030_gpio_platform_data twl_gpio_auxdata;
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init __used legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias("main_clk", NULL, clkname, NULL);
- if (ret)
- pr_err("%s:Failed to add main_clk alias to %s :%d\n",
- __func__, clkname, ret);
-}
-
#if IS_ENABLED(CONFIG_WL12XX)
static struct wl12xx_platform_data wl12xx __initdata;
@@ -182,7 +168,6 @@ static void __init omap4_sdp_legacy_init(void)
static void __init omap4_panda_legacy_init(void)
{
omap4_panda_display_init_of();
- legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
#endif
@@ -190,7 +175,6 @@ static void __init omap4_panda_legacy_init(void)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_uevm_legacy_init(void)
{
- legacy_init_ehci_clk("auxclk1_ck");
}
#endif
--
1.8.3.2
--
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 v7 12/12] usb: omap: dts: Update DT binding example usage
Remove non-compatible id from examples.
CC: Alan Stern
Signed-off-by: Roger Quadros
---
Documentation/devicetree/bindings/usb/ehci-omap.txt | 2 +-
Documentation/devicetree/bindings/usb/ohci-omap3.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt
b/Documentation/devicetree/bindings/usb/ehci-omap.txt
index 485a9a1..3dc231c 100644
--- a/Documentation/devicetree/bindings/usb/ehci-omap.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-omap.txt
@@ -21,7 +21,7 @@ Documentation/devicetree/bindings/mfd/omap-usb-host.txt
Example for OMAP4:
usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
interrupts = <0 77 0x4>;
};
diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt
b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
index 14ab428..ce8c47cff 100644
--- a/Documentation/devicetree/bindings/usb/ohci-omap3.txt
+++ b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
@@ -9,7 +9,7 @@ Required properties:
Example for OMAP4:
usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupts = <0 76 0x4>;
};
--
1.8.3.2
--
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 v7 09/12] ARM: dts: omap5-uevm: Provide USB PHY clock
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros
---
arch/arm/boot/dts/omap5-uevm.dts | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70..3b99ec2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,12 +31,8 @@
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio3 16 GPIO_ACTIVE_LOW>; /* gpio3_80
HUB_NRESET */
- /**
- * FIXME
- * Put the right clock phandle here when available
- * clocks = <&auxclk1>;
- * clock-names = "main_clk";
- */
+ clocks = <&auxclk1_ck>;
+ clock-names = "main_clk";
clock-frequency = <1920>;
};
--
1.8.3.2
--
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 of 1]: musb: fixed a potential NULL pointer dereference.
fixed a potential NULL pointer dereference. Rationale: this is the only location in the musb driver where the otg->gadget pointer is dereferenced. Assuming that it is never NULL is not only potentially unsafe but was observed in the wild on a GTA04 (OMAP3/TPS65950 based board) when trying to boot a device tree based 3.14-rc2 kernel with USB cable plugged in. DT boot appears to modify the order in which components (gadget driver) are loaded and linked and therefore an early musb interrupt triggers with a NULL gadget pointer ending in a kernel panic. Since a non-existing gadget can never be "active" we simply use a 0 value for musb->is_active. Signed-off-by: H. Nikolaus Schaller 0001-fixed-a-potential-NULL-pointer-dereference.patch Description: Binary data
Re: [PATCH] USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support
On Mon, Feb 10, 2014 at 01:33:39PM +0800, liujunliang_...@163.com wrote: > From: Liu Junliang > > > Signed-off-by: Liu Junliang > --- > drivers/net/usb/Kconfig | 16 + > drivers/net/usb/Makefile |1 + > drivers/net/usb/sr9800.c | 873 > ++ > drivers/net/usb/sr9800.h | 202 +++ > 4 files changed, 1092 insertions(+), 0 deletions(-) > create mode 100644 drivers/net/usb/sr9800.c > create mode 100644 drivers/net/usb/sr9800.h > > diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig > index 47b0f73..2551bf6 100644 > --- a/drivers/net/usb/Kconfig > +++ b/drivers/net/usb/Kconfig > @@ -291,6 +291,22 @@ config USB_NET_SR9700 > This option adds support for CoreChip-sz SR9700 based USB 1.1 > 10/100 Ethernet adapters. > > +config USB_NET_SR9800 > + tristate "CoreChip-sz SR9800 based USB 2.0 10/100 ethernet devices" > + depends on USB_USBNET > + select CRC32 > + default y Why is this selected by default? I can see that some of the other USB network drivers are also selected by default, but not all of them. Is there some rule of thumb as to which should default to y and which shouldn't? Thierry pgpLkbJA6W7a4.pgp Description: PGP signature
Cash Awaiting Pick Up..
This is to re-notify you that you have $500,000.00 waiting for pick-up at Money Gram, Contact Mrs Hillary Florence via email : heritd...@xtra.co.nz for claims. -- 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 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
On Wednesday 29 January 2014 08:17 PM, Heikki Krogerus wrote: > Hi, > > On Tue, Jan 28, 2014 at 10:30:36AM -0600, Felipe Balbi wrote: >> On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote: >>> On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote: >>> For the controller drivers the PHYs are just a resource like any >>> other. The controller drivers can't have any responsibility of >>> them. They should not care if PHY drivers are available for them or >>> not, or even if the PHY framework is available or not. >> >> huh? If memory isn't available you don't continue probing, right ? If >> your IORESOURCE_MEM is missing, you also don't continue probing, if your >> IRQ line is missing, you bail too. Those are also nothing but resources >> to the driver, what you're asking here is to treat PHY as a _different_ >> resource; which might be fine, but we need to make sure we don't >> continue probing when a PHY is missing in a platform that certainly >> needs a PHY. > > Yes, true. In my head I was comparing the PHY only to resources like > gpios, clocks, dma channels, etc. that are often optional to the > drivers. > >> But I really want to see the argument against using no-op. As far as I >> could see, everybody needs a PHY driver one way or another, some >> platforms just haven't sent any PHY driver upstream and have their own >> hacked up solution to avoid using the PHY layer. > > Not true in our case. Platforms using Intel's SoCs and chip sets may > or may not have controllable USB PHY. Quite often they don't. The > Baytrails have usually ULPI PHY for USB2, but that does not mean they > provide any vendor specific functions or any need for a driver in any > case. that's different from what I heard. >>> >>> I don't know where you got that impression, but it's not true. The >>> Baytrail SoCs for example don't have internal USB PHYs, which means >>> the manufacturers using it can select what they want. So we have >>> boards where PHY driver(s) is needed and boards where it isn't. >> >> alright, that explains it ;-) So you have external USB2 and USB3 PHYs ? >> You have an external PIPE3 interface ? That's quite an achievement, >> kudos to your HW designers. Getting timing closure on PIPE3 is a >> difficult task. > > No, only the USB2 PHY is external. I'm giving you wrong information, > I'm sorry about that. Need to concentrate on what I'm writing. > > > >>> This is really good to get. We have some projects where we are dealing >>> with more embedded environments, like IVI, where the kernel should be >>> stripped of everything useless. Since the PHYs are autonomous, we >>> should be able to disable the PHY libraries/frameworks. >> >> hmmm, in that case it's a lot easier to treat. We can use >> ERR_PTR(-ENXIO) as an indication that the framework is disabled, or >> something like that. >> >> The difficult is really reliably supporting e.g. OMAP5 (which won't work >> without a PHY) and your BayTrail with autonomous PHYs. What can we use >> as an indication ? > > OMAP has it's own glue driver, so shouldn't it depend on the PHY > layer? right, but the PHY is connected to the dwc3 core and not to the glue. > >> I mean, I need to know that a particular platform depends on a PHY >> driver before I decide to return -EPROBE_DEFER or just assume the PHY >> isn't needed ;-) > > I don't think dwc3 (core) should care about that. The PHY layer needs > to tell us that. If the PHY driver that the platform depends is not > available yet, the PHY layer returns -EPROBE_DEFER and dwc3 ends up > returning -EPROBE_DEFER. I don't think the PHY layer can 'reliably' tell if PHY driver is available or not. Consider when the phy_provider_register fails, there is no way to know if PHY driver is available or not. There are a few cases where PHY layer returns -EPROBE_DEFER but none of them can tell for sure that PHY driver is either available and failed or not available at all. It would be best for us to leave that to the platforms if we want to be sure if the platform needs a PHY or not. Thanks Kishon -- 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 1/2] ohci-platform: Change compatible string from usb-ohci to generic-ohci
On 02/11/2014 06:35 PM, Hans de Goede wrote:
> The initial versions of the devicetree enablement patches for ohci-platform
> used "ohci-platform" as compatible string. However this was disliked by
> various
> reviewers because the platform bus is a Linux invention and devicetree is
> supposed to be OS agnostic. After much discussion I gave up and went with
> the generic usb-ohci as requested.
>
> In retro-spect I should have chosen something different, the dts files for
> many
> existing boards already claim to be compatible with "usb-ohci", ie they have:
>
> compatible = "ti,ohci-omap3", "usb-ohci";
>
> In theory this should not be a problem since the "ti,ohci-omap3" entry takes
> presedence, but in practice using a conflicting compatible string is an issue,
> because it makes which driver gets used depend on driver registration order.
>
> This patch changes the compatible string claimed by ohci-platform to
> "generic-ohci", avoiding the driver registration / module loading ordering
> problems.
>
> Signed-off-by: Hans de Goede
> ---
> Documentation/devicetree/bindings/usb/usb-ohci.txt | 4 ++--
> drivers/usb/host/ohci-platform.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt
> b/Documentation/devicetree/bindings/usb/usb-ohci.txt
> index 6933b0c..45f67d9 100644
> --- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
> +++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
> @@ -1,7 +1,7 @@
> USB OHCI controllers
>
> Required properties:
> -- compatible : "usb-ohci"
> +- compatible : "generic-ohci"
> - reg : ohci controller register range (address and length)
> - interrupts : ohci controller interrupt
>
> @@ -16,7 +16,7 @@ Optional properties:
> Example:
>
> ohci0: usb@01c14400 {
> - compatible = "allwinner,sun4i-a10-ohci", "usb-ohci";
> + compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
> reg = <0x01c14400 0x100>;
> interrupts = <64>;
> clocks = <&usb_clk 6>, <&ahb_gates 2>;
> diff --git a/drivers/usb/host/ohci-platform.c
> b/drivers/usb/host/ohci-platform.c
> index e2c28fd..b6ca0b2 100644
> --- a/drivers/usb/host/ohci-platform.c
> +++ b/drivers/usb/host/ohci-platform.c
> @@ -319,7 +319,7 @@ static int ohci_platform_resume(struct device *dev)
> #endif /* CONFIG_PM */
>
> static const struct of_device_id ohci_platform_ids[] = {
> - { .compatible = "usb-ohci", },
> + { .compatible = "generic-ohci", },
> { }
> };
> MODULE_DEVICE_TABLE(of, ohci_platform_ids);
>
both v2 patches
Acked-by: Roger Quadros
--
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
