Re: [PATCH 0/2] USB: serial: ftdi_sio: Add support for new Xsens devices

[Frans Klaver]

Hi Greg,

On Wed, Jul 23, 2014 at 05:01:02PM -0700, Greg Kroah-Hartman wrote:
> Your patches were mal-formed and could not be applied at all, please fix
> up your email client to not eat tabs and resend.

It seems we're running into mail server settings that have been adapted
for my use, but not for Patrick's. I've resubmitted the patches with
proper whitespace.

> Oh, also:
> 
> > The information transmitted is intended only for the person or entity to 
> > which it is addressed and may contain
> > confidential and/or privileged material. Any review, retransmission, 
> > dissemination or other use of, or taking of
> > any action in reliance upon, this information by persons or entities other 
> > than the intended recipient is prohibited.
> > If you received this in error, please contact the sender and delete the 
> > material from any computer.
> 
> 
> Because of that, I'm not supposed to even be able to read this email, as
> it directly contridicts the agreement you are making when you submit the
> patch to us :(
> 
> Please have that footer removed if you wish to contribute to the kernel.

And also without the footer. You may ignore the cover letter as far as
I'm concerned ;).

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

[PATCH 2/2] USB: serial: ftdi_sio: Add support for new Xsens devices

[Frans Klaver]

From: Patrick Riphagen 

This adds support for new Xsens devices, using Xsens' own Vendor ID.

Signed-off-by: Patrick Riphagen 
Signed-off-by: Frans Klaver 
Cc: Johan Hovold 
Cc: Greg Kroah-Hartman 
Cc: stable 
---
 drivers/usb/serial/ftdi_sio.c | 2 ++
 drivers/usb/serial/ftdi_sio_ids.h | 3 +++
 2 files changed, 5 insertions(+)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 8a3813b..e266464 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -673,6 +673,8 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_5_PID) },
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_6_PID) },
{ USB_DEVICE(FTDI_VID, XSENS_CONVERTER_7_PID) },
+   { USB_DEVICE(XSENS_VID, XSENS_CONVERTER_PID) },
+   { USB_DEVICE(XSENS_VID, XSENS_MTW_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_OMNI1509) },
{ USB_DEVICE(MOBILITY_VID, MOBILITY_USB_SERIAL_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_ACTIVE_ROBOTS_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index 3fc7897..1e58d90 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -140,6 +140,9 @@
 /*
  * Xsens Technologies BV products (http://www.xsens.com).
  */
+#define XSENS_VID  0x2639
+#define XSENS_CONVERTER_PID0xD00D  /* Xsens USB-serial converter */
+#define XSENS_MTW_PID  0x0200  /* Xsens MTw */
 #define XSENS_CONVERTER_0_PID  0xD388  /* Xsens USB converter */
 #define XSENS_CONVERTER_1_PID  0xD389  /* Xsens Wireless Receiver */
 #define XSENS_CONVERTER_2_PID  0xD38A
-- 
1.9.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

[PATCH 1/2] USB: serial: ftdi_sio: Annotate the current Xsens PID assignments

[Frans Klaver]

From: Patrick Riphagen 

The converters are used in specific products. It can be useful to know
which they are exactly.

Signed-off-by: Patrick Riphagen 
Signed-off-by: Frans Klaver 
Cc: Johan Hovold 
Cc: Greg Kroah-Hartman 
Cc: stable 
---
 drivers/usb/serial/ftdi_sio_ids.h | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/serial/ftdi_sio_ids.h 
b/drivers/usb/serial/ftdi_sio_ids.h
index c4777bc..3fc7897 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -140,12 +140,12 @@
 /*
  * Xsens Technologies BV products (http://www.xsens.com).
  */
-#define XSENS_CONVERTER_0_PID  0xD388
-#define XSENS_CONVERTER_1_PID  0xD389
+#define XSENS_CONVERTER_0_PID  0xD388  /* Xsens USB converter */
+#define XSENS_CONVERTER_1_PID  0xD389  /* Xsens Wireless Receiver */
 #define XSENS_CONVERTER_2_PID  0xD38A
-#define XSENS_CONVERTER_3_PID  0xD38B
-#define XSENS_CONVERTER_4_PID  0xD38C
-#define XSENS_CONVERTER_5_PID  0xD38D
+#define XSENS_CONVERTER_3_PID  0xD38B  /* Xsens USB-serial converter */
+#define XSENS_CONVERTER_4_PID  0xD38C  /* Xsens Wireless Receiver */
+#define XSENS_CONVERTER_5_PID  0xD38D  /* Xsens Awinda Station */
 #define XSENS_CONVERTER_6_PID  0xD38E
 #define XSENS_CONVERTER_7_PID  0xD38F
 
-- 
1.9.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

[PATCH 09/10 linux-next] USB: ftdi_sio: remove unnecessary break after return

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/serial/ftdi_sio.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index b9035c3..bb45c71 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2414,7 +2414,6 @@ static int ftdi_ioctl(struct tty_struct *tty,
(struct serial_struct __user *) arg);
case TIOCSERGETLSR:
return get_lsr_info(port, (struct serial_struct __user *)arg);
-   break;
default:
break;
}
-- 
1.8.4.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 05/10 linux-next] usb: gadget: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/gadget/function/f_hid.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/usb/gadget/function/f_hid.c 
b/drivers/usb/gadget/function/f_hid.c
index a95290a..21c4b9c 100644
--- a/drivers/usb/gadget/function/f_hid.c
+++ b/drivers/usb/gadget/function/f_hid.c
@@ -386,25 +386,21 @@ static int hidg_setup(struct usb_function *f,
memset(req->buf, 0x0, length);
 
goto respond;
-   break;
 
case ((USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8
  | HID_REQ_GET_PROTOCOL):
VDBG(cdev, "get_protocol\n");
goto stall;
-   break;
 
case ((USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8
  | HID_REQ_SET_REPORT):
VDBG(cdev, "set_report | wLenght=%d\n", ctrl->wLength);
goto stall;
-   break;
 
case ((USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE) << 8
  | HID_REQ_SET_PROTOCOL):
VDBG(cdev, "set_protocol\n");
goto stall;
-   break;
 
case ((USB_DIR_IN | USB_TYPE_STANDARD | USB_RECIP_INTERFACE) << 8
  | USB_REQ_GET_DESCRIPTOR):
@@ -415,20 +411,17 @@ static int hidg_setup(struct usb_function *f,
   hidg_desc.bLength);
memcpy(req->buf, &hidg_desc, length);
goto respond;
-   break;
case HID_DT_REPORT:
VDBG(cdev, "USB_REQ_GET_DESCRIPTOR: REPORT\n");
length = min_t(unsigned short, length,
   hidg->report_desc_length);
memcpy(req->buf, hidg->report_desc, length);
goto respond;
-   break;
 
default:
VDBG(cdev, "Unknown descriptor request 0x%x\n",
 value >> 8);
goto stall;
-   break;
}
break;
 
@@ -436,7 +429,6 @@ static int hidg_setup(struct usb_function *f,
VDBG(cdev, "Unknown request 0x%x\n",
 ctrl->bRequest);
goto stall;
-   break;
}
 
 stall:
-- 
1.8.4.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 08/10 linux-next] USB: serial: remove unnecessary break after return

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/serial/iuu_phoenix.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/serial/iuu_phoenix.c b/drivers/usb/serial/iuu_phoenix.c
index 5ad4a0f..705e9dd 100644
--- a/drivers/usb/serial/iuu_phoenix.c
+++ b/drivers/usb/serial/iuu_phoenix.c
@@ -860,7 +860,6 @@ static int iuu_uart_baud(struct usb_serial_port *port, u32 
baud_base,
default:
kfree(dataout);
return IUU_INVALID_PARAMETER;
-   break;
}
 
switch (parity & 0xF0) {
@@ -874,7 +873,6 @@ static int iuu_uart_baud(struct usb_serial_port *port, u32 
baud_base,
default:
kfree(dataout);
return IUU_INVALID_PARAMETER;
-   break;
}
 
status = bulk_immediate(port, dataout, DataCount);
-- 
1.8.4.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 06/10 linux-next] xhci: remove unnecessary break after return

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/host/xhci-mem.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 8056d90..aa5eb64 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1129,7 +1129,6 @@ int xhci_setup_addressable_virt_dev(struct xhci_hcd 
*xhci, struct usb_device *ud
case USB_SPEED_WIRELESS:
xhci_dbg(xhci, "FIXME xHCI doesn't support wireless speeds\n");
return -EINVAL;
-   break;
default:
/* Speed was set earlier, this shouldn't happen. */
return -EINVAL;
-- 
1.8.4.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 07/10 linux-next] usb: storage: remove unnecessary break after return

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/storage/freecom.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/storage/freecom.c b/drivers/usb/storage/freecom.c
index ef16068..e6f8c1f 100644
--- a/drivers/usb/storage/freecom.c
+++ b/drivers/usb/storage/freecom.c
@@ -417,7 +417,6 @@ static int freecom_transport(struct scsi_cmnd *srb, struct 
us_data *us)
 us->srb->sc_data_direction);
/* Return fail, SCSI seems to handle this better. */
return USB_STOR_TRANSPORT_FAILED;
-   break;
}
 
return USB_STOR_TRANSPORT_GOOD;
-- 
1.8.4.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 04/10 linux-next] usb: gadget: remove unnecessary break after return

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/gadget/legacy/tcm_usb_gadget.c 
b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
index 6cdb7a5..fb7cbb4 100644
--- a/drivers/usb/gadget/legacy/tcm_usb_gadget.c
+++ b/drivers/usb/gadget/legacy/tcm_usb_gadget.c
@@ -465,13 +465,11 @@ static int usbg_bot_setup(struct usb_function *f,
*ret_lun = luns;
cdev->req->length = 1;
return usb_ep_queue(cdev->gadget->ep0, cdev->req, GFP_ATOMIC);
-   break;
 
case US_BULK_RESET_REQUEST:
/* XXX maybe we should remove previous requests for IN + OUT */
bot_enqueue_cmd_cbw(fu);
return 0;
-   break;
}
return -ENOTSUPP;
 }
-- 
1.8.4.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 03/10 linux-next] usb: dcw3: remove unnecessary break after return

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/dwc3/ep0.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 21a3520..927dad3 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -422,7 +422,6 @@ static int dwc3_ep0_handle_feature(struct dwc3 *dwc,
 
case USB_DEVICE_LTM_ENABLE:
return -EINVAL;
-   break;
 
case USB_DEVICE_TEST_MODE:
if ((wIndex & 0xff) != 0)
@@ -530,7 +529,6 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
switch (state) {
case USB_STATE_DEFAULT:
return -EINVAL;
-   break;
 
case USB_STATE_ADDRESS:
ret = dwc3_ep0_delegate_req(dwc, ctrl);
-- 
1.8.4.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 01/10 linux-next] USB: iowarrior: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/misc/iowarrior.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index c6bfd13..17ce9a4 100644
--- a/drivers/usb/misc/iowarrior.c
+++ b/drivers/usb/misc/iowarrior.c
@@ -381,7 +381,6 @@ static ssize_t iowarrior_write(struct file *file,
retval = usb_set_report(dev->interface, 2, 0, buf, count);
kfree(buf);
goto exit;
-   break;
case USB_DEVICE_ID_CODEMERCS_IOW56:
/* The IOW56 uses asynchronous IO and more urbs */
if (atomic_read(&dev->write_busy) == MAX_WRITES_IN_FLIGHT) {
@@ -447,14 +446,12 @@ static ssize_t iowarrior_write(struct file *file,
retval = count;
usb_free_urb(int_out_urb);
goto exit;
-   break;
default:
/* what do we have here ? An unsupported Product-ID ? */
dev_err(&dev->interface->dev, "%s - not supported for 
product=0x%x\n",
__func__, dev->product_id);
retval = -EFAULT;
goto exit;
-   break;
}
 error:
usb_free_coherent(dev->udev, dev->report_size, buf,
-- 
1.8.4.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 00/10 linux-next] drivers/usb: remove unnecessary break after goto/return

[Fabian Frederick]

Small patchset addressing break redundancy on drivers/usb branch
(suggested by Joe Perches).

Fabian Frederick (10):
  USB: iowarrior: remove unnecessary break after goto
  USB: usblcd: remove unnecessary break after return
  usb: dcw3: remove unnecessary break after return
  usb: gadget: remove unnecessary break after return
  usb: gadget: remove unnecessary break after goto
  xhci: remove unnecessary break after return
  usb: storage: remove unnecessary break after return
  USB: serial: remove unnecessary break after return
  USB: ftdi_sio: remove unnecessary break after return
  USB: microtek: remove unnecessary break after goto

 drivers/usb/dwc3/ep0.c | 2 --
 drivers/usb/gadget/function/f_hid.c| 8 
 drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2 --
 drivers/usb/host/xhci-mem.c| 1 -
 drivers/usb/image/microtek.c   | 1 -
 drivers/usb/misc/iowarrior.c   | 3 ---
 drivers/usb/misc/usblcd.c  | 1 -
 drivers/usb/serial/ftdi_sio.c  | 1 -
 drivers/usb/serial/iuu_phoenix.c   | 2 --
 drivers/usb/storage/freecom.c  | 1 -
 10 files changed, 22 deletions(-)

-- 
1.8.4.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 02/10 linux-next] USB: usblcd: remove unnecessary break after return

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/misc/usblcd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/misc/usblcd.c b/drivers/usb/misc/usblcd.c
index 1184390..5085d69 100644
--- a/drivers/usb/misc/usblcd.c
+++ b/drivers/usb/misc/usblcd.c
@@ -190,7 +190,6 @@ static long lcd_ioctl(struct file *file, unsigned int cmd, 
unsigned long arg)
break;
default:
return -ENOTTY;
-   break;
}
 
return 0;
-- 
1.8.4.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 10/10 linux-next] USB: microtek: remove unnecessary break after goto

[Fabian Frederick]

Signed-off-by: Fabian Frederick 
---
 drivers/usb/image/microtek.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/image/microtek.c b/drivers/usb/image/microtek.c
index 37b44b0..5cf2111 100644
--- a/drivers/usb/image/microtek.c
+++ b/drivers/usb/image/microtek.c
@@ -294,7 +294,6 @@ static inline void mts_show_command(struct scsi_cmnd *srb)
default:
MTS_DEBUG("can't decode command\n");
goto out;
-   break;
}
MTS_DEBUG( "Command %s (%d bytes)\n", what, srb->cmd_len);
 
-- 
1.8.4.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 net] r8152: fix the checking of the usb speed

[Hayes Wang]

When the usb speed of the RTL8152 is not high speed, the USB_DEV_STAT[2:1]
should be equal to [0 1]. That is, the STAT_SPEED_FULL should be equal
to 2.

There is a easy way to check the usb speed by the speed field of the
struct usb_device. Use it to replace the original metheod.

Signed-off-by: Hayes Wang 
Spotted-by: Andrey Utkin 
---
 drivers/net/usb/r8152.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 7bad2d3..3eab74c 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -282,7 +282,7 @@
 /* USB_DEV_STAT */
 #define STAT_SPEED_MASK0x0006
 #define STAT_SPEED_HIGH0x
-#define STAT_SPEED_FULL0x0001
+#define STAT_SPEED_FULL0x0002
 
 /* USB_TX_AGG */
 #define TX_AGG_MAX_THRESHOLD   0x03
@@ -2292,9 +2292,8 @@ static void r8152b_exit_oob(struct r8152 *tp)
/* rx share fifo credit full threshold */
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RXFIFO_CTRL0, RXFIFO_THR1_NORMAL);
 
-   ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_DEV_STAT);
-   ocp_data &= STAT_SPEED_MASK;
-   if (ocp_data == STAT_SPEED_FULL) {
+   if (tp->udev->speed == USB_SPEED_FULL ||
+   tp->udev->speed == USB_SPEED_LOW) {
/* rx share fifo credit near full threshold */
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RXFIFO_CTRL1,
RXFIFO_THR2_FULL);
-- 
1.9.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: Linux 3.16-rc6

[Borislav Petkov]

On Thu, Jul 24, 2014 at 08:43:53AM +0200, Peter Zijlstra wrote:
> On Wed, Jul 23, 2014 at 05:37:43PM -0700, Linus Torvalds wrote:
> > On Wed, Jul 23, 2014 at 2:53 AM, Borislav Petkov  wrote:
> > >
> > > Well, it looks like we f*cked up something after -rc5 since I'm starting
> > > to see lockdep splats all over the place which I didn't see before. I'm
> > > running rc6 + tip/master.
> > >
> > > There was one in r8169 yesterday:
> > >
> > > https://lkml.kernel.org/r/20140722081840.ga6...@pd.tnic
> > >
> > > and now I'm seeing the following in a kvm guest. I'm adding some more
> > > lists to CC which look like might be related, judging from the stack
> > > traces.
> > 
> > Hmm. I'm not seeing the reason for this.
> > 
> > > [   31.704282] [ INFO: possible irq lock inversion dependency detected ]
> > > [   31.704282] 3.16.0-rc6+ #1 Not tainted
> > > [   31.704282] -
> > > [   31.704282] Xorg/3484 just changed the state of lock:
> > > [   31.704282]  (tasklist_lock){.?.+..}, at: [] 
> > > send_sigio+0x59/0x1b0
> > > [   31.704282] but this lock took another, HARDIRQ-unsafe lock in the 
> > > past:
> > > [   31.704282]  (&(&p->alloc_lock)->rlock){+.+...}
> > 
> > Ok, so the claim is that there's a 'p->alloc_lock' (ie "task_lock()")
> > that is inside the tasklist_lock, which would indeed be wrong. But I'm
> > not seeing it. The "shortest dependencies" thing seems to imply
> > __set_task_comm(), but that only takes task_lock.
> > 
> > Unless there is something in tip/master. 
> 
> lkml.kernel.org/r/tip-e0645a111cb44e01adc6bfff34f683323863f...@git.kernel.org
> 
> Its supposed to change lockdep to the stricter semantics provided by the
> qrwlock.
> 
> Where the rwlock used to be unfair and reader biased, qrwlock is 'fair'
> and only allows interrupt recursion.
> 
> > Can you check that this is
> > actually in plain -rc6?
> > 
> > Or maybe I'm just blind. Those lockdep splats are easy to get wrong.
> > Adding PeterZ and Ingo to the list just because they are my lockdep
> > go-to people.
> 
> I've been staring at this splat from borislav since yesterday morning
> and confusing myself properly.. I'll continue doing so until I'm
> decided.

CCing original author:

@Waiman, you can easily reproduce by booting a kvm guest with rc6 +
tip/master. It does not trigger everytime so you need to try a couple of
iterations.

I'm attaching my .config.

Also, here the splats I'm seeing on my machines:

https://lkml.kernel.org/r/20140722081840.ga6...@pd.tnic
https://lkml.kernel.org/r/20140723095327.ga23...@pd.tnic

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.16.0-rc6 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx 
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 
-fcall-saved-r11"
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_FHANDLE is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_LEGACY_ALLOC_HWIRQ=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IR

Report about a "please report the device ID to the Linux USB developers!" message

[Antonio]

Hi!

When using a ZTE usb modem (that works correctly) I found a "please report the 
device ID to the Linux USB developers!" message in the /var/log/syslog file of 
a computer running Kubuntu 14.04.

The command "uname -a" answers 
Linux laptop 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 
x86_64 x86_64 x86_64 GNU/Linux

The ZTE usb modem is:
Manufacturer: ZTE INCORPORATED
Model: MF668A
Revision: BD_MF668AV1.0.0B04

Those were the last lines of /var/log/syslog:
Jul 23 19:19:29 laptop kernel: [63008.344697] usb 2-3: USB disconnect, 
device number 44
Jul 23 19:19:29 laptop kernel: [63008.344955] option1 ttyUSB0: GSM modem 
(1-port) converter now disconnected from ttyUSB0
Jul 23 19:19:29 laptop kernel: [63008.344986] option 2-3:1.0: device 
disconnected
Jul 23 19:19:29 laptop kernel: [63008.345868] option1 ttyUSB1: GSM modem 
(1-port) converter now disconnected from ttyUSB1
Jul 23 19:19:29 laptop kernel: [63008.345899] option 2-3:1.1: device 
disconnected
Jul 23 19:19:29 laptop kernel: [63008.348050] option1 ttyUSB2: 
option_instat_callback: error -108
Jul 23 19:19:29 laptop kernel: [63008.348299] option1 ttyUSB2: GSM modem 
(1-port) converter now disconnected from ttyUSB2
Jul 23 19:19:29 laptop kernel: [63008.348335] option 2-3:1.2: device 
disconnected
Jul 23 19:19:45 laptop kernel: [63024.076135] usb 2-3: new high-speed USB 
device number 45 using ehci-pci
Jul 23 19:19:45 laptop kernel: [63024.214911] usb 2-3: New USB device 
found, idVendor=19d2, idProduct=2000
Jul 23 19:19:45 laptop kernel: [63024.214921] usb 2-3: New USB device 
strings: Mfr=3, Product=2, SerialNumber=4
Jul 23 19:19:45 laptop kernel: [63024.214928] usb 2-3: Product: ZTE WCDMA 
Technologies MSM
Jul 23 19:19:45 laptop kernel: [63024.214933] usb 2-3: Manufacturer: 
ZTE,Incorporated
Jul 23 19:19:45 laptop kernel: [63024.214938] usb 2-3: SerialNumber: 
P680A1ZTED01
Jul 23 19:19:45 laptop kernel: [63024.217788] usb-storage 2-3:1.0: USB 
Mass Storage device detected
Jul 23 19:19:45 laptop kernel: [63024.217930] scsi31 : usb-storage 2-3:1.0
Jul 23 19:19:45 laptop mtp-probe: checking bus 2, device 45: 
"/sys/devices/pci:00/:00:1d.7/usb2/2-3"
Jul 23 19:19:45 laptop mtp-probe: bus: 2, device: 45 was not an MTP device
Jul 23 19:19:46 laptop kernel: [63025.217470] scsi 31:0:0:0: CD-ROM 
   
ZTE  USB SCSI CD-ROM  2.31 PQ: 0 ANSI: 2
Jul 23 19:19:46 laptop kernel: [63025.223708] sr1: scsi-1 drive
Jul 23 19:19:46 laptop kernel: [63025.224064] sr 31:0:0:0: Attached scsi 
CD-ROM sr1
Jul 23 19:19:46 laptop kernel: [63025.224486] sr 31:0:0:0: Attached scsi 
generic sg3 type 5
Jul 23 19:19:46 laptop usb_modeswitch: switch device 19d2:2000 on 002/045
Jul 23 19:19:49 laptop kernel: [63027.836496] usb 2-3: USB disconnect, 
device number 45
Jul 23 19:19:52 laptop kernel: [63031.340125] usb 2-3: new high-speed USB 
device number 46 using ehci-pci
Jul 23 19:19:52 laptop kernel: [63031.475177] usb 2-3: New USB device 
found, idVendor=19d2, idProduct=0117
Jul 23 19:19:52 laptop kernel: [63031.475189] usb 2-3: New USB device 
strings: Mfr=3, Product=2, SerialNumber=4
Jul 23 19:19:52 laptop kernel: [63031.475195] usb 2-3: Product: ZTE WCDMA 
Technologies MSM
Jul 23 19:19:52 laptop kernel: [63031.475201] usb 2-3: Manufacturer: 
ZTE,Incorporated
Jul 23 19:19:52 laptop kernel: [63031.475206] usb 2-3: SerialNumber: 
P680A1ZTED01
Jul 23 19:19:52 laptop kernel: [63031.478703] option 2-3:1.0: GSM modem 
(1-port) converter detected
Jul 23 19:19:52 laptop kernel: [63031.478896] usb 2-3: GSM modem (1-port) 
converter now attached to ttyUSB0
Jul 23 19:19:52 laptop kernel: [63031.479097] option 2-3:1.1: GSM modem 
(1-port) converter detected
Jul 23 19:19:52 laptop kernel: [63031.480267] usb 2-3: GSM modem (1-port) 
converter now attached to ttyUSB1
Jul 23 19:19:52 laptop kernel: [63031.480477] option 2-3:1.2: GSM modem 
(1-port) converter detected
Jul 23 19:19:52 laptop kernel: [63031.480683] usb 2-3: GSM modem (1-port) 
converter now attached to ttyUSB2
Jul 23 19:19:52 laptop kernel: [63031.480863] usb-storage 2-3:1.3: USB 
Mass Storage device detected
Jul 23 19:19:52 laptop kernel: [63031.481012] scsi32 : usb-storage 2-3:1.3
Jul 23 19:19:52 laptop mtp-probe: checking bus 2, device 46: 
"/sys/devices/pci:00/:00:1d.7/usb2/2-3"
Jul 23 19:19:52 laptop mtp-probe: bus: 2, device: 46 was not an MTP device
Jul 23 19:19:53 laptop kernel: [63032.481464] scsi 32:0:0:0: Direct-Access  
   
ZTE  MMC Storage  2.31 PQ: 0 ANSI: 2
Jul 23 19:19:53 laptop kernel: [63032.482084] sd 32:0:0:0: Attached scsi 
generic sg3 type 0
Jul 23 19:19:53 laptop kernel: [63032.491639] sd 32:0:0:0: [sdc] Attached 
SCSI removable disk
Jul 23 19:19:53 laptop usb_modeswitch: switched to 19d2: on 002/045
Jul 23 19:19:54 laptop usb_modeswitch[9252]: usb_mode

Re: [PATCH v2] usb:serial:pl2303: add GPIOs interface on PL2303

[One Thousand Gnomes]

On Wed, 23 Jul 2014 09:21:29 -0700
Greg KH  wrote:

> On Wed, Jul 23, 2014 at 05:03:14PM +0100, One Thousand Gnomes wrote:
> > > + if (gpiochip_remove(&spriv->gpio->gpio_chip))
> > > + dev_err(&serial->interface->dev, "unable to remove 
> > > gpio_chip?\n");
> > > + kfree(spriv->gpio);
> > > + }
> > > +#endif
> > >   kfree(spriv);
> > 
> > Only other question I have - if I have multiple PL2303HX adapters how
> > will I work out which GPIO lines belong to which /dev/ttyUSB* interface ?
> 
> sysfs _should_ show you this, as it should point to the "parent" device,
> which will be associated with the ttyUSB interface.  Well, both the tty
> device and the gpio device will have the same parent, is that good
> enough to determine this, or should the gpio device have the tty device
> as its parent?

Good point - that's probably sufficient as is. The GPIO and tty lines are
sometimes used together and sometimes not.

Alan
--
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/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Peter Griffin]

Hi Lee,

Thanks for reviewing. All your review comments have been fixed in v2.

regards,

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

Re: Report about a "please report the device ID to the Linux USB developers!" message

[Lars Melin]

On 2014-07-24 16:07, Antonio wrote:

Hi!

When using a ZTE usb modem (that works correctly) I found a "please report the
device ID to the Linux USB developers!" message in the /var/log/syslog file of
a computer running Kubuntu 14.04.

The command "uname -a" answers
 Linux laptop 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux

The ZTE usb modem is:
 Manufacturer: ZTE INCORPORATED
 Model: MF668A
 Revision: BD_MF668AV1.0.0B04

Those were the last lines of /var/log/syslog:
 Jul 23 19:19:29 laptop kernel: [63008.344697] usb 2-3: USB disconnect,
device number 44
 Jul 23 19:19:29 laptop kernel: [63008.344955] option1 ttyUSB0: GSM modem
(1-port) converter now disconnected from ttyUSB0
 Jul 23 19:19:29 laptop kernel: [63008.344986] option 2-3:1.0: device
disconnected
 Jul 23 19:19:29 laptop kernel: [63008.345868] option1 ttyUSB1: GSM modem
(1-port) converter now disconnected from ttyUSB1
 Jul 23 19:19:29 laptop kernel: [63008.345899] option 2-3:1.1: device
disconnected
 Jul 23 19:19:29 laptop kernel: [63008.348050] option1 ttyUSB2:
option_instat_callback: error -108
 Jul 23 19:19:29 laptop kernel: [63008.348299] option1 ttyUSB2: GSM modem
(1-port) converter now disconnected from ttyUSB2
 Jul 23 19:19:29 laptop kernel: [63008.348335] option 2-3:1.2: device
disconnected
 Jul 23 19:19:45 laptop kernel: [63024.076135] usb 2-3: new high-speed USB
device number 45 using ehci-pci
 Jul 23 19:19:45 laptop kernel: [63024.214911] usb 2-3: New USB device
found, idVendor=19d2, idProduct=2000
 Jul 23 19:19:45 laptop kernel: [63024.214921] usb 2-3: New USB device
strings: Mfr=3, Product=2, SerialNumber=4
 Jul 23 19:19:45 laptop kernel: [63024.214928] usb 2-3: Product: ZTE WCDMA
Technologies MSM
 Jul 23 19:19:45 laptop kernel: [63024.214933] usb 2-3: Manufacturer:
ZTE,Incorporated
 Jul 23 19:19:45 laptop kernel: [63024.214938] usb 2-3: SerialNumber:
P680A1ZTED01
 Jul 23 19:19:45 laptop kernel: [63024.217788] usb-storage 2-3:1.0: USB
Mass Storage device detected
 Jul 23 19:19:45 laptop kernel: [63024.217930] scsi31 : usb-storage 2-3:1.0
 Jul 23 19:19:45 laptop mtp-probe: checking bus 2, device 45:
"/sys/devices/pci:00/:00:1d.7/usb2/2-3"
 Jul 23 19:19:45 laptop mtp-probe: bus: 2, device: 45 was not an MTP device
 Jul 23 19:19:46 laptop kernel: [63025.217470] scsi 31:0:0:0: CD-ROM
ZTE  USB SCSI CD-ROM  2.31 PQ: 0 ANSI: 2
 Jul 23 19:19:46 laptop kernel: [63025.223708] sr1: scsi-1 drive
 Jul 23 19:19:46 laptop kernel: [63025.224064] sr 31:0:0:0: Attached scsi
CD-ROM sr1
 Jul 23 19:19:46 laptop kernel: [63025.224486] sr 31:0:0:0: Attached scsi
generic sg3 type 5
 Jul 23 19:19:46 laptop usb_modeswitch: switch device 19d2:2000 on 002/045
 Jul 23 19:19:49 laptop kernel: [63027.836496] usb 2-3: USB disconnect,
device number 45
 Jul 23 19:19:52 laptop kernel: [63031.340125] usb 2-3: new high-speed USB
device number 46 using ehci-pci
 Jul 23 19:19:52 laptop kernel: [63031.475177] usb 2-3: New USB device
found, idVendor=19d2, idProduct=0117
 Jul 23 19:19:52 laptop kernel: [63031.475189] usb 2-3: New USB device
strings: Mfr=3, Product=2, SerialNumber=4
 Jul 23 19:19:52 laptop kernel: [63031.475195] usb 2-3: Product: ZTE WCDMA
Technologies MSM
 Jul 23 19:19:52 laptop kernel: [63031.475201] usb 2-3: Manufacturer:
ZTE,Incorporated
 Jul 23 19:19:52 laptop kernel: [63031.475206] usb 2-3: SerialNumber:
P680A1ZTED01
 Jul 23 19:19:52 laptop kernel: [63031.478703] option 2-3:1.0: GSM modem
(1-port) converter detected
 Jul 23 19:19:52 laptop kernel: [63031.478896] usb 2-3: GSM modem (1-port)
converter now attached to ttyUSB0
 Jul 23 19:19:52 laptop kernel: [63031.479097] option 2-3:1.1: GSM modem
(1-port) converter detected
 Jul 23 19:19:52 laptop kernel: [63031.480267] usb 2-3: GSM modem (1-port)
converter now attached to ttyUSB1
 Jul 23 19:19:52 laptop kernel: [63031.480477] option 2-3:1.2: GSM modem
(1-port) converter detected
 Jul 23 19:19:52 laptop kernel: [63031.480683] usb 2-3: GSM modem (1-port)
converter now attached to ttyUSB2
 Jul 23 19:19:52 laptop kernel: [63031.480863] usb-storage 2-3:1.3: USB
Mass Storage device detected
 Jul 23 19:19:52 laptop kernel: [63031.481012] scsi32 : usb-storage 2-3:1.3
 Jul 23 19:19:52 laptop mtp-probe: checking bus 2, device 46:
"/sys/devices/pci:00/:00:1d.7/usb2/2-3"
 Jul 23 19:19:52 laptop mtp-probe: bus: 2, device: 46 was not an MTP device
 Jul 23 19:19:53 laptop kernel: [63032.481464] scsi 32:0:0:0: Direct-Access
ZTE  MMC Storage  2.31 PQ: 0 ANSI: 2
 Jul 23 19:19:53 laptop kernel: [63032.482084] sd 32:0:0:0: Attached scsi
generic sg3 type 0
 Jul 23 19:19:53 laptop kernel: [63032.491639] sd 32:0:0:0: [sdc] Attached
SCSI removable disk
 Jul 23 19:19:53 laptop usb_modeswitch: switched to 19d2: on 002/045
 Jul 23 19:19:54 laptop u

Re: Report about a "please report the device ID to the Linux USB developers!" message

[Antonio]

Hi!

> What we see here is a device not being stable on the usb bus and the 
> same has been reported for Ubuntu 14.04, multiple switching due to the 
> device being reset.
> What kind of USB port is it connected to,  USB 3.0?

The modem is connected to a USB 2.0 port  (that lapton only has USB 2.0 ports, 
I've also checked it looking at the official documentation).

If someone needs more information, please tell me. Many thanks for all!
--
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 v2 0/3] Add USB HCD support for STi SoCs

[Peter Griffin]

This driver adds support for the USB HCD controller present in STi
SoC's from STMicroelectronics. It has been tested on the stih416-b2020
board.

The original author is no longer with the company and therefore emails
to his address bounce, thus I have not added him to CC.

Changes since v1:
 - Correct s/OCHI/OHCI/ spelling
 - Improve kconfig help message
 - Various formating / spelling nits identified by Lee Jones
 - Make driver depend on OF & remove node checks in code
 - Use devm_ioremap_resource
 - Remove unnecessary header files

Peter Griffin (3):
  usb: host: st-hcd: Add USB HCD support for STi SoCs
  usb: host: st-hcd: Add st-hcd devicetree bindings documentation.
  MAINTAINERS: Add st-hcd to ARCH/STI architecture

 Documentation/devicetree/bindings/usb/st-hcd.txt |  51 +++
 MAINTAINERS  |   1 +
 drivers/usb/host/Kconfig |  13 +
 drivers/usb/host/Makefile|   1 +
 drivers/usb/host/st-hcd.c| 471 +++
 5 files changed, 537 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/st-hcd.txt
 create mode 100644 drivers/usb/host/st-hcd.c

-- 
1.9.1

--
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 v2 2/3] usb: host: st-hcd: Add st-hcd devicetree bindings documentation.

[Peter Griffin]

This patch documents the device tree documentation required for
the ST HCD controller found in STMicroelectronics SoCs.

Signed-off-by: Peter Griffin 
---
 Documentation/devicetree/bindings/usb/st-hcd.txt | 49 
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/st-hcd.txt

diff --git a/Documentation/devicetree/bindings/usb/st-hcd.txt 
b/Documentation/devicetree/bindings/usb/st-hcd.txt
new file mode 100644
index 000..b963be2
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/st-hcd.txt
@@ -0,0 +1,49 @@
+ST HCD (Host Controller Driver) for USB 2.0 and 1.1
+
+The device node has the following properties.
+
+Required properties:
+ - compatible  : must be "st,usb-300x"
+ - reg : physical base addresses of the controller and length 
of memory mapped
+ region
+ - reg-names   : names associated to the reg defines above, should be 
"ehci" and "ohci"
+ - interrupts  : interrupt numbers to the cpu
+ - interrupt-names : should be "ehci" and "ohci"
+
+ - pinctrl-names   : a pinctrl state named "default" must be defined
+-  pinctrl-0   : phandle referencing pin configuration of the USB 
controller
+See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - clocks  : phandle list of usb clocks.
+ - clock-names : should be "ic" for interconnect clock and "ohci" for 
the 48MHz clock
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+ - resets  : phandle to the powerdown and reset controller for the 
USB IP
+ - reset-names : should be "powerdown" and "softreset".
+See: Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
+See: Documentation/devicetree/bindings/reset/reset.txt
+
+Example:
+
+usb0: usb@fe10 {
+   compatible  = "st,usb-300x";
+   reg = <0xfe1ffc00 0x100>,
+ <0xfe1ffe00 0x100>;
+   reg-names   = "ohci", "ehci";
+
+   interrupts  =  ,
+  ;
+   interrupt-names = "ehci", "ohci";
+   pinctrl-names   = "default";
+   pinctrl-0   = <&pinctrl_usb0>;
+   clocks  = <&clk_s_a1_ls CLK_ICN_IF_2>,
+ <&clockgen_b0 0>;
+   clock-names = "ic", "ohci";
+
+   resets  = <&powerdown STIH416_USB0_POWERDOWN>,
+ <&softreset STIH416_USB0_SOFTRESET>;
+   reset-names = "powerdown", "softreset";
+
+   phys= <&usb2_phy>;
+   phy-names   = "usb2-phy";
+};
-- 
1.9.1

--
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 v2 3/3] MAINTAINERS: Add st-hcd to ARCH/STI architecture

[Peter Griffin]

Signed-off-by: Peter Griffin 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 702ca10..359a64e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1325,6 +1325,7 @@ F:drivers/pinctrl/pinctrl-st.c
 F: drivers/media/rc/st_rc.c
 F: drivers/i2c/busses/i2c-st.c
 F: drivers/tty/serial/st-asc.c
+F: drivers/usb/host/st-hcd.c
 
 ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
 M: Lennert Buytenhek 
-- 
1.9.1

--
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 v2 1/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Peter Griffin]

This driver adds support for the USB HCD present in STi
SoC's from STMicroelectronics. It has been tested on the
stih416-b2020 board.

Signed-off-by: Peter Griffin 
---
 drivers/usb/host/Kconfig  |  12 ++
 drivers/usb/host/Makefile |   1 +
 drivers/usb/host/st-hcd.c | 460 ++
 3 files changed, 473 insertions(+)
 create mode 100644 drivers/usb/host/st-hcd.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 61b7817..a5e7f71 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -753,6 +753,18 @@ config USB_HCD_SSB
 
  If unsure, say N.
 
+config USB_HCD_ST
+   tristate "STMicroelectronics STi family HCD support"
+   depends on ARCH_STI && OF
+   select USB_OHCI_HCD_PLATFORM if USB_OHCI_HCD
+   select USB_EHCI_HCD_PLATFORM if USB_EHCI_HCD
+   select GENERIC_PHY
+   help
+ Enable support for the EHCI and OHCI host controller on ST
+ consumer electronics SoCs.
+
+ If unsure, say N.
+
 config USB_HCD_TEST_MODE
bool "HCD test mode support"
---help---
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index af89a90..af0b81d 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_USB_HCD_SSB) += ssb-hcd.o
 obj-$(CONFIG_USB_FUSBH200_HCD) += fusbh200-hcd.o
 obj-$(CONFIG_USB_FOTG210_HCD)  += fotg210-hcd.o
 obj-$(CONFIG_USB_MAX3421_HCD)  += max3421-hcd.o
+obj-$(CONFIG_USB_HCD_ST)   += st-hcd.o
diff --git a/drivers/usb/host/st-hcd.c b/drivers/usb/host/st-hcd.c
new file mode 100644
index 000..eaec345
--- /dev/null
+++ b/drivers/usb/host/st-hcd.c
@@ -0,0 +1,460 @@
+/*
+ * STMicroelectronics HCD (Host Controller Driver) for USB 2.0 and 1.1.
+ *
+ * Copyright (c) 2013 STMicroelectronics (R&D) Ltd.
+ * Authors: Stephen Gallimore 
+ *  Peter Griffin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2, as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ohci.h"
+
+#define EHCI_CAPS_SIZE 0x10
+#define AHB2STBUS_INSREG01 (EHCI_CAPS_SIZE + 0x84)
+
+struct st_hcd_dev {
+   int port_nr;
+   struct platform_device *ehci_device;
+   struct platform_device *ohci_device;
+   struct clk *ic_clk;
+   struct clk *ohci_clk;
+   struct reset_control *pwr;
+   struct reset_control *rst;
+   struct phy *phy;
+};
+
+static inline void st_ehci_configure_bus(void __iomem *regs)
+{
+   /* Set EHCI packet buffer IN/OUT threshold to 128 bytes */
+   u32 threshold = 128 | (128 << 16);
+
+   writel(threshold, regs + AHB2STBUS_INSREG01);
+}
+
+static int st_hcd_enable_clocks(struct device *dev,
+   struct st_hcd_dev *hcd_dev)
+{
+   int err;
+
+   /*
+* The interconnect input clock have either a fixed
+* rate or the rate is defined on boot, so we are only concerned about
+* enabling any gates for this clock.
+*/
+   err = clk_prepare_enable(hcd_dev->ic_clk);
+   if (err) {
+   dev_err(dev, "can't enable ic clock\n");
+   return err;
+   }
+
+   /*
+* The 48MHz OHCI clock is usually provided by a programmable
+* frequency synthesizer, which is often not programmed on boot/chip
+* reset, so we set its rate here to ensure it is correct.
+*
+* However not all SoC's have a dedicated OHCI clock so it isn't fatal
+* for this not to exist.
+*/
+   if (!hcd_dev->ohci_clk)
+   return 0;
+
+   err = clk_set_rate(hcd_dev->ohci_clk, 4800);
+   if (err) {
+   dev_err(dev, "can't set OHCI clock rate\n");
+   goto error;
+   }
+   err = clk_prepare_enable(hcd_dev->ohci_clk);
+   if (err) {
+   dev_err(dev, "can't enable OHCI clock\n");
+   goto error;
+   }
+
+   return 0;
+error:
+   clk_disable_unprepare(hcd_dev->ic_clk);
+   return err;
+}
+
+static void st_hcd_disable_clocks(struct st_hcd_dev *hcd_dev)
+{
+   clk_disable_unprepare(hcd_dev->ohci_clk);
+   clk_disable_unprepare(hcd_dev->ic_clk);
+}
+
+static void st_hcd_assert_resets(struct device *dev,
+   struct st_hcd_dev *hcd_dev)
+{
+   int err;
+
+   err = reset_control_assert(hcd_dev->pwr);
+   if (err)
+   dev_err(dev, "unable to put into powerdown\n");
+
+   err = reset_control_assert(hcd_dev->rst);
+   if (err)
+   dev_err(dev, "unable to put into softreset\n");
+}
+
+static int st_hcd_deassert_resets(struct device *dev,
+   struct st_hcd_dev *hcd_dev)
+{
+   int err;
+
+ 

Re: [PATCH v2 3/3] MAINTAINERS: Add st-hcd to ARCH/STI architecture

[Lee Jones]

On Thu, 24 Jul 2014, Peter Griffin wrote:

> Signed-off-by: Peter Griffin 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

I Acked, this already.  Please carry them forward through revisions.

Acked-by: Lee Jones 

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 702ca10..359a64e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1325,6 +1325,7 @@ F:  drivers/pinctrl/pinctrl-st.c
>  F:   drivers/media/rc/st_rc.c
>  F:   drivers/i2c/busses/i2c-st.c
>  F:   drivers/tty/serial/st-asc.c
> +F:   drivers/usb/host/st-hcd.c
>  
>  ARM/TECHNOLOGIC SYSTEMS TS7250 MACHINE SUPPORT
>  M:   Lennert Buytenhek 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 2/3] usb: host: st-hcd: Add st-hcd devicetree bindings documentation.

[Lee Jones]

On Thu, 24 Jul 2014, Peter Griffin wrote:

> This patch documents the device tree documentation required for
> the ST HCD controller found in STMicroelectronics SoCs.
> 
> Signed-off-by: Peter Griffin 
> ---
>  Documentation/devicetree/bindings/usb/st-hcd.txt | 49 
> 
>  1 file changed, 49 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/st-hcd.txt

If you've fixed the nits from the previous review, you should have
applied my Ack for this submission.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Arnd Bergmann]

On Thursday 24 July 2014 12:00:14 Peter Griffin wrote:
> This driver adds support for the USB HCD present in STi
> SoC's from STMicroelectronics. It has been tested on the
> stih416-b2020 board.

Unfortunately, this seems to be done in a rather strange way,
I suspect you'll have to start over, but I'll let Alan and Greg
weigh in.

> +
> +struct st_hcd_dev {
> + int port_nr;
> + struct platform_device *ehci_device;
> + struct platform_device *ohci_device;
> + struct clk *ic_clk;
> + struct clk *ohci_clk;
> + struct reset_control *pwr;
> + struct reset_control *rst;
> + struct phy *phy;
> +};

The way you do this apparently is to create a device that encapsulates
the OHCI and the EHCI and then goes on to create child devices that
are bound to the real drivers.

The way it should be done however is to put the two host controllers
into DT directly and describe their resources (phy, clock, reset, ...)
using the DT bindings for those.

Depending on what kind of special requirements the ST version has,
this can be done either by using the generic ohci/ehci bindings
with extensions where necessary, or by creating a new binding and
new driver files that use 'ohci_init_driver'/'ehci_init_driver'
to inherit from the common code.

The first of the two approaches is preferred.

> + pdev->dev.parent = &parent->dev;
> + pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);

This is something we shouldn't ever do these days, the DMA settings
should come directly from DT without driver interaction.

Arnd
--
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 7/8] usb: rename transceiver and phy to usb_phy in ChipIdea

[Peter Chen]

On Tue, Jul 15, 2014 at 04:39:15PM +0200, Antoine Ténart wrote:
> This patch prepares the introduction of the generic PHY support in the
> USB ChipIdea common functions. The USB PHY member of the ChipIdea
> structure ('transceiver') is renamed to 'usb_phy', the 'phy' member of
> the ChipIdea pdata structure is renamed to 'usb_phy' and modifications
> are done in all drivers accessing it. Renaming this pointer will allow
> to keep the compatibility for USB PHY drivers.
> 
> Signed-off-by: Antoine Ténart 
> ---
>  drivers/usb/chipidea/ci.h  |  4 ++--
>  drivers/usb/chipidea/ci_hdrc_imx.c |  2 +-
>  drivers/usb/chipidea/ci_hdrc_msm.c |  8 
>  drivers/usb/chipidea/core.c| 20 ++--
>  drivers/usb/chipidea/debug.c   |  2 +-
>  drivers/usb/chipidea/host.c|  4 ++--
>  drivers/usb/chipidea/otg_fsm.c |  4 ++--
>  drivers/usb/chipidea/udc.c |  4 ++--
>  include/linux/usb/chipidea.h   |  2 +-
>  9 files changed, 25 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 9563cb56d564..b2caa1772712 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -161,7 +161,7 @@ struct hw_bank {
>   * @test_mode: the selected test mode
>   * @platdata: platform specific information supplied by parent device
>   * @vbus_active: is VBUS active
> - * @transceiver: pointer to USB PHY, if any
> + * @usb_phy: pointer to USB PHY, if any
>   * @hcd: pointer to usb_hcd for ehci host driver
>   * @debugfs: root dentry for this controller in debugfs
>   * @id_event: indicates there is an id event, and handled at ci_otg_work
> @@ -201,7 +201,7 @@ struct ci_hdrc {
>  
>   struct ci_hdrc_platform_data*platdata;
>   int vbus_active;
> - struct usb_phy  *transceiver;
> + struct usb_phy  *usb_phy;
>   struct usb_hcd  *hcd;
>   struct dentry   *debugfs;
>   boolid_event;
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 2e58f8dfd311..33b982dddac5 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -136,7 +136,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>   goto err_clk;
>   }
>  
> - pdata.phy = data->phy;
> + pdata.usb_phy = data->phy;
>  
>   if (imx_platform_flag->flags & CI_HDRC_IMX_IMX28_WRITE_FIX)
>   pdata.flags |= CI_HDRC_IMX28_WRITE_FIX;
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index d72b9d2de2c5..94cd7c3e12a3 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -31,13 +31,13 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, 
> unsigned event)
>   case CI_HDRC_CONTROLLER_STOPPED_EVENT:
>   dev_dbg(dev, "CI_HDRC_CONTROLLER_STOPPED_EVENT received\n");
>   /*
> -  * Put the transceiver in non-driving mode. Otherwise host
> +  * Put the phy in non-driving mode. Otherwise host
>* may not detect soft-disconnection.
>*/
> - val = usb_phy_io_read(ci->transceiver, ULPI_FUNC_CTRL);
> + val = usb_phy_io_read(ci->usb_phy, ULPI_FUNC_CTRL);
>   val &= ~ULPI_FUNC_CTRL_OPMODE_MASK;
>   val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
> - usb_phy_io_write(ci->transceiver, val, ULPI_FUNC_CTRL);
> + usb_phy_io_write(ci->usb_phy, val, ULPI_FUNC_CTRL);
>   break;
>   default:
>   dev_dbg(dev, "unknown ci_hdrc event\n");
> @@ -71,7 +71,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
>   if (IS_ERR(phy))
>   return PTR_ERR(phy);
>  
> - ci_hdrc_msm_platdata.phy = phy;
> + ci_hdrc_msm_platdata.usb_phy = phy;
>  
>   plat_ci = ci_hdrc_add_device(&pdev->dev,
>   pdev->resource, pdev->num_resources,
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 619d13e29995..a8cd35fd8175 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -306,7 +306,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
>   case USBPHY_INTERFACE_MODE_UTMI:
>   case USBPHY_INTERFACE_MODE_UTMIW:
>   case USBPHY_INTERFACE_MODE_HSIC:
> - ret = usb_phy_init(ci->transceiver);
> + ret = usb_phy_init(ci->usb_phy);
>   if (ret)
>   return ret;
>   hw_phymode_configure(ci);
> @@ -314,12 +314,12 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
>   case USBPHY_INTERFACE_MODE_ULPI:
>   case USBPHY_INTERFACE_MODE_SERIAL:
>   hw_phymode_configure(ci);
> - ret = usb_phy_init(ci->transceiver);
> + ret = usb_phy_init(ci->usb_phy);
>  

Re: [PATCH v2 1/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Lee Jones]

On Thu, 24 Jul 2014, Peter Griffin wrote:

> This driver adds support for the USB HCD present in STi
> SoC's from STMicroelectronics. It has been tested on the
> stih416-b2020 board.
> 
> Signed-off-by: Peter Griffin 
> ---
>  drivers/usb/host/Kconfig  |  12 ++
>  drivers/usb/host/Makefile |   1 +
>  drivers/usb/host/st-hcd.c | 460 
> ++
>  3 files changed, 473 insertions(+)
>  create mode 100644 drivers/usb/host/st-hcd.c

Looks good to me now:

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 06/10 linux-next] xhci: remove unnecessary break after return

[Mathias Nyman]

On 07/24/2014 11:18 AM, Fabian Frederick wrote:
> Signed-off-by: Fabian Frederick 
> ---

Acked-by: Mathias Nyman 


--
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 00/10 linux-next] drivers/usb: remove unnecessary break after goto/return

[Oliver Neukum]

On Thu, 2014-07-24 at 10:18 +0200, Fabian Frederick wrote:
> Small patchset addressing break redundancy on drivers/usb branch
> (suggested by Joe Perches).

Frankly, that is not a good idea. Somebody will remove a "goto"
and forget to readd the "break"

Regards
Oliver


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

Re: [PATCH v2 8/8] usb: chipidea: add support to the generic PHY framework in ChipIdea

[Peter Chen]

On Tue, Jul 15, 2014 at 04:39:16PM +0200, Antoine Ténart wrote:
> This patch adds support of the PHY framework for ChipIdea drivers.
> Changes are done in both the ChipIdea common code and in the drivers
> accessing the PHY. This is done by adding a new PHY member in
> ChipIdea's structures and by taking care of it in the code.
> 
> Signed-off-by: Antoine Ténart 
> ---
>  drivers/usb/chipidea/ci.h  |  5 ++-
>  drivers/usb/chipidea/core.c| 71 
> ++
>  drivers/usb/chipidea/debug.c   |  4 ++-
>  drivers/usb/chipidea/host.c| 18 +++
>  drivers/usb/chipidea/otg_fsm.c |  6 ++--
>  include/linux/usb/chipidea.h   |  2 ++
>  6 files changed, 83 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index b2caa1772712..f219588f4ce6 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -161,7 +161,8 @@ struct hw_bank {
>   * @test_mode: the selected test mode
>   * @platdata: platform specific information supplied by parent device
>   * @vbus_active: is VBUS active
> - * @usb_phy: pointer to USB PHY, if any
> + * @phy: pointer to PHY, if any
> + * @usb_phy: pointer to USB PHY, if any and if using the USB PHY framework
>   * @hcd: pointer to usb_hcd for ehci host driver
>   * @debugfs: root dentry for this controller in debugfs
>   * @id_event: indicates there is an id event, and handled at ci_otg_work
> @@ -201,6 +202,8 @@ struct ci_hdrc {
>  
>   struct ci_hdrc_platform_data*platdata;
>   int vbus_active;
> + struct phy  *phy;
> + /* old usb_phy interface */
>   struct usb_phy  *usb_phy;
>   struct usb_hcd  *hcd;
>   struct dentry   *debugfs;
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index a8cd35fd8175..28bcefcdbd9a 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -293,6 +294,46 @@ static void hw_phymode_configure(struct ci_hdrc *ci)
>  }
>  
>  /**
> + * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
> + * interfaces
> + * @ci: the controller
> + *
> + * This function returns an error code if the phy failed to init
> + */
> +static int _ci_usb_phy_init(struct ci_hdrc *ci)
> +{
> + int ret;
> +
> + if (ci->phy) {
> + ret = phy_init(ci->phy);
> + if (ret) {
> + phy_exit(ci->phy);

If phy_init fails, we still need to call phy_exit?

> + return ret;
> + }
> + ret = phy_power_on(ci->phy);

If phy_power_on fails, we may need to call phy_exit
> + } else {
> + ret = usb_phy_init(ci->usb_phy);
> + }
> +
> + return ret;
> +}
> +
> +/**
> + * _ci_usb_phy_exit: deinitialize phy taking in account both phy and usb_phy
> + * interfaces
> + * @ci: the controller
> + */
> +static void ci_usb_phy_exit(struct ci_hdrc *ci)
> +{
> + if (ci->phy) {
> + phy_power_off(ci->phy);
> + phy_exit(ci->phy);
> + } else {
> + usb_phy_shutdown(ci->usb_phy);
> + }
> +}
> +
> +/**
>   * ci_usb_phy_init: initialize phy according to different phy type
>   * @ci: the controller
>*
> @@ -306,7 +347,7 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
>   case USBPHY_INTERFACE_MODE_UTMI:
>   case USBPHY_INTERFACE_MODE_UTMIW:
>   case USBPHY_INTERFACE_MODE_HSIC:
> - ret = usb_phy_init(ci->usb_phy);
> + ret = _ci_usb_phy_init(ci);
>   if (ret)
>   return ret;
>   hw_phymode_configure(ci);
> @@ -314,12 +355,12 @@ static int ci_usb_phy_init(struct ci_hdrc *ci)
>   case USBPHY_INTERFACE_MODE_ULPI:
>   case USBPHY_INTERFACE_MODE_SERIAL:
>   hw_phymode_configure(ci);
> - ret = usb_phy_init(ci->usb_phy);
> + ret = _ci_usb_phy_init(ci);
>   if (ret)
>   return ret;
>   break;
>   default:
> - ret = usb_phy_init(ci->usb_phy);
> + ret = _ci_usb_phy_init(ci);
>   }
>  
>   return ret;
> @@ -595,23 +636,27 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>   return -ENODEV;
>   }
>  
> - if (ci->platdata->usb_phy)
> + if (ci->platdata->phy)
> + ci->phy = ci->platdata->phy;
> + else if (ci->platdata->usb_phy)
>   ci->usb_phy = ci->platdata->usb_phy;
>   else
> - ci->usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> + ci->phy = of_phy_get(dev->of_node, 0);

Here, we may need to consider both usb_phy and generic_phy, and
the core device is not populated from device tree.

You can use devm_usb_get_phy and devm_phy_get for global phy case.

>  
> - if 

Re: [PATCH v2 1/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Peter Griffin]

Hi Arnd,

Thanks for reviewing, see my comments below: -

> Unfortunately, this seems to be done in a rather strange way,
> I suspect you'll have to start over, but I'll let Alan and Greg
> weigh in.
> 
> > +
> > +struct st_hcd_dev {
> > +   int port_nr;
> > +   struct platform_device *ehci_device;
> > +   struct platform_device *ohci_device;
> > +   struct clk *ic_clk;
> > +   struct clk *ohci_clk;
> > +   struct reset_control *pwr;
> > +   struct reset_control *rst;
> > +   struct phy *phy;
> > +};
> 
> The way you do this apparently is to create a device that encapsulates
> the OHCI and the EHCI and then goes on to create child devices that
> are bound to the real drivers.

Yes, although this isn't the first driver to take that approach USB_HCD_BCMA
(bcma-hcd.c) and USB_HCD_SSB (ssb-hcd.c) do much the same thing.

> 
> The way it should be done however is to put the two host controllers
> into DT directly and describe their resources (phy, clock, reset, ...)
> using the DT bindings for those.

I'm of course happy to change it if required. I see looking through that a lot 
of other platforms do it the way you describe with a

ehci-.c and ohci-.c 
> 
> Depending on what kind of special requirements the ST version has,
> this can be done either by using the generic ohci/ehci bindings
> with extensions where necessary, or by creating a new binding and
> new driver files that use 'ohci_init_driver'/'ehci_init_driver'
> to inherit from the common code.
> 
> The first of the two approaches is preferred.

We don't have anything particularly special, just a couple of reset lines,
clock, phy, etc.
> 
> > +   pdev->dev.parent = &parent->dev;
> > +   pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> > +   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> 
> This is something we shouldn't ever do these days, the DMA settings
> should come directly from DT without driver interaction.

Ok, I'll wait to hear the outcome of Greg/Alans views before either fixing
it or starting over.

regards,

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

Re: Linux 3.16-rc6

[Borislav Petkov]

On Thu, Jul 24, 2014 at 10:41:27AM +0200, Borislav Petkov wrote:
> you can easily reproduce by booting a kvm guest with rc6 + tip/master.

Right, so reverting

586fefe5bbdc ("locking/selftest: Support queued rwlock")
e0645a111cb4 ("locking/lockdep: Restrict the use of recursive read_lock() with 
qrwlock")

from the top of tip/locking/core seems to fix the issue, with the kvm
guests at least.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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 8/8] usb: chipidea: add support to the generic PHY framework in ChipIdea

[Antoine Ténart]

Hi Peter,

On Thu, Jul 24, 2014 at 07:39:42PM +0800, Peter Chen wrote:
> On Tue, Jul 15, 2014 at 04:39:16PM +0200, Antoine Ténart wrote:
> >  
> >  /**
> > + * _ci_usb_phy_init: initialize phy taking in account both phy and usb_phy
> > + * interfaces
> > + * @ci: the controller
> > + *
> > + * This function returns an error code if the phy failed to init
> > + */
> > +static int _ci_usb_phy_init(struct ci_hdrc *ci)
> > +{
> > +   int ret;
> > +
> > +   if (ci->phy) {
> > +   ret = phy_init(ci->phy);
> > +   if (ret) {
> > +   phy_exit(ci->phy);
> 
> If phy_init fails, we still need to call phy_exit?
> 
> > +   return ret;
> > +   }
> > +   ret = phy_power_on(ci->phy);
> 
> If phy_power_on fails, we may need to call phy_exit

Sure, phy_exit() should be moved under the calling to phy_power_on().

> >  
> > -   if (ci->platdata->usb_phy)
> > +   if (ci->platdata->phy)
> > +   ci->phy = ci->platdata->phy;
> > +   else if (ci->platdata->usb_phy)
> > ci->usb_phy = ci->platdata->usb_phy;
> > else
> > -   ci->usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> > +   ci->phy = of_phy_get(dev->of_node, 0);
> 
> Here, we may need to consider both usb_phy and generic_phy, and
> the core device is not populated from device tree.
> 
> You can use devm_usb_get_phy and devm_phy_get for global phy case.

This is the case. If no PHY is found by of_phy_get() we try to get an
USB PHY by calling devm_usb_get_phy().

> 
> >  
> > -   if (IS_ERR(ci->usb_phy)) {
> > -   ret = PTR_ERR(ci->usb_phy);
> > +   if (IS_ERR(ci->phy)) {
> > /*
> >  * if -ENXIO is returned, it means PHY layer wasn't
> >  * enabled, so it makes no sense to return -EPROBE_DEFER
> >  * in that case, since no PHY driver will ever probe.
> >  */
> > -   if (ret == -ENXIO)
> > -   return ret;
> > +   if (PTR_ERR(ci->phy) == -ENXIO)
> > +   return -ENXIO;
> >  
> > -   dev_err(dev, "no usb2 phy configured\n");
> > -   return -EPROBE_DEFER;
> > +   ci->usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> > +   if (IS_ERR(ci->usb_phy)) {
> > +   dev_err(dev, "no usb2 phy configured\n");
> > +   return -EPROBE_DEFER;
> > +   }
> > }

[snip]

> > diff --git a/drivers/usb/chipidea/debug.c b/drivers/usb/chipidea/debug.c
> > index d47cddd38e4a..77881a5ce48f 100644
> > --- a/drivers/usb/chipidea/debug.c
> > +++ b/drivers/usb/chipidea/debug.c
> > @@ -219,7 +219,9 @@ int ci_otg_show(struct seq_file *s, void *unused)
> > fsm = &ci->fsm;
> >  
> > /* -- State - */
> > -   usb_otg_state_string(ci->usb_phy->otg.state));
> > +   if (ci->usb_phy)
> > +   seq_printf(s, "OTG state: %s\n\n",
> > +   usb_otg_state_string(ci->usb_phy->otg->state));
> 
> You may change wrongly here.

I thought a pointer to the OTG info wasn't available from there. I just
checked, and it seems we can retrieve if from the otg_fsm structure
here. I'll test and update.

> > @@ -85,13 +88,16 @@ static int host_start(struct ci_hdrc *ci)
> > if (ret) {
> > goto disable_reg;
> > } else {
> > -   struct usb_otg *otg = ci->usb_phy->otg;
> > +   if (ci->usb_phy) {
> > +   struct usb_otg *otg = ci->usb_phy->otg;
> >  
> > -   ci->hcd = hcd;
> > -   if (otg) {
> > -   otg->host = &hcd->self;
> > -   hcd->self.otg_port = 1;
> > +   if (otg) {
> > +   otg->host = &hcd->self;
> > +   hcd->self.otg_port = 1;
> > +   }
> > }
> 
> The otg port is still existed even use generic phy.

Yes. I don't know how to retrieve the OTG pointer when we do not use an
USB PHY. We may have to add an OTG member into the ci_hdrc structure,
but I didn't understand well where does occur this OTG setup.

I may have missed something. Do you know if CI OTG always is in FSM
mode? If so we could access the OTG pointer through ci_hdrc->fsm.

> >  
> > if (ci->platdata->flags & CI_HDRC_DISABLE_STREAMING)
> > diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
> > index 8a64ce87364e..2c11f260633c 100644
> > --- a/drivers/usb/chipidea/otg_fsm.c
> > +++ b/drivers/usb/chipidea/otg_fsm.c
> > @@ -788,10 +788,12 @@ int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
> > return -ENOMEM;
> > }
> >  
> > -   otg->usb_phy = ci->usb_phy;
> > +   if (ci->phy)
> > +   otg->phy = ci->phy;
> > +   else
> > +   otg->usb_phy = ci->usb_phy;
> > otg->gadget = &ci->gadget;
> > ci->fsm.otg = otg;
> > -   ci->usb_phy->otg = ci->fsm.otg;
> 
> Why you remove above line?

It shouldn't be removed as it is, because we still use it in CI. As far
as I know, this is not used in the commo

Re: Linux 3.16-rc6

[Peter Zijlstra]

On Thu, Jul 24, 2014 at 02:25:13PM +0200, Borislav Petkov wrote:
> On Thu, Jul 24, 2014 at 10:41:27AM +0200, Borislav Petkov wrote:
> > you can easily reproduce by booting a kvm guest with rc6 + tip/master.
> 
> Right, so reverting
> 
> 586fefe5bbdc ("locking/selftest: Support queued rwlock")
> e0645a111cb4 ("locking/lockdep: Restrict the use of recursive read_lock() 
> with qrwlock")
> 
> from the top of tip/locking/core seems to fix the issue, with the kvm
> guests at least.

Well, it makes the report go away.. I'm currently leaning towards that
the report is valid. We did after all change rwlock semantics, and that
lockdep patch is making lockdep match those new semantics.

Of course, its also possible the lockdep patch is wrong. But I'm leaning
towards that the report is valid.

So going by the nifty picture rostedt made:

[   61.454336]CPU0CPU1
[   61.454336]
[   61.454336]   lock(&(&p->alloc_lock)->rlock);
[   61.454336]local_irq_disable();
[   61.454336]lock(tasklist_lock);
[   61.454336]lock(&(&p->alloc_lock)->rlock);
[   61.454336]   
[   61.454336] lock(tasklist_lock);

the fact that CPU1 holds tasklist_lock for reading, does not
automagically allow CPU0 to acquire tasklist_lock for reading too, for
example if CPU2 (not in the picture) is waiting to acquire tasklist_lock
for writing, CPU0's read acquire is made to wait.

The only kind of recursion that's safe is same CPU interrupt.

Of course we should have made the lockdep change before merging qrwlock,
and that's entirely my fail, but with qrwlock in these new semantics are
already a reality.

We could of course disable qrwlock until all such issues are cleared up
(its the safe option)...


pgpObnJ6NCL62.pgp
Description: PGP signature

Re: [PATCH v2 1/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Arnd Bergmann]

On Thursday 24 July 2014 13:22:54 Peter Griffin wrote:
> Thanks for reviewing, see my comments below: -
> 
> > Unfortunately, this seems to be done in a rather strange way,
> > I suspect you'll have to start over, but I'll let Alan and Greg
> > weigh in.
> > 
> > > +
> > > +struct st_hcd_dev {
> > > +   int port_nr;
> > > +   struct platform_device *ehci_device;
> > > +   struct platform_device *ohci_device;
> > > +   struct clk *ic_clk;
> > > +   struct clk *ohci_clk;
> > > +   struct reset_control *pwr;
> > > +   struct reset_control *rst;
> > > +   struct phy *phy;
> > > +};
> > 
> > The way you do this apparently is to create a device that encapsulates
> > the OHCI and the EHCI and then goes on to create child devices that
> > are bound to the real drivers.
> 
> Yes, although this isn't the first driver to take that approach USB_HCD_BCMA
> (bcma-hcd.c) and USB_HCD_SSB (ssb-hcd.c) do much the same thing.

I just had a look at them, and I think the case is different here:

For the two bcma driver, there is a discoverable bus (bcma) rather than
the platform bus, and it only exposes one device, so the bcma-hcd driver
is actually needed so we get two device that can be bound to the regular
drivers.

For the ssb-hcd driver, it's less clear and that one could be
reworked into two separate drivers.

> > The way it should be done however is to put the two host controllers
> > into DT directly and describe their resources (phy, clock, reset, ...)
> > using the DT bindings for those.
> 
> I'm of course happy to change it if required. I see looking through that a 
> lot 
> of other platforms do it the way you describe with a
> 
> ehci-.c and ohci-.c

Right. We are trying to  gradually move some of them over to use the
generic *hci-platform.c drivers though.

> > Depending on what kind of special requirements the ST version has,
> > this can be done either by using the generic ohci/ehci bindings
> > with extensions where necessary, or by creating a new binding and
> > new driver files that use 'ohci_init_driver'/'ehci_init_driver'
> > to inherit from the common code.
> > 
> > The first of the two approaches is preferred.
> 
> We don't have anything particularly special, just a couple of reset lines,
> clock, phy, etc.

Ok, good. Please see Documentation/devicetree/bindings/usb/usb-?hci.txt
then. You might actually be able to just use the existing drivers
without new code by just adding the proper DT nodes that follow these
bindings.

> > > +   pdev->dev.parent = &parent->dev;
> > > +   pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> > > +   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > 
> > This is something we shouldn't ever do these days, the DMA settings
> > should come directly from DT without driver interaction.
> 
> Ok, I'll wait to hear the outcome of Greg/Alans views before either fixing
> it or starting over.

Ok.

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

Re: [PATCH] usb-core: Remove Fix mes in file hcd.c

[Vlastimil Babka]

On 07/23/2014 05:24 AM, Nick Krause wrote:

On Tue, Jul 22, 2014 at 8:44 PM, Sasha Levin  wrote:

On 07/18/2014 10:52 PM, Nick Krause wrote:

Please explain exactly why it's not needed, why it can never be NULL, and
what prevents it from being NULL.

"after dicussing" (do you run spellcheck on your mails?) won't mean anything
to someone looking at this commit in a year.

Your commit message also mentions usb_device which has nothing to do with
your patch.


Thanks,
Sasha


Sasha ,
Greg seems to have signed it off.
Cheers Nick


Greg?

Even if the patch is correct (and I'm not saying it is) the commit message is 
way off.


Thanks,
Sasha



Sasha,
The patch is in the  kernel now.


Greg's tree is not Linus' tree, so it's not set to stone in git commit 
history yet.


> I am not going through the trouble of removing

it, if you want to fix the commit message go on ahead.
Nick


This kind of attitude might significantly lower your chances of future 
patches being accepted.


Vlastimil



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

Re: [PATCH] usb-core: Revert "usb-core: Remove Fix mes in file hcd.c"

[Sasha Levin]

On 07/23/2014 12:49 PM, Greg KH wrote:
> On Wed, Jul 23, 2014 at 08:56:10AM -0400, Sasha Levin wrote:
>> > Revert since the commit message is incorrect and the original author 
>> > refuses
>> > to fix/maintain it because "it's in the kernel already".
> How can someone "fix" a commit message that is already in the tree?  You
> can't.  The code part is correct, so why introduce the issue back?

(I'm not trying to be aggressive, I just think that I misunderstand how this
part of the process works exactly).

I thought we can always edit -next trees? Why do we have to maintain fast 
forward
on them?

What happens, if for example you take a patch that causes build breakage? Would 
you
add a revert after that or just yank the commit out of the tree?

If you add a revert and leave the original broken commit in, wouldn't it cause 
issues
for anyone trying to bisect a build breakage?


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

Re: [PATCH] usb: xhci: Fix Set TR Dequeue Pointer cycle state for quirky xHCs

[Mathias Nyman]

On 07/17/2014 10:50 PM, Julius Werner wrote:
>> Hmm. Wouldn't it be safer to have a quirk for this, and only enable
>> the workaround if the Asmedia controller is detected? This code is so
>> complicated that it is difficult to see whether this could have a
>> harmful effect on controllers without the bug.
> 
> Sorry for making it complicated, but it kinda has been like that
> before already... I don't think the new patch adds much confusion on
> its own. I would really advise against making this a quirk: checking
> for it in every case essentially doesn't cost us anything (just one
> more register compare that is negligible against all the
> cache-coherent memory accesses of walking the ring), and hardcoding a
> quirk would mean that we have to identify and add every host
> controller that does this individually.
> 
> I still haven't seen anything in the XHCI spec that actually forbids
> this behavior, so it might be a perfectly legal interpretation and who
> knows how many host controllers chose to do it that way. Until we find
> them all, we would have some really bad and hard to track down bugs on
> those controllers (we really just got lucky this time that Maciej was
> able to catch it in a bisect). I think it's better to program the
> driver defensively and able to deal with unexpected situations in
> general.
> --
> 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
> 

It's starting to get a bit too complicated.
xhci find_new_dequeue_state() now has four places where it can toggle the cycle 
bit
in addition to the cycle toggle in find_trb_seg().

In the end we really just want to do it max once.

I'll see if I can simplify the whole cycle bit code somehow.

If not, then we need to take this or revert the original patch

-Mathias

 
--
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/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Peter Griffin]

Hi Arnd,



> > 
> > I'm of course happy to change it if required. I see looking through that a 
> > lot 
> > of other platforms do it the way you describe with a
> > 
> > ehci-.c and ohci-.c
> 
> Right. We are trying to  gradually move some of them over to use the
> generic *hci-platform.c drivers though.

Right, ok I understand.
 
> > > Depending on what kind of special requirements the ST version has,
> > > this can be done either by using the generic ohci/ehci bindings
> > > with extensions where necessary, or by creating a new binding and
> > > new driver files that use 'ohci_init_driver'/'ehci_init_driver'
> > > to inherit from the common code.
> > > 
> > > The first of the two approaches is preferred.
> > 
> > We don't have anything particularly special, just a couple of reset lines,
> > clock, phy, etc.
> 
> Ok, good. Please see Documentation/devicetree/bindings/usb/usb-?hci.txt
> then. You might actually be able to just use the existing drivers
> without new code by just adding the proper DT nodes that follow these
> bindings.

The only issues I can see with the generic versions are: -
1) We also have a powerdown line in addition to the reset line both of which 
are 
exposed via reset controller API, so I would need to add that into ehci-platform
and ohci-platform.

2) We have a magic poke in st_ehci_configure_bus of the current driver to 
configure
the AHB to ST bus protocol convertor IP. I'm not quite sure where I could hook 
that
in (sorry... slightly pulling back on my "nothing special comment" a bit ;-).

3) We also set the rate of the ohci clock, which the generic driver doesn't do.

regards,

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

Re: [PATCH v2 1/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Alan Stern]

On Thu, 24 Jul 2014, Arnd Bergmann wrote:

> > > The way you do this apparently is to create a device that encapsulates
> > > the OHCI and the EHCI and then goes on to create child devices that
> > > are bound to the real drivers.
> > 
> > Yes, although this isn't the first driver to take that approach USB_HCD_BCMA
> > (bcma-hcd.c) and USB_HCD_SSB (ssb-hcd.c) do much the same thing.
> 
> I just had a look at them, and I think the case is different here:
> 
> For the two bcma driver, there is a discoverable bus (bcma) rather than
> the platform bus, and it only exposes one device, so the bcma-hcd driver
> is actually needed so we get two device that can be bound to the regular
> drivers.
> 
> For the ssb-hcd driver, it's less clear and that one could be
> reworked into two separate drivers.
> 
> > > The way it should be done however is to put the two host controllers
> > > into DT directly and describe their resources (phy, clock, reset, ...)
> > > using the DT bindings for those.
> > 
> > I'm of course happy to change it if required. I see looking through that a 
> > lot 
> > of other platforms do it the way you describe with a
> > 
> > ehci-.c and ohci-.c
> 
> Right. We are trying to  gradually move some of them over to use the
> generic *hci-platform.c drivers though.
> 
> > > Depending on what kind of special requirements the ST version has,
> > > this can be done either by using the generic ohci/ehci bindings
> > > with extensions where necessary, or by creating a new binding and
> > > new driver files that use 'ohci_init_driver'/'ehci_init_driver'
> > > to inherit from the common code.
> > > 
> > > The first of the two approaches is preferred.
> > 
> > We don't have anything particularly special, just a couple of reset lines,
> > clock, phy, etc.
> 
> Ok, good. Please see Documentation/devicetree/bindings/usb/usb-?hci.txt
> then. You might actually be able to just use the existing drivers
> without new code by just adding the proper DT nodes that follow these
> bindings.
> 
> > > > +   pdev->dev.parent = &parent->dev;
> > > > +   pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
> > > > +   pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> > > 
> > > This is something we shouldn't ever do these days, the DMA settings
> > > should come directly from DT without driver interaction.
> > 
> > Ok, I'll wait to hear the outcome of Greg/Alans views before either fixing
> > it or starting over.
> 
> Ok.

As far as I'm concerned, any of these approaches is okay although
putting everything into DT is the most desirable, because it will
minimize the code size.

Mostly what's at issue here is the design preferences of the people at 
Linaro and all others who work on architecture-specific stuff.

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 00/10 linux-next] drivers/usb: remove unnecessary break after goto/return

[Fabian Frederick]

> On 24 July 2014 at 13:37 Oliver Neukum  wrote:
>
>
> On Thu, 2014-07-24 at 10:18 +0200, Fabian Frederick wrote:
> > Small patchset addressing break redundancy on drivers/usb branch
> > (suggested by Joe Perches).
>
> Frankly, that is not a good idea. Somebody will remove a "goto"
> and forget to readd the "break"

No problem ; checkpatch would give a warning anyway. See "Possible switch
case/default not preceeded by break or fallthrough comment"

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

Re: [PATCH 00/10 linux-next] drivers/usb: remove unnecessary break after goto/return

[Joe Perches]

On Thu, 2014-07-24 at 17:46 +0200, Fabian Frederick wrote:
> 
> > On 24 July 2014 at 13:37 Oliver Neukum  wrote:
> >
> >
> > On Thu, 2014-07-24 at 10:18 +0200, Fabian Frederick wrote:
> > > Small patchset addressing break redundancy on drivers/usb branch
> > > (suggested by Joe Perches).
> >
> > Frankly, that is not a good idea. Somebody will remove a "goto"
> > and forget to readd the "break"
> 
> No problem ; checkpatch would give a warning anyway. See "Possible switch
> case/default not preceeded by break or fallthrough comment"

Generally true, but not everyone uses checkpatch.


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

Re: [PATCH] usb-core: Revert "usb-core: Remove Fix mes in file hcd.c"

[Greg KH]

On Thu, Jul 24, 2014 at 09:14:49AM -0400, Sasha Levin wrote:
> On 07/23/2014 12:49 PM, Greg KH wrote:
> > On Wed, Jul 23, 2014 at 08:56:10AM -0400, Sasha Levin wrote:
> >> > Revert since the commit message is incorrect and the original author 
> >> > refuses
> >> > to fix/maintain it because "it's in the kernel already".
> > How can someone "fix" a commit message that is already in the tree?  You
> > can't.  The code part is correct, so why introduce the issue back?
> 
> (I'm not trying to be aggressive, I just think that I misunderstand how this
> part of the process works exactly).
> 
> I thought we can always edit -next trees? Why do we have to maintain fast 
> forward
> on them?

I can never edit my public trees, because people base their work on
them, and they are public.

> What happens, if for example you take a patch that causes build breakage? 
> Would you
> add a revert after that or just yank the commit out of the tree?

I add a revert, or add a patch that fixes it.

> If you add a revert and leave the original broken commit in, wouldn't it 
> cause issues
> for anyone trying to bisect a build breakage?

Yes it does.

I can not rebase my public trees, nor should any other kernel
maintainer.  This has been true for _many_ years.

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: [PATCH] usb-core: Remove Fix mes in file hcd.c

[Nick Krause]

On Thu, Jul 24, 2014 at 9:07 AM, Vlastimil Babka  wrote:
> On 07/23/2014 05:24 AM, Nick Krause wrote:
>>
>> On Tue, Jul 22, 2014 at 8:44 PM, Sasha Levin  wrote:
>>>
>>> On 07/18/2014 10:52 PM, Nick Krause wrote:
>>
>> Please explain exactly why it's not needed, why it can never be NULL,
>> and
>> what prevents it from being NULL.
>>
>> "after dicussing" (do you run spellcheck on your mails?) won't mean
>> anything
>> to someone looking at this commit in a year.
>>
>> Your commit message also mentions usb_device which has nothing to do
>> with
>> your patch.
>>
>>
>> Thanks,
>> Sasha


 Sasha ,
 Greg seems to have signed it off.
 Cheers Nick
>>>
>>>
>>> Greg?
>>>
>>> Even if the patch is correct (and I'm not saying it is) the commit
>>> message is way off.
>>>
>>>
>>> Thanks,
>>> Sasha
>>
>>
>>
>> Sasha,
>> The patch is in the  kernel now.
>
>
> Greg's tree is not Linus' tree, so it's not set to stone in git commit
> history yet.
>
>
>> I am not going through the trouble of removing
>>
>> it, if you want to fix the commit message go on ahead.
>> Nick
>
>
> This kind of attitude might significantly lower your chances of future
> patches being accepted.
>
> Vlastimil
>
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>

I thought Greg's tree get's directly into the mainline and after
checking it seems to me in
 the mainline.
Cheers Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb-core: Revert "usb-core: Remove Fix mes in file hcd.c"

[Sasha Levin]

On 07/24/2014 12:04 PM, Greg KH wrote:
>> If you add a revert and leave the original broken commit in, wouldn't it 
>> cause issues
>> > for anyone trying to bisect a build breakage?
> Yes it does.
> 
> I can not rebase my public trees, nor should any other kernel
> maintainer.  This has been true for _many_ years.

This isn't the case with -mm, for example, where the tree does get edited
quite often.

What stops you from editing it even if people are working on it? 'git pull 
--rebase'
will dtrt for both the ff and the non-ff case, where the non-ff case would have 
happen
either way if those people kept tracking your -next tree.


Thanks,
Sasha
--
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/3] usb: host: st-hcd: Add USB HCD support for STi SoCs

[Arnd Bergmann]

On Thursday 24 July 2014 15:14:12 Peter Griffin wrote:

> > > > Depending on what kind of special requirements the ST version has,
> > > > this can be done either by using the generic ohci/ehci bindings
> > > > with extensions where necessary, or by creating a new binding and
> > > > new driver files that use 'ohci_init_driver'/'ehci_init_driver'
> > > > to inherit from the common code.
> > > > 
> > > > The first of the two approaches is preferred.
> > > 
> > > We don't have anything particularly special, just a couple of reset lines,
> > > clock, phy, etc.
> > 
> > Ok, good. Please see Documentation/devicetree/bindings/usb/usb-?hci.txt
> > then. You might actually be able to just use the existing drivers
> > without new code by just adding the proper DT nodes that follow these
> > bindings.
> 
> The only issues I can see with the generic versions are: -
> 1) We also have a powerdown line in addition to the reset line both of which 
> are 
> exposed via reset controller API, so I would need to add that into 
> ehci-platform
> and ohci-platform.

Ok, adding this would not be too hard.

> 2) We have a magic poke in st_ehci_configure_bus of the current driver to 
> configure
> the AHB to ST bus protocol convertor IP. I'm not quite sure where I could 
> hook that
> in (sorry... slightly pulling back on my "nothing special comment" a bit ;-).

Hmm, doing this would require adding some form of quirk, either by compatible
string or using an extra DT property for detection.

> 3) We also set the rate of the ohci clock, which the generic driver doesn't 
> do.

Hmm, I guess this is the reason why sometimes it's nice to have names associated
with the clocks. The generic driver assumes that all clocks just need to be
turned on, and we decided not to use any naming when that binding was 
introduced.

Each of these seems solvable, but the combination of these sounds like it
would be better to create a new pair of drivers. I'd suggest you start by making
a copy of ohci-platform and removing everything you don't need, then add support
for the three things above. Give the clock a name, in case we want to merge the
drivers again later.

Arnd
--
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: Linux 3.16-rc6

[Borislav Petkov]

On Thu, Jul 24, 2014 at 02:58:14PM +0200, Peter Zijlstra wrote:
> Of course we should have made the lockdep change before merging qrwlock,
> and that's entirely my fail, but with qrwlock in these new semantics are
> already a reality.
> 
> We could of course disable qrwlock until all such issues are cleared up
> (its the safe option)...

So we leave in the lockdep change and disable qrwlock ontop of
tip/locking/core. Nothing's hurt yet as this whole pile is queued for
3.17 anyway.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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 v4] usb:serial:pl2303: add GPIOs interface on PL2303

[Wang YanQing]

PL2303HX has two GPIOs, this patch add interface for it.

Signed-off-by: Wang YanQing 
---
 Changes v3-v4:
 1: fix missing static for gpio_dir_mask and gpio_value_mask
 2: reduce unneeded compile macro defined suggested by 
gno...@lxorguk.ukuu.org.uk
 3: use true instead of 1 corrected by Linus Walleij
 4: ignore return value of gpiochip_remove suggested by Linus Walleij
 5: fix multi gpio_chips registered by pl2303 can't be distinguished in kernel 
space.

Give different labels to different gpio_chips is good for diagnostic,
and we could identify per gpio_chip registered by pl2303 by try different
lable name then detect its parent device.


 drivers/usb/serial/Kconfig  |  10 +++
 drivers/usb/serial/pl2303.c | 163 
 2 files changed, 173 insertions(+)

diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
index 3ce5c74..4bc0d0f 100644
--- a/drivers/usb/serial/Kconfig
+++ b/drivers/usb/serial/Kconfig
@@ -516,6 +516,16 @@ config USB_SERIAL_PL2303
  To compile this driver as a module, choose M here: the
  module will be called pl2303.
 
+config USB_SERIAL_PL2303_GPIO
+   bool "USB Prolific 2303 Single Port GPIOs support"
+   depends on USB_SERIAL_PL2303 && GPIOLIB
+   ---help---
+ Say Y here if you want to use the GPIOs on PL2303 USB Serial single 
port
+ adapter from Prolific.
+
+ It support 2 GPIOs on PL2303HX currently,
+ if unsure, say N.
+
 config USB_SERIAL_OTI6858
tristate "USB Ours Technology Inc. OTi-6858 USB To RS232 Bridge 
Controller"
help
diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index b3d5a35..f5c0df6 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "pl2303.h"
 
 
@@ -143,9 +145,25 @@ struct pl2303_type_data {
unsigned long quirks;
 };
 
+struct pl2303_gpio {
+   /*
+* 0..3: unknown (zero)
+* 4: gp0 output enable (1: gp0 pin is output, 0: gp0 pin is input)
+* 5: gp1 output enable (1: gp1 pin is output, 0: gp1 pin is input)
+* 6: gp0 pin value
+* 7: gp1 pin value
+*/
+   u8 index;
+   struct usb_serial *serial;
+   struct gpio_chip gpio_chip;
+};
+
 struct pl2303_serial_private {
const struct pl2303_type_data *type;
unsigned long quirks;
+#ifdef CONFIG_USB_SERIAL_PL2303_GPIO
+   struct pl2303_gpio *gpio;
+#endif
 };
 
 struct pl2303_private {
@@ -213,6 +231,145 @@ static int pl2303_probe(struct usb_serial *serial,
return 0;
 }
 
+#ifdef CONFIG_USB_SERIAL_PL2303_GPIO
+#define GPIO_NUM (2)
+static u8 gpio_dir_mask[GPIO_NUM] = {0x10, 0x20};
+static u8 gpio_value_mask[GPIO_NUM] = {0x40, 0x80};
+static atomic_t gpio_chip_index = ATOMIC_INIT(-1);
+
+static inline struct pl2303_gpio *to_pl2303_gpio(struct gpio_chip *chip)
+{
+   return container_of(chip, struct pl2303_gpio, gpio_chip);
+}
+
+static int pl2303_gpio_direction_in(struct gpio_chip *chip, unsigned offset)
+{
+   struct pl2303_gpio *gpio = to_pl2303_gpio(chip);
+
+   if (offset >= chip->ngpio)
+   return -EINVAL;
+
+   gpio->index &= ~gpio_dir_mask[offset];
+   pl2303_vendor_write(gpio->serial, 1, gpio->index);
+   return 0;
+}
+
+static int pl2303_gpio_direction_out(struct gpio_chip *chip,
+   unsigned offset, int value)
+{
+   struct pl2303_gpio *gpio = to_pl2303_gpio(chip);
+
+   if (offset >= chip->ngpio)
+   return -EINVAL;
+
+   gpio->index |= gpio_dir_mask[offset];
+   if (value)
+   gpio->index |= gpio_value_mask[offset];
+   else
+   gpio->index &= ~gpio_value_mask[offset];
+
+   pl2303_vendor_write(gpio->serial, 1, gpio->index);
+   return 0;
+}
+
+static void pl2303_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+   struct pl2303_gpio *gpio = to_pl2303_gpio(chip);
+
+   if (offset >= chip->ngpio)
+   return;
+
+   if (value)
+   gpio->index |= gpio_value_mask[offset];
+   else
+   gpio->index &= ~gpio_value_mask[offset];
+
+   pl2303_vendor_write(gpio->serial, 1, gpio->index);
+}
+
+static int pl2303_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+   struct pl2303_gpio *gpio = to_pl2303_gpio(chip);
+   unsigned char buf[1];
+   int value = 0;
+
+   if (offset >= chip->ngpio)
+   return -EINVAL;
+
+   if (pl2303_vendor_read(gpio->serial, 0x0081, buf))
+   return -EIO;
+
+   value = buf[0] & gpio_value_mask[offset];
+   return value;
+}
+
+static const struct gpio_chip template_chip = {
+   .owner  = THIS_MODULE,
+   .direction_input= pl2303_gpio_direction_in,
+   .get= pl2303_gpio_get,
+   .direction_output   = pl2303_gpio_directio

Re: Report about a "please report the device ID to the Linux USB developers!" message

[Antonio]

Hi!

>  [...] will probably fix your problem
Thank you for being kind. As far as I can tell, the modem is working 
correctly, I wrote to this list because I saw a 
"usb_modeswitch: please report the device ID to the Linux USB developers!"
message and I thought that reporting was my duty :-). But now I have the doubt 
that if the reporting must be done always, or only in some cases.

This is the last message and the prior ones:
Jul 23 19:19:53 laptop kernel: [63032.491639] sd 32:0:0:0: [sdc] 
Attached SCSI removable disk
Jul 23 19:19:53 laptop usb_modeswitch: switched to 19d2: on 
002/045
Jul 23 19:19:54 laptop usb_modeswitch[9252]: usb_modeswitch: switched 
to 19d2:0117 on 2/46
Jul 23 19:19:55 laptop usb_modeswitch[9252]: usb_modeswitch: add 
device ID 19d2:0117 to driver option
   Jul 23 19:19:55 laptop usb_modeswitch[9252]: usb_modeswitch: please 
report the device ID to the Linux USB developers!
Maybe some text could be added to the last message to let the user know when 
he should report the device ID to the Linux USB developers (always, or only in 
some cases).

If the device 19d2:0117 is already supported by the option serial driver, as 
you said, then it's possibly an effect of the bug that you talked about in the 
text:
"What we see here is a device not being stable on the usb bus and the
same has been reported for Ubuntu 14.04, multiple switching due to the
device being reset" 
and then other people may write in this list while this bug is not solved.

> error -108 in your log is caused by the dongle no longer present, the
> device numbers you get (44,45,46,47) are unusually high unless you have
> plugged in and out a device so many times on that port. 
Yes, yesterday I plugged in and out the device many times when I had to do 
some tests, you are clever :-).  I looked for that "please report the device 
ID to the Linux USB developers" text in the other /var/log/syslog* files, and 
it isn't there, that message only was in the log of yesterday.

Many thanks for all!
--
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: Linux 3.16-rc6

[Linus Torvalds]

On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra  wrote:
>
> So going by the nifty picture rostedt made:
>
> [   61.454336]CPU0CPU1
> [   61.454336]
> [   61.454336]   lock(&(&p->alloc_lock)->rlock);
> [   61.454336]local_irq_disable();
> [   61.454336]lock(tasklist_lock);
> [   61.454336]lock(&(&p->alloc_lock)->rlock);
> [   61.454336]   
> [   61.454336] lock(tasklist_lock);

So this *should* be fine. It always has been in the past, and it was
certainly the *intention* that it should continue to work with
qrwlock, even in the presense of pending writers on other cpu's.

The qrwlock rules are that a read-lock in an interrupt is still going
to be unfair and succeed if there are other readers.

> the fact that CPU1 holds tasklist_lock for reading, does not
> automagically allow CPU0 to acquire tasklist_lock for reading too, for
> example if CPU2 (not in the picture) is waiting to acquire tasklist_lock
> for writing, CPU0's read acquire is made to wait.

No.

That is true for qrwlock in general. But *not* in interrupt context.
In interrupt context, it's unfair. At least that was the _intent_ of
the code, maybe that got screwed up some way.

> The only kind of recursion that's safe is same CPU interrupt.

Any read-lock from an irq should still be unfair, no "same CPU" rules.
See queue_read_lock_slowpath(), where it will just wait for any actual
write lockers (not *waiting* writers) to go away. So by definition, of
somebody else (not just the current CPU) holds the lock for reading,
taking it for reading is safe on all cpu's in irq context, because we
obviously won't be waiting for any actual write lock holders.

So it sounds to me like the new lockdep rules in tip/master are too
strict and are throwing a false positive.

  Linus
--
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: Linux 3.16-rc6

[Peter Zijlstra]

On Thu, Jul 24, 2014 at 11:18:16AM -0700, Linus Torvalds wrote:
> On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra  wrote:
> >
> > So going by the nifty picture rostedt made:
> >
> > [   61.454336]CPU0CPU1
> > [   61.454336]
> > [   61.454336]   lock(&(&p->alloc_lock)->rlock);
> > [   61.454336]local_irq_disable();
> > [   61.454336]lock(tasklist_lock);
> > [   61.454336]
> > lock(&(&p->alloc_lock)->rlock);
> > [   61.454336]   
> > [   61.454336] lock(tasklist_lock);
> 
> So this *should* be fine. It always has been in the past, and it was
> certainly the *intention* that it should continue to work with
> qrwlock, even in the presense of pending writers on other cpu's.
> 
> The qrwlock rules are that a read-lock in an interrupt is still going
> to be unfair and succeed if there are other readers.

Ah, indeed. Should have checked :/

> So it sounds to me like the new lockdep rules in tip/master are too
> strict and are throwing a false positive.

Right. Waiman can you have a look?
--
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: Linux 3.16-rc6

[Waiman Long]

On 07/24/2014 02:36 PM, Peter Zijlstra wrote:

On Thu, Jul 24, 2014 at 11:18:16AM -0700, Linus Torvalds wrote:

On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra  wrote:

So going by the nifty picture rostedt made:

[   61.454336]CPU0CPU1
[   61.454336]
[   61.454336]   lock(&(&p->alloc_lock)->rlock);
[   61.454336]local_irq_disable();
[   61.454336]lock(tasklist_lock);
[   61.454336]lock(&(&p->alloc_lock)->rlock);
[   61.454336]
[   61.454336] lock(tasklist_lock);

So this *should* be fine. It always has been in the past, and it was
certainly the *intention* that it should continue to work with
qrwlock, even in the presense of pending writers on other cpu's.

The qrwlock rules are that a read-lock in an interrupt is still going
to be unfair and succeed if there are other readers.

Ah, indeed. Should have checked :/


So it sounds to me like the new lockdep rules in tip/master are too
strict and are throwing a false positive.

Right. Waiman can you have a look?


Yes, I think I may have a solution for that.

Borislav, can you apply the following patch on top of the lockdep patch 
to see if it can fix the problem?


diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index d24e433..507a8ce 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3595,6 +3595,12 @@ void lock_acquire(struct lockdep_map *lock, 
unsigned int

raw_local_irq_save(flags);
check_flags(flags);

+   /*
+* An interrupt recursive read in interrupt context can be 
considered

+* to be the same as a recursive read from checking perspective.
+*/
+   if ((read == 3) && in_interrupt())
+   read = 2;
current->lockdep_recursion = 1;
trace_lock_acquire(lock, subclass, trylock, read, check, 
nest_lock, ip);

__lock_acquire(lock, subclass, trylock, read, check,

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

Re: [PATCH] usb-core: Revert "usb-core: Remove Fix mes in file hcd.c"

[Greg KH]

On Thu, Jul 24, 2014 at 12:20:37PM -0400, Sasha Levin wrote:
> On 07/24/2014 12:04 PM, Greg KH wrote:
> >> If you add a revert and leave the original broken commit in, wouldn't it 
> >> cause issues
> >> > for anyone trying to bisect a build breakage?
> > Yes it does.
> > 
> > I can not rebase my public trees, nor should any other kernel
> > maintainer.  This has been true for _many_ years.
> 
> This isn't the case with -mm, for example, where the tree does get edited
> quite often.

-mm is a set of quilt patches, not a git tree.

> What stops you from editing it even if people are working on it? 'git pull 
> --rebase'
> will dtrt for both the ff and the non-ff case, where the non-ff case would 
> have happen
> either way if those people kept tracking your -next tree.

No, subsystem maintainers are not allowed to break their trees like
this, unless something really major happens that requires it.

Again, it's been this way for years, and is one of the requirements of
subsystem maintainers.  If you want a "testing" branch, use a "testing"
branch, but don't cause problems on your "real" branch or problems will
happen.

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: Linux 3.16-rc6

[Borislav Petkov]

On Thu, Jul 24, 2014 at 04:38:28PM -0400, Waiman Long wrote:
> Borislav, can you apply the following patch on top of the lockdep
> patch to see if it can fix the problem?

It is too late here for me to test anything but the ingridients to
reproduce are nothing special. Just grab a kvm guest and pick out the
locking or so options out of the .config I sent previously. Then boot it
a couple of times, it triggers pretty easy after a couple of tries.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
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: Linux 3.16-rc6

[John Stoffel]

> "Waiman" == Waiman Long  writes:

Waiman> On 07/24/2014 02:36 PM, Peter Zijlstra wrote:
>> On Thu, Jul 24, 2014 at 11:18:16AM -0700, Linus Torvalds wrote:
>>> On Thu, Jul 24, 2014 at 5:58 AM, Peter Zijlstra  
>>> wrote:
 So going by the nifty picture rostedt made:
 
 [   61.454336]CPU0CPU1
 [   61.454336]
 [   61.454336]   lock(&(&p->alloc_lock)->rlock);
 [   61.454336]local_irq_disable();
 [   61.454336]lock(tasklist_lock);
 [   61.454336]
 lock(&(&p->alloc_lock)->rlock);
 [   61.454336]
 [   61.454336] lock(tasklist_lock);
>>> So this *should* be fine. It always has been in the past, and it was
>>> certainly the *intention* that it should continue to work with
>>> qrwlock, even in the presense of pending writers on other cpu's.
>>> 
>>> The qrwlock rules are that a read-lock in an interrupt is still going
>>> to be unfair and succeed if there are other readers.
>> Ah, indeed. Should have checked :/
>> 
>>> So it sounds to me like the new lockdep rules in tip/master are too
>>> strict and are throwing a false positive.
>> Right. Waiman can you have a look?

Waiman> Yes, I think I may have a solution for that.

Waiman> Borislav, can you apply the following patch on top of the lockdep patch 
Waiman> to see if it can fix the problem?

Waiman> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
Waiman> index d24e433..507a8ce 100644
Waiman> --- a/kernel/locking/lockdep.c
Waiman> +++ b/kernel/locking/lockdep.c
Waiman> @@ -3595,6 +3595,12 @@ void lock_acquire(struct lockdep_map *lock, 
Waiman> unsigned int
Waiman>  raw_local_irq_save(flags);
Waiman>  check_flags(flags);

Waiman> +   /*
Waiman> +* An interrupt recursive read in interrupt context can be 
Waiman> considered
Waiman> +* to be the same as a recursive read from checking perspective.
Waiman> +*/
Waiman> +   if ((read == 3) && in_interrupt())
Waiman> +   read = 2;
current-> lockdep_recursion = 1;
Waiman>  trace_lock_acquire(lock, subclass, trylock, read, check, 
Waiman> nest_lock, ip);
Waiman>  __lock_acquire(lock, subclass, trylock, read, check,

Instead of the magic numbers 1,2,3, could you use some nicely named
constants here instead?  

John
--
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: OMAP3/AM3517 EHCI USB Issue

[Michael Welling]

On Wed, Jul 23, 2014 at 3:34 PM, Michael Welling  wrote:
> There appears to be a bug in the USB host driver for the AM3517 in the
> 3.16 kernel. When the AM3517 board boots with a USB device plugged in
> the host it detects and works fines as long as it is plugged in.
>
> The board does not detect any device that is hotplugged and the kernel
> message report nothing.
>
> The board that I am porting is using the USB3320 PHY connected to the
> USB host 1 interface. It should be noted that the same hardware worked
> fine using an old 2.6.30 kernel.
>
> The kernel has drastically changed since then and it appears that
> something broke along the way.
>
> I did notice this magical code in the old kernel:
> http://marc.info/?l=linux-usb&m=127841764930798&w=2
So I may be barking up the wrong tree on this one.

Today I discovered something that may lead to the resolution of my issue.

The hardware I am using incorporates a USB switch on-board to avoid the
having an external switch to plug in keyboards etc. If two devices are plugged
into the downstream ports they are both detected on boot. When I unplug
one of the devices and plug it back in, it is detected again.

As long as one downstream device ports is populated the device discovery works
on the other. Any clue on this?

This reminded of a note that I made on the schematic after talking to SMSC.

Set "UseExternalVbus Indicator" BIT 7 in register 0x0a.

This is a PHY register that may actually be accessible in
drivers/usb/phy/phy-ulpi.c
but it looks like I cannot access the code from device tree.

What would be the best way to go about adding support for this?

Added a few more on the CC list to see if I can get any answers.

https://lkml.org/lkml/2013/12/4/50

>
> Since then the PHY code and host driver have been seperated. I am not
> sure that the soft reset is ever being performed. I do notice that there
> are remnants of the old driver as there are multiple macro defines that
> are never used in the driver:
> #define EHCI_INSNREG05_ULPI (0xA4)
> #define EHCI_INSNREG05_ULPI_CONTROL_SHIFT   31
> #define EHCI_INSNREG05_ULPI_PORTSEL_SHIFT   24
> #define EHCI_INSNREG05_ULPI_OPSEL_SHIFT 22
> #define EHCI_INSNREG05_ULPI_REGADD_SHIFT16
> #define EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
> #define EHCI_INSNREG05_ULPI_WRDATA_SHIFT0
>
> Any advice as to how to address this would be greatly appreciated.
--
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 8/8] usb: chipidea: add support to the generic PHY framework in ChipIdea

[Peter Chen]

 
> > >
> > > - if (ci->platdata->usb_phy)
> > > + if (ci->platdata->phy)
> > > + ci->phy = ci->platdata->phy;
> > > + else if (ci->platdata->usb_phy)
> > >   ci->usb_phy = ci->platdata->usb_phy;
> > >   else
> > > - ci->usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> > > + ci->phy = of_phy_get(dev->of_node, 0);
> >
> > Here, we may need to consider both usb_phy and generic_phy, and the
> > core device is not populated from device tree.
> >
> > You can use devm_usb_get_phy and devm_phy_get for global phy case.
> 
> This is the case. If no PHY is found by of_phy_get() we try to get an USB
> PHY by calling devm_usb_get_phy().
> 

Like I said above, the core device is not populated from DT, so the DT version
phy API may not be needed. 

> >
> > >
> > > - if (IS_ERR(ci->usb_phy)) {
> > > - ret = PTR_ERR(ci->usb_phy);
> > > + if (IS_ERR(ci->phy)) {
> > >   /*
> > >* if -ENXIO is returned, it means PHY layer wasn't
> > >* enabled, so it makes no sense to return -EPROBE_DEFER
> > >* in that case, since no PHY driver will ever probe.
> > >*/
> > > - if (ret == -ENXIO)
> > > - return ret;
> > > + if (PTR_ERR(ci->phy) == -ENXIO)
> > > + return -ENXIO;
> > >
> > > - dev_err(dev, "no usb2 phy configured\n");
> > > - return -EPROBE_DEFER;
> > > + ci->usb_phy = devm_usb_get_phy(dev, USB_PHY_TYPE_USB2);
> > > + if (IS_ERR(ci->usb_phy)) {
> > > + dev_err(dev, "no usb2 phy configured\n");
> > > + return -EPROBE_DEFER;
> > > + }
> > >   }
> 
> [snip]
> 
> > > diff --git a/drivers/usb/chipidea/debug.c
> > > b/drivers/usb/chipidea/debug.c index d47cddd38e4a..77881a5ce48f
> > > 100644
> > > --- a/drivers/usb/chipidea/debug.c
> > > +++ b/drivers/usb/chipidea/debug.c
> > > @@ -219,7 +219,9 @@ int ci_otg_show(struct seq_file *s, void *unused)
> > >   fsm = &ci->fsm;
> > >
> > >   /* -- State - */
> > > - usb_otg_state_string(ci->usb_phy->otg.state));
> > > + if (ci->usb_phy)
> > > + seq_printf(s, "OTG state: %s\n\n",
> > > + usb_otg_state_string(ci->usb_phy->otg->state));
> >
> > You may change wrongly here.
> 
> I thought a pointer to the OTG info wasn't available from there. I just
> checked, and it seems we can retrieve if from the otg_fsm structure here.
> I'll test and update.
> 
> > > @@ -85,13 +88,16 @@ static int host_start(struct ci_hdrc *ci)
> > >   if (ret) {
> > >   goto disable_reg;
> > >   } else {
> > > - struct usb_otg *otg = ci->usb_phy->otg;
> > > + if (ci->usb_phy) {
> > > + struct usb_otg *otg = ci->usb_phy->otg;
> > >
> > > - ci->hcd = hcd;
> > > - if (otg) {
> > > - otg->host = &hcd->self;
> > > - hcd->self.otg_port = 1;
> > > + if (otg) {
> > > + otg->host = &hcd->self;
> > > + hcd->self.otg_port = 1;
> > > + }
> > >   }
> >
> > The otg port is still existed even use generic phy.
> 
> Yes. I don't know how to retrieve the OTG pointer when we do not use an
> USB PHY. We may have to add an OTG member into the ci_hdrc structure, but
> I didn't understand well where does occur this OTG setup.
> 
> I may have missed something. Do you know if CI OTG always is in FSM mode?
> If so we could access the OTG pointer through ci_hdrc->fsm.
> 

Just add OTG member into ci_hdrc structure, see below patch

diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
index 9563cb5..186fb3f 100644
--- a/drivers/usb/chipidea/ci.h
+++ b/drivers/usb/chipidea/ci.h
@@ -207,6 +207,7 @@ struct ci_hdrc {
boolid_event;
boolb_sess_valid_event;
boolimx28_write_fix;
+   struct usb_otg  otg;
 };
 
 static inline struct ci_role_driver *ci_role(struct ci_hdrc *ci)
diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
index a93d950..70d7fe2 100644
--- a/drivers/usb/chipidea/host.c
+++ b/drivers/usb/chipidea/host.c
@@ -85,7 +85,7 @@ static int host_start(struct ci_hdrc *ci)
if (ret) {
goto disable_reg;
} else {
-   struct usb_otg *otg = ci->transceiver->otg;
+   struct usb_otg *otg = &ci->otg;
 
ci->hcd = hcd;
if (otg) {
diff --git a/drivers/usb/chipidea/otg_fsm.c b/drivers/usb/chipidea/otg_fsm.c
index 8cb2508..fc8847e 100644
--- a/drivers/usb/chipidea/otg_fsm.c
+++ b/drivers/usb/chipidea/otg_fsm.c
@@ -778,20 +778,8 @@ void ci_hdrc_otg_fsm_start(struct ci_hdrc *ci)
 int ci_hdrc_otg_fsm_init(struct ci_hdrc *ci)
 {
int retval = 0;
-   struct usb_otg *otg;
 
-   otg = devm_kzalloc(ci->dev,
-   sizeof(struct usb_otg), GFP_KERNEL);
-   if (!ot

Re: Report about a "please report the device ID to the Linux USB developers!" message

[Lars Melin]

On 2014-07-25 00:50, Antonio wrote:

Hi!


  [...] will probably fix your problem

Thank you for being kind. As far as I can tell, the modem is working
correctly, I wrote to this list because I saw a
"usb_modeswitch: please report the device ID to the Linux USB developers!"
message and I thought that reporting was my duty :-). But now I have the doubt
that if the reporting must be done always, or only in some cases.

This is the last message and the prior ones:
 Jul 23 19:19:53 laptop kernel: [63032.491639] sd 32:0:0:0: [sdc]
Attached SCSI removable disk
 Jul 23 19:19:53 laptop usb_modeswitch: switched to 19d2: on
002/045
 Jul 23 19:19:54 laptop usb_modeswitch[9252]: usb_modeswitch: switched
to 19d2:0117 on 2/46
 Jul 23 19:19:55 laptop usb_modeswitch[9252]: usb_modeswitch: add
device ID 19d2:0117 to driver option
Jul 23 19:19:55 laptop usb_modeswitch[9252]: usb_modeswitch: please
report the device ID to the Linux USB developers!
Maybe some text could be added to the last message to let the user know when
he should report the device ID to the Linux USB developers (always, or only in
some cases).

If the device 19d2:0117 is already supported by the option serial driver, as
you said, then it's possibly an effect of the bug that you talked about in the
text:
"What we see here is a device not being stable on the usb bus and the
same has been reported for Ubuntu 14.04, multiple switching due to the
device being reset"
and then other people may write in this list while this bug is not solved.


error -108 in your log is caused by the dongle no longer present, the
device numbers you get (44,45,46,47) are unusually high unless you have
plugged in and out a device so many times on that port.

Yes, yesterday I plugged in and out the device many times when I had to do
some tests, you are clever :-).  I looked for that "please report the device
ID to the Linux USB developers" text in the other /var/log/syslog* files, and
it isn't there, that message only was in the log of yesterday.

Many thanks for all!
The usb_modeswitch  driver loading/driver bind check could do with an 
additional test when driver binding has failed, a check to see if the 
device has disappeared from the bus during the 1 sec time when 
usb_modeswitch waits for the driver to bind.
If it has disappeared then don't throw the message about reporting the 
device to linux USB developers, I will suggest this to the creator of 
the program.

--
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 07/12] usb: chipidea: add a usb2 driver for ci13xxx

[Peter Chen]

On Wed, Jul 16, 2014 at 10:26:01AM +0200, Antoine Ténart wrote:
> Add a USB2 ChipIdea driver for ci13xxx, with optional PHY, clock
> and DMA mask, to support USB2 ChipIdea controllers that don't need
> specific functions.

You may need to indicate it is a generic usb2 glue layer driver at both
subject and context.
> 
> Needed for the Marvell Berlin SoCs USB controllers.

You can say it is tested at Marvell Berlin SoCs USB controllers.

> 
> Signed-off-by: Antoine Ténart 
> ---
>  drivers/usb/chipidea/Makefile   |   1 +
>  drivers/usb/chipidea/ci_hdrc_usb2.c | 147 
> 
>  2 files changed, 148 insertions(+)
>  create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c
> 
> diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
> index 2f099c7df7b5..1fc86a2ca22d 100644
> --- a/drivers/usb/chipidea/Makefile
> +++ b/drivers/usb/chipidea/Makefile
> @@ -10,6 +10,7 @@ ci_hdrc-$(CONFIG_USB_OTG_FSM)   += otg_fsm.o
>  
>  # Glue/Bridge layers go here
>  
> +obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_usb2.o
>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_msm.o
>  obj-$(CONFIG_USB_CHIPIDEA)   += ci_hdrc_zevio.o
>  
> diff --git a/drivers/usb/chipidea/ci_hdrc_usb2.c 
> b/drivers/usb/chipidea/ci_hdrc_usb2.c
> new file mode 100644
> index ..4ec2240d00a1
> --- /dev/null
> +++ b/drivers/usb/chipidea/ci_hdrc_usb2.c
> @@ -0,0 +1,147 @@
> +/*
> + * Copyright (C) 2014 Marvell Technology Group Ltd.
> + *
> + * Antoine Ténart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ci.h"
> +
> +struct ci_hdrc_usb2_priv {
> + struct platform_device  *ci_pdev;
> + struct clk  *clk;
> + u32 dma_mask;
> +};
> +
> +static int ci_hdrc_usb2_dt_probe(struct device *dev,
> + struct ci_hdrc_platform_data *ci_pdata,
> + struct ci_hdrc_usb2_priv *priv)
> +{
> + u32 mask;
> + int ret;
> +
> + priv->clk = devm_clk_get(dev, NULL);
> + if (!IS_ERR(priv->clk)) {
> + ret = clk_prepare_enable(priv->clk);
> + if (ret) {
> + dev_err(dev, "failed to enable the clock: %d\n", ret);
> + return ret;
> + }
> + }

The clk API may be needed for both DT and non-DT cases.

> +
> + ci_pdata->phy = of_phy_get(dev->of_node, 0);
> + if (IS_ERR(ci_pdata->phy)) {
> + if (PTR_ERR(ci_pdata->phy) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> +
> + /* PHY is optional */
> + ci_pdata->phy = NULL;
> + }
> +
> + if (of_property_read_u32(dev->of_node, "dma-mask", &mask))
> + priv->dma_mask = mask;
> +
According to discussion, you may not need dma_mask in driver any more,
and use below API for both DT and non-DT case.

err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
if (err)
handle error;

Peter

> + return 0;
> +}
> +
> +static struct ci_hdrc_platform_data ci_default_pdata = {
> + .capoffset  = DEF_CAPOFFSET,
> + .flags  = CI_HDRC_REQUIRE_TRANSCEIVER |
> +   CI_HDRC_DISABLE_STREAMING,
> +};
> +
> +static int ci_hdrc_usb2_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct ci_hdrc_usb2_priv *priv;
> + struct ci_hdrc_platform_data *ci_pdata = dev_get_platdata(&pdev->dev);
> + int ret;
> +
> + if (!ci_pdata)
> + ci_pdata = &ci_default_pdata;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + if (dev->of_node) {
> + ret = ci_hdrc_usb2_dt_probe(dev, ci_pdata, priv);
> + if (ret)
> + return ret;
> + }
> +
> + ci_pdata->name = dev_name(&pdev->dev);
> +
> + if (priv->dma_mask) {
> + ret = dma_coerce_mask_and_coherent(&pdev->dev, priv->dma_mask);
> + if (ret)
> + return ret;
> + }
> +
> + priv->ci_pdev = ci_hdrc_add_device(dev, pdev->resource,
> +  pdev->num_resources, ci_pdata);
> + if (IS_ERR(priv->ci_pdev)) {
> + ret = PTR_ERR(priv->ci_pdev);
> + if (ret != -EPROBE_DEFER)
> + dev_err(dev,
> + "failed to register ci_hdrc platform device: 
> %d\n",
> + ret);
> + goto clk_err;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + pm_runtime_no_callbacks(dev);
> + pm_runtime_enable(dev);
> +
> + return 0;
> +
> +clk_err:
> + if (!IS_E

[PATCH resend] Revert "usb: gadget: u_ether: synchronize with transmit when stopping queue"

[roy . qing . li]

From: Li RongQing 

This reverts commit a9232076374334ca2bc2a448dfde96d38a54349a.

It introduced a dead lock, and did not fix anything.

it made netif_tx_lock() be called in IRQ context, but in softirq context,
the same lock is locked without disabling IRQ. In fact, the commit a923207637
did not fix anything, since netif_stop_queue did not free the any resource

[   10.154920] =
[   10.156026] [ INFO: inconsistent lock state ]
[   10.156026] 3.16.0-rc5+ #13 Not tainted
[   10.156026] -
[   10.156026] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[   10.156026] swapper/1/0 [HC0[0]:SC1[5]:HE1:SE0] takes:
[   10.156026]  (_xmit_ETHER){?.-...}, at: [<80948b6a>] 
sch_direct_xmit+0x7a/0x250
[   10.156026] {IN-HARDIRQ-W} state was registered at:
[   10.156026]   [<804811f0>] __lock_acquire+0x800/0x17a0
[   10.156026]   [<804828ba>] lock_acquire+0x6a/0xf0
[   10.156026]   [<809ed477>] _raw_spin_lock+0x27/0x40
[   10.156026]   [<8088d508>] gether_disconnect+0x68/0x280
[   10.156026]   [<8088e777>] eem_set_alt+0x37/0xc0
[   10.156026]   [<808847ce>] composite_setup+0x30e/0x1240
[   10.156026]   [<8088b8ae>] pch_udc_isr+0xa6e/0xf50
[   10.156026]   [<8048abe8>] handle_irq_event_percpu+0x38/0x1e0
[   10.156026]   [<8048adc1>] handle_irq_event+0x31/0x50
[   10.156026]   [<8048d94b>] handle_fasteoi_irq+0x6b/0x140
[   10.156026]   [<804040a5>] handle_irq+0x65/0x80
[   10.156026]   [<80403cfc>] do_IRQ+0x3c/0xc0
[   10.156026]   [<809ee6ae>] common_interrupt+0x2e/0x34
[   10.156026]   [<804668c5>] finish_task_switch+0x65/0xd0
[   10.156026]   [<809e89df>] __schedule+0x20f/0x7d0
[   10.156026]   [<809e94aa>] schedule_preempt_disabled+0x2a/0x70
[   10.156026]   [<8047bf03>] cpu_startup_entry+0x143/0x410
[   10.156026]   [<809e2e61>] rest_init+0xa1/0xb0
[   10.156026]   [<80ce2a3b>] start_kernel+0x336/0x33b
[   10.156026]   [<80ce22ab>] i386_start_kernel+0x79/0x7d
[   10.156026] irq event stamp: 52070
[   10.156026] hardirqs last  enabled at (52070): [<809375de>] 
neigh_resolve_output+0xee/0x2a0
[   10.156026] hardirqs last disabled at (52069): [<809375a8>] 
neigh_resolve_output+0xb8/0x2a0
[   10.156026] softirqs last  enabled at (52020): [<8044401f>] 
_local_bh_enable+0x1f/0x50
[   10.156026] softirqs last disabled at (52021): [<80404036>] 
do_softirq_own_stack+0x26/0x30
[   10.156026]
[   10.156026] other info that might help us debug this:
[   10.156026]  Possible unsafe locking scenario:
[   10.156026]
[   10.156026]CPU0
[   10.156026]
[   10.156026]   lock(_xmit_ETHER);
[   10.156026]   
[   10.156026] lock(_xmit_ETHER);
[   10.156026]
[   10.156026]  *** DEADLOCK ***
[   10.156026]
[   10.156026] 4 locks held by swapper/1/0:
[   10.156026]  #0:  (((&idev->mc_ifc_timer))){+.-...}, at: [<8044b100>] 
call_timer_fn+0x0/0x190
[   10.156026]  #1:  (rcu_read_lock){..}, at: [] 
mld_sendpack+0x0/0x590 [ipv6]
[   10.156026]  #2:  (rcu_read_lock_bh){..}, at: [] 
ip6_finish_output2+0x4c/0x7f0 [ipv6]
[   10.156026]  #3:  (rcu_read_lock_bh){..}, at: [<8092e510>] 
__dev_queue_xmit+0x0/0x5f0
[   10.156026]
[   10.156026] stack backtrace:
[   10.156026] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.16.0-rc5+ #13
[   10.156026]  811dbb10  9e919d10 809e6785 9e8b8000 9e919d3c 809e561e 
80b95511
[   10.156026]  80b9545a 80b9543d 80b95450 80b95441 80b957e4 9e8b84e0 0002 
8047f7b0
[   10.156026]  9e919d5c 8048043b 0002  9e8b8000 0001 0004 
9e8b8000
[   10.156026] Call Trace:
[   10.156026]  [<809e6785>] dump_stack+0x48/0x69
[   10.156026]  [<809e561e>] print_usage_bug+0x18f/0x19c
[   10.156026]  [<8047f7b0>] ? print_shortest_lock_dependencies+0x170/0x170
[   10.156026]  [<8048043b>] mark_lock+0x53b/0x5f0
[   10.156026]  [<804810cf>] __lock_acquire+0x6df/0x17a0
[   10.156026]  [<804828ba>] lock_acquire+0x6a/0xf0
[   10.156026]  [<80948b6a>] ? sch_direct_xmit+0x7a/0x250
[   10.156026]  [<809ed477>] _raw_spin_lock+0x27/0x40
[   10.156026]  [<80948b6a>] ? sch_direct_xmit+0x7a/0x250
[   10.156026]  [<80948b6a>] sch_direct_xmit+0x7a/0x250
[   10.156026]  [<8092e6bf>] __dev_queue_xmit+0x1af/0x5f0
[   10.156026]  [<80947fc0>] ? ether_setup+0x80/0x80
[   10.156026]  [<8092eb0f>] dev_queue_xmit+0xf/0x20
[   10.156026]  [<8093764c>] neigh_resolve_output+0x15c/0x2a0
[   10.156026]  [] ip6_finish_output2+0x167/0x7f0 [ipv6]
[   10.156026]  [] ip6_finish_output+0x85/0x1c0 [ipv6]
[   10.156026]  [] ip6_output+0x77/0x240 [ipv6]
[   10.156026]  [] mld_sendpack+0x523/0x590 [ipv6]
[   10.156026]  [<80480501>] ? mark_held_locks+0x11/0x90
[   10.156026]  [] mld_ifc_timer_expire+0x15d/0x280 [ipv6]
[   10.156026]  [<8044b168>] call_timer_fn+0x68/0x190
[   10.156026]  [] ? igmp6_group_added+0x150/0x150 [ipv6]
[   10.156026]  [<8044b3fa>] run_timer_softirq+0x16a/0x240
[   10.156026]  [] ? igmp6_group_added+0x150/0x150 [ipv6]
[   10.156026]  [<80444984>] __do_softirq+0xd4/0x2f0
[   10.156026]  [<804448b0>] ? tasklet_action+0x100/0x100

Re: [PATCH net] r8152: fix the checking of the usb speed

[David Miller]

From: Hayes Wang 
Date: Thu, 24 Jul 2014 16:37:43 +0800

> When the usb speed of the RTL8152 is not high speed, the USB_DEV_STAT[2:1]
> should be equal to [0 1]. That is, the STAT_SPEED_FULL should be equal
> to 2.
> 
> There is a easy way to check the usb speed by the speed field of the
> struct usb_device. Use it to replace the original metheod.
> 
> Signed-off-by: Hayes Wang 
> Spotted-by: Andrey Utkin 

Applied, thanks.
--
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