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

[Vicentiu Neagoe]

From: Jeff Westfahl 

When disconnecting, it's possible that another thread has already made it
into eth_start_xmit before we call netif_stop_queue. This can lead to a
crash as eth_start_xmit tries to use resources that gether_disconnect is
freeing. Use netif_tx_lock/unlock around netif_stop_queue to ensure no
threads are executing during the remainder of gether_disconnect.

Signed-off-by: Jeff Westfahl 
Tested-by: Jaeden Amero 
---
 drivers/usb/gadget/u_ether.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/gadget/u_ether.c b/drivers/usb/gadget/u_ether.c
index b7d4f82..085a76e 100644
--- a/drivers/usb/gadget/u_ether.c
+++ b/drivers/usb/gadget/u_ether.c
@@ -1120,7 +1120,10 @@ void gether_disconnect(struct gether *link)
 
DBG(dev, "%s\n", __func__);
 
+   netif_tx_lock(dev->net);
netif_stop_queue(dev->net);
+   netif_tx_unlock(dev->net);
+
netif_carrier_off(dev->net);
 
/* disable endpoints, forcing (synchronous) completion
-- 
1.7.9.5

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

[PATCH] USB: qcserial: add Netgear AirCard 341U PID

[Johan Hovold]

From: Aleksander Morgado 

Add Netgear AirCard 341U PID.

Signed-off-by: Aleksander Morgado 
Link: http://marc.info/?l=linux-usb&m=140130486111309&w=2
Cc: # backport in link above
Signed-off-by: Johan Hovold 
---

Aleksander, thanks for the patch and backport! I added a minimal commit
message, stable tag and reference to your backport.

Greg, this one is for usb-next with a stable backport provided in the
link. I think this is the easiest way to handle this. What do you say?

Thanks,
Johan


 drivers/usb/serial/qcserial.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index ca7b43092439..9c8b6ee1d21d 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -144,6 +144,7 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x901f)},   /* Sierra Wireless EM7355 */
{DEVICE_SWI(0x1199, 0x9041)},   /* Sierra Wireless MC7305/MC7355 */
{DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
+   {DEVICE_SWI(0x1199, 0x9055)},   /* Netgear AirCard 341U */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
-- 
1.8.5.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] usb: core: update wait routine to set a timeout

[Huang Rui]

Currently, in usb_sg_wait routine there isn't a timeout on waiting for
completion signal. When using TEST 5 -> 8 at usbtest module to verify
a new device controller with gadget zero, it would be hang on this
phase and this routine waits forever. So it should add a timeout about
10s to export a TIMEOUT error to return.

Cc: 
Signed-off-by: Huang Rui 
---
 drivers/usb/core/message.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 0c8a7fc..b9c2841 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -507,6 +507,8 @@ void usb_sg_wait(struct usb_sg_request *io)
 {
int i;
int entries = io->entries;
+   unsigned long timeout;
+   long timeleft;
 
/* queue the urbs.  */
spin_lock_irq(&io->lock);
@@ -561,7 +563,13 @@ void usb_sg_wait(struct usb_sg_request *io)
 * So could the submit loop above ... but it's easier to
 * solve neither problem than to solve both!
 */
-   wait_for_completion(&io->complete);
+   timeout = msecs_to_jiffies(1);
+   timeleft = wait_for_completion_timeout(&io->complete, timeout);
+   if (timeleft <= 0) {
+   usb_sg_cancel(io);
+   if (timeleft == 0)
+   io->status = -ETIMEDOUT;
+   }
 
sg_clean(io);
 }
-- 
1.7.9.5

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

Re: [PATCH net-next 0/8] cdc_ncm: fixes and conversion to sysfs API

[Bjørn Mork]

Bjørn Mork  writes:

> After considering the comments received after the ethtool coalesce
> support was commited, I have ended up concluding that we should
> remove it again, while we can, before it hits a release. The idea
> was not well enough thought through, and all comments received
> pointed to advantages of using a sysfs based API instead.
>
> This series removes the ethtool coalesce support and replaces it
> with sysfs attributes in a driver specific group under the netdev.

Hello David,

I see that this series is now marked "Not Applicable" in patchwork. But
the reason is not obvious to me.  May I ask why?

AFAICS, the series technically still applies to net-next, so I assume
the reason is that it is somehow inappropriate.  That's OK, but I do
assume some of it can be applied if split out from the rest?  It would
be good to have some hints about which parts I need to change or remove
for a possible resubmission.


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

Re: [PATCH] net: qmi_wwan: add Netgear AirCard 341U

[Bjørn Mork]

Aleksander Morgado  writes:

> Signed-off-by: Aleksander Morgado 
> ---
>  drivers/net/usb/qmi_wwan.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index 83208d4..c0b611f 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -753,6 +753,7 @@ static const struct usb_device_id products[] = {
>   {QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
>   {QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
> MC7305/MC7355 */
>   {QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
> + {QMI_FIXED_INTF(0x1199, 0x9055, 8)},/* Netgear AirCard 341U */
>   {QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
> (Alcatel One Touch L100V LTE) */
>   {QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
>   {QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */

Acked-by: Bjørn Mork 

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

[PATCH 3/3] usb host/MIPS: Remove hard-coded OCTEON platform information.

[Alex Smith]

From: David Daney 

The device tree will *always* have correct ehci/ohci clock
configuration, so use it.  This allows us to remove a big chunk of
platform configuration code from octeon-platform.c.

Tested-by: Alex Smith 
Signed-off-by: David Daney 
Signed-off-by: Alex Smith 
Cc: linux-usb@vger.kernel.org
---
 arch/mips/cavium-octeon/octeon-platform.c | 102 --
 drivers/usb/host/ehci-octeon.c|  17 +++--
 drivers/usb/host/octeon2-common.c |  47 --
 drivers/usb/host/ohci-octeon.c|  17 +++--
 4 files changed, 69 insertions(+), 114 deletions(-)

diff --git a/arch/mips/cavium-octeon/octeon-platform.c 
b/arch/mips/cavium-octeon/octeon-platform.c
index 6df0f4d..f8cced4 100644
--- a/arch/mips/cavium-octeon/octeon-platform.c
+++ b/arch/mips/cavium-octeon/octeon-platform.c
@@ -66,108 +66,6 @@ out:
 }
 device_initcall(octeon_rng_device_init);
 
-#ifdef CONFIG_USB
-
-static int __init octeon_ehci_device_init(void)
-{
-   struct platform_device *pd;
-   int ret = 0;
-
-   struct resource usb_resources[] = {
-   {
-   .flags  = IORESOURCE_MEM,
-   }, {
-   .flags  = IORESOURCE_IRQ,
-   }
-   };
-
-   /* Only Octeon2 has ehci/ohci */
-   if (!OCTEON_IS_MODEL(OCTEON_CN63XX))
-   return 0;
-
-   if (octeon_is_simulation() || usb_disabled())
-   return 0; /* No USB in the simulator. */
-
-   pd = platform_device_alloc("octeon-ehci", 0);
-   if (!pd) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   usb_resources[0].start = 0x00016F00ULL;
-   usb_resources[0].end = usb_resources[0].start + 0x100;
-
-   usb_resources[1].start = OCTEON_IRQ_USB0;
-   usb_resources[1].end = OCTEON_IRQ_USB0;
-
-   ret = platform_device_add_resources(pd, usb_resources,
-   ARRAY_SIZE(usb_resources));
-   if (ret)
-   goto fail;
-
-   ret = platform_device_add(pd);
-   if (ret)
-   goto fail;
-
-   return ret;
-fail:
-   platform_device_put(pd);
-out:
-   return ret;
-}
-device_initcall(octeon_ehci_device_init);
-
-static int __init octeon_ohci_device_init(void)
-{
-   struct platform_device *pd;
-   int ret = 0;
-
-   struct resource usb_resources[] = {
-   {
-   .flags  = IORESOURCE_MEM,
-   }, {
-   .flags  = IORESOURCE_IRQ,
-   }
-   };
-
-   /* Only Octeon2 has ehci/ohci */
-   if (!OCTEON_IS_MODEL(OCTEON_CN63XX))
-   return 0;
-
-   if (octeon_is_simulation() || usb_disabled())
-   return 0; /* No USB in the simulator. */
-
-   pd = platform_device_alloc("octeon-ohci", 0);
-   if (!pd) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   usb_resources[0].start = 0x00016F000400ULL;
-   usb_resources[0].end = usb_resources[0].start + 0x100;
-
-   usb_resources[1].start = OCTEON_IRQ_USB0;
-   usb_resources[1].end = OCTEON_IRQ_USB0;
-
-   ret = platform_device_add_resources(pd, usb_resources,
-   ARRAY_SIZE(usb_resources));
-   if (ret)
-   goto fail;
-
-   ret = platform_device_add(pd);
-   if (ret)
-   goto fail;
-
-   return ret;
-fail:
-   platform_device_put(pd);
-out:
-   return ret;
-}
-device_initcall(octeon_ohci_device_init);
-
-#endif /* CONFIG_USB */
-
 static struct of_device_id __initdata octeon_ids[] = {
{ .compatible = "simple-bus", },
{ .compatible = "cavium,octeon-6335-uctl", },
diff --git a/drivers/usb/host/ehci-octeon.c b/drivers/usb/host/ehci-octeon.c
index 9051439..e1a264f5 100644
--- a/drivers/usb/host/ehci-octeon.c
+++ b/drivers/usb/host/ehci-octeon.c
@@ -19,14 +19,14 @@
 #define OCTEON_EHCI_HCD_NAME "octeon-ehci"
 
 /* Common clock init code.  */
-void octeon2_usb_clocks_start(void);
+void octeon2_usb_clocks_start(struct device *dev);
 void octeon2_usb_clocks_stop(void);
 
-static void ehci_octeon_start(void)
+static void ehci_octeon_start(struct device *dev)
 {
union cvmx_uctlx_ehci_ctl ehci_ctl;
 
-   octeon2_usb_clocks_start();
+   octeon2_usb_clocks_start(dev);
 
ehci_ctl.u64 = cvmx_read_csr(CVMX_UCTLX_EHCI_CTL(0));
/* Use 64-bit addressing. */
@@ -134,7 +134,7 @@ static int ehci_octeon_drv_probe(struct platform_device 
*pdev)
goto err1;
}
 
-   ehci_octeon_start();
+   ehci_octeon_start(&pdev->dev);
 
ehci = hcd_to_ehci(hcd);
 
@@ -175,6 +175,14 @@ static int ehci_octeon_drv_remove(struct platform_device 
*pdev)
return 0;
 }
 
+static struct of_device_id ehci_octeon_match[] = {
+   {
+   .compatible = "cavium,octeon-6335-ehci",
+   },
+   {},
+};
+MODULE_DEVICE_TABLE(of, ehci_octeon_match);
+
 

Re: [PATCH] USB: qcserial: add Netgear AirCard 341U PID

[Aleksander Morgado]

On Thu, May 29, 2014 at 10:20 AM, Johan Hovold  wrote:
> From: Aleksander Morgado 
>
> Add Netgear AirCard 341U PID.
>
> Signed-off-by: Aleksander Morgado 
> Link: http://marc.info/?l=linux-usb&m=140130486111309&w=2
> Cc: # backport in link above
> Signed-off-by: Johan Hovold 
> ---
>
> Aleksander, thanks for the patch and backport! I added a minimal commit
> message, stable tag and reference to your backport.
>

No problem :) but I think Greg already picked the original one I wrote
in his usb-next branch...

I have more patches to come, so I'll use your approach when sending them.

> Greg, this one is for usb-next with a stable backport provided in the
> link. I think this is the easiest way to handle this. What do you say?
>
> Thanks,
> Johan
>
>
>  drivers/usb/serial/qcserial.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index ca7b43092439..9c8b6ee1d21d 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -144,6 +144,7 @@ static const struct usb_device_id id_table[] = {
> {DEVICE_SWI(0x1199, 0x901f)},   /* Sierra Wireless EM7355 */
> {DEVICE_SWI(0x1199, 0x9041)},   /* Sierra Wireless MC7305/MC7355 */
> {DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
> +   {DEVICE_SWI(0x1199, 0x9055)},   /* Netgear AirCard 341U */
> {DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
> Mobile Broadband Card */
> {DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
> Mobile Broadband Card */
> {DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
> Mobile Broadband Card */
> --
> 1.8.5.5
>



-- 
Aleksander
https://aleksander.es
--
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: qcserial: add Netgear AirCard 341U PID

[Johan Hovold]

On Thu, May 29, 2014 at 12:48:56PM +0200, Aleksander Morgado wrote:
> On Thu, May 29, 2014 at 10:20 AM, Johan Hovold  wrote:
> > From: Aleksander Morgado 
> >
> > Add Netgear AirCard 341U PID.
> >
> > Signed-off-by: Aleksander Morgado 
> > Link: http://marc.info/?l=linux-usb&m=140130486111309&w=2
> > Cc: # backport in link above
> > Signed-off-by: Johan Hovold 
> > ---
> >
> > Aleksander, thanks for the patch and backport! I added a minimal commit
> > message, stable tag and reference to your backport.
> >
> 
> No problem :) but I think Greg already picked the original one I wrote
> in his usb-next branch...

Ahh, great. He's fast sometimes. ;)

> I have more patches to come, so I'll use your approach when sending them.

Excellent.

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

[PATCH usb,stable] usb: qcserial: add additional Sierra Wireless QMI devices

[Aleksander Morgado]

A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
Sierra Wireless drivers.

Signed-off-by: Aleksander Morgado 
---

Hey,

This patch is for stable branches only, and should be applied after the
following one:
  [PATCH usb,stable] usb: qcserial: add Netgear AirCard 341U
  http://marc.info/?l=linux-usb&m=140130486111309&w=2

Cheers!

 drivers/usb/serial/qcserial.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 781e4db..43d93db 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -145,15 +145,33 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 0)},   /* Sierra 
Wireless EM7355 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 2)},   /* Sierra 
Wireless EM7355 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x901f, 3)},   /* Sierra 
Wireless EM7355 Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9040, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9040, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9040, 3)},   /* Sierra 
Wireless Modem Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 0)},   /* Sierra 
Wireless MC7305/MC7355 Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 2)},   /* Sierra 
Wireless MC7305/MC7355 NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9041, 3)},   /* Sierra 
Wireless MC7305/MC7355 Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 0)},   /* Netgear 
AirCard 340U Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 2)},   /* Netgear 
AirCard 340U NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9051, 3)},   /* Netgear 
AirCard 340U Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9053, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9053, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9053, 3)},   /* Sierra 
Wireless Modem Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9054, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9054, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9054, 3)},   /* Sierra 
Wireless Modem Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 0)},   /* Netgear 
AirCard 341U Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 2)},   /* Netgear 
AirCard 341U NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9055, 3)},   /* Netgear 
AirCard 341U Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9056, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9056, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9056, 3)},   /* Sierra 
Wireless Modem Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9060, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9060, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9060, 3)},   /* Sierra 
Wireless Modem Modem */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9061, 0)},   /* Sierra 
Wireless Modem Device Management */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9061, 2)},   /* Sierra 
Wireless Modem NMEA */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1199, 0x9061, 3)},   /* Sierra 
Wireless Modem Modem */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 0)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Device Management */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 2)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card NMEA */
{USB_DEVICE_INTERFACE_NUMBER(0x413c, 0x81a2, 3)},   /* Dell 
Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card Modem */
--
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 usb-next] usb: qcserial: add additional Sierra Wireless QMI devices

[Aleksander Morgado]

A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
Sierra Wireless drivers.

Signed-off-by: Aleksander Morgado 
Link: http://marc.info/?l=linux-usb&m=140136310027293&w=2
Cc: # backport in link above
---
 drivers/usb/serial/qcserial.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index 9c8b6ee..b2aa003 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -142,9 +142,15 @@ static const struct usb_device_id id_table[] = {
{DEVICE_SWI(0x1199, 0x68c0)},   /* Sierra Wireless MC73xx */
{DEVICE_SWI(0x1199, 0x901c)},   /* Sierra Wireless EM7700 */
{DEVICE_SWI(0x1199, 0x901f)},   /* Sierra Wireless EM7355 */
+   {DEVICE_SWI(0x1199, 0x9040)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9041)},   /* Sierra Wireless MC7305/MC7355 */
{DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
+   {DEVICE_SWI(0x1199, 0x9053)},   /* Sierra Wireless Modem */
+   {DEVICE_SWI(0x1199, 0x9054)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9055)},   /* Netgear AirCard 341U */
+   {DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
+   {DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
+   {DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
{DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
Mobile Broadband Card */
{DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
Mobile Broadband Card */
--
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: [PATCH usb-next] usb: qcserial: add additional Sierra Wireless QMI devices

[Johan Hovold]

On Thu, May 29, 2014 at 01:33:27PM +0200, Aleksander Morgado wrote:
> A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
> Sierra Wireless drivers.
> 
> Signed-off-by: Aleksander Morgado 
> Link: http://marc.info/?l=linux-usb&m=140136310027293&w=2
> Cc:   # backport in link above

Signed-off-by: Johan Hovold 

Next time you should put your Signed-off-by tag after any other tags.
Not everyone follows that, but it makes it possible to track who added
which tag in the Signed-off-by chain (and can also be used to track
other changes made to patches in the chain using [who: description]
annotation).

Thanks,
Johan

> ---
>  drivers/usb/serial/qcserial.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index 9c8b6ee..b2aa003 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -142,9 +142,15 @@ static const struct usb_device_id id_table[] = {
>   {DEVICE_SWI(0x1199, 0x68c0)},   /* Sierra Wireless MC73xx */
>   {DEVICE_SWI(0x1199, 0x901c)},   /* Sierra Wireless EM7700 */
>   {DEVICE_SWI(0x1199, 0x901f)},   /* Sierra Wireless EM7355 */
> + {DEVICE_SWI(0x1199, 0x9040)},   /* Sierra Wireless Modem */
>   {DEVICE_SWI(0x1199, 0x9041)},   /* Sierra Wireless MC7305/MC7355 */
>   {DEVICE_SWI(0x1199, 0x9051)},   /* Netgear AirCard 340U */
> + {DEVICE_SWI(0x1199, 0x9053)},   /* Sierra Wireless Modem */
> + {DEVICE_SWI(0x1199, 0x9054)},   /* Sierra Wireless Modem */
>   {DEVICE_SWI(0x1199, 0x9055)},   /* Netgear AirCard 341U */
> + {DEVICE_SWI(0x1199, 0x9056)},   /* Sierra Wireless Modem */
> + {DEVICE_SWI(0x1199, 0x9060)},   /* Sierra Wireless Modem */
> + {DEVICE_SWI(0x1199, 0x9061)},   /* Sierra Wireless Modem */
>   {DEVICE_SWI(0x413c, 0x81a2)},   /* Dell Wireless 5806 Gobi(TM) 4G LTE 
> Mobile Broadband Card */
>   {DEVICE_SWI(0x413c, 0x81a3)},   /* Dell Wireless 5570 HSPA+ (42Mbps) 
> Mobile Broadband Card */
>   {DEVICE_SWI(0x413c, 0x81a4)},   /* Dell Wireless 5570e HSPA+ (42Mbps) 
> Mobile Broadband Card */
--
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: qmi_wwan: add additional Sierra Wireless QMI devices

[Aleksander Morgado]

A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
Sierra Wireless drivers.

Signed-off-by: Aleksander Morgado 
---

Hey,

The patch should be applied after the following one:
  [PATCH] net: qmi_wwan: add Netgear AirCard 341U
  http://marc.info/?l=linux-netdev&m=140130407711048&w=2

Cheers!

 drivers/net/usb/qmi_wwan.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index c0b611f..faa1277 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -753,7 +753,11 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
{QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
MC7305/MC7355 */
{QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
+   {QMI_FIXED_INTF(0x1199, 0x9053, 8)},/* Sierra Wireless Modem */
+   {QMI_FIXED_INTF(0x1199, 0x9054, 8)},/* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1199, 0x9055, 8)},/* Netgear AirCard 341U */
+   {QMI_FIXED_INTF(0x1199, 0x9056, 8)},/* Sierra Wireless Modem */
+   {QMI_FIXED_INTF(0x1199, 0x9061, 8)},/* Sierra Wireless Modem */
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
(Alcatel One Touch L100V LTE) */
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
{QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
--
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/1] usb: host: max3421-hcd: Use module_spi_driver

[Sachin Kamat]

module_spi_driver simplifies the code by eliminating
boilerplate code.

Signed-off-by: Sachin Kamat 
---
 drivers/usb/host/max3421-hcd.c |   15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index 28abda14c5e2..e8568c0f1df3 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1919,20 +1919,7 @@ static struct spi_driver max3421_driver = {
},
 };
 
-static int __init
-max3421_mod_init(void)
-{
-   return spi_register_driver(&max3421_driver);
-}
-
-static void __exit
-max3421_mod_exit(void)
-{
-   spi_unregister_driver(&max3421_driver);
-}
-
-module_init(max3421_mod_init);
-module_exit(max3421_mod_exit);
+module_spi_driver(max3421_driver);
 
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_AUTHOR("David Mosberger ");
-- 
1.7.9.5

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

[PATCH] net: qmi_wwan: interface #11 in Sierra Wireless MC73xx is not QMI

[Aleksander Morgado]

This interface is unusable, as the cdc-wdm character device doesn't reply to
any QMI command. Also, the out-of-tree Sierra Wireless GobiNet driver fully
skips it.

Signed-off-by: Aleksander Morgado 
---
 drivers/net/usb/qmi_wwan.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index faa1277..dc4bf06 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -748,7 +748,6 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
QMI mode */
{QMI_FIXED_INTF(0x1199, 0x68c0, 8)},/* Sierra Wireless MC73xx */
{QMI_FIXED_INTF(0x1199, 0x68c0, 10)},   /* Sierra Wireless MC73xx */
-   {QMI_FIXED_INTF(0x1199, 0x68c0, 11)},   /* Sierra Wireless MC73xx */
{QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
{QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
{QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
MC7305/MC7355 */
-- 
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: [PATCH] net: qmi_wwan: add additional Sierra Wireless QMI devices

[Bjørn Mork]

Aleksander Morgado  writes:

> A set of new VID/PIDs retrieved from the out-of-tree GobiNet/GobiSerial
> Sierra Wireless drivers.
>
> Signed-off-by: Aleksander Morgado 
> ---
>
> Hey,
>
> The patch should be applied after the following one:
>   [PATCH] net: qmi_wwan: add Netgear AirCard 341U
>   http://marc.info/?l=linux-netdev&m=140130407711048&w=2
>
> Cheers!
>
>  drivers/net/usb/qmi_wwan.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index c0b611f..faa1277 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -753,7 +753,11 @@ static const struct usb_device_id products[] = {
>   {QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
>   {QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
> MC7305/MC7355 */
>   {QMI_FIXED_INTF(0x1199, 0x9051, 8)},/* Netgear AirCard 340U */
> + {QMI_FIXED_INTF(0x1199, 0x9053, 8)},/* Sierra Wireless Modem */
> + {QMI_FIXED_INTF(0x1199, 0x9054, 8)},/* Sierra Wireless Modem */
>   {QMI_FIXED_INTF(0x1199, 0x9055, 8)},/* Netgear AirCard 341U */
> + {QMI_FIXED_INTF(0x1199, 0x9056, 8)},/* Sierra Wireless Modem */
> + {QMI_FIXED_INTF(0x1199, 0x9061, 8)},/* Sierra Wireless Modem */
>   {QMI_FIXED_INTF(0x1bbb, 0x011e, 4)},/* Telekom Speedstick LTE II 
> (Alcatel One Touch L100V LTE) */
>   {QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
>   {QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
> --
> 1.9.3

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

Re: [PATCH] net: qmi_wwan: interface #11 in Sierra Wireless MC73xx is not QMI

[Bjørn Mork]

Aleksander Morgado  writes:

> This interface is unusable, as the cdc-wdm character device doesn't reply to
> any QMI command. Also, the out-of-tree Sierra Wireless GobiNet driver fully
> skips it.
>
> Signed-off-by: Aleksander Morgado 
> ---
>  drivers/net/usb/qmi_wwan.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
> index faa1277..dc4bf06 100644
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -748,7 +748,6 @@ static const struct usb_device_id products[] = {
>   {QMI_FIXED_INTF(0x1199, 0x68a2, 19)},   /* Sierra Wireless MC7710 in 
> QMI mode */
>   {QMI_FIXED_INTF(0x1199, 0x68c0, 8)},/* Sierra Wireless MC73xx */
>   {QMI_FIXED_INTF(0x1199, 0x68c0, 10)},   /* Sierra Wireless MC73xx */
> - {QMI_FIXED_INTF(0x1199, 0x68c0, 11)},   /* Sierra Wireless MC73xx */
>   {QMI_FIXED_INTF(0x1199, 0x901c, 8)},/* Sierra Wireless EM7700 */
>   {QMI_FIXED_INTF(0x1199, 0x901f, 8)},/* Sierra Wireless EM7355 */
>   {QMI_FIXED_INTF(0x1199, 0x9041, 8)},/* Sierra Wireless 
> MC7305/MC7355 */

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

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

>>> I think problem is caused by access to OHCI regs from PCI quirks - before
>>> driver was initialized. ULI1553 southbridge chip could be in strange state
>>> at this point.
>>
>> If that is the cause, we ought to be able to see it from the values
>> printed out by the debugging statements.  And if that is so, it's a
>> serious problem.  The southbridge chip really should be working at this
>> point, because the quirk_usb_handoff_* routines need to be able to
>> communicate with the host controllers.
> 
> In this case, communication looks possible.
> However, read of OHCI_FMINTERVAL register somehow breaks it.

I realized that source of the problem is elsewhere.

P2020DS board's USB connectors are not connected to ULI1553 USB.
These are connected to P2020 SOC's USB, handled by fsl-ehci driver (even
for USB 1.1 devices)
As for ULI1553 USB - it is not wired.
But - due to hardware misfeature - ULI1553 USB is not hardware-masked,
and with mainline kernel it visible on the bus:

root@freescale-p2020ds:~# lspci
:00:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)
0001:02:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)
0001:03:00.0 PCI bridge: ULi Electronics Inc. M5249 HTT to PCI Bridge
0001:04:1c.0 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.1 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.2 USB controller: ULi Electronics Inc. USB 1.1 Controller (rev 03)
0001:04:1c.3 USB controller: ULi Electronics Inc. USB 2.0 Controller (rev 01)
0001:04:1e.0 ISA bridge: ULi Electronics Inc. M1575 South Bridge
0001:04:1e.1 Bridge: ULi Electronics Inc. M7101 Power Management Controller 
[PMU]
0001:04:1f.0 IDE interface: ULi Electronics Inc. M5229 IDE (rev c8)
0001:04:1f.1 IDE interface: ULi Electronics Inc. ULi M5288 SATA (rev 10)
0002:05:00.0 PCI bridge: Freescale Semiconductor Inc P2020E (rev 10)

I forgot about that when checking our local tree for mainlineable commits.
Sorry.

I don't know how linux usb subsystem should behave against such
"half-existing" hardware. Perhaps hanging is not the best idea...
but maybe it should be fixed elsewhere, e.g. by masking non-wired
devices in platform PCI setup. Perhaps controlled by some device-tree
key.

Nikita
--
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: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[One Thousand Gnomes]

> I don't know how linux usb subsystem should behave against such
> "half-existing" hardware. Perhaps hanging is not the best idea...
> but maybe it should be fixed elsewhere, e.g. by masking non-wired
> devices in platform PCI setup. Perhaps controlled by some device-tree
> key.

Does it have a unique svid/sdid set for the platform - if so you could
just blacklist that combination of vid/did/svid/sdid.

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: BUG: EHCI Bios handoff fails and system gets stuck

[Alan Stern]

On Wed, 28 May 2014, Leandro Liptak wrote:

> > If you comment out the pci_write and plug in a USB device, like a flash
> > drive, does it work okay?
> >
> > Have you checked for any BIOS updates available from the manufacturer?
> > This really sounds like a bug in the BIOS.
> 
> Yes, any plugged USB device seems to work ok! I didn't find any BIOS
> update.. So I don't know if this line of code is really necessary at
> all, perhaps it could be a configuration option at kernel compilation
> time (?)

It really is necessary.  It is documented in section 5.1 of the EHCI
specification.  If your computer hangs then your computer is not
compliant with the spec.  This is undoubtedly caused by a BIOS bug.

What happens if you initialize try_handoff (at the start of the 
functionn) to 0 instead of 1, and leave the pci_write unchanged?

Also, can you post the output from dmidecode?

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] usb: core: update wait routine to set a timeout

[Alan Stern]

On Thu, 29 May 2014, Huang Rui wrote:

> Currently, in usb_sg_wait routine there isn't a timeout on waiting for
> completion signal. When using TEST 5 -> 8 at usbtest module to verify
> a new device controller with gadget zero, it would be hang on this
> phase and this routine waits forever.

Why did it hang?  That's the real problem; you should fix that instead 
of adding a timeout.

> So it should add a timeout about
> 10s to export a TIMEOUT error to return.

What makes you think 10 seconds is a good timeout value?

Sorry, this is not acceptable.  Any timeout value you specify has to 
work for _all_ places that call this routine.  10 minutes might be 
okay.

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 3/3] usb host/MIPS: Remove hard-coded OCTEON platform information.

[Alan Stern]

On Thu, 29 May 2014, Alex Smith wrote:

> From: David Daney 
> 
> The device tree will *always* have correct ehci/ohci clock
> configuration, so use it.  This allows us to remove a big chunk of
> platform configuration code from octeon-platform.c.

Instead of doing this, how about moving the octeon2_usb_clocks_start() 
and _stop() routines into octeon-platform.c, and then using the 
ehci-platform and ohci-platform drivers instead of special-purpose 
ehci-octeon and ohci-octeon drivers?

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] usb: core: update wait routine to set a timeout

[Huang Rui]

On Thu, May 29, 2014 at 10:50:03AM -0400, Alan Stern wrote:
> On Thu, 29 May 2014, Huang Rui wrote:
> 
> > Currently, in usb_sg_wait routine there isn't a timeout on waiting for
> > completion signal. When using TEST 5 -> 8 at usbtest module to verify
> > a new device controller with gadget zero, it would be hang on this
> > phase and this routine waits forever.
> 
> Why did it hang?  That's the real problem; you should fix that instead 
> of adding a timeout.
> 

Right, it might be a HW issue and still under analysis.

> > So it should add a timeout about
> > 10s to export a TIMEOUT error to return.
> 
> What makes you think 10 seconds is a good timeout value?
> 

This value is rough estimate, and can be changed.

> Sorry, this is not acceptable.  Any timeout value you specify has to 
> work for _all_ places that call this routine.  10 minutes might be 
> okay.
> 

But as a developer's view, when I run the tests, it should be better
to report a error even though it fails. But in some specail error
cases, usbtest TEST 5 -> 8 which used usb_sg_wait might wait forever
and the test is unable to stop. I think it is still not expected,
right? So do you have any idea to resolve this issue to make the
usbtest report the error codes and complete normally?

Thanks,
Rui
--
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: update wait routine to set a timeout

[Alan Stern]

On Thu, 29 May 2014, Huang Rui wrote:

> On Thu, May 29, 2014 at 10:50:03AM -0400, Alan Stern wrote:
> > On Thu, 29 May 2014, Huang Rui wrote:
> > 
> > > Currently, in usb_sg_wait routine there isn't a timeout on waiting for
> > > completion signal. When using TEST 5 -> 8 at usbtest module to verify
> > > a new device controller with gadget zero, it would be hang on this
> > > phase and this routine waits forever.
> > 
> > Why did it hang?  That's the real problem; you should fix that instead 
> > of adding a timeout.
> > 
> 
> Right, it might be a HW issue and still under analysis.
> 
> > > So it should add a timeout about
> > > 10s to export a TIMEOUT error to return.
> > 
> > What makes you think 10 seconds is a good timeout value?
> > 
> 
> This value is rough estimate, and can be changed.
> 
> > Sorry, this is not acceptable.  Any timeout value you specify has to 
> > work for _all_ places that call this routine.  10 minutes might be 
> > okay.
> > 
> 
> But as a developer's view, when I run the tests, it should be better
> to report a error even though it fails. But in some specail error
> cases, usbtest TEST 5 -> 8 which used usb_sg_wait might wait forever
> and the test is unable to stop. I think it is still not expected,
> right? So do you have any idea to resolve this issue to make the
> usbtest report the error codes and complete normally?

You could disconnect the gadget from the host.  Then usb_sg_wait() 
would complete.  :-)

Seriously, the right way to handle timeouts with usb_sg_wait() is to
have a timer routine call usb_sg_cancel() when the timeout expires.  
You could add such a timer to tests 5-8 in usbtest.

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] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

29.05.2014 18:42, One Thousand Gnomes пишет:
>> I don't know how linux usb subsystem should behave against such
>> "half-existing" hardware. Perhaps hanging is not the best idea...
>> but maybe it should be fixed elsewhere, e.g. by masking non-wired
>> devices in platform PCI setup. Perhaps controlled by some device-tree
>> key.
> 
> Does it have a unique svid/sdid set for the platform - if so you could
> just blacklist that combination of vid/did/svid/sdid.

Unfortunately vid/did/svid/sdid come from ULI 1553 southbridge chip,
that is used by other hardware as well. AFAIK it is still being
manufactured, and could appear in PCs or laptops.

Nikita

--
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: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

29.05.2014 19:33, Nikita Yushchenko пишет:
> 29.05.2014 18:42, One Thousand Gnomes пишет:
>>> I don't know how linux usb subsystem should behave against such
>>> "half-existing" hardware. Perhaps hanging is not the best idea...
>>> but maybe it should be fixed elsewhere, e.g. by masking non-wired
>>> devices in platform PCI setup. Perhaps controlled by some device-tree
>>> key.
>>
>> Does it have a unique svid/sdid set for the platform - if so you could
>> just blacklist that combination of vid/did/svid/sdid.
> 
> Unfortunately vid/did/svid/sdid come from ULI 1553 southbridge chip,
> that is used by other hardware as well. AFAIK it is still being
> manufactured, and could appear in PCs or laptops.

Sorry I mistyped in entire thread... Chip is ULI M1575.

Nikita

--
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: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Alan Stern]

On Thu, 29 May 2014, Nikita Yushchenko wrote:

> 29.05.2014 18:42, One Thousand Gnomes пишет:
> >> I don't know how linux usb subsystem should behave against such
> >> "half-existing" hardware. Perhaps hanging is not the best idea...
> >> but maybe it should be fixed elsewhere, e.g. by masking non-wired
> >> devices in platform PCI setup. Perhaps controlled by some device-tree
> >> key.
> > 
> > Does it have a unique svid/sdid set for the platform - if so you could
> > just blacklist that combination of vid/did/svid/sdid.
> 
> Unfortunately vid/did/svid/sdid come from ULI 1553 southbridge chip,
> that is used by other hardware as well. AFAIK it is still being
> manufactured, and could appear in PCs or laptops.

> > It would help to print the value of fminterval.
> > And here to print the value obtained by the readl().
>
> I've checked these... all values read as 0x - which does not
> look correct

You could have the platform setup code read one of those hardware
registers, such as FMINTERVAL.  If it obtains 0x, don't
register the OHCI controller as a platform device.

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] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Nikita Yushchenko]

29.05.2014 19:44, Alan Stern пишет:
> On Thu, 29 May 2014, Nikita Yushchenko wrote:
> 
>> 29.05.2014 18:42, One Thousand Gnomes пишет:
 I don't know how linux usb subsystem should behave against such
 "half-existing" hardware. Perhaps hanging is not the best idea...
 but maybe it should be fixed elsewhere, e.g. by masking non-wired
 devices in platform PCI setup. Perhaps controlled by some device-tree
 key.
>>>
>>> Does it have a unique svid/sdid set for the platform - if so you could
>>> just blacklist that combination of vid/did/svid/sdid.
>>
>> Unfortunately vid/did/svid/sdid come from ULI 1553 southbridge chip,
>> that is used by other hardware as well. AFAIK it is still being
>> manufactured, and could appear in PCs or laptops.
> 
>>> It would help to print the value of fminterval.
>>> And here to print the value obtained by the readl().
>>
>> I've checked these... all values read as 0x - which does not
>> look correct
> 
> You could have the platform setup code read one of those hardware
> registers, such as FMINTERVAL.  If it obtains 0x, don't
> register the OHCI controller as a platform device.

It is not a platform_device, it is PCI device that is found via bus scan.

--
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: update wait routine to set a timeout

[Huang Rui]

On Thu, May 29, 2014 at 11:31:54AM -0400, Alan Stern wrote:
> On Thu, 29 May 2014, Huang Rui wrote:
> 
> > On Thu, May 29, 2014 at 10:50:03AM -0400, Alan Stern wrote:
> > > On Thu, 29 May 2014, Huang Rui wrote:
> > > 
> > > > Currently, in usb_sg_wait routine there isn't a timeout on waiting for
> > > > completion signal. When using TEST 5 -> 8 at usbtest module to verify
> > > > a new device controller with gadget zero, it would be hang on this
> > > > phase and this routine waits forever.
> > > 
> > > Why did it hang?  That's the real problem; you should fix that instead 
> > > of adding a timeout.
> > > 
> > 
> > Right, it might be a HW issue and still under analysis.
> > 
> > > > So it should add a timeout about
> > > > 10s to export a TIMEOUT error to return.
> > > 
> > > What makes you think 10 seconds is a good timeout value?
> > > 
> > 
> > This value is rough estimate, and can be changed.
> > 
> > > Sorry, this is not acceptable.  Any timeout value you specify has to 
> > > work for _all_ places that call this routine.  10 minutes might be 
> > > okay.
> > > 
> > 
> > But as a developer's view, when I run the tests, it should be better
> > to report a error even though it fails. But in some specail error
> > cases, usbtest TEST 5 -> 8 which used usb_sg_wait might wait forever
> > and the test is unable to stop. I think it is still not expected,
> > right? So do you have any idea to resolve this issue to make the
> > usbtest report the error codes and complete normally?
> 
> You could disconnect the gadget from the host.  Then usb_sg_wait() 
> would complete.  :-)
> 

Ahh, yes, you're right. :)

> Seriously, the right way to handle timeouts with usb_sg_wait() is to
> have a timer routine call usb_sg_cancel() when the timeout expires.  
> You could add such a timer to tests 5-8 in usbtest.
> 

So you mean I should do it in special class driver, not in core level,
right?

Thanks,
Rui
--
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/1] usb: host: max3421-hcd: Use module_spi_driver

[David Mosberger]

On Thu, May 29, 2014 at 5:51 AM, Sachin Kamat  wrote:
> module_spi_driver simplifies the code by eliminating
> boilerplate code.

Nice!

Acked-by: David Mosberger 

>
> Signed-off-by: Sachin Kamat 
> ---
>  drivers/usb/host/max3421-hcd.c |   15 +--
>  1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
> index 28abda14c5e2..e8568c0f1df3 100644
> --- a/drivers/usb/host/max3421-hcd.c
> +++ b/drivers/usb/host/max3421-hcd.c
> @@ -1919,20 +1919,7 @@ static struct spi_driver max3421_driver = {
> },
>  };
>
> -static int __init
> -max3421_mod_init(void)
> -{
> -   return spi_register_driver(&max3421_driver);
> -}
> -
> -static void __exit
> -max3421_mod_exit(void)
> -{
> -   spi_unregister_driver(&max3421_driver);
> -}
> -
> -module_init(max3421_mod_init);
> -module_exit(max3421_mod_exit);
> +module_spi_driver(max3421_driver);
>
>  MODULE_DESCRIPTION(DRIVER_DESC);
>  MODULE_AUTHOR("David Mosberger ");
> --
> 1.7.9.5
>



-- 
eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] usb: host: max3421-hcd: Allow platform-data to specify Vbus polarity

[David Mosberger]

From: David Mosberger-Tang 

Signed-off-by: Davidm Mosberger 
---
 drivers/usb/host/max3421-hcd.c| 6 --
 include/linux/platform_data/max3421-hcd.h | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/max3421-hcd.c b/drivers/usb/host/max3421-hcd.c
index fa5ee8e..83c8355 100644
--- a/drivers/usb/host/max3421-hcd.c
+++ b/drivers/usb/host/max3421-hcd.c
@@ -1714,7 +1714,8 @@ max3421_hub_control(struct usb_hcd *hcd, u16 type_req, 
u16 value, u16 index,
break;
case USB_PORT_FEAT_POWER:
dev_dbg(hcd->self.controller, "power-off\n");
-   max3421_gpout_set_value(hcd, pdata->vbus_gpout, 0);
+   max3421_gpout_set_value(hcd, pdata->vbus_gpout,
+   !pdata->vbus_active_level);
/* FALLS THROUGH */
default:
max3421_hcd->port_status &= ~(1 << value);
@@ -1763,7 +1764,8 @@ max3421_hub_control(struct usb_hcd *hcd, u16 type_req, 
u16 value, u16 index,
case USB_PORT_FEAT_POWER:
dev_dbg(hcd->self.controller, "power-on\n");
max3421_hcd->port_status |= USB_PORT_STAT_POWER;
-   max3421_gpout_set_value(hcd, pdata->vbus_gpout, 1);
+   max3421_gpout_set_value(hcd, pdata->vbus_gpout,
+   pdata->vbus_active_level);
break;
case USB_PORT_FEAT_RESET:
max3421_reset_port(hcd);
diff --git a/include/linux/platform_data/max3421-hcd.h 
b/include/linux/platform_data/max3421-hcd.h
index 4ad4596..0303d19 100644
--- a/include/linux/platform_data/max3421-hcd.h
+++ b/include/linux/platform_data/max3421-hcd.h
@@ -18,6 +18,7 @@
  */
 struct max3421_hcd_platform_data {
u8 vbus_gpout;  /* pin controlling Vbus */
+   u8 vbus_active_level;   /* level that turns on power */
 };
 
 #endif /* MAX3421_HCD_PLAT_H_INCLUDED */
-- 
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

Re: [PATCH 3/3] usb host/MIPS: Remove hard-coded OCTEON platform information.

[Florian Fainelli]

2014-05-29 8:03 GMT-07:00 Alan Stern :
> On Thu, 29 May 2014, Alex Smith wrote:
>
>> From: David Daney 
>>
>> The device tree will *always* have correct ehci/ohci clock
>> configuration, so use it.  This allows us to remove a big chunk of
>> platform configuration code from octeon-platform.c.
>
> Instead of doing this, how about moving the octeon2_usb_clocks_start()
> and _stop() routines into octeon-platform.c, and then using the
> ehci-platform and ohci-platform drivers instead of special-purpose
> ehci-octeon and ohci-octeon drivers?

How about they get their changes in now, and eventually they cleanup
the octeon driver in the future? My personal experience with that sort
of request, is that I had to come up with 50+ patches to clean up the
Kconfig mess that USB drivers had back then and I still have not
re-submitted the bcm63xx USB patchset.

It is fair to pinpoint what *should* be improved and what the next
steps could look like, it is not fair to ask people submitting changes
to come up with a much bigger task before their patches can be merged.
-- 
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v1 3/3] usb: gadget: NCM: Stop RX TCP Bursts getting dropped.

[Jim Baxter]

This fixes a problem with dropped packets over 16k CDC-NCM
when the connection is being heavily used.

The issue was that the skb truesize for the unpacked NCM
packets was too high after they were cloned from the 16k
skb, this lead to the potential memory calculated by the
Kernel running out of memory earlier then it should.

Signed-off-by: Jim Baxter 
---
 drivers/usb/gadget/f_ncm.c |   15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index 5452fb6..bcdc882 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -1229,16 +1229,17 @@ static int ncm_unwrap_ntb(struct gether *port,
index2 = get_ncm(&tmp, opts->dgram_item_len);
dg_len2 = get_ncm(&tmp, opts->dgram_item_len);
 
-   skb2 = skb_clone(skb, GFP_ATOMIC);
+   /*
+* Copy the data into a new skb.
+* This ensures the truesize is correct
+*/
+   skb2 = netdev_alloc_skb_ip_align(ncm->netdev,
+dg_len - crc_len);
if (skb2 == NULL)
goto err;
+   memcpy(skb_put(skb2, dg_len - crc_len),
+  skb->data + index, dg_len - crc_len);
 
-   if (!skb_pull(skb2, index)) {
-   ret = -EOVERFLOW;
-   goto err;
-   }
-
-   skb_trim(skb2, dg_len - crc_len);
skb_queue_tail(list, skb2);
 
ndp_len -= 2 * (opts->dgram_item_len * 2);
-- 
1.7.9.5

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

[PATCH v1 2/3] usb: gadget: NCM: Add transmit multi-frame.

[Jim Baxter]

This adds multi-frame support to the NCM NTB's for
the gadget driver. This allows multiple network
packets to be put inside a single USB NTB with a
maximum size of 16kB.

It has a time out of 300ms to ensure that smaller
number of packets still maintain a normal latency.

Also the .fp_index and .next_fp_index have been
changed to .ndp_index and .next_ndp_index to
match the latest CDC-NCM specification and
help with maintenance.

Results transmitting from gadget to host.

Before the change:

TCP_STREAM Throughput (10^6bits/sec): 22.72
UDP_STREAM Throughput (10^6bits/sec): 25.94

Latency:
netperf -H 192.168.1.101 -v2 -l 50 -t TCP_RR -- -r 16384,16384
Trans.   RoundTrip  Throughput
Rate Latency10^6bits/s
per sec  usec/Tran  Outbound

100.83   9918.116   13.215

After the change:

TCP_STREAM Throughput (10^6bits/sec): 124.26
UDP_STREAM Throughput (10^6bits/sec): 227.48

Latency:
netperf -H 192.168.1.101 -v2 -l 50 -t TCP_RR -- -r 16384,16384
Trans.   RoundTrip  Throughput
Rate Latency10^6bits/s
per sec  usec/Tran  Outbound

156.80   6377.730   20.552

Signed-off-by: Jim Baxter 
---
 drivers/usb/gadget/f_ncm.c   |  335 --
 drivers/usb/gadget/u_ether.c |   19 ++-
 drivers/usb/gadget/u_ether.h |2 +
 3 files changed, 269 insertions(+), 87 deletions(-)

diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index d0ebbac..5452fb6 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -68,6 +68,18 @@ struct f_ncm {
 * callback and ethernet open/close
 */
spinlock_t  lock;
+
+   struct net_device   *netdev;
+
+   /* For multi-frame NDP TX */
+   struct sk_buff  *skb_tx_data;
+   struct sk_buff  *skb_tx_ndp;
+   u16 ndp_dgram_count;
+   booltimer_force_tx;
+   struct tasklet_struct   tx_tasklet;
+   struct hrtimer  task_timer;
+
+   booltimer_stopping;
 };
 
 static inline struct f_ncm *func_to_ncm(struct usb_function *f)
@@ -92,15 +104,20 @@ static inline unsigned ncm_bitrate(struct usb_gadget *g)
  * If the host can group frames, allow it to do that, 16K is selected,
  * because it's used by default by the current linux host driver
  */
-#define NTB_DEFAULT_IN_SIZEUSB_CDC_NCM_NTB_MIN_IN_SIZE
+#define NTB_DEFAULT_IN_SIZE16384
 #define NTB_OUT_SIZE   16384
 
-/*
- * skbs of size less than that will not be aligned
- * to NCM's dwNtbInMaxSize to save bus bandwidth
+/* Allocation for storing the NDP, 32 should suffice for a
+ * 16k packet. This allows a maximum of 32 * 507 Byte packets to
+ * be transmitted in a single 16kB skb, though when sending full size
+ * packets this limit will be plenty.
+ * Smaller packets are not likely to be trying to maximize the
+ * throughput and will be mstly sending smaller infrequent frames.
  */
+#define TX_MAX_NUM_DPE 32
 
-#defineMAX_TX_NONFIXED (512 * 3)
+/* Delay for the transmit to wait before sending an unfilled NTB frame. */
+#define TX_TIMEOUT_NSECS   30
 
 #define FORMATS_SUPPORTED  (USB_CDC_NCM_NTB16_SUPPORTED |  \
 USB_CDC_NCM_NTB32_SUPPORTED)
@@ -355,14 +372,15 @@ struct ndp_parser_opts {
u32 ndp_sign;
unsignednth_size;
unsignedndp_size;
+   unsigneddpe_size;
unsignedndplen_align;
/* sizes in u16 units */
unsigneddgram_item_len; /* index or length */
unsignedblock_length;
-   unsignedfp_index;
+   unsignedndp_index;
unsignedreserved1;
unsignedreserved2;
-   unsignednext_fp_index;
+   unsignednext_ndp_index;
 };
 
 #define INIT_NDP16_OPTS {  \
@@ -370,13 +388,14 @@ struct ndp_parser_opts {
.ndp_sign = USB_CDC_NCM_NDP16_NOCRC_SIGN,   \
.nth_size = sizeof(struct usb_cdc_ncm_nth16),   \
.ndp_size = sizeof(struct usb_cdc_ncm_ndp16),   \
+   .dpe_size = sizeof(struct usb_cdc_ncm_dpe16),   \
.ndplen_align = 4,  \
.dgram_item_len = 1,\
.block_length = 1,  \
-   .fp_index = 1,  \
+   .ndp_index = 1, \
.reserved1 = 0, \
.reserved2 = 0, \
-   .next_fp_index = 1, \
+   .next_ndp_index = 1,\
}
 
 
@@ -385,13 +404,14 @@ struct ndp_parser_opts {
.ndp_sign = USB_CDC_NCM_NDP32_NOCRC

[PATCH v1 1/3] usb: gadget: NCM: RX function support multiple NDPs

[Jim Baxter]

The NDP was ignoring the wNextNdpIndex in the NDP which
means that NTBs containing multiple NDPs would have missed
frames.

Signed-off-by: Jim Baxter 
---
 drivers/usb/gadget/f_ncm.c |  146 +++-
 1 file changed, 78 insertions(+), 68 deletions(-)

diff --git a/drivers/usb/gadget/f_ncm.c b/drivers/usb/gadget/f_ncm.c
index a9499fd..d0ebbac 100644
--- a/drivers/usb/gadget/f_ncm.c
+++ b/drivers/usb/gadget/f_ncm.c
@@ -963,6 +963,7 @@ static int ncm_unwrap_ntb(struct gether *port,
struct f_ncm*ncm = func_to_ncm(&port->func);
__le16  *tmp = (void *) skb->data;
unsignedindex, index2;
+   int ndp_index;
unsigneddg_len, dg_len2;
unsignedndp_len;
struct sk_buff  *skb2;
@@ -995,91 +996,100 @@ static int ncm_unwrap_ntb(struct gether *port,
goto err;
}
 
-   index = get_ncm(&tmp, opts->fp_index);
-   /* NCM 3.2 */
-   if (((index % 4) != 0) && (index < opts->nth_size)) {
-   INFO(port->func.config->cdev, "Bad index: %x\n",
-   index);
-   goto err;
-   }
-
-   /* walk through NDP */
-   tmp = ((void *)skb->data) + index;
-   if (get_unaligned_le32(tmp) != ncm->ndp_sign) {
-   INFO(port->func.config->cdev, "Wrong NDP SIGN\n");
-   goto err;
-   }
-   tmp += 2;
-
-   ndp_len = get_unaligned_le16(tmp++);
-   /*
-* NCM 3.3.1
-* entry is 2 items
-* item size is 16/32 bits, opts->dgram_item_len * 2 bytes
-* minimal: struct usb_cdc_ncm_ndpX + normal entry + zero entry
-*/
-   if ((ndp_len < opts->ndp_size + 2 * 2 * (opts->dgram_item_len * 2))
-   || (ndp_len % opts->ndplen_align != 0)) {
-   INFO(port->func.config->cdev, "Bad NDP length: %x\n", ndp_len);
-   goto err;
-   }
-   tmp += opts->reserved1;
-   tmp += opts->next_fp_index; /* skip reserved (d)wNextFpIndex */
-   tmp += opts->reserved2;
-
-   ndp_len -= opts->ndp_size;
-   index2 = get_ncm(&tmp, opts->dgram_item_len);
-   dg_len2 = get_ncm(&tmp, opts->dgram_item_len);
-   dgram_counter = 0;
+   ndp_index = get_ncm(&tmp, opts->fp_index);
 
+   /* Run through all the NDP's in the NTB */
do {
-   index = index2;
-   dg_len = dg_len2;
-   if (dg_len < 14 + crc_len) { /* ethernet header + crc */
-   INFO(port->func.config->cdev, "Bad dgram length: %x\n",
-dg_len);
+   /* NCM 3.2 */
+   if (((ndp_index % 4) != 0) &&
+   (ndp_index < opts->nth_size)) {
+   INFO(port->func.config->cdev, "Bad index: %#X\n",
+ndp_index);
goto err;
}
-   if (ncm->is_crc) {
-   uint32_t crc, crc2;
-
-   crc = get_unaligned_le32(skb->data +
-index + dg_len - crc_len);
-   crc2 = ~crc32_le(~0,
-skb->data + index,
-dg_len - crc_len);
-   if (crc != crc2) {
-   INFO(port->func.config->cdev, "Bad CRC\n");
-   goto err;
-   }
+
+   /* walk through NDP */
+   tmp = (void *)(skb->data + ndp_index);
+   if (get_unaligned_le32(tmp) != ncm->ndp_sign) {
+   INFO(port->func.config->cdev, "Wrong NDP SIGN\n");
+   goto err;
}
+   tmp += 2;
 
+   ndp_len = get_unaligned_le16(tmp++);
+   /*
+* NCM 3.3.1
+* entry is 2 items
+* item size is 16/32 bits, opts->dgram_item_len * 2 bytes
+* minimal: struct usb_cdc_ncm_ndpX + normal entry + zero entry
+* Each entry is a dgram index and a dgram length.
+*/
+   if ((ndp_len < opts->ndp_size
+   + 2 * 2 * (opts->dgram_item_len * 2))
+   || (ndp_len % opts->ndplen_align != 0)) {
+   INFO(port->func.config->cdev, "Bad NDP length: %#X\n",
+ndp_len);
+   goto err;
+   }
+   tmp += opts->reserved1;
+   /* Check for another NDP (d)wNextNdpIndex */
+   ndp_index = get_ncm(&tmp, opts->next_fp_index);
+   tmp += opts->reserved2;
+
+   ndp_len -= opts->ndp_size;
index2 = get_ncm(&tmp, opts->dgram_item_len);
dg_len2 = get_ncm(&tmp, opts->dgram_item_len);
+   dgram_counter = 0;
+
+   do {
+

[PATCH v1 0/3] usb: gadget: NCM: Fixes and Multi-frame for TX.

[Jim Baxter]

This series adds the ability to support packaging multiple network
packets into a single 16k CDC-NCM NTB.

Patches 1 and 3 are fixes for the receive unwrap function which
previously was unable to handle an NTB with multiple NDP's and a fix
that switches from using skb_clone to creating a new packet to fix the
issue of the truesize being far to big and causing packets to be
dropped incorrectly.

Jim Baxter (3):
  usb: gadget: NCM: RX function support multiple NDPs
  usb: gadget: NCM: Add transmit multi-frame.
  usb: gadget: NCM: Stop RX TCP Bursts getting dropped.

 drivers/usb/gadget/f_ncm.c   |  480 +-
 drivers/usb/gadget/u_ether.c |   19 +-
 drivers/usb/gadget/u_ether.h |2 +
 3 files changed, 347 insertions(+), 154 deletions(-)

-- 
1.7.9.5

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

Re: [PATCH] usb: pci-quirks: do not access OHCI_FMINTERVAL register on ULI hw

[Alan Stern]

On Thu, 29 May 2014, Nikita Yushchenko wrote:

> >> I've checked these... all values read as 0x - which does not
> >> look correct
> > 
> > You could have the platform setup code read one of those hardware
> > registers, such as FMINTERVAL.  If it obtains 0x, don't
> > register the OHCI controller as a platform device.
> 
> It is not a platform_device, it is PCI device that is found via bus scan.

Yes, of course, I got it mixed up.

Well, the quirk_usb_handoff_ohci() routine could do something like 
this.  If the FMINTERVAL value is 0x, deregister the device 
from the PCI bus.

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 v3 1/2] usb: host: xhci-plat: add optional PHY support

[Sergei Shtylyov]

Hello.

On 05/29/2014 05:32 AM, Yoshihiro Shimoda wrote:


From: Gregory CLEMENT 



This commit extends the xhci-plat so that it can optionally be passed
a reference to a PHY through the Device Tree. It will be useful for
the Armada 375 SoCs. If no PHY is provided then the behavior of the
driver is unchanged.



As for the clock, to achieve this, it adds a 'struct phy *' member in
xhci_hcd. While only used for now in xhci-plat, here again, it might
be used by other drivers in the future.



Signed-off-by: Gregory CLEMENT 
Signed-off-by: Yoshihiro Shimoda 
---
  drivers/usb/host/xhci-plat.c |   27 ++-
  drivers/usb/host/xhci.h  |2 ++
  2 files changed, 28 insertions(+), 1 deletion(-)


   I've already posted a patch adding generic PHY support to all USB HCDs 
about 1.5 months ago, which should make this patch unneeded.


WBR, Sergei

--
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 3/3] usb host/MIPS: Remove hard-coded OCTEON platform information.

[Greg KH]

On Thu, May 29, 2014 at 09:55:08AM -0700, Florian Fainelli wrote:
> 2014-05-29 8:03 GMT-07:00 Alan Stern :
> > On Thu, 29 May 2014, Alex Smith wrote:
> >
> >> From: David Daney 
> >>
> >> The device tree will *always* have correct ehci/ohci clock
> >> configuration, so use it.  This allows us to remove a big chunk of
> >> platform configuration code from octeon-platform.c.
> >
> > Instead of doing this, how about moving the octeon2_usb_clocks_start()
> > and _stop() routines into octeon-platform.c, and then using the
> > ehci-platform and ohci-platform drivers instead of special-purpose
> > ehci-octeon and ohci-octeon drivers?
> 
> How about they get their changes in now, and eventually they cleanup
> the octeon driver in the future?

Nope, sorry, we don't do that for kernel development, you know that.

> My personal experience with that sort of request, is that I had to
> come up with 50+ patches to clean up the Kconfig mess that USB drivers
> had back then and I still have not re-submitted the bcm63xx USB
> patchset.

Well, that's not our fault you haven't resent them :)

> It is fair to pinpoint what *should* be improved and what the next
> steps could look like, it is not fair to ask people submitting changes
> to come up with a much bigger task before their patches can be merged.

Of course it is, that's how we do Linux development, again, you know
this.

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 3/3] usb host/MIPS: Remove hard-coded OCTEON platform information.

[David Daney]

On 05/29/2014 10:37 AM, Greg KH wrote:

On Thu, May 29, 2014 at 09:55:08AM -0700, Florian Fainelli wrote:

2014-05-29 8:03 GMT-07:00 Alan Stern :

On Thu, 29 May 2014, Alex Smith wrote:


From: David Daney 

The device tree will *always* have correct ehci/ohci clock
configuration, so use it.  This allows us to remove a big chunk of
platform configuration code from octeon-platform.c.


Instead of doing this, how about moving the octeon2_usb_clocks_start()
and _stop() routines into octeon-platform.c, and then using the
ehci-platform and ohci-platform drivers instead of special-purpose
ehci-octeon and ohci-octeon drivers?


How about they get their changes in now, and eventually they cleanup
the octeon driver in the future?


Nope, sorry, we don't do that for kernel development, you know that.


My personal experience with that sort of request, is that I had to
come up with 50+ patches to clean up the Kconfig mess that USB drivers
had back then and I still have not re-submitted the bcm63xx USB
patchset.


Well, that's not our fault you haven't resent them :)


It is fair to pinpoint what *should* be improved and what the next
steps could look like, it is not fair to ask people submitting changes
to come up with a much bigger task before their patches can be merged.


Of course it is, that's how we do Linux development, again, you know
this.



Several points of clarification:

1) I wrote the patch in question, not Florian.

2) I agree that OCTEON ehci/ohci support could probably be refactored 
along the lines of Alan's suggestion.


3) This patch is a relatively minor change to an *existing* driver 
rather than a completely new thing that hasn't yet been merged.


4) There is a lot of precedent for merging minor enhancements and bug 
fixes instead of requiring a complete refactoring of *existing* code.


All that said, I haven't dug into the ehci-platform and ohci-platform 
enough to be able to opine on the best course of action in this 
particular case.  I hope to be able to make a more educated follow-up 
next week.


David Daney



--
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: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran Microelectronics, Ltd Digital Camera EX-20 DSC

[Richie Gress]

> Date: Wed, 28 May 2014 10:56:51 +0200
> From: hverk...@xs4all.nl
> To: searchfgold67...@live.com; linux-usb@vger.kernel.org; 
> linux-me...@vger.kernel.org
> Subject: Re: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran 
> Microelectronics, Ltd Digital Camera EX-20 DSC
>
> On 05/27/14 19:55, Richie Gress wrote:
>>
>>
>>> Date: Tue, 27 May 2014 09:03:33 +0200
>>> From: hverk...@xs4all.nl
>>> To: searchfgold67...@live.com; linux-usb@vger.kernel.org; 
>>> linux-me...@vger.kernel.org
>>> Subject: Re: 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran 
>>> Microelectronics, Ltd Digital Camera EX-20 DSC
>>>
>>> On 05/27/2014 03:34 AM, Richie wrote:
 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1322380

 [1.] One line summary of the problem:

 1d6b:0001 [MSI A55M-P33] No webcam functionality with Zoran 
 Microelectronics,
 Ltd Digital Camera EX-20 DSC

 [2.] Full description of the problem/report:

 No software recognizes the webcam and this is not a regression. dmesg 
 reports
 the following additional output after plugging the camera. You can see 
 where I
 change the camera to "PC Mode" (in order to use the webcam, users must do 
 this
 from the camera) at [ 691.147589]. The device is turned off at [ 
 1094.746444]:

 [ 688.796908] usb 4-2: new full-speed USB device number 2 using ohci-pci
 [ 688.965802] usb 4-2: New USB device found, idVendor=0595, idProduct=2002
 [ 688.965807] usb 4-2: New USB device strings: Mfr=4, Product=5,
 SerialNumber=6
 [ 688.965809] usb 4-2: Product: COACH DSC
 [ 688.965811] usb 4-2: Manufacturer: ZORAN
 [ 688.965813] usb 4-2: SerialNumber: ZORAN01234567
 [ 689.012630] usb-storage 4-2:1.0: USB Mass Storage device detected
 [ 689.021168] scsi6 : usb-storage 4-2:1.0
 [ 689.021266] usbcore: registered new interface driver usb-storage
 [ 690.030971] scsi 6:0:0:0: Direct-Access ZORAN COACH6 (I62) 1.10 PQ: 0 
 ANSI:
 0 CCS
 [ 690.036147] sd 6:0:0:0: Attached scsi generic sg3 type 0
 [ 690.044964] sd 6:0:0:0: [sdc] 3962629 512-byte logical blocks: (2.02 
 GB/1.88
 GiB)
 [ 690.054977] sd 6:0:0:0: [sdc] Write Protect is off
 [ 690.054984] sd 6:0:0:0: [sdc] Mode Sense: 00 06 00 00
 [ 690.064965] sd 6:0:0:0: [sdc] No Caching mode page found
 [ 690.064971] sd 6:0:0:0: [sdc] Assuming drive cache: write through
 [ 690.108960] sd 6:0:0:0: [sdc] No Caching mode page found
 [ 690.108966] sd 6:0:0:0: [sdc] Assuming drive cache: write through
 [ 690.156970] sdc:
 [ 690.210974] sd 6:0:0:0: [sdc] No Caching mode page found
 [ 690.210980] sd 6:0:0:0: [sdc] Assuming drive cache: write through
 [ 690.210985] sd 6:0:0:0: [sdc] Attached SCSI removable disk
 [ 691.147589] usb 4-2: USB disconnect, device number 2
 [ 691.793364] usb 4-2: new full-speed USB device number 3 using ohci-pci
 [ 691.962202] usb 4-2: New USB device found, idVendor=0595, idProduct=4343
 [ 691.962207] usb 4-2: New USB device strings: Mfr=7, Product=8,
 SerialNumber=9
 [ 691.962209] usb 4-2: Product: COACH DSC
 [ 691.962211] usb 4-2: Manufacturer: ZORAN
 [ 691.962213] usb 4-2: SerialNumber: ZORAN0001
 [ 691.964262] usb-storage 4-2:1.0: USB Mass Storage device detected
 [ 691.965410] usb-storage: probe of 4-2:1.0 failed with error -5
 [ 692.053929] Linux video capture interface: v2.00
 [ 692.091447] zr364xx 4-2:1.0: Zoran 364xx compatible webcam plugged
 [ 692.091453] zr364xx 4-2:1.0: model 0595:4343 detected
 [ 692.091461] usb 4-2: 320x240 mode selected
 [ 692.094356] usb 4-2: Zoran 364xx controlling device video0
>>>
>>> Clearly the webcam is recognized and a /dev/video0 node is created.
>>> Please check that /dev/video0 exists. Try e.g. v4l2-ctl -D -d /dev/video0,
>>> it should list it as using the zr364xx driver.
>>>
>>> So what exactly doesn't work?
>>>
>>> Regards,
>>>
>>> Hans
>>>
 [ 692.094672] usbcore: registered new interface driver zr364xx
 [ 1094.746444] hub 4-0:1.0: port 2 disabled by hub (EMI?), re-enabling...
 [ 1094.746451] usb 4-2: USB disconnect, device number 3
 [ 1094.747395] zr364xx 4-2:1.0: Zoran 364xx webcam unplugged
>>>
>>
>> Yes, it does seem to be using the zr364xx driver:
>>
>> $ v4l2-ctl -D -d /dev/video0
>> Driver Info (not using libv4l2):
>> Driver name : Zoran 364xx
>> Card type : COACH DSC
>> Bus info : 4-1
>> Driver version: 3.15.0
>> Capabilities : 0x8501
>> Video Capture
>> Read/Write
>> Streaming
>> Device Capabilities
>> Device Caps : 0x0501
>> Video Capture
>> Read/Write
>> Streaming
>>
>> The exact problem is that while the camera is recognized as a camera by 
>> software like Skype, Kamoso, and Cheese, there is no picture, just black. A 
>> "320x240 mode" was mentioned... perhaps that resolution is just too small to 
>> use by the software?
>
> Try using qv4l2. If that doesn't work, then it is likely t

Re: [PATCH v1 1/3] usb: gadget: NCM: RX function support multiple NDPs

[Bjørn Mork]

Jim Baxter  writes:

> The NDP was ignoring the wNextNdpIndex in the NDP which
> means that NTBs containing multiple NDPs would have missed
> frames.

Well, just for the record: I believe this field was meant to be reserved
and always 0 in the CDC NCM spec.  Table 3-3, describing 16bit NDPs,
says so.  But reading the spec now, I noticed that there is an
inconsistency between table 3-3 and table 3-4 describing 32bit NDPs.  It
looks like the field is not reserved in the 32bit version.

I am pretty sure that is a specification error, but I guess it doesn't
harm to implement the support anyway.  And it paves the way for an MBIM
gadget :-)




Bjørn
--
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

Humanitaria Help.

[Mrs. Margaret]

I am Mrs. Margaret Crawford, i write you this email to seek for your 
Humanitarian help, i have decided to donate part of my inheritance to you for 
humanitarian work and your personal use. As a result of my heart status. I need 
you to contact my Attoney. Mark lawson. with this email for a better 
information only if you are interested. Email: mlaw...@mail2mark.com

Thank you
Mrs. Margaret Crawford


"Zero Problem 2014, Cakupan Semesta 2019"

Mari kita bergotong royong sukseskan Sistem Jaminan Sosial Kesehatan, demi 
tercapainya Jaminan Kesehatan untuk Semesta Bagi Seluruh Rakyat Indonesia Tahun 
2019

HALLO BPJS KESEHATAN 500-400
--
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 v10 18/19] usb: force warm reset to break link re-connect livelock

[Dan Williams]

On Wed, May 21, 2014 at 1:12 PM, Alan Stern  wrote:
> On Tue, 20 May 2014, Dan Williams wrote:
>
>> Resuming a powered down port sometimes results in the port state being
>> stuck in the training sequence.
>>
>>  hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
>>  port1: can't get reconnection after setting port  power on, status -110
>>  hub 3-0:1.0: port 1 status .02e0 after resume, -19
>>  usb 3-1: can't resume, status -19
>>  hub 3-0:1.0: logical disconnect on port 1
>>
>> In the case above we wait for the port re-connect timeout of 2 seconds
>> and observe that the port status is USB_SS_PORT_LS_POLLING (although it
>> is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT).
>> This is indicative of a case where the device is failing to progress the
>> link training state machine.
>>
>> It is resolved by issuing a warm reset to get the hub and device link
>> state machines back in sync.
>>
>>  hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
>>  usb usb3: port1 usb_port_runtime_resume requires warm reset
>>  hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms
>>  usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
>>
>> After a reconnect timeout when we expect the device to be present, force
>> a warm reset of the device.  Note that we can not simply look at the
>> link status to determine if a warm reset is required as any of the
>> training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
>> USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need
>> for warm reset by themselves.
>
>
>> --- a/drivers/usb/core/hub.c
>> +++ b/drivers/usb/core/hub.c
>> @@ -2570,10 +2570,12 @@ static int hub_port_reset(struct usb_hub *hub, int 
>> port1,
>>  /* Is a USB 3.0 port in the Inactive or Compliance Mode state?
>>   * Port worm reset is required to recover
>>   */
>> -static bool hub_port_warm_reset_required(struct usb_hub *hub, u16 
>> portstatus)
>> +static bool hub_port_warm_reset_required(struct usb_hub *hub, int port1,
>> +  u16 portstatus)
>>  {
>>   return hub_is_superspeed(hub->hdev) &&
>> - (((portstatus & USB_PORT_STAT_LINK_STATE) ==
>> + (test_bit(port1, hub->warm_reset_bits) ||
>> + ((portstatus & USB_PORT_STAT_LINK_STATE) ==
>> USB_SS_PORT_LS_SS_INACTIVE) ||
>>((portstatus & USB_PORT_STAT_LINK_STATE) ==
>> USB_SS_PORT_LS_COMP_MOD)) ;
>
> This might be a little more clear if you separate out the tests and
> remove the excess parens:
>
> unsigned ls;
>
> if (!hub_is_superspeed(hub->hdev))
> return 0;
> if (test_bit(port1, hub->warm_reset_bits))
> return 1;
> ls = portstatus & USB_PORT_STAT_LINK_STATE;
> return ls == USB_SS_PORT_LS_SS_INACTIVE ||
> ls == USB_SS_PORT_LS_COMP_MOD;
>

Fixed.

>> @@ -2839,8 +2843,13 @@ static int check_port_resume_type(struct usb_device 
>> *udev,
>>  {
>>   struct usb_port *port_dev = hub->ports[port1 - 1];
>>
>> + /* Is a warm reset needed to recover the connection? */
>> + if (udev->reset_resume
>> + && hub_port_warm_reset_required(hub, port1, portstatus)) {
>> + /* pass */;
>
> You mustn't call hub_port_warm_reset_required when status < 0, because
> then the portstatus value is undefined.

Good catch.

> Have you tested this after turning off the device's persist_enabled
> flag?  Without a reset-resume, this will go through an awkward sequence
> involving disabling the port.  I think you still end up performing the
> warm reset, but it's worth checking.

Fixed.

The warm reset is still performed, however the "force warm reset" flag
was not being cleared correctly.
--
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 v1 3/3] usb: gadget: NCM: Stop RX TCP Bursts getting dropped.

[Eric Dumazet]

On Thu, 2014-05-29 at 18:12 +0100, Jim Baxter wrote:
> This fixes a problem with dropped packets over 16k CDC-NCM
> when the connection is being heavily used.
> 
> The issue was that the skb truesize for the unpacked NCM
> packets was too high after they were cloned from the 16k
> skb, this lead to the potential memory calculated by the
> Kernel running out of memory earlier then it should.
> 
> Signed-off-by: Jim Baxter 
> ---

Note the patch is OK, but changelog a bit misleading ;)

Kernel was not running out of memory, because truesize was correct.

The problem here is that a frame was consuming more kernel memory than
really needed, so chances of hitting socket sk_rcvbuf limit was high.

BTW :
#define NTB_OUT_SIZE  16384

alloc_skb(size) ->
kmalloc(16384 + sizeof(struct skb_shared_info)) ->
roundup() => 32768

So truesize of the skb was infact ~32KB, which is really insane indeed.
After your patch, its back to ~2KB

Acked-by: Eric Dumazet 



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

Re: [PATCH net-next 0/8] cdc_ncm: fixes and conversion to sysfs API

[David Miller]

From: Bjørn Mork 
Date: Thu, 29 May 2014 11:59:07 +0200

> I see that this series is now marked "Not Applicable" in patchwork. But
> the reason is not obvious to me.  May I ask why?

I meant to mark it as "Changes Requested", because patch 8 had some feedback
that you said you'd address.
--
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 v10 19/19] usb: documentation for usb port power off mechanisms

[Dan Williams]

On Wed, May 21, 2014 at 1:29 PM, Alan Stern  wrote:
> On Tue, 20 May 2014, Dan Williams wrote:
>
>> From: Lan Tianyu 
>>
>> describe the mechanisms for controlling port power policy and
>> discovering the port power state.
>
>
>> +Example of the relevant files for port power control.
>> +
>> +   child device link +
>> +   port device + |
>> +parent hub +   | |
>> +   v   v v
>> + /sys/bus/devices/usb2/2-0:1.0/port1/device
>> +
>> + /sys/bus/devices/usb2/2-0:1.0/port1/power/pm_qos_no_power_off
>> + /sys/bus/devices/usb2/2-0:1.0/port1/device/power/control
>> + /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:/driver/unbind
>> + /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:/driver/unbind
>> + ...
>> + /sys/bus/devices/usb2/2-0:1.0/port1/device/2-1:/driver/unbind
>
> These port names are out of date.  Likewise the names below.

Fixed.

>
> +While a superspeed port is powered off a device may downgrade its
> +connection and attempt to connect to the hi-speed pins.  The
> +implementation takes steps to prevent this:
> +
> +1/ Port suspend is sequenced to guarantee that hi-speed ports are powered-off
> +   before their superspeed peer is permitted to power-off.  The implication 
> is
> +   that the setting pm_qos_no_power_off to zero on a superspeed port may not 
> cause
> +   the port to power-off until its highspeed peer to go to its runtime 
> suspend
>
> s/to go/has gone/

Fixed.

Thanks, 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

[PATCH 0/3] port power control rework stragglers

[Dan Williams]

1/ A compile fix from Stephen

2/ Patch 18 "usb: force warm reset to break link re-connect livelock"
   from v10 [1] updated to address Alan's comments.
   * Cleaned up hub_port_warm_reset_required()
   * Verified that warm-reset occurs in the persist_enabled = 0 case
   * Fixed up clearing warm_reset_bits

3/ Patch 19 "usb: documentation for usb port power off mechanisms" from
   v10 updated to address Alan's comments.
   * Fixed up the names of port devices in sysfs
   * Grammar fix.

[1]: v10: http://marc.info/?l=linux-usb&m=140063512208229&w=2
---

Dan Williams (1):
  usb: force warm reset to break link re-connect livelock

Lan Tianyu (1):
  usb: documentation for usb port power off mechanisms

Stephen Rothwell (1):
  usb: fix hub_handle_remote_wakeup() only exists for CONFIG_PM=y


 Documentation/usb/power-management.txt |  245 
 drivers/usb/core/hub.c |   42 -
 drivers/usb/core/hub.h |2 
 drivers/usb/core/port.c|   21 ++-
 4 files changed, 288 insertions(+), 22 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] usb: force warm reset to break link re-connect livelock

[Dan Williams]

Resuming a powered down port sometimes results in the port state being
stuck in the training sequence.

 hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
 port1: can't get reconnection after setting port  power on, status -110
 hub 3-0:1.0: port 1 status .02e0 after resume, -19
 usb 3-1: can't resume, status -19
 hub 3-0:1.0: logical disconnect on port 1

In the case above we wait for the port re-connect timeout of 2 seconds
and observe that the port status is USB_SS_PORT_LS_POLLING (although it
is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT).
This is indicative of a case where the device is failing to progress the
link training state machine.

It is resolved by issuing a warm reset to get the hub and device link
state machines back in sync.

 hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
 usb usb3: port1 usb_port_runtime_resume requires warm reset
 hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms
 usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd

After a reconnect timeout when we expect the device to be present, force
a warm reset of the device.  Note that we can not simply look at the
link status to determine if a warm reset is required as any of the
training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need
for warm reset by themselves.

Cc: Alan Stern 
Cc: Kukjin Kim 
Cc: Vincent Palatin 
Cc: Lan Tianyu 
Cc: Ksenia Ragiadakou 
Cc: Vivek Gautam 
Cc: Douglas Anderson 
Cc: Felipe Balbi 
Cc: Sunil Joshi 
Cc: Hans de Goede 
Acked-by: Julius Werner 
Signed-off-by: Dan Williams 
---
 drivers/usb/core/hub.c  |   36 +---
 drivers/usb/core/hub.h  |2 ++
 drivers/usb/core/port.c |   21 -
 3 files changed, 39 insertions(+), 20 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index db6287025c06..61443c5d2f77 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2570,13 +2570,20 @@ static int hub_port_reset(struct usb_hub *hub, int 
port1,
 /* Is a USB 3.0 port in the Inactive or Compliance Mode state?
  * Port worm reset is required to recover
  */
-static bool hub_port_warm_reset_required(struct usb_hub *hub, u16 portstatus)
+static bool hub_port_warm_reset_required(struct usb_hub *hub, int port1,
+   u16 portstatus)
 {
-   return hub_is_superspeed(hub->hdev) &&
-   (((portstatus & USB_PORT_STAT_LINK_STATE) ==
- USB_SS_PORT_LS_SS_INACTIVE) ||
-((portstatus & USB_PORT_STAT_LINK_STATE) ==
- USB_SS_PORT_LS_COMP_MOD)) ;
+   u16 link_state;
+
+   if (!hub_is_superspeed(hub->hdev))
+   return false;
+
+   if (test_bit(port1, hub->warm_reset_bits))
+   return true;
+
+   link_state = portstatus & USB_PORT_STAT_LINK_STATE;
+   return link_state == USB_SS_PORT_LS_SS_INACTIVE
+   || link_state == USB_SS_PORT_LS_COMP_MOD;
 }
 
 static int hub_port_wait_reset(struct usb_hub *hub, int port1,
@@ -2613,7 +2620,7 @@ static int hub_port_wait_reset(struct usb_hub *hub, int 
port1,
if ((portstatus & USB_PORT_STAT_RESET))
return -EBUSY;
 
-   if (hub_port_warm_reset_required(hub, portstatus))
+   if (hub_port_warm_reset_required(hub, port1, portstatus))
return -ENOTCONN;
 
/* Device went away? */
@@ -2713,9 +2720,10 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
if (status < 0)
goto done;
 
-   if (hub_port_warm_reset_required(hub, portstatus))
+   if (hub_port_warm_reset_required(hub, port1, portstatus))
warm = true;
}
+   clear_bit(port1, hub->warm_reset_bits);
 
/* Reset the port */
for (i = 0; i < PORT_RESET_TRIES; i++) {
@@ -2752,7 +2760,8 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
&portstatus, &portchange) < 0)
goto done;
 
-   if (!hub_port_warm_reset_required(hub, portstatus))
+   if (!hub_port_warm_reset_required(hub, port1,
+   portstatus))
goto done;
 
/*
@@ -2839,8 +2848,13 @@ static int check_port_resume_type(struct usb_device 
*udev,
 {
struct usb_port *port_dev = hub->ports[port1 - 1];
 
+   /* Is a warm reset needed to recover the connection? */
+   if (status == 0 && udev->reset_resume
+   && hub_port_warm_reset_required(hub, port1, portstatus)) {
+   /* pass */;
+   }
/* Is the device still present? */
-   if (status || port_is_suspended(hub, portstatus) ||
+   else if (status || port_is_suspended(hub, portstatus) ||
!port_is_power_on(hub, portstatus)

[PATCH 1/3] usb: fix hub_handle_remote_wakeup() only exists for CONFIG_PM=y

[Dan Williams]

From: Stephen Rothwell 

Stephen notes:
  After merging the usb tree, today's linux-next build (sparc64 defconfig)
  failed like this:

  drivers/usb/core/hub.c: In function 'port_event':
  drivers/usb/core/hub.c:4853:2: error: implicit declaration of function
  'hub_handle_remote_wakeup' [-Werror=implicit-function-declaration]

  Caused by commits af376a461cf0 ("usb: refactor port handling in
  hub_events()") and 7e73be227b15 ("usb: hub_handle_remote_wakeup()
  depends on CONFIG_PM_RUNTIME=y") This build has CONFIG_PM not set ...

The kbuild robot also reported this.

Reported-by: kbuild test robot 
Signed-off-by: Stephen Rothwell 
Signed-off-by: Dan Williams 
---
 drivers/usb/core/hub.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 6346fb2acbd7..db6287025c06 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -3966,6 +3966,12 @@ EXPORT_SYMBOL_GPL(usb_disable_ltm);
 void usb_enable_ltm(struct usb_device *udev) { }
 EXPORT_SYMBOL_GPL(usb_enable_ltm);
 
+static int hub_handle_remote_wakeup(struct usb_hub *hub, unsigned int port,
+   u16 portstatus, u16 portchange)
+{
+   return 0;
+}
+
 #endif /* CONFIG_PM */
 
 

--
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 3/3] usb: documentation for usb port power off mechanisms

[Dan Williams]

From: Lan Tianyu 

describe the mechanisms for controlling port power policy and
discovering the port power state.

[oliver]: fixes, clarification of wakeup vs port-power-control
[sarah]: wordsmithing
[djbw]: updates for peer port changes
[alan]: review and fixes
Cc: Oliver Neukum 
Signed-off-by: Lan Tianyu 
Signed-off-by: Dan Williams 
---
 Documentation/usb/power-management.txt |  245 
 1 files changed, 243 insertions(+), 2 deletions(-)

diff --git a/Documentation/usb/power-management.txt 
b/Documentation/usb/power-management.txt
index 1392b61d6ebe..7b90fe034c4b 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/usb/power-management.txt
@@ -2,8 +2,27 @@
 
 Alan Stern 
 
-   October 28, 2010
-
+  Last-updated: February 2014
+
+
+   Contents:
+   -
+   * What is Power Management?
+   * What is Remote Wakeup?
+   * When is a USB device idle?
+   * Forms of dynamic PM
+   * The user interface for dynamic PM
+   * Changing the default idle-delay time
+   * Warnings
+   * The driver interface for Power Management
+   * The driver interface for autosuspend and autoresume
+   * Other parts of the driver interface
+   * Mutual exclusion
+   * Interaction between dynamic PM and system PM
+   * xHCI hardware link PM
+   * USB Port Power Control
+   * User Interface for Port Power Control
+   * Suggested Userspace Port Power Policy
 
 
What is Power Management?
@@ -516,3 +535,225 @@ relevant attribute files is usb2_hardware_lpm.
driver will enable hardware LPM for the device. You
can write y/Y/1 or n/N/0 to the file to enable/disable
USB2 hardware LPM manually. This is for test purpose mainly.
+
+
+   USB Port Power Control
+   --
+
+In addition to suspending endpoint devices and enabling hardware
+controlled link power management, the USB subsystem also has the
+capability to disable power to ports under some conditions.  Power is
+controlled through Set/ClearPortFeature(PORT_POWER) requests to a hub.
+In the case of a root or platform-internal hub the host controller
+driver translates PORT_POWER requests into platform firmware (ACPI)
+method calls to set the port power state. For more background see the
+Linux Plumbers Conference 2012 slides [1] and video [2]:
+
+Upon receiving a ClearPortFeature(PORT_POWER) request a USB port is
+logically off, and may trigger the actual loss of VBUS to the port [3].
+VBUS may be maintained in the case where a hub gangs multiple ports into
+a shared power well causing power to remain until all ports in the gang
+are turned off.  VBUS may also be maintained by hub ports configured for
+a charging application.  In any event a logically off port will lose
+connection with its device, not respond to hotplug events, and not
+respond to remote wakeup events*.
+
+WARNING: turning off a port may result in the inability to hot add a device.
+Please see "User Interface for Port Power Control" for details.
+
+As far as the effect on the device itself it is similar to what a device
+goes through during system suspend, i.e. the power session is lost.  Any
+USB device or driver that misbehaves with system suspend will be
+similarly affected by a port power cycle event.  For this reason the
+implementation shares the same device recovery path (and honors the same
+quirks) as the system resume path for the hub.
+
+[1]: http://dl.dropbox.com/u/96820575/sarah-sharp-lpt-port-power-off2-mini.pdf
+[2]: 
http://linuxplumbers.ubicast.tv/videos/usb-port-power-off-kerneluserspace-api/
+[3]: USB 3.1 Section 10.12
+* wakeup note: if a device is configured to send wakeup events the port
+  power control implementation will block poweroff attempts on that
+  port.
+
+
+   User Interface for Port Power Control
+   -
+
+The port power control mechanism uses the PM runtime system.  Poweroff is
+requested by clearing the power/pm_qos_no_power_off flag of the port device
+(defaults to 1).  If the port is disconnected it will immediately receive a
+ClearPortFeature(PORT_POWER) request.  Otherwise, it will honor the pm runtime
+rules and require the attached child device and all descendants to be 
suspended.
+This mechanism is dependent on the hub advertising port power switching in its
+hub descriptor (wHubCharacteristics logical power switching mode field).
+
+Note, some interface devices/drivers do not support autosuspend.  Userspace may
+need to unbind the interface drivers before the usb_device will suspend.  An
+unbound interface device is suspended by default.  When unbinding, be careful
+to unbind interface drivers, not the driver of the parent usb device.  Also,
+leave hub interface drivers bound.  If the driver for the usb device (not
+interface) is unbound the kernel is no longer able to 

Re: [PATCH 3/3] usb host/MIPS: Remove hard-coded OCTEON platform information.

[Alan Stern]

On Thu, 29 May 2014, David Daney wrote:

> Several points of clarification:
> 
> 1) I wrote the patch in question, not Florian.
> 
> 2) I agree that OCTEON ehci/ohci support could probably be refactored 
> along the lines of Alan's suggestion.
> 
> 3) This patch is a relatively minor change to an *existing* driver 
> rather than a completely new thing that hasn't yet been merged.
> 
> 4) There is a lot of precedent for merging minor enhancements and bug 
> fixes instead of requiring a complete refactoring of *existing* code.
> 
> All that said, I haven't dug into the ehci-platform and ohci-platform 
> enough to be able to opine on the best course of action in this 
> particular case.  I hope to be able to make a more educated follow-up 
> next week.

Moving these into the respective platform drivers shouldn't be a big
deal.  Below is a totally untested preliminary pass -- I'm pleased that
it removes a lot more lines than it adds.

This first attempt leaves a few matters unresolved:

The EHCI DMA mask is coerced to 32 bits by ehci-platform.c.
Maybe this should be controllable by a flag in the
usb_ehci_pdata structure.

The timing of the calls to octeon_[eo]hci_hw_start() might
be wrong.  The patch does it before the memory resources
are mapped, rather than afterward as it is done now.  I don't
know if this will matter.

The clock management is awkward at best.  But it's about the
same as what we do now.

Anyway, it shouldn't be hard to fix this up and get it working, and 
then rebase your patch on top of it.

Alan Stern



 arch/mips/cavium-octeon/octeon-platform.c |  274 +-
 arch/mips/configs/cavium_octeon_defconfig |3 
 drivers/usb/host/Kconfig  |   18 +
 drivers/usb/host/Makefile |1 
 drivers/usb/host/ehci-hcd.c   |5 
 drivers/usb/host/ehci-octeon.c|  188 
 drivers/usb/host/octeon2-common.c |  200 -
 drivers/usb/host/ohci-hcd.c   |5 
 drivers/usb/host/ohci-octeon.c|  202 --
 9 files changed, 285 insertions(+), 611 deletions(-)

Index: usb-3.15/arch/mips/cavium-octeon/octeon-platform.c
===
--- usb-3.15.orig/arch/mips/cavium-octeon/octeon-platform.c
+++ usb-3.15/arch/mips/cavium-octeon/octeon-platform.c
@@ -7,22 +7,27 @@
  * Copyright (C) 2008 Wind River Systems
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /* Octeon Random Number Generator.  */
 static int __init octeon_rng_device_init(void)
@@ -68,6 +73,229 @@ device_initcall(octeon_rng_device_init);
 
 #ifdef CONFIG_USB
 
+static DEFINE_MUTEX(octeon2_usb_clocks_mutex);
+
+static int octeon2_usb_clock_start_cnt;
+
+static void octeon2_usb_clocks_start(void)
+{
+   u64 div;
+   union cvmx_uctlx_if_ena if_ena;
+   union cvmx_uctlx_clk_rst_ctl clk_rst_ctl;
+   union cvmx_uctlx_uphy_ctl_status uphy_ctl_status;
+   union cvmx_uctlx_uphy_portx_ctl_status port_ctl_status;
+   int i;
+   unsigned long io_clk_64_to_ns;
+
+
+   mutex_lock(&octeon2_usb_clocks_mutex);
+
+   octeon2_usb_clock_start_cnt++;
+   if (octeon2_usb_clock_start_cnt != 1)
+   goto exit;
+
+   io_clk_64_to_ns = 640ull / octeon_get_io_clock_rate();
+
+   /*
+* Step 1: Wait for voltages stable.  That surely happened
+* before starting the kernel.
+*
+* Step 2: Enable  SCLK of UCTL by writing UCTL0_IF_ENA[EN] = 1
+*/
+   if_ena.u64 = 0;
+   if_ena.s.en = 1;
+   cvmx_write_csr(CVMX_UCTLX_IF_ENA(0), if_ena.u64);
+
+   /* Step 3: Configure the reference clock, PHY, and HCLK */
+   clk_rst_ctl.u64 = cvmx_read_csr(CVMX_UCTLX_CLK_RST_CTL(0));
+
+   /*
+* If the UCTL looks like it has already been started, skip
+* the initialization, otherwise bus errors are obtained.
+*/
+   if (clk_rst_ctl.s.hrst)
+   goto end_clock;
+   /* 3a */
+   clk_rst_ctl.s.p_por = 1;
+   clk_rst_ctl.s.hrst = 0;
+   clk_rst_ctl.s.p_prst = 0;
+   clk_rst_ctl.s.h_clkdiv_rst = 0;
+   clk_rst_ctl.s.o_clkdiv_rst = 0;
+   clk_rst_ctl.s.h_clkdiv_en = 0;
+   clk_rst_ctl.s.o_clkdiv_en = 0;
+   cvmx_write_csr(CVMX_UCTLX_CLK_RST_CTL(0), clk_rst_ctl.u64);
+
+   /* 3b */
+   /* 12MHz crystal. */
+   clk_rst_ctl.s.p_refclk_sel = 0;
+   clk_rst_ctl.s.p_refclk_div = 0;
+   cvmx_write_csr(CVMX_UCTLX_CLK_RST_CTL(0), clk_rst_ctl.u64);
+
+   /* 3c */
+   div = octeon_get_io_clock_rate() / 13000ull;
+
+   switch (div) {
+   case 0:
+   div = 1;
+   break;
+   case 1:
+ 

Re: [PATCH 2/3] usb: force warm reset to break link re-connect livelock

[Alan Stern]

On Thu, 29 May 2014, Dan Williams wrote:

> Resuming a powered down port sometimes results in the port state being
> stuck in the training sequence.
> 
>  hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
>  port1: can't get reconnection after setting port  power on, status -110
>  hub 3-0:1.0: port 1 status .02e0 after resume, -19
>  usb 3-1: can't resume, status -19
>  hub 3-0:1.0: logical disconnect on port 1
> 
> In the case above we wait for the port re-connect timeout of 2 seconds
> and observe that the port status is USB_SS_PORT_LS_POLLING (although it
> is likely toggling between this state and USB_SS_PORT_LS_RX_DETECT).
> This is indicative of a case where the device is failing to progress the
> link training state machine.
> 
> It is resolved by issuing a warm reset to get the hub and device link
> state machines back in sync.
> 
>  hub 3-0:1.0: debounce: port 1: total 2000ms stable 0ms status 0x2e0
>  usb usb3: port1 usb_port_runtime_resume requires warm reset
>  hub 3-0:1.0: port 1 not warm reset yet, waiting 50ms
>  usb 3-1: reset SuperSpeed USB device number 2 using xhci_hcd
> 
> After a reconnect timeout when we expect the device to be present, force
> a warm reset of the device.  Note that we can not simply look at the
> link status to determine if a warm reset is required as any of the
> training states USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
> USB_SS_PORT_LS_COMP_MOD are valid states that do not indicate the need
> for warm reset by themselves.

Acked-by: 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 3/3] usb: documentation for usb port power off mechanisms

[Alan Stern]

On Thu, 29 May 2014, Dan Williams wrote:

> From: Lan Tianyu 
> 
> describe the mechanisms for controlling port power policy and
> discovering the port power state.
> 
> [oliver]: fixes, clarification of wakeup vs port-power-control
> [sarah]: wordsmithing
> [djbw]: updates for peer port changes
> [alan]: review and fixes
> Cc: Oliver Neukum 
> Signed-off-by: Lan Tianyu 
> Signed-off-by: Dan Williams 

Acked-by: Alan Stern 

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

Re: [PATCH 1/3] usb: fix hub_handle_remote_wakeup() only exists for CONFIG_PM=y

[Alan Stern]

On Thu, 29 May 2014, Dan Williams wrote:

> From: Stephen Rothwell 
> 
> Stephen notes:
>   After merging the usb tree, today's linux-next build (sparc64 defconfig)
>   failed like this:
> 
>   drivers/usb/core/hub.c: In function 'port_event':
>   drivers/usb/core/hub.c:4853:2: error: implicit declaration of function
>   'hub_handle_remote_wakeup' [-Werror=implicit-function-declaration]
> 
>   Caused by commits af376a461cf0 ("usb: refactor port handling in
>   hub_events()") and 7e73be227b15 ("usb: hub_handle_remote_wakeup()
>   depends on CONFIG_PM_RUNTIME=y") This build has CONFIG_PM not set ...
> 
> The kbuild robot also reported this.
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Stephen Rothwell 
> Signed-off-by: Dan Williams 
> ---
>  drivers/usb/core/hub.c |6 ++
>  1 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index 6346fb2acbd7..db6287025c06 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -3966,6 +3966,12 @@ EXPORT_SYMBOL_GPL(usb_disable_ltm);
>  void usb_enable_ltm(struct usb_device *udev) { }
>  EXPORT_SYMBOL_GPL(usb_enable_ltm);
>  
> +static int hub_handle_remote_wakeup(struct usb_hub *hub, unsigned int port,
> + u16 portstatus, u16 portchange)
> +{
> + return 0;
> +}
> +
>  #endif   /* CONFIG_PM */

Duplicating code like this is a little awkward.  My preference would be 
to move both usb_remote_wakeup() and hub_handle_remote_wakeup() out 
from underneath the #if CONFIG_PM section.

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] usb: core: update wait routine to set a timeout

[Alan Stern]

On Thu, 29 May 2014, Huang Rui wrote:

> > Seriously, the right way to handle timeouts with usb_sg_wait() is to
> > have a timer routine call usb_sg_cancel() when the timeout expires.  
> > You could add such a timer to tests 5-8 in usbtest.
> > 
> 
> So you mean I should do it in special class driver, not in core level,
> right?

Right.  In this case, the class driver is usbtest.c.

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 3/3] usb host/MIPS: Remove hard-coded OCTEON platform information.

[David Daney]

On 05/29/2014 01:55 PM, Alan Stern wrote:

On Thu, 29 May 2014, David Daney wrote:


Several points of clarification:

1) I wrote the patch in question, not Florian.

2) I agree that OCTEON ehci/ohci support could probably be refactored
along the lines of Alan's suggestion.

3) This patch is a relatively minor change to an *existing* driver
rather than a completely new thing that hasn't yet been merged.

4) There is a lot of precedent for merging minor enhancements and bug
fixes instead of requiring a complete refactoring of *existing* code.

All that said, I haven't dug into the ehci-platform and ohci-platform
enough to be able to opine on the best course of action in this
particular case.  I hope to be able to make a more educated follow-up
next week.


Moving these into the respective platform drivers shouldn't be a big
deal.  Below is a totally untested preliminary pass -- I'm pleased that
it removes a lot more lines than it adds.

This first attempt leaves a few matters unresolved:

The EHCI DMA mask is coerced to 32 bits by ehci-platform.c.
Maybe this should be controllable by a flag in the
usb_ehci_pdata structure.

The timing of the calls to octeon_[eo]hci_hw_start() might
be wrong.  The patch does it before the memory resources
are mapped, rather than afterward as it is done now.  I don't
know if this will matter.

The clock management is awkward at best.  But it's about the
same as what we do now.

Anyway, it shouldn't be hard to fix this up and get it working, and
then rebase your patch on top of it.

Alan Stern



  arch/mips/cavium-octeon/octeon-platform.c |  274 
+-
  arch/mips/configs/cavium_octeon_defconfig |3
  drivers/usb/host/Kconfig  |   18 +
  drivers/usb/host/Makefile |1
  drivers/usb/host/ehci-hcd.c   |5
  drivers/usb/host/ehci-octeon.c|  188 
  drivers/usb/host/octeon2-common.c |  200 -
  drivers/usb/host/ohci-hcd.c   |5
  drivers/usb/host/ohci-octeon.c|  202 --
  9 files changed, 285 insertions(+), 611 deletions(-)



Thanks Alan,

That goes beyond the call of duty!


I will try to test (and improve if necessary) this patch.

David Daney

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

Re: [PATCH net-next 0/8] cdc_ncm: fixes and conversion to sysfs API

[Bjørn Mork]

On 29 May 2014 21:20:52 CEST, David Miller  wrote:
>From: Bjørn Mork 
>Date: Thu, 29 May 2014 11:59:07 +0200
>
>> I see that this series is now marked "Not Applicable" in patchwork.
>But
>> the reason is not obvious to me.  May I ask why?
>
>I meant to mark it as "Changes Requested",

Yes, that I expected :-)

I worried that I might have missed something important. Thanks for clearing it 
up.

>because patch 8 had some
>feedback
>that you said you'd address.

I will. I am just waiting a bit to see if there is anything else to fix.


Bjørn


--
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: xHCI regression for VIA USB 3.0 controller in handle_cmd_completion

[Xenia Ragiadakou]

On 28/05/2014 07:26 πμ, Saran Neti wrote:

Hi,

My VIA USB 3.0 controller has stopped working in recent kernels. 
During boot,

dmesg shows a WARNING stack trace at drivers/usb/host/xhci-ring.c:1615
containing handle_cmd_completion+0xdc7/0x1000.

USB ports become unusable - mouse, keyboard and fdisking mass storage
devices all spew error messages and stack traces followed by logs of
device resets.

Git-bisection from 3.10 to 3.14 for drivers/usb/host points to 
20e7acb13ff48,
which commit message appears to indicate that the VIA controller in 
question

may not be xhci spec rev1.0-compliant.

I'm not sure what Linux's policy on regression for non-compliant hardware
is, but it'll save me the trouble of patching/building a kernel each time
if you can revert, or otherwise fix this.

Thanks



Hi Saran,

Thanks for reporting this. I read again the spec and I realized that 
using the slot id field of the event TRB for a Reset Device Command was 
a mistake.


I misunderstood the following description regarding the slot id field of 
Command Completion Event TRB:
"The Slot ID field shall be updated by the xHC to reflect the slot 
associated with the

command that generated the event, with the following exceptions:
- The Slot ID shall be cleared to ‘0’ for No Op, Set Latency Tolerance 
Value, Get Port

Bandwidth, and Force Event Commands.
- The Slot ID shall be set to the ID of the newly allocated Device Slot 
for the Enable Slot

Command.
- The value of Slot ID shall be vendor defined when generated by a 
vendor defined command.
This value is used as an index in the Device Context Base Address Array 
to select the Device
Context of the source device. If this Event is due to a Host Controller 
Command, then this field

shall be cleared to ‘0’."

The xhci spec rev1.0, for the Stop Endpoint Command, the Set TR Dequeue 
Pointer Command
and the Reset Endpoint Command, states explicitely that the Command 
Completion Event
placed on the Event Ring by the xHC shall have initialized the Slot ID 
field to the value of the
command’s Slot ID. However, regarding the Reset Device Command it states 
that this field
should be cleared to zero. So, it was my mistake and your hardware is 
compatible with the

spec.

Hence, either the patch can be reverted or I can send a patch to replace:

case TRB_RESET_DEV:
WARN_ON(slot_id != TRB_TO_SLOT_ID(
le32_to_cpu(cmd_trb->generic.field[3])));
xhci_handle_cmd_reset_dev(xhci, slot_id, event);
break;

with:

case TRB_RESET_DEV:
slot_id = TRB_TO_SLOT_ID(le32_to_cpu(cmd_trb->generic.field[3]));
xhci_handle_cmd_reset_dev(xhci, slot_id, event);
break;

I cc Sarah Sharp and Mathias Nyman to decide which is the best way to 
revert this regression.


regards,
Xenia


--- Bisection details ---

# git bisect log
git bisect start '--' 'drivers/usb/host/'
# good: [8bb495e3f02401ee6f76d1b1d77f3ac9f079e376]
Linux 3.10
git bisect good 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376
# bad: [455c6fdbd219161bd09b1165f11699d6d73de11c]
Linux 3.14
git bisect bad 455c6fdbd219161bd09b1165f11699d6d73de11c
# good: [40b3dc6da05c4ac0e317723a22eaa807c4b98648]
usb: pci-quirks: amd_chipset_sb_type_init() can be static
git bisect good 40b3dc6da05c4ac0e317723a22eaa807c4b98648
# bad: [9b547a882e9ffec67bb41a4e66b4bcc0e91a2737]
usb: r8a66597-hcd: Convert to clk_prepare/unprepare
git bisect bad 9b547a882e9ffec67bb41a4e66b4bcc0e91a2737
# good: [a393a807d0c805e7c723315ff0e88a857055e9c6]
USB: EHCI: start new isochronous streams ASAP
git bisect good a393a807d0c805e7c723315ff0e88a857055e9c6
# bad: [a2cdc3432c361bb885476d1c625e22b518e0bc07]
usb: xhci: remove the unused ->address field
git bisect bad a2cdc3432c361bb885476d1c625e22b518e0bc07
# bad: [20e7acb13ff48fbc884d5918c3697c27de63922a]
xhci: use completion event's slot id rather than dig it out of command
git bisect bad 20e7acb13ff48fbc884d5918c3697c27de63922a
# good: [d194c031994d3fc1038fa09e9e92d9be24a21921]
xhci: correct the usage of USB_CTRL_SET_TIMEOUT
git bisect good d194c031994d3fc1038fa09e9e92d9be24a21921
# good: [b244b431f89e152dd4bf35d71786f1c0eb8cba7e]
xhci: refactor TRB_ENABLE_SLOT case into function
git bisect good b244b431f89e152dd4bf35d71786f1c0eb8cba7e
# good: [9b3103ac9d19525781c297c4fb1e544e077c8901]
xhci: refactor TRB_ADDR_DEV case into function
git bisect good 9b3103ac9d19525781c297c4fb1e544e077c8901
# first bad commit: [20e7acb13ff48fbc884d5918c3697c27de63922a]
xhci: use completion event's slot id rather than dig it out of command

# git show 20e7acb13ff48fbc884d5918c3697c27de63922a
commit 20e7acb13ff48fbc884d5918c3697c27de63922a
Author: Xenia Ragiadakou >

Date:   Mon Sep 9 13:29:50 2013 +0300

 xhci: use completion event's slot id rather than dig it out of command
 Since the slot id retrieved from the Reset Device TRB matches the 
slot id in
 the command completion event, which is available, there is no need to 
determine

 it again.
 This patch removes the uneccessary re

Get back to me

[Kong Hui]

I am a bank director from Hong Kong, I want you to be my partner in a
business project of mutual benefit. Get back to me if interested.


Thank you,
Kong Hui.
--
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: xHCI regression for VIA USB 3.0 controller in handle_cmd_completion

[Saran Neti]

Hi Xenia,

Thanks for looking into this.

On Thu, May 29, 2014 at 6:31 PM, Xenia Ragiadakou  wrote:
> I misunderstood the following description regarding the slot id field of
> Command Completion Event TRB:
>
> "The Slot ID field shall be updated by the xHC to reflect the slot
> associated with the
> command that generated the event, with the following exceptions:
> - The Slot ID shall be cleared to ‘0’ for No Op, Set Latency Tolerance
> Value, Get Port
> Bandwidth, and Force Event Commands.
> - The Slot ID shall be set to the ID of the newly allocated Device Slot for
> the Enable Slot
> Command.
> - The value of Slot ID shall be vendor defined when generated by a vendor
> defined command.
> This value is used as an index in the Device Context Base Address Array to
> select the Device
> Context of the source device. If this Event is due to a Host Controller
> Command, then this field
> shall be cleared to ‘0’."
>
> The xhci spec rev1.0, for the Stop Endpoint Command, the Set TR Dequeue
> Pointer Command and the Reset Endpoint Command, states explicitely that the
> Command Completion Event placed on the Event Ring by the xHC shall have
> initialized the Slot ID field to the value of the command’s Slot ID.
> However, regarding the Reset Device Command it states that this field should
> be cleared to zero. So, it was my mistake and your hardware is compatible
> with the spec.
>

While the spec appears to be unambiguous about Slot ID for
Reset Device event TRB (always 0), in the case of
Set TR Dequeue Pointer Command, Section 4.6.10 says (in xHCI rev 1.1 -
is rev 1.0 similar?):

"To issue a Set TR Dequeue Pointer Command system software shall
perform the following operations:
...
 Write the Host Controller Doorbell with DB Target = Host Controller Command
...

When a Set TR Dequeue Pointer Command is executed by the xHC it shall
perform the following operations:
...
 Slot ID = The value of the command?s Slot ID.
..."

So, when xHC writes a Set TR Dequeue Pointer Command Completion Event
on the ring, there seem to be two different, possibly contradictory,
ways to do it:
1. Following 4.6.10, "Slot ID = The value of the command?s Slot ID."
2. Following your quoted block of text from 6.4.2.2, "If this Event is
due to a Host Controller Command, then this (Slot ID) field shall be
cleared to 0"

Both statements use 'shall', which according Word Usage is the new
'must'. Is there a Section-wise precedence order for cases like this?

The other two commands - Stop Endpoint Command and Reset Endpoint
Command are also subject to the same conundrum, if indeed there is
one.

If I'm mistaken, the email + patch I sent yesterday should be ignored:
http://www.spinics.net/lists/linux-usb/msg108566.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] usb: pci-quirks: Prevent Sony VAIO t-series from switching usb ports

[Jorge]

Just in case, here I am and I'm still using this kernel, and it still 
works :)


Jorge

On 28/05/14 16:52, Greg KH wrote:

On Wed, May 28, 2014 at 03:42:55PM -0400, Alan Stern wrote:

On Wed, 28 May 2014, Greg KH wrote:


On Thu, May 15, 2014 at 11:51:04AM -0400, Alan Stern wrote:

On Thu, 15 May 2014, Mathias Nyman wrote:


Sony VAIO t-series machines are not capable of switching usb2 ports over
from Intel EHCI to xHCI controller. If tried the USB2 port will be left 
unconnected
and unusable.

Signed-off-by: Mathias Nyman 

Have you heard back from Jorge?  Does this fix the problem?

Given a lack of response here, I've dropped this from my queue.
Mathias, please resend when you get answers to this.

To be fair, Jorge did write back after my message was posted.  He said
that the patch does fix his problem.

Ah, I missed that response, sorry.  I'll go dig this back out of my
discard pile...


--
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] Port dummy_hcd to hrtimers

[pktoss]

From: Pantelis Koukousoulas 

dummy_hcd uses jiffies and seems to assume that HZ=1000 and no
tickless behavior. This makes for some horrible performance in
ordinary desktop kernels (tickless / HZ=250) as found in distros.

This patch ports dummy_hcd to use hrtimers instead, which allows
for reasonable performance in distro kernels as well.
(Around 25MB/s for g_mass_storage, around 100MB/s for UAS).

Implementation uses the tasklet_hrtimer framework. This means
dummy_timer callback is executed in softirq context (as it was
with wheel timers) which keeps required changes to a minimum.
---
 drivers/usb/gadget/dummy_hcd.c | 55 +++---
 1 file changed, 36 insertions(+), 19 deletions(-)

diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 67ebf90..7fb6f76 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -166,7 +166,7 @@ enum dummy_rh_state {
 struct dummy_hcd {
struct dummy*dum;
enum dummy_rh_state rh_state;
-   struct timer_list   timer;
+   struct tasklet_hrtimer  ttimer;
u32 port_status;
u32 old_status;
unsigned long   re_timeout;
@@ -1190,8 +1190,11 @@ static int dummy_urb_enqueue(
urb->error_count = 1;   /* mark as a new urb */
 
/* kick the scheduler, it'll do the rest */
-   if (!timer_pending(&dum_hcd->timer))
-   mod_timer(&dum_hcd->timer, jiffies + 1);
+   if (!hrtimer_is_queued(&dum_hcd->ttimer.timer)) {
+   tasklet_hrtimer_start(&dum_hcd->ttimer,
+   ms_to_ktime(1),
+   HRTIMER_MODE_REL);
+   }
 
  done:
spin_unlock_irqrestore(&dum_hcd->dum->lock, flags);
@@ -1211,8 +1214,12 @@ static int dummy_urb_dequeue(struct usb_hcd *hcd, struct 
urb *urb, int status)
 
rc = usb_hcd_check_unlink_urb(hcd, urb, status);
if (!rc && dum_hcd->rh_state != DUMMY_RH_RUNNING &&
-   !list_empty(&dum_hcd->urbp_list))
-   mod_timer(&dum_hcd->timer, jiffies);
+   !list_empty(&dum_hcd->urbp_list) &&
+   !hrtimer_is_queued(&dum_hcd->ttimer.timer)) {
+   tasklet_hrtimer_start(&dum_hcd->ttimer,
+   ns_to_ktime(100),
+   HRTIMER_MODE_REL);
+   }
 
spin_unlock_irqrestore(&dum_hcd->dum->lock, flags);
return rc;
@@ -1646,17 +1653,25 @@ static int handle_control_request(struct dummy_hcd 
*dum_hcd, struct urb *urb,
return ret_val;
 }
 
+
 /* drive both sides of the transfers; looks like irq handlers to
  * both drivers except the callbacks aren't in_irq().
  */
-static void dummy_timer(unsigned long _dum_hcd)
+static enum hrtimer_restart dummy_timer(struct hrtimer *timer)
 {
-   struct dummy_hcd*dum_hcd = (struct dummy_hcd *) _dum_hcd;
+   struct tasklet_hrtimer *ttimer = container_of(timer,
+ struct tasklet_hrtimer,
+ timer);
+   struct dummy_hcd *dum_hcd = container_of(ttimer,
+struct dummy_hcd,
+ttimer);
+
struct dummy*dum = dum_hcd->dum;
struct urbp *urbp, *tmp;
unsigned long   flags;
int limit, total;
int i;
+   ktime_t next_tick;
 
/* simplistic model for one frame's bandwidth */
switch (dum->gadget.speed) {
@@ -1675,11 +1690,9 @@ static void dummy_timer(unsigned long _dum_hcd)
break;
default:
dev_err(dummy_dev(dum_hcd), "bogus device speed\n");
-   return;
+   goto out;
}
 
-   /* FIXME if HZ != 1000 this will probably misbehave ... */
-
/* look at each urb queued by the host side driver */
spin_lock_irqsave(&dum->lock, flags);
 
@@ -1687,7 +1700,7 @@ static void dummy_timer(unsigned long _dum_hcd)
dev_err(dummy_dev(dum_hcd),
"timer fired with no URBs pending?\n");
spin_unlock_irqrestore(&dum->lock, flags);
-   return;
+   goto out;
}
 
for (i = 0; i < DUMMY_ENDPOINTS; i++) {
@@ -1859,10 +1872,16 @@ return_urb:
dum_hcd->udev = NULL;
} else if (dum_hcd->rh_state == DUMMY_RH_RUNNING) {
/* want a 1 msec delay here */
-   mod_timer(&dum_hcd->timer, jiffies + msecs_to_jiffies(1));
+   next_tick = 
ktime_add(hrtimer_get_expires(&dum_hcd->ttimer.timer),
+   ms_to_ktime(1));
+   tasklet_hrtimer_start(&dum_hcd->ttimer, next_tic

dummy_hcd performance / correctness

[pktoss]

I couldn't use dummy_hcd with g_tcm_gadget (UAS storage) with recent 3.15-rc
kernels, firstly it wouldn't even work because stream support was broken
and when I could get it to work with g_mass_storage, performance was horrible
due to the driver using jiffies instead of hrtimers.

With these two patches dummy_hcd works for me acceptably (no doubt it can
be improved even more). Without them I get 4MB/s with usb-storage
(because uas.ko wouldn't bind due to broken streams regression).
With them I get 100MB/s with uas / tcm_usb_gadget (and 25MB/s
for g_mass_storage) in an ordinary 3.15-rc8 HZ=250 tickless kernel.

Please review and consider merging, other people have complained for
the performance problem of dummy_hcd as well, e.g:

http://stackoverflow.com/questions/18606393/very-low-performance-of-g-mass-storage-virtual-usb-device
http://comments.gmane.org/gmane.linux.usb.general/86580

--
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] Add can_do_streams to dummy_hcd

[pktoss]

From: Pantelis Koukousoulas 

Recent commit (14aec589327a6fc4035f5327d90ac5548f501c4c) added the
"can_do_streams" field to the hcd structure but only set it to 1
in the XHCI driver.

dummy_hcd can also do streams so set can_do_streams = 1 for that
as well.

This fixes the regression that uas host driver stopped accepting
to bind to the tcm_usb_gadget under dummy_hcd after the offending
commit above.
---
 drivers/usb/gadget/dummy_hcd.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/gadget/dummy_hcd.c b/drivers/usb/gadget/dummy_hcd.c
index 8c06430..67ebf90 100644
--- a/drivers/usb/gadget/dummy_hcd.c
+++ b/drivers/usb/gadget/dummy_hcd.c
@@ -2544,6 +2544,8 @@ static int dummy_hcd_probe(struct platform_device *pdev)
retval = usb_add_hcd(ss_hcd, 0, 0);
if (retval)
goto put_usb3_hcd;
+
+   ss_hcd->can_do_streams = 1;
}
return 0;
 
-- 
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