[PATCH 1/4] usb: mtu3: add generic compatible string

[Chunfeng Yun]

The mtu3 driver is a generic driver for MediaTek usb3 DRD IP, add
a generic compatible to avoid confusion when support new SoCs but
use a compatible with specific SoC's name "mt8173".

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_plat.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index 0d3ebb3..088e3e6 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -500,6 +500,7 @@ static int __maybe_unused mtu3_resume(struct device *dev)
 
 static const struct of_device_id mtu3_of_match[] = {
{.compatible = "mediatek,mt8173-mtu3",},
+   {.compatible = "mediatek,mtu3",},
{},
 };
 
-- 
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 2/4] usb: xhci-mtk: add generic compatible string

[Chunfeng Yun]

The xhci-mtk driver is a generic driver for MediaTek xHCI IP, add
a generic compatible to avoid confusion when support new SoCs but
use a compatible with specific SoC's name "mt8173".

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 67d5dc7..d2934b9 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -795,6 +795,7 @@ static int __maybe_unused xhci_mtk_resume(struct device 
*dev)
 #ifdef CONFIG_OF
 static const struct of_device_id mtk_xhci_of_match[] = {
{ .compatible = "mediatek,mt8173-xhci"},
+   { .compatible = "mediatek,xhci-mtk"},
{ },
 };
 MODULE_DEVICE_TABLE(of, mtk_xhci_of_match);
-- 
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 3/4] dt-bindings: mt8173-mtu3: add generic compatible and rename file

[Chunfeng Yun]

The mt8173-mtu3.txt actually holds the bindings for all mediatek
SoCs with usb3 DRD IP, so add a generic compatible and change the
name to mtu3.txt.

Signed-off-by: Chunfeng Yun 
---
 .../bindings/usb/{mt8173-mtu3.txt => mtu3.txt} |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
 rename Documentation/devicetree/bindings/usb/{mt8173-mtu3.txt => mtu3.txt} 
(95%)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
b/Documentation/devicetree/bindings/usb/mtu3.txt
similarity index 95%
rename from Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
rename to Documentation/devicetree/bindings/usb/mtu3.txt
index 1d7c3bc..832741d 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mtu3.txt
@@ -1,7 +1,9 @@
 The device node for Mediatek USB3.0 DRD controller
 
 Required properties:
- - compatible : should be "mediatek,mt8173-mtu3"
+ - compatible : should be one of
+   "mediatek,mt8173-mtu3" (deprecated, use "mediatek,mtu3" instead),
+   "mediatek,mtu3"
  - reg : specifies physical base address and size of the registers
  - reg-names: should be "mac" for device IP and "ippc" for IP port control
  - interrupts : interrupt used by the device IP
@@ -44,7 +46,7 @@ Optional properties:
 Sub-nodes:
 The xhci should be added as subnode to mtu3 as shown in the following example
 if host mode is enabled. The DT binding details of xhci can be found in:
-Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+Documentation/devicetree/bindings/usb/xhci-mtk.txt
 
 Example:
 ssusb: usb@11271000 {
-- 
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 4/4] dt-bindings: mt8173-xhci: add generic compatible and rename file

[Chunfeng Yun]

The mt8173-xhci.txt actually holds the bindings for all mediatek
SoCs with xHCI controller, so add a generic compatible and change
the name to xhci-mtk.txt to reflect that.

Signed-off-by: Chunfeng Yun 
---
 .../bindings/usb/{mt8173-xhci.txt => xhci-mtk.txt} |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)
 rename Documentation/devicetree/bindings/usb/{mt8173-xhci.txt => xhci-mtk.txt} 
(92%)

diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt 
b/Documentation/devicetree/bindings/usb/xhci-mtk.txt
similarity index 92%
rename from Documentation/devicetree/bindings/usb/mt8173-xhci.txt
rename to Documentation/devicetree/bindings/usb/xhci-mtk.txt
index 0acfc8a..1ce77c7 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/xhci-mtk.txt
@@ -11,7 +11,9 @@ into two parts.
 
 
 Required properties:
- - compatible : should contain "mediatek,mt8173-xhci"
+ - compatible : should be one of
+   "mediatek,mt8173-xhci" (deprecated, use "mediatek,xhci-mtk" instead),
+   "mediatek,xhci-mtk"
  - reg : specifies physical base address and size of the registers
  - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
  - interrupts : interrupt used by the controller
@@ -68,10 +70,12 @@ usb30: usb@1127 {
 
 In the case, xhci is added as subnode to mtu3. An example and the DT binding
 details of mtu3 can be found in:
-Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
+Documentation/devicetree/bindings/usb/mtu3.txt
 
 Required properties:
- - compatible : should contain "mediatek,mt8173-xhci"
+ - compatible : should be one of
+   "mediatek,mt8173-xhci" (deprecated, use "mediatek,xhci-mtk" instead),
+   "mediatek,xhci-mtk"
  - reg : specifies physical base address and size of the registers
  - reg-names: should be "mac" for xHCI MAC
  - interrupts : interrupt used by the host controller
-- 
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: dwc3: omap: fix error return code in dwc3_omap_probe()

[Gustavo A. R. Silva]

platform_get_irq() returns an error code, but the dwc3-omap driver
ignores it and always returns -EINVAL. This is not correct and,
prevents -EPROBE_DEFER from being propagated properly.

Notice that platform_get_irq() no longer returns 0 on error:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af

Print and propagate the return value of platform_get_irq on failure.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/dwc3/dwc3-omap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index f5aaa0c..3530795 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -478,8 +478,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
 
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
-   dev_err(dev, "missing IRQ resource\n");
-   return -EINVAL;
+   dev_err(dev, "missing IRQ resource: %d\n", irq);
+   return irq;
}
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
2.5.0

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

new usb LTE modem device

[Giuseppe Lippolis]

Hi all,
I'm working to port OpenWRT/LEDE on a new router with embedded usb LTE
modem.
The modem have 3 qmi_wwan interfaces and 2 option.

I would like to prepare the patch, but before I would like to know if using
the QMI_FIXED_INTF macro is the best way to identify the interface or if
there is a better way.

Here the info grapped from cat /proc/bus/usb/devices using the stock
firmware:

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1435 ProdID=0918 Rev= 2.32
S:  Manufacturer=Android
S:  Product=Android
S:  SerialNumber=0123456789ABCDEF
C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E:  Ad=84(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=86(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=88(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E:  Ad=8a(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
E:  Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 6 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=(none)
E:  Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS= 512 Ivl=125us

Thanks,
Bye.

--
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: imx21-hcd: fix error return code in imx21_probe()

[Gustavo A. R. Silva]

platform_get_irq() returns an error code, but the imx21-hcd driver
ignores it and always returns -ENXIO. This is not correct, and
prevents -EPROBE_DEFER from being propagated properly.

Notice that platform_get_irq() no longer returns 0 on error:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af

Print error message and propagate the return value of platform_get_irq
on failure.

This issue was detected with the help of Coccinelle.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/usb/host/imx21-hcd.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/imx21-hcd.c b/drivers/usb/host/imx21-hcd.c
index f542045..e25d72e 100644
--- a/drivers/usb/host/imx21-hcd.c
+++ b/drivers/usb/host/imx21-hcd.c
@@ -1849,8 +1849,10 @@ static int imx21_probe(struct platform_device *pdev)
if (!res)
return -ENODEV;
irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
-   return -ENXIO;
+   if (irq < 0) {
+   dev_err(>dev, "Failed to get IRQ: %d\n", irq);
+   return irq;
+   }
 
hcd = usb_create_hcd(_hc_driver,
>dev, dev_name(>dev));
-- 
2.5.0

--
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 v5 1/1] usb:host:xhci support option to disable the xHCI USB2 HW LPM

[Thang Q. Nguyen]

XHCI specification 1.1 does not require xHCI-compliant controllers
to always enable hardware USB2 LPM. However, the current xHCI
driver always enable it when seeing HLC=1.
This patch supports an option for users to control disabling
USB2 Hardware LPM via DT/ACPI attribute.
This option is needed in case user would like to disable this
feature. For example, their xHCI controller has its USB2 HW LPM
broken.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
Acked-by: Rob Herring 
---
Changes since v4:
 - When HW LPM is optionally disabled, explicitly disable HLE, RWE, ...
 - Update codes to work with kernel 4.13-rc4
 - Add Acked-By from Rob Herring 
Changes since v3:
 - Bypass updating LPM parameters when HW LPM is optionally disabled.
Changes since v2:
 - Change code to disable HW LPM as an option for user which
   is set via ACPI/DT.
Changes since v1:
 - Update DT/ACPI attribute and corresponding codes from HLE to LPM to
   be consistent with other attribute names.
---
 Documentation/devicetree/bindings/usb/usb-xhci.txt |1 +
 drivers/usb/host/xhci-plat.c   |3 +++
 drivers/usb/host/xhci.c|2 +-
 drivers/usb/host/xhci.h|1 +
 4 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt 
b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 2d80b60..ae6e484 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -26,6 +26,7 @@ Required properties:
 
 Optional properties:
   - clocks: reference to a clock
+  - usb2-lpm-disable: indicate if we don't want to enable USB2 HW LPM
   - usb3-lpm-capable: determines if platform is USB3 LPM capable
   - quirk-broken-port-ped: set if the controller has broken port disable 
mechanism
 
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index c04144b..9028fb5 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -267,6 +267,9 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto disable_clk;
}
 
+   if (device_property_read_bool(sysdev, "usb2-lpm-disable"))
+   xhci->quirks |= XHCI_HW_LPM_DISABLE;
+
if (device_property_read_bool(sysdev, "usb3-lpm-capable"))
xhci->quirks |= XHCI_LPM_SUPPORT;
 
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index b2ff1ff..3a8e75f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4087,7 +4087,7 @@ static int xhci_set_usb2_hardware_lpm(struct usb_hcd *hcd,
xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n",
enable ? "enable" : "disable", port_num + 1);
 
-   if (enable) {
+   if (enable && !(xhci->quirks & XHCI_HW_LPM_DISABLE)) {
/* Host supports BESL timeout instead of HIRD */
if (udev->usb2_hw_lpm_besl_capable) {
/* if device doesn't have a preferred BESL value use a
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index e3e9352..5d89c51 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1821,6 +1821,7 @@ struct xhci_hcd {
 #define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
 #define XHCI_U2_DISABLE_WAKE   (1 << 27)
 #define XHCI_ASMEDIA_MODIFY_FLOWCONTROL(1 << 28)
+#define XHCI_HW_LPM_DISABLE(1 << 29)
 
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
-- 
1.7.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 v2 2/3] usb: chipidea: Hook into mux framework to toggle usb switch

[Stephen Boyd]

Quoting Peter Rosin (2017-07-31 03:33:22)
> On 2017-07-14 23:40, Stephen Boyd wrote:
> > @@ -1964,16 +1965,26 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
> >  
> >  static int udc_id_switch_for_device(struct ci_hdrc *ci)
> >  {
> > + int ret = 0;
> > +
> >   if (ci->is_otg)
> >   /* Clear and enable BSV irq */
> >   hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
> >   OTGSC_BSVIS | OTGSC_BSVIE);
> >  
> > - return 0;
> > + if (!ci_otg_is_fsm_mode(ci))
> > + ret = mux_control_select(ci->platdata->usb_switch, 0);
> > +
> > + if (ci->is_otg && ret)
> > + hw_write_otgsc(ci, OTGSC_BSVIE | OTGSC_BSVIS, OTGSC_BSVIS);
> > +
> > + return ret;
> >  }
> >  
> >  static void udc_id_switch_for_host(struct ci_hdrc *ci)
> >  {
> > + mux_control_deselect(ci->platdata->usb_switch);
> > +
> 
> This looks broken. You conditionally lock the mux and you unconditionally
> unlock it. Quoting the mux_control_deselect doc:
> 
>  * It is required that a single call is made to mux_control_deselect() for
>  * each and every successful call made to either of mux_control_select() or
>  * mux_control_try_select().
> 
> Think of the mux as a semaphore with a max count of one. If you lock it,
> you have to unlock it when you're done. If you didn't lock it, you have
> zero business unlocking it. If you try to lock it but fail, you also have
> no business unlocking it. Just like a semaphore.

Good catch. I've added a if (!ci_otg_is_fsm_mode()) check here.

> 
> Another point: I do not know if udc_id_switch_for_host is *only* called
> when there has been a prior call to udc_id_switch_for_device that
> succeeded or how this works exactly. But this all looks fragile. Using
> mux_control_select and mux_control_deselect *must* be done in pairs.
> If you want a mux to be locked for "a while", such as in this case, you
> have to make sure you stay within the rules. There is no room for half
> measures, or you will likely cause a deadlock when something unexpected
> happens.
> 

Can you elaborate? Is it bad that we keep it "locked" while we're in
host or device mode? It looked like we paired the start/stop ops with
each other so that the mux is properly managed across these ops. My
testing hasn't shown a problem, but maybe there's some corner case
you're thinking of? I'll double check the code.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common

[Lu Baolu]

Hi,

On 08/07/2017 04:13 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu  writes:
>> The component u_serial provides a glue layer between TTY layer
>> and a USB gadget device needed to provide a basic serial port
>> functionality. Currently, u_serial sits under gadget/function
>> and depends on CONFIG_USB_GADGET to be compiled and used.
>>
>> Most of the serial gadget devices are based on a UDC (USB device
>> controller) and implemented by making use of the Linux gadget
>> frameworks. But we are facing other implementions as well. One
>> example can be found with xHCI debug capability. The xHCI debug
>> capability implements a serial gadget with hardware and firmware,
>> and provides an interface similar with xHCI host for submitting
>> and reaping the transfer requests.
>>
>> In order to make better use of u_serial when implementing xHCI
>> debug capability in xHCI driver, this patch moves u_serial.c
>> from gadget/function to usb/common, and moves u_serial.h from
>> gadget/function to include/linux/usb.
>>
>> Signed-off-by: Lu Baolu 
> NAK, u_serial uses the gadget API. It's definitely not COMMON.
>

Okay. It seems that I can't use u_serial anyway. I will implement
a new tty glue for my case.

Best regards,
Lu Baolu
--
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

work as our crude oil facilitator

[Randell waters]

Venon Oil/Energy Corporation Us is looking for a partner, to be our 
coordinator in Europe and Asia,

which you will act as an intermediary between our company and the
final buyer of petroleum products in those regions,Inform us if you are 
interested

Sincerely,
Randell Waters
(Managing Director, Petroleum Sales Department)
--
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] arm64: dts: hi6220: improve g-tx-fifo-size setting for usb device

[John Stultz]

On Sun, Aug 6, 2017 at 10:01 PM, Shawn Guo  wrote:
> From: Shawn Guo 
>
> The current usb device g-tx-fifo-size setting in DT causes two problems
> for kernel driver.
>
> 1. On hi6220, there are 15 tx_fifo dedicated for all EPs except EP0,
>while DT only provides tx_fifo settings for 6 EPs.  It results in the
>following annoying complaints from kernel.
>
> [4.451623] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[7]=0
> [4.461303] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[8]=0
> [4.470969] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[9]=0
> [4.480632] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[10]=0
> [4.490385] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[11]=0
> [4.500140] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[12]=0
> [4.509892] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[13]=0
> [4.519646] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[14]=0
> [4.529399] dwc2 f72c.usb: dwc2_check_param_tx_fifo_sizes: Invalid 
> parameter g_tx_fifo_size[15]=0
> [4.539244] dwc2 f72c.usb: EPs: 16, dedicated fifos, 1920 entries in 
> SPRAM
>
>Besides of that, the total 1920 fifo entries isn't fully utilized.
>Endpoint Info Control block consumes 128 entries, g-rx-fifo-size
>is 512, and g-np-tx-fifo-size is 128.  So the fifi entries available
>for tx_fifo is: 1920 - 128 - 512 - 128 = 1152.  Considering that
>the minimal valid tx_fifo size for each EP is 16, it should be
>reasonable to allocate 1152 entries as: 128 x 8 + 16 x 7 = 1136 (only
>16 entries unused).  With this new setting, we can get more EPs to
>use while removing the above warning messages in the meantime.
>
> 2. Another consequence of above invalid g_tx_fifo_size parameter is that
>kernel driver will use values read from hardware register as the
>fall-back.  The value is 2048 for each EP fifo.  That's obviously
>invalid either, because even fifo entries for one EP exceeds the
>total entries 1920.  That's why we see the following fat warning from
>function dwc2_hsotg_init_fifo().  The new g-tx-fifo-size settings
>help to remove the warning as well.


Nice! This has been bothering me for awhile, and your fix seems to
resolve it well! I can now remove one of the hack patches I've been
carrying.

Tested-by: John Stultz 
(if its useful: Acked-by: John Stultz )

Wei: Can we be sure to get this queued for 4.14?

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

Re: unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[John Stultz]

On Mon, Aug 7, 2017 at 2:05 PM, John Stultz  wrote:
> So, with recent testing with my HiKey board, I've been noticing some
> quirky behavior with my USB eth adapter.
>
> Basically, pluging the usb eth adapter in and then removing it, when
> plugging it back in I often find that its not detected, and the system
> slowly spits out the following message over and over:
>   unregister_netdevice: waiting for eth0 to become free. Usage count = 1

The other bit is that after this starts printing, the board will no
longer reboot (it hangs continuing to occasionally print the above
message), and I have to manually reset the device.

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

unregister_netdevice: waiting for eth0 to become free. Usage count = 1

[John Stultz]

So, with recent testing with my HiKey board, I've been noticing some
quirky behavior with my USB eth adapter.

Basically, pluging the usb eth adapter in and then removing it, when
plugging it back in I often find that its not detected, and the system
slowly spits out the following message over and over:
  unregister_netdevice: waiting for eth0 to become free. Usage count = 1

I've tried to go through and bisect it, but apparently the issue isn't
always reproducible, as I'm apparently getting lots of false negatives
(where I can't always reproduce boot to boot the issue on the same
kernel).

I've done three bisection passes (always restarting with the "first
bad commit" from the previous bisection as the initial bad commit for
the following pass), and it does seem to keep moving back. But it
seems much easier to trigger with newer kernels then older (and so far
I've not seen it with 4.12).

Wanted to see if anyone had any ideas what might be going wrong, and
how I should further debug this.

The last bisect log I generated was:

# good: [6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c] Linux 4.12
git bisect good 6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
# bad: [98fdd857a3bd6a3bf0003d3f68f07c25c85dcde3] net: ethernet: ti:
cpsw: move skb timestamp to packet_submit
git bisect bad 98fdd857a3bd6a3bf0003d3f68f07c25c85dcde3
# good: [48b6bbef9a1789f0365c1a385879a1fea4460016] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
git bisect good 48b6bbef9a1789f0365c1a385879a1fea4460016
# good: [a2e8bbd2ef5457485f00b6b947bbbfa2778e5b1e] bpf: Fix
test_obj_id.c for llvm 5.0
git bisect good a2e8bbd2ef5457485f00b6b947bbbfa2778e5b1e
# good: [273889e306256e95ea55d5ebaef99310cf589def] Merge tag
'mlx5-updates-2017-06-16' of
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
git bisect good 273889e306256e95ea55d5ebaef99310cf589def
# bad: [8f46d46715a12f509e13200033a1ed4d6cf335ff] cxgb4: Use Firmware
params to get buffer-group map
git bisect bad 8f46d46715a12f509e13200033a1ed4d6cf335ff
# bad: [f5c306470ed0a8f03ba7017f397da2555b5800d4] Merge tag
'mlx5-updates-2017-06-20' of
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
git bisect bad f5c306470ed0a8f03ba7017f397da2555b5800d4
# bad: [e289ef0ded13021db292be9aef134451546e7c60] net: dsa: mv88e6xxx:
clarify SMI PHY functions
git bisect bad e289ef0ded13021db292be9aef134451546e7c60
# bad: [836d57e5c08e13bb206dcd559d96ee9355e8316e] liquidio: implement
vlan filter enable and disable
git bisect bad 836d57e5c08e13bb206dcd559d96ee9355e8316e
# bad: [ad65a2f05695aced349e308193c6e2a6b1d87112] ipv6: call
dst_hold_safe() properly
git bisect bad ad65a2f05695aced349e308193c6e2a6b1d87112
# good: [0830106c53900181d336350581119af09e123bf3] ipv4: take
dst->__refcnt when caching dst in fib
git bisect good 0830106c53900181d336350581119af09e123bf3
# good: [b838d5e1c5b6e57b10ec8af2268824041e3ea911] ipv4: mark DST_NOGC
and remove the operation of dst_free()
git bisect good b838d5e1c5b6e57b10ec8af2268824041e3ea911
# bad: [9514528d92d4cbe086499322370155ed69f5d06c] ipv6: call
dst_dev_put() properly
git bisect bad 9514528d92d4cbe086499322370155ed69f5d06c
# good: [1cfb71eeb12047bcdbd3e6730ffed66e810a0855] ipv6: take
dst->__refcnt for insertion into fib6 tree
git bisect good 1cfb71eeb12047bcdbd3e6730ffed66e810a0855
# first bad commit: [9514528d92d4cbe086499322370155ed69f5d06c] ipv6:
call dst_dev_put() properly


But again, reverting the "ipv6: call dst_dev_put() properly" commit
doesn't seem to completely resolve the issue on newer kernels (though
it may make it harder to trigger), and I suspect with further
bisection passes I might move further back.

Ideas?  I don't seem to have similar issues with USB mass storage
devices, so it seems to be networking specific.

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

Re: [PATCH V1 0/3] asix: Improve robustness

[David Miller]

From: Dean Jenkins 
Date: Mon, 7 Aug 2017 09:50:13 +0100

> Please consider taking these patches to improve the robustness of the ASIX USB
> to Ethernet driver.

I applied these to 'net' since they are bug fixes.

Please target bug fixes to 'net' instead of 'net-next' in the
future, unless they are fixing problems which only exist in
'net-next'.

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

RE: EMPLOYEE SURVEY!!!!

[Oo, Thiri T (OOTT15)]

From: Oo, Thiri T (OOTT15)
Sent: Monday, August 07, 2017 10:20 PM
To: Oo, Thiri T (OOTT15)
Subject: EMPLOYEE SURVEY

Dear Colleague,
Please take a moment to complete a survey on incident INC0903501
Regarding "help desk survey on your email" Your feedback is extremely valuable.

Please Click 
HERE To Begin 
Survey.

HR Management
IT-SERVICE HELPDESK



CONFIDENTIALITY NOTICE: The materials in this electronic mail transmission 
(including all attachments) are private and confidential and are the property 
of the sender. The information contained in the material is privileged and is 
intended only for the use of the named addressee(s). If you are not the 
intended addressee, be advised that any unauthorized disclosure, copying, 
distribution or the taking of any action in reliance on the contents of this 
material is strictly prohibited. If you have received this e-mail in error, 
please immediately notify the sender by replying to the e-mail, and then 
destroy it immediately. Thank you.
--
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] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 Toughbook

[Johan Hovold]

On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
> From: Oleg Kokorin 
> Date: Mon, 7 Aug 2017 15:35:53 +0200
> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
>  Toughbook

Please use

USB: serial: qcserial: add support for Panasonic CF-U1 Toughbook

as Subject (patch summary), and also add a commit message here (e.g.
your current summary).

> Signed-off-by: Oleg Kokorin 
> ---
>  drivers/usb/serial/qcserial.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
> index ebc0bee..53786ce 100644
> --- a/drivers/usb/serial/qcserial.c
> +++ b/drivers/usb/serial/qcserial.c
> @@ -76,6 +76,8 @@ static const struct usb_device_id id_table[] = {
> {DEVICE_G1K(0x1bc7, 0x900e)},   /* Telit Gobi QDL device */
>  
> /* Gobi 2000 devices */
> +   {USB_DEVICE(0x04da, 0x250e)},   /* Panasonic Gobi 2000 QDL device */
> +   {USB_DEVICE(0x04da, 0x250f)},   /* Panasonic Gobi 2000 Modem device */

This patch is whitespace-damaged and does not apply. Please try sending
the patch to yourself first (e.g. using git-send-email) and make sure
you can apply it it with git am. Running checkpatch on the result is
also a good idea.

> {USB_DEVICE(0x1410, 0xa010)},   /* Novatel Gobi 2000 QDL device */
> {USB_DEVICE(0x1410, 0xa011)},   /* Novatel Gobi 2000 QDL device */
> {USB_DEVICE(0x1410, 0xa012)},   /* Novatel Gobi 2000 QDL device */

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

Possible null pointer dereference in isp1760.ko

[Anton Volkov]

Hello.

While searching for races in the Linux kernel I've come across 
"drivers/usb/isp1760/isp1760.ko" module. Here is a question that I came 
up with while analyzing results. Lines are given using the info from 
Linux v4.12.


Consider the following case:

Thread 1: Thread 2:
isp1760_plat_probe
-> isp1760_register
   -> isp1760_udc_register
 request_irq(...,udc)
  -> isp1760_udc_init_eps(udc)isp1760_udc_irq
   for(i = 0; ...){  for(i = 0; ...) {
 ep = >ep[i]   ep = >ep[i%2]
 -> isp1760_ep_rx_ready(ep)
 INIT_LIST_HEAD(ep->queue) list_empty(>queue)
 (isp1760-udc.c: line 1367)(isp1760-udc.c: line 303)

As far as I understand ep->queue is NULL before its initialization in 
isp1760_udc_init_eps and list_empty() tries to access the '->next' 
pointer member of the passed parameter.


Is this case possible from your point of view?

Thank you for your time.

-- Anton Volkov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: avol...@ispras.ru
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/3] ARM: dts: k2g: Add support for USB instances on 66AK2G

[santosh.shilim...@oracle.com]

On 8/2/17 1:17 PM, Franklin S Cooper Jr wrote:

Add support for 66AK2G usb instances. However, the driver needs to be updated
to support PM_RUNTIME. This update has been validated to work on K2L and boot
tested on K2HK and K2E.

Franklin S Cooper Jr (2):
   usb: dwc3: keystone: Add PM_RUNTIME Support to DWC3 Keystone USB
 driver
   dt-bindings: usb: keystone-usb: Update bindings pm and clocks
 properties

Vitaly Andrianov (1):
   ARM: dts: k2g: Add USB instances

  .../devicetree/bindings/usb/keystone-usb.txt   | 18 ++-
  arch/arm/boot/dts/keystone-k2g.dtsi| 56 ++
  drivers/usb/dwc3/dwc3-keystone.c   | 22 -
  3 files changed, 82 insertions(+), 14 deletions(-)


Once you get you driver patch lined up, post
the DTS patch separately.

Regards,
Santosh
--
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: drivers/usb/host/xhci-ring.c:1390 handle_cmd_completion

[Mathias Nyman]

Hi

back from my vacation.

On 27.07.2017 04:04, Jason A. Donenfeld wrote:

Hey Mathias,

While the oops has been fixed in the latest kernels, as of 4.12.3, I'm
still having issues where USB "stops working" after a while. If I
restart, then after a long while, it stops working again. If I simply
rmmod all the USB-related modules and modprobe xhci_pci, things work
again, but pretty soon after -- maybe 15ish minutes -- it's broken
again. If it's of any help, I'm often plugging and unplugging a USB
hub with quite a few devices on it. The message in my dmesg this time
isn't an BUG, like in the previous kernels, but rather this more
subdued set of messages:

[529153.583731] xhci_hcd :00:14.0: Timeout while waiting for setup
device command
[529159.215731] xhci_hcd :00:14.0: ERROR mismatched command completion event
[529159.215768] xhci_hcd :00:14.0: Timeout while waiting for setup
device command


Odd, looks like something could still messed up with the comma queue,
or events are received out of order. Or maybe we don't get the interrupt for 
command completion event.

Any chance you could take traces of this?
It would show more details about the queued commands and completions.

xhci traces can be taken with:

mount -t debugfs none /sys/kernel/debug
echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable

then after issue triggers send me the content of
/sys/kernel/debug/tracing/trace   (it will be huge)
and dmesg

Thanks
Mathias


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

Re: [PATCH] usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter

[Oliver Neukum]

Am Montag, den 07.08.2017, 17:33 +0800 schrieb Kai-Heng Feng:
> On Mon, Aug 7, 2017 at 5:08 PM, Oliver Neukum  wrote:
> > 
> > Am Freitag, den 04.08.2017, 17:34 +0800 schrieb Kai-Heng Feng:
> > > 
> > > The Realtek r8153 ethernet does not work on Genesys Logic hub, no-lpm
> > > quirk can make it work.
> > 
> > So can you confirm it works with LPM on another hub?
> 
> Yes, another r8153 dongle (Dell Type-C to Ethernet) does not have this issue.

OK.

> > 
> > 
> > > 
> > > Since another r8153 dongle at my hand does not have the issue, so add
> > > the quirk to the hub instead.
> > 
> > This does not match the comment in the patch. This needs to
> > be clarified.
> 
> The Moshi USB to Ethernet Adapter internally has a Genesys Logic hub.
> Ethernet chip r8153 is connected to the Genesys Logic hub.
> 
> I'll resend a patch with this information if it's clear enough.

Thanks. The piece about an internal hub was missing.

Regards
Oliver

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

Re: [PATCH] usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter

[Kai-Heng Feng]

On Mon, Aug 7, 2017 at 5:08 PM, Oliver Neukum  wrote:
> Am Freitag, den 04.08.2017, 17:34 +0800 schrieb Kai-Heng Feng:
>> The Realtek r8153 ethernet does not work on Genesys Logic hub, no-lpm
>> quirk can make it work.
>
> So can you confirm it works with LPM on another hub?

Yes, another r8153 dongle (Dell Type-C to Ethernet) does not have this issue.

>
>> Since another r8153 dongle at my hand does not have the issue, so add
>> the quirk to the hub instead.
>
> This does not match the comment in the patch. This needs to
> be clarified.

The Moshi USB to Ethernet Adapter internally has a Genesys Logic hub.
Ethernet chip r8153 is connected to the Genesys Logic hub.

I'll resend a patch with this information if it's clear enough.

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

Re: [PATCH 2/3] gpio: Add FT232H CBUS GPIO driver

[Linus Walleij]

On Tue, Aug 1, 2017 at 11:24 AM, Johan Hovold  wrote:
> On Tue, Aug 01, 2017 at 08:49:02AM +0200, Linus Walleij wrote:
>> On Thu, Jul 6, 2017 at 10:49 PM, Anatolij Gustschin  wrote:
>>
>> > Add driver for CBUS pins on FT232H. The driver supports setting
>> > GPIO direction and getting/setting CBUS 0-3 pin value. The CBUS
>> > pins have to be enabled by configuring I/O mode in the FTDI EEPROM.
>> >
>> > Signed-off-by: Anatolij Gustschin 
>
>> Apart from these small things it looks like a solid and nice driver,
>> do you plan to merge this into MFD or should I merge it? Since it depends
>> on the Kconfig symbol I guess I can merge it orthogonally if I am sure
>> Lee will pick the MFD part.
>
> There are some fundamental problems with this series which prevents it
> from being merged. Please take a look at the discussion following patch
> 1/3.

Allright it is on hold pending the MFD discussion.

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

Re: [PATCH] usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter

[Oliver Neukum]

Am Freitag, den 04.08.2017, 17:34 +0800 schrieb Kai-Heng Feng:
> The Realtek r8153 ethernet does not work on Genesys Logic hub, no-lpm
> quirk can make it work.

So can you confirm it works with LPM on another hub?

> Since another r8153 dongle at my hand does not have the issue, so add
> the quirk to the hub instead.

This does not match the comment in the patch. This needs to
be clarified.

Regards
Oliver

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

[PATCH V1 2/3] asix: Ensure asix_rx_fixup_info members are all reset

[Dean Jenkins]

There is a risk that the members of the structure asix_rx_fixup_info
become unsynchronised leading to the possibility of a malfunction.

For example, rx->split_head was not being set to false after an
error was detected so potentially could cause a malformed 32-bit
Data header word to be formed.

Therefore add function reset_asix_rx_fixup_info() to reset all the
members of asix_rx_fixup_info so that future processing will start
with known initial conditions.

Also, if (skb->len != offset) becomes true then call
reset_asix_rx_fixup_info() so that the processing of the next URB
starts with known initial conditions. Without the call, the check
does nothing which potentially could lead to a malfunction
when the next URB is processed.

In addition, for robustness, call reset_asix_rx_fixup_info() before
every error path's "return 0". This ensures that the next URB is
processed from known initial conditions.

Signed-off-by: Dean Jenkins 
---
 drivers/net/usb/asix_common.c | 34 +-
 1 file changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 6983b6b..fda74f3 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -75,6 +75,27 @@ void asix_write_cmd_async(struct usbnet *dev, u8 cmd, u16 
value, u16 index,
   value, index, data, size);
 }
 
+static void reset_asix_rx_fixup_info(struct asix_rx_fixup_info *rx)
+{
+   /* Reset the variables that have a lifetime outside of
+* asix_rx_fixup_internal() so that future processing starts from a
+* known set of initial conditions.
+*/
+
+   if (rx->ax_skb) {
+   /* Discard any incomplete Ethernet frame in the netdev buffer */
+   kfree_skb(rx->ax_skb);
+   rx->ax_skb = NULL;
+   }
+
+   /* Assume the Data header 32-bit word is at the start of the current
+* or next URB socket buffer so reset all the state variables.
+*/
+   rx->remaining = 0;
+   rx->split_head = false;
+   rx->header = 0;
+}
+
 int asix_rx_fixup_internal(struct usbnet *dev, struct sk_buff *skb,
   struct asix_rx_fixup_info *rx)
 {
@@ -99,15 +120,7 @@ int asix_rx_fixup_internal(struct usbnet *dev, struct 
sk_buff *skb,
if (size != ((~rx->header >> 16) & 0x7ff)) {
netdev_err(dev->net, "asix_rx_fixup() Data Header 
synchronisation was lost, remaining %d\n",
   rx->remaining);
-   if (rx->ax_skb) {
-   kfree_skb(rx->ax_skb);
-   rx->ax_skb = NULL;
-   /* Discard the incomplete netdev Ethernet frame
-* and assume the Data header is at the start of
-* the current URB socket buffer.
-*/
-   }
-   rx->remaining = 0;
+   reset_asix_rx_fixup_info(rx);
}
}
 
@@ -139,11 +152,13 @@ int asix_rx_fixup_internal(struct usbnet *dev, struct 
sk_buff *skb,
if (size != ((~rx->header >> 16) & 0x7ff)) {
netdev_err(dev->net, "asix_rx_fixup() Bad 
Header Length 0x%x, offset %d\n",
   rx->header, offset);
+   reset_asix_rx_fixup_info(rx);
return 0;
}
if (size > dev->net->mtu + ETH_HLEN + VLAN_HLEN) {
netdev_dbg(dev->net, "asix_rx_fixup() Bad RX 
Length %d\n",
   size);
+   reset_asix_rx_fixup_info(rx);
return 0;
}
 
@@ -180,6 +195,7 @@ int asix_rx_fixup_internal(struct usbnet *dev, struct 
sk_buff *skb,
if (skb->len != offset) {
netdev_err(dev->net, "asix_rx_fixup() Bad SKB Length %d, %d\n",
   skb->len, offset);
+   reset_asix_rx_fixup_info(rx);
return 0;
}
 
-- 
2.7.4

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

[PATCH V1 1/3] asix: Add rx->ax_skb = NULL after usbnet_skb_return()

[Dean Jenkins]

In asix_rx_fixup_internal() there is a risk that rx->ax_skb gets
reused after passing the Ethernet frame into the network stack via
usbnet_skb_return().

The risks include:

a) asynchronously freeing rx->ax_skb after passing the netdev buffer
   to the NAPI layer which might corrupt the backlog queue.

b) erroneously reusing rx->ax_skb such as calling skb_put_data() multiple
   times which causes writing off the end of the netdev buffer.

Therefore add a defensive rx->ax_skb = NULL after usbnet_skb_return()
so that it is not possible to free rx->ax_skb or to apply
skb_put_data() too many times.

Signed-off-by: Dean Jenkins 
---
 drivers/net/usb/asix_common.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index 7847436..6983b6b 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -168,8 +168,10 @@ int asix_rx_fixup_internal(struct usbnet *dev, struct 
sk_buff *skb,
if (rx->ax_skb) {
skb_put_data(rx->ax_skb, skb->data + offset,
 copy_length);
-   if (!rx->remaining)
+   if (!rx->remaining) {
usbnet_skb_return(dev, rx->ax_skb);
+   rx->ax_skb = NULL;
+   }
}
 
offset += (copy_length + 1) & 0xfffe;
-- 
2.7.4

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

[PATCH V1 3/3] asix: Fix small memory leak in ax88772_unbind()

[Dean Jenkins]

When Ethernet frames span mulitple URBs, the netdev buffer memory
pointed to by the asix_rx_fixup_info structure remains allocated
during the time gap between the 2 executions of asix_rx_fixup_internal().

This means that if ax88772_unbind() is called within this time
gap to free the memory of the parent private data structure then
a memory leak of the part filled netdev buffer memory will occur.

Therefore, create a new function asix_rx_fixup_common_free() to
free the memory of the netdev buffer and add a call to
asix_rx_fixup_common_free() from inside ax88772_unbind().

Consequently when an unbind occurs part way through receiving
an Ethernet frame, the netdev buffer memory that is holding part
of the received Ethernet frame will now be freed.

Signed-off-by: Dean Jenkins 
---
 drivers/net/usb/asix.h |  1 +
 drivers/net/usb/asix_common.c  | 15 +++
 drivers/net/usb/asix_devices.c |  1 +
 3 files changed, 17 insertions(+)

diff --git a/drivers/net/usb/asix.h b/drivers/net/usb/asix.h
index d109242..9a4171b 100644
--- a/drivers/net/usb/asix.h
+++ b/drivers/net/usb/asix.h
@@ -209,6 +209,7 @@ void asix_write_cmd_async(struct usbnet *dev, u8 cmd, u16 
value,
 int asix_rx_fixup_internal(struct usbnet *dev, struct sk_buff *skb,
   struct asix_rx_fixup_info *rx);
 int asix_rx_fixup_common(struct usbnet *dev, struct sk_buff *skb);
+void asix_rx_fixup_common_free(struct asix_common_private *dp);
 
 struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
  gfp_t flags);
diff --git a/drivers/net/usb/asix_common.c b/drivers/net/usb/asix_common.c
index fda74f3..522d290 100644
--- a/drivers/net/usb/asix_common.c
+++ b/drivers/net/usb/asix_common.c
@@ -210,6 +210,21 @@ int asix_rx_fixup_common(struct usbnet *dev, struct 
sk_buff *skb)
return asix_rx_fixup_internal(dev, skb, rx);
 }
 
+void asix_rx_fixup_common_free(struct asix_common_private *dp)
+{
+   struct asix_rx_fixup_info *rx;
+
+   if (!dp)
+   return;
+
+   rx = >rx_fixup_info;
+
+   if (rx->ax_skb) {
+   kfree_skb(rx->ax_skb);
+   rx->ax_skb = NULL;
+   }
+}
+
 struct sk_buff *asix_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
  gfp_t flags)
 {
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index a3aa0a2..b2ff88e 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -764,6 +764,7 @@ static int ax88772_bind(struct usbnet *dev, struct 
usb_interface *intf)
 
 static void ax88772_unbind(struct usbnet *dev, struct usb_interface *intf)
 {
+   asix_rx_fixup_common_free(dev->driver_priv);
kfree(dev->driver_priv);
 }
 
-- 
2.7.4

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

[PATCH V1 0/3] asix: Improve robustness

[Dean Jenkins]

Please consider taking these patches to improve the robustness of the ASIX USB
to Ethernet driver.


Failures prompting an ASIX driver code review
=

On an ARM i.MX6 embedded platform some strange one-off and two-off failures were
observed in and around the ASIX USB to Ethernet driver. This was observed on a
highly modified kernel 3.14 with the ASIX driver containing back-ported changes
from kernel.org up to kernel 4.8 approximately. 


a) A one-off failure in asix_rx_fixup_internal():

There was an occurrence of an attempt to write off the end of the netdev buffer
which was trapped by skb_over_panic() in skb_put().

[20030.846440] skbuff: skb_over_panic: text:7f2271c0 len:120 put:60 
head:8366ecc0 data:8366ed02 tail:0x8366ed7a end:0x8366ed40 dev:eth0
[20030.863007] Kernel BUG at 8044ce38 [verbose debug info unavailable]

[20031.215345] Backtrace: 
[20031.217884] [<8044cde0>] (skb_panic) from [<8044d50c>] (skb_put+0x50/0x5c)
[20031.227408] [<8044d4bc>] (skb_put) from [<7f2271c0>] 
(asix_rx_fixup_internal+0x1c4/0x23c [asix])
[20031.242024] [<7f226ffc>] (asix_rx_fixup_internal [asix]) from [<7f22724c>] 
(asix_rx_fixup_common+0x14/0x18 [asix])
[20031.260309] [<7f227238>] (asix_rx_fixup_common [asix]) from [<7f21f7d4>] 
(usbnet_bh+0x74/0x224 [usbnet])
[20031.269879] [<7f21f760>] (usbnet_bh [usbnet]) from [<8002f834>] 
(call_timer_fn+0xa4/0x1f0)
[20031.283961] [<8002f790>] (call_timer_fn) from [<80030834>] 
(run_timer_softirq+0x230/0x2a8)
[20031.302782] [<80030604>] (run_timer_softirq) from [<80028780>] 
(__do_softirq+0x15c/0x37c)
[20031.321511] [<80028624>] (__do_softirq) from [<80028c38>] 
(irq_exit+0x8c/0xe8)
[20031.339298] [<80028bac>] (irq_exit) from [<8000e9c8>] (handle_IRQ+0x8c/0xc8)
[20031.350038] [<8000e93c>] (handle_IRQ) from [<800085c8>] 
(gic_handle_irq+0xb8/0xf8)
[20031.365528] [<80008510>] (gic_handle_irq) from [<8050de80>] 
(__irq_svc+0x40/0x70)

Analysis of the logic of the ASIX driver (containing backported changes from
kernel.org up to kernel 4.8 approximately) suggested that the software could not
trigger skb_over_panic(). The analysis of the kernel BUG() crash information
suggested that the netdev buffer was written with 2 minimal 60 octet length
Ethernet frames (ASIX hardware drops the 4 octet FCS field) and the 2nd Ethernet
frame attempted to write off the end of the netdev buffer.

Note that the netdev buffer should only contain 1 Ethernet frame so if an
attempt to write 2 Ethernet frames into the buffer is made then that is wrong.
However, the logic of the asix_rx_fixup_internal() only allows 1 Ethernet frame
to be written into the netdev buffer.

Potentially this failure was due to memory corruption because it was only seen
once.


b) Two-off failures in the NAPI layer's backlog queue:

There were 2 crashes in the NAPI layer's backlog queue presumably after
asix_rx_fixup_internal() called usbnet_skb_return().

[24097.273945] Unable to handle kernel NULL pointer dereference at virtual 
address 0004

[24097.398944] PC is at process_backlog+0x80/0x16c

[24097.569466] Backtrace: 
[24097.572007] [<8045ad98>] (process_backlog) from [<8045b64c>] 
(net_rx_action+0xcc/0x248)
[24097.591631] [<8045b580>] (net_rx_action) from [<80028780>] 
(__do_softirq+0x15c/0x37c)
[24097.610022] [<80028624>] (__do_softirq) from [<800289cc>] 
(run_ksoftirqd+0x2c/0x84)

and

[ 1059.828452] Unable to handle kernel NULL pointer dereference at virtual 
address 

[ 1059.953715] PC is at process_backlog+0x84/0x16c

[ 1060.140896] Backtrace: 
[ 1060.143434] [<8045ad98>] (process_backlog) from [<8045b64c>] 
(net_rx_action+0xcc/0x248)
[ 1060.163075] [<8045b580>] (net_rx_action) from [<80028780>] 
(__do_softirq+0x15c/0x37c)
[ 1060.181474] [<80028624>] (__do_softirq) from [<80028c38>] 
(irq_exit+0x8c/0xe8)
[ 1060.199256] [<80028bac>] (irq_exit) from [<8000e9c8>] (handle_IRQ+0x8c/0xc8)
[ 1060.210006] [<8000e93c>] (handle_IRQ) from [<800085c8>] 
(gic_handle_irq+0xb8/0xf8)
[ 1060.225492] [<80008510>] (gic_handle_irq) from [<8050de80>] 
(__irq_svc+0x40/0x70)

The embedded board was only using an ASIX USB to Ethernet adaptor eth0.

Analysis suggested that the doubly-linked list pointers of the backlog queue had
been corrupted because one of the link pointers was NULL.

Potentially this failure was due to memory corruption because it was only seen
twice.


Results of the ASIX driver code review
==

During the code review some weaknesses were observed in the ASIX driver and the
following patches have been created to improve the robustness.


Brief overview of the patches
-

1. asix: Add rx->ax_skb = NULL after usbnet_skb_return()

The current ASIX driver sends the received Ethernet frame to the NAPI layer of
the network stack via the call to usbnet_skb_return() in
asix_rx_fixup_internal() but retains the rx->ax_skb pointer to the netdev
buffer. The driver no longer needs the rx->ax_skb pointer at this point 

Re: [PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common

[Felipe Balbi]

Hi,

Lu Baolu  writes:
> The component u_serial provides a glue layer between TTY layer
> and a USB gadget device needed to provide a basic serial port
> functionality. Currently, u_serial sits under gadget/function
> and depends on CONFIG_USB_GADGET to be compiled and used.
>
> Most of the serial gadget devices are based on a UDC (USB device
> controller) and implemented by making use of the Linux gadget
> frameworks. But we are facing other implementions as well. One
> example can be found with xHCI debug capability. The xHCI debug
> capability implements a serial gadget with hardware and firmware,
> and provides an interface similar with xHCI host for submitting
> and reaping the transfer requests.
>
> In order to make better use of u_serial when implementing xHCI
> debug capability in xHCI driver, this patch moves u_serial.c
> from gadget/function to usb/common, and moves u_serial.h from
> gadget/function to include/linux/usb.
>
> Signed-off-by: Lu Baolu 

NAK, u_serial uses the gadget API. It's definitely not COMMON.

-- 
balbi


signature.asc
Description: PGP signature

[PATCH v2 3/4] usb: xhci: Add DbC support in xHCI driver

[Lu Baolu]

xHCI compatible USB host controllers(i.e. super-speed USB3 controllers)
can be implemented with the Debug Capability(DbC). It presents a debug
device which is fully compliant with the USB framework and provides the
equivalent of a very high performance full-duplex serial link. The debug
capability operation model and registers interface are defined in 7.6.8
of the xHCI specification, revision 1.1.

The DbC debug device shares a root port with the xHCI host. By default,
the debug capability is disabled and the root port is assigned to xHCI.
When the DbC is enabled, the root port will be assigned to the DbC debug
device, and the xHCI sees nothing on this port. This implementation uses
a sysfs node named  under the xHCI device to manage the enabling
and disabling of the debug capability.

When the debug capability is enabled, it will present a debug device
through the debug port. This debug device is fully compliant with the
USB3 framework, and it can be enumerated by a debug host on the other
end of the USB link. As soon as the debug device is configured, a TTY
serial device named /dev/ttyGSn will be created.

One use of this link is running a login service on the debug target.
Hence it can be remote accessed by a debug host. Another use case can
probably be found in servers. It provides a peer-to-peer USB link
between two host-only machines. This provides a reasonable out-of-band
communication method between two servers.

Signed-off-by: Lu Baolu 
---
 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd |   25 +
 drivers/usb/host/Kconfig   |9 +
 drivers/usb/host/Makefile  |5 +
 drivers/usb/host/xhci-dbgcap.c | 1100 
 drivers/usb/host/xhci-dbgcap.h |  194 
 drivers/usb/host/xhci-trace.h  |   65 ++
 drivers/usb/host/xhci.c|   10 +
 drivers/usb/host/xhci.h|1 +
 include/linux/usb/gadget.h |   52 +
 9 files changed, 1461 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 drivers/usb/host/xhci-dbgcap.c
 create mode 100644 drivers/usb/host/xhci-dbgcap.h

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd 
b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
new file mode 100644
index 000..0088aba
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
@@ -0,0 +1,25 @@
+What:  /sys/bus/pci/drivers/xhci_hcd/.../dbc
+Date:  June 2017
+Contact:   Lu Baolu 
+Description:
+   xHCI compatible USB host controllers (i.e. super-speed
+   USB3 controllers) are often implemented with the Debug
+   Capability (DbC). It can present a debug device which
+   is fully compliant with the USB framework and provides
+   the equivalent of a very high performance full-duplex
+   serial link for debug purpose.
+
+   The DbC debug device shares a root port with xHCI host.
+   When the DbC is enabled, the root port will be assigned
+   to the Debug Capability. Otherwise, it will be assigned
+   to xHCI.
+
+   Writing "enable" to this attribute will enable the DbC
+   functionality and the shared root port will be assigned
+   to the DbC device. Writing "disable" to this attribute
+   will disable the DbC functionality and the shared root
+   port will roll back to the xHCI.
+
+   Reading this attribute gives the state of the DbC. It
+   can be one of the following states: disabled, enabled,
+   initialized, connected, configured and stalled.
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index fa5692d..968a196 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -27,6 +27,15 @@ config USB_XHCI_HCD
  module will be called xhci-hcd.
 
 if USB_XHCI_HCD
+config USB_XHCI_DBGCAP
+   bool "xHCI support for debug capability"
+   depends on TTY
+   select USB_U_SERIAL
+   ---help---
+ Say 'Y' to enable the support for the xHCI debug capability. Make
+ sure that your xHCI host supports the extended debug capability and
+ you want a TTY serial device based on the xHCI debug capability
+ before enabling this option. If unsure, say 'N'.
 
 config USB_XHCI_PCI
tristate
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cf2691f..4629d20 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -13,6 +13,11 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
+
+ifneq ($(CONFIG_USB_XHCI_DBGCAP), )
+   

[PATCH v2 1/4] usb: xhci: Make some static functions global

[Lu Baolu]

This patch makes some static functions global to avoid duplications
in different files. These functions can be used in the implementation
of xHCI debug capability. There is no functional change.

Signed-off-by: Lu Baolu 
---
 drivers/usb/host/xhci-mem.c  | 94 ++--
 drivers/usb/host/xhci-ring.c |  4 +-
 drivers/usb/host/xhci.h  | 16 +++-
 3 files changed, 72 insertions(+), 42 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 2a82c92..1ccb1c5 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -368,7 +368,7 @@ static int xhci_alloc_segments_for_ring(struct xhci_hcd 
*xhci,
  * Set the end flag and the cycle toggle bit on the last segment.
  * See section 4.9.1 and figures 15 and 16.
  */
-static struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
+struct xhci_ring *xhci_ring_alloc(struct xhci_hcd *xhci,
unsigned int num_segs, unsigned int cycle_state,
enum xhci_ring_type type, unsigned int max_packet, gfp_t flags)
 {
@@ -467,7 +467,7 @@ int xhci_ring_expansion(struct xhci_hcd *xhci, struct 
xhci_ring *ring,
 
 #define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
 
-static struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd 
*xhci,
+struct xhci_container_ctx *xhci_alloc_container_ctx(struct xhci_hcd *xhci,
int type, gfp_t flags)
 {
struct xhci_container_ctx *ctx;
@@ -492,7 +492,7 @@ static struct xhci_container_ctx 
*xhci_alloc_container_ctx(struct xhci_hcd *xhci
return ctx;
 }
 
-static void xhci_free_container_ctx(struct xhci_hcd *xhci,
+void xhci_free_container_ctx(struct xhci_hcd *xhci,
 struct xhci_container_ctx *ctx)
 {
if (!ctx)
@@ -1762,21 +1762,61 @@ void xhci_free_command(struct xhci_hcd *xhci,
kfree(command);
 }
 
+int xhci_alloc_erst(struct xhci_hcd *xhci,
+   struct xhci_ring *evt_ring,
+   struct xhci_erst *erst,
+   gfp_t flags)
+{
+   size_t size;
+   unsigned int val;
+   struct xhci_segment *seg;
+   struct xhci_erst_entry *entry;
+
+   size = sizeof(struct xhci_erst_entry) * evt_ring->num_segs;
+   erst->entries = dma_alloc_coherent(xhci_to_hcd(xhci)->self.sysdev,
+  size,
+  >erst_dma_addr,
+  flags);
+   if (!erst->entries)
+   return -ENOMEM;
+
+   memset(erst->entries, 0, size);
+   erst->num_entries = evt_ring->num_segs;
+
+   seg = evt_ring->first_seg;
+   for (val = 0; val < evt_ring->num_segs; val++) {
+   entry = >entries[val];
+   entry->seg_addr = cpu_to_le64(seg->dma);
+   entry->seg_size = cpu_to_le32(TRBS_PER_SEGMENT);
+   entry->rsvd = 0;
+   seg = seg->next;
+   }
+
+   return 0;
+}
+
+void xhci_free_erst(struct xhci_hcd *xhci, struct xhci_erst *erst)
+{
+   size_t size;
+   struct device *dev = xhci_to_hcd(xhci)->self.sysdev;
+
+   size = sizeof(struct xhci_erst_entry) * (erst->num_entries);
+   if (erst->entries)
+   dma_free_coherent(dev, size,
+   erst->entries,
+   erst->erst_dma_addr);
+   erst->entries = NULL;
+}
+
 void xhci_mem_cleanup(struct xhci_hcd *xhci)
 {
struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
-   int size;
int i, j, num_ports;
 
cancel_delayed_work_sync(>cmd_timer);
 
-   /* Free the Event Ring Segment Table and the actual Event Ring */
-   size = sizeof(struct xhci_erst_entry)*(xhci->erst.num_entries);
-   if (xhci->erst.entries)
-   dma_free_coherent(dev, size,
-   xhci->erst.entries, xhci->erst.erst_dma_addr);
-   xhci->erst.entries = NULL;
-   xhci_dbg_trace(xhci, trace_xhci_dbg_init, "Freed ERST");
+   xhci_free_erst(xhci, >erst);
+
if (xhci->event_ring)
xhci_ring_free(xhci, xhci->event_ring);
xhci->event_ring = NULL;
@@ -2313,9 +2353,8 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
struct device   *dev = xhci_to_hcd(xhci)->self.sysdev;
unsigned intval, val2;
u64 val_64;
-   struct xhci_segment *seg;
-   u32 page_size, temp;
-   int i;
+   u32 page_size, temp;
+   int i, ret;
 
INIT_LIST_HEAD(>cmd_list);
 
@@ -2454,32 +2493,9 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
if (xhci_check_trb_in_td_math(xhci) < 0)
goto fail;
 
-   xhci->erst.entries = dma_alloc_coherent(dev,
-   sizeof(struct xhci_erst_entry) * ERST_NUM_SEGS, ,
-   flags);
-   if 

[PATCH v2 4/4] usb: doc: Update document for USB3 debug port usage

[Lu Baolu]

Update Documentation/driver-api/usb/usb3-debug-port.rst. This update
includes the guide for using xHCI debug capability based TTY serial
link.

Signed-off-by: Lu Baolu 
---
 Documentation/driver-api/usb/usb3-debug-port.rst | 68 
 1 file changed, 68 insertions(+)

diff --git a/Documentation/driver-api/usb/usb3-debug-port.rst 
b/Documentation/driver-api/usb/usb3-debug-port.rst
index feb1a36..e4bb02e 100644
--- a/Documentation/driver-api/usb/usb3-debug-port.rst
+++ b/Documentation/driver-api/usb/usb3-debug-port.rst
@@ -98,3 +98,71 @@ you to check the sanity of the setup.
cat /dev/ttyUSB0
done
= end of bash scripts ===
+
+Serial TTY
+==
+
+DbC has also been designed for a serial TTY device at runtime.
+One use of this is running a login service on the debug target.
+Hence it can be remote accessed by the debug host. Another use
+can probably be found in servers. It provides a peer-to-peer USB
+link between two host-only machines. This provides a reasonable
+out-of-band communication method between two servers.
+
+In order to use this, you need to make sure your kernel has been
+configured to support USB_XHCI_DBGCAP. A sysfs attribute under
+the xHCI device node is used to enable or disable DbC. By default,
+DbC is disabled::
+
+   root@target:/sys/bus/pci/devices/:00:14.0# cat dbc
+   disabled
+
+Enable DbC with the following command::
+
+   root@target:/sys/bus/pci/devices/:00:14.0# echo enable > dbc
+
+You can check the DbC state at anytime::
+
+   root@target:/sys/bus/pci/devices/:00:14.0# cat dbc
+   enabled
+
+Connect the debug target to the debug host with a USB 3.0 super-
+speed A-to-A debugging cable. You can see the /dev/ttyGSn created
+on the debug target. You will see below kernel message lines::
+
+   root@target: tail -f /var/log/kern.log
+   [  182.730103] xhci_hcd :00:14.0: DbC connected
+   [  191.169420] xhci_hcd :00:14.0: DbC configured
+   [  191.169597] xhci_hcd :00:14.0: DbC now attached to /dev/ttyGS0
+
+Accordingly, the DbC state has been brought up to::
+
+   root@host:/sys/bus/pci/devices/:00:14.0# cat dbc
+   configured
+
+On the debug host, you will see the debug device has been enumerated.
+You will see below kernel message lines::
+
+   root@host: tail -f /var/log/kern.log
+   [   79.454780] usb 2-2.1: new SuperSpeed USB device number 3 using 
xhci_hcd
+   [   79.475003] usb 2-2.1: LPM exit latency is zeroed, disabling LPM.
+   [   79.475389] usb 2-2.1: New USB device found, idVendor=1d6b, 
idProduct=0004
+   [   79.475390] usb 2-2.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
+   [   79.475391] usb 2-2.1: Product: Remote GDB
+   [   79.475392] usb 2-2.1: Manufacturer: Linux
+   [   79.475393] usb 2-2.1: SerialNumber: 0001
+   [   79.660368] usb_debug 2-2.1:1.0: xhci_dbc converter detected
+   [   79.660439] usb 2-2.1: xhci_dbc converter now attached to ttyUSB0
+
+You can simply verify whether it works by::
+
+   # On target side
+   root@target: echo "Hello world" > /dev/ttyGS0
+
+   # On host side
+   root@host: cat /dev/ttyUSB0
+   Hello world
+
+   # vice versa
+
+You have a workable serial link over USB now.
-- 
2.7.4

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

[PATCH v2 0/4] usb: xhci: Add debug capability support in xhci

[Lu Baolu]

Hi,

This series is for xHCI debug capability (spec section 7.6.8) support
in the xHCI driver.

xHCI compatible USB host controllers(i.e. super-speed USB3 controllers)
can be implemented with the Debug Capability(DbC). It presents a debug
device which is fully compliant with the USB framework and provides the
equivalent of a very high performance full-duplex serial link. The debug
capability operation model and registers interface are defined in 7.6.8
of the xHCI specification, revision 1.1.

The DbC debug device shares a root port with the xHCI host. By default,
the debug capability is disabled and the root port is assigned to xHCI.
When the DbC is enabled, the root port will be assigned to the DbC debug
device, and the xHCI sees nothing on this port. This implementation uses
a sysfs node named  under the xHCI device to manage the enabling
and disabling of the debug capability.

When the debug capability is enabled, it will present a debug device
through the debug port. This debug device is fully compliant with the
USB3 framework, and it can be enumerated by a debug host on the other
end of the USB link. As soon as the debug device is configured, a TTY
serial device named /dev/ttyGSn will be created.

One use of this link is running a login service on the debug target.
Hence it can be remote accessed by a debug host. Another use case can
probably be found in servers. It provides a peer-to-peer USB link
between two host-only machines. This provides a reasonable out-of-band
communication method between two servers.

Best regards,
Lu Baolu

---
Change log:
v1->v2:
  - Add a new patch to move u_serial.c from drivers/usb/gadget/function
to drivers/usb/common/ and move u_serial.h to include/linux/usb/.

Lu Baolu (4):
  usb: xhci: Make some static functions global
  usb: common: Move u_serial from gadget/function to usb/common
  usb: xhci: Add DbC support in xHCI driver
  usb: doc: Update document for USB3 debug port usage

 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd |   25 +
 Documentation/driver-api/usb/usb3-debug-port.rst   |   68 +
 drivers/usb/Kconfig|3 +
 drivers/usb/Makefile   |3 +-
 drivers/usb/common/Makefile|1 +
 drivers/usb/common/u_serial.c  | 1604 +++
 drivers/usb/gadget/Kconfig |3 -
 drivers/usb/gadget/function/Makefile   |1 -
 drivers/usb/gadget/function/f_acm.c|4 +-
 drivers/usb/gadget/function/f_obex.c   |4 +-
 drivers/usb/gadget/function/f_serial.c |3 +-
 drivers/usb/gadget/function/u_serial.c | 1606 
 drivers/usb/gadget/function/u_serial.h |   71 -
 drivers/usb/gadget/legacy/acm_ms.c |3 +-
 drivers/usb/gadget/legacy/cdc2.c   |2 +-
 drivers/usb/gadget/legacy/dbgp.c   |3 +-
 drivers/usb/gadget/legacy/multi.c  |2 +-
 drivers/usb/gadget/legacy/nokia.c  |2 +-
 drivers/usb/gadget/legacy/serial.c |3 +-
 drivers/usb/host/Kconfig   |9 +
 drivers/usb/host/Makefile  |5 +
 drivers/usb/host/xhci-dbgcap.c | 1100 ++
 drivers/usb/host/xhci-dbgcap.h |  194 +++
 drivers/usb/host/xhci-mem.c|   94 +-
 drivers/usb/host/xhci-ring.c   |4 +-
 drivers/usb/host/xhci-trace.h  |   65 +
 drivers/usb/host/xhci.c|   10 +
 drivers/usb/host/xhci.h|   17 +-
 include/linux/usb/gadget.h |   52 +
 include/linux/usb/u_serial.h   |   71 +
 30 files changed, 3290 insertions(+), 1742 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 drivers/usb/common/u_serial.c
 delete mode 100644 drivers/usb/gadget/function/u_serial.c
 delete mode 100644 drivers/usb/gadget/function/u_serial.h
 create mode 100644 drivers/usb/host/xhci-dbgcap.c
 create mode 100644 drivers/usb/host/xhci-dbgcap.h
 create mode 100644 include/linux/usb/u_serial.h

-- 
2.7.4

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

[PATCH v2 2/4] usb: common: Move u_serial from gadget/function to usb/common

[Lu Baolu]

The component u_serial provides a glue layer between TTY layer
and a USB gadget device needed to provide a basic serial port
functionality. Currently, u_serial sits under gadget/function
and depends on CONFIG_USB_GADGET to be compiled and used.

Most of the serial gadget devices are based on a UDC (USB device
controller) and implemented by making use of the Linux gadget
frameworks. But we are facing other implementions as well. One
example can be found with xHCI debug capability. The xHCI debug
capability implements a serial gadget with hardware and firmware,
and provides an interface similar with xHCI host for submitting
and reaping the transfer requests.

In order to make better use of u_serial when implementing xHCI
debug capability in xHCI driver, this patch moves u_serial.c
from gadget/function to usb/common, and moves u_serial.h from
gadget/function to include/linux/usb.

Signed-off-by: Lu Baolu 
---
 drivers/usb/Kconfig|3 +
 drivers/usb/Makefile   |3 +-
 drivers/usb/common/Makefile|1 +
 drivers/usb/common/u_serial.c  | 1604 +++
 drivers/usb/gadget/Kconfig |3 -
 drivers/usb/gadget/function/Makefile   |1 -
 drivers/usb/gadget/function/f_acm.c|4 +-
 drivers/usb/gadget/function/f_obex.c   |4 +-
 drivers/usb/gadget/function/f_serial.c |3 +-
 drivers/usb/gadget/function/u_serial.c | 1606 
 drivers/usb/gadget/function/u_serial.h |   71 --
 drivers/usb/gadget/legacy/acm_ms.c |3 +-
 drivers/usb/gadget/legacy/cdc2.c   |2 +-
 drivers/usb/gadget/legacy/dbgp.c   |3 +-
 drivers/usb/gadget/legacy/multi.c  |2 +-
 drivers/usb/gadget/legacy/nokia.c  |2 +-
 drivers/usb/gadget/legacy/serial.c |3 +-
 include/linux/usb/u_serial.h   |   71 ++
 18 files changed, 1689 insertions(+), 1700 deletions(-)
 create mode 100644 drivers/usb/common/u_serial.c
 delete mode 100644 drivers/usb/gadget/function/u_serial.c
 delete mode 100644 drivers/usb/gadget/function/u_serial.h
 create mode 100644 include/linux/usb/u_serial.h

diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 939a63b..c39aceb 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -35,6 +35,9 @@ config USB_COMMON
 config USB_ARCH_HAS_HCD
def_bool y
 
+config USB_U_SERIAL
+   tristate
+
 config USB
tristate "Support for Host-side USB"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 9650b35..a3274aa 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -5,6 +5,7 @@
 # Object files in subdirectories
 
 obj-$(CONFIG_USB)  += core/
+obj-$(CONFIG_USB_COMMON)   += common/
 obj-$(CONFIG_USB_SUPPORT)  += phy/
 
 obj-$(CONFIG_USB_DWC3) += dwc3/
@@ -59,8 +60,6 @@ obj-$(CONFIG_USB_CHIPIDEA)+= chipidea/
 obj-$(CONFIG_USB_RENESAS_USBHS)+= renesas_usbhs/
 obj-$(CONFIG_USB_GADGET)   += gadget/
 
-obj-$(CONFIG_USB_COMMON)   += common/
-
 obj-$(CONFIG_USBIP_CORE)   += usbip/
 
 obj-$(CONFIG_TYPEC)+= typec/
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 6bbb3ec..dff720b 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -8,3 +8,4 @@ usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
 obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
 obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
+obj-$(CONFIG_USB_U_SERIAL) += u_serial.o
diff --git a/drivers/usb/common/u_serial.c b/drivers/usb/common/u_serial.c
new file mode 100644
index 000..da09602
--- /dev/null
+++ b/drivers/usb/common/u_serial.c
@@ -0,0 +1,1604 @@
+/*
+ * u_serial.c - utilities for USB gadget "serial port"/TTY support
+ *
+ * Copyright (C) 2003 Al Borchers (alborch...@steinerpoint.com)
+ * Copyright (C) 2008 David Brownell
+ * Copyright (C) 2008 by Nokia Corporation
+ *
+ * This code also borrows from usbserial.c, which is
+ * Copyright (C) 1999 - 2002 Greg Kroah-Hartman (g...@kroah.com)
+ * Copyright (C) 2000 Peter Berger (pber...@brimson.com)
+ * Copyright (C) 2000 Al Borchers (alborch...@steinerpoint.com)
+ *
+ * This software is distributed under the terms of the GNU General
+ * Public License ("GPL") as published by the Free Software Foundation,
+ * either version 2 of that License or (at your option) any later version.
+ */
+
+/* #define VERBOSE_DEBUG */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * This component encapsulates the TTY layer glue needed to provide basic
+ * "serial port" functionality through the USB gadget stack.  Each such
+ * port is exposed through a /dev/ttyGS* node.
+ *
+ * After this module has been loaded, the individual TTY port can be requested
+ * (gserial_alloc_line()) and it will stay available until they are removed
+ * (gserial_free_line()). 

[PATCH] uwb: lc-rc: constify attribute_group structures.

[Arvind Yadav]

attribute_group are not supposed to change at runtime. All functions
working with attribute_group provided by  work with
const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/uwb/lc-rc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/uwb/lc-rc.c b/drivers/uwb/lc-rc.c
index 97ee1b4..b0816c7 100644
--- a/drivers/uwb/lc-rc.c
+++ b/drivers/uwb/lc-rc.c
@@ -228,7 +228,7 @@ static ssize_t ASIE_store(struct device *dev,
NULL,
 };
 
-static struct attribute_group rc_attr_group = {
+static const struct attribute_group rc_attr_group = {
.attrs = rc_attrs,
 };
 
-- 
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