[RESEND PATCH 1/5] usb: mtu3: avoid TX data length truncated in SS/SSP mode

[Chunfeng Yun]

The variable of 'count' is declared as u8, this will cause an issue
due to value truncated when works in SS or SSP mode and data length
is greater than 255, so change it as u32.

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

diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c 
b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index ebdcf7a..d67b540 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -546,7 +546,7 @@ static void ep0_tx_state(struct mtu3 *mtu)
struct usb_request *req;
u32 csr;
u8 *src;
-   u8 count;
+   u32 count;
u32 maxp;
 
dev_dbg(mtu->dev, "%s\n", __func__);
-- 
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

[RESEND PATCH 3/5] usb: mtu3: fix an unrecognized issue when connected with PC

[Chunfeng Yun]

When boot on the platform with the USB cable connected to Win7,
the Win7 will pop up an error dialog: "USB Device not recognized",
but finally the Win7 can enumerate it successfully.
The root cause is as the following:
When the xHCI driver set PORT_POWER of the OTG port, and if both
IDPIN and VBUS_VALID are high at the same time, the MTU3 controller
will set SESSION and pull up DP, so the Win7 can detect existence
of USB device, but if the mtu3 driver can't switch to device mode
during the debounce time, the Win7 can not enumerate it.
Here to fix it by removing the 1s delayed EXTCON register to speed up
mode switch.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3.h|  4 
 drivers/usb/mtu3/mtu3_dr.c | 25 +++--
 2 files changed, 3 insertions(+), 26 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 2cd00a2..a56fee0 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -197,9 +197,6 @@ struct mtu3_gpd_ring {
 * @edev: external connector used to detect vbus and iddig changes
 * @vbus_nb: notifier for vbus detection
 * @vbus_nb: notifier for iddig(idpin) detection
-* @extcon_reg_dwork: delay work for extcon notifier register, waiting for
-*  xHCI driver initialization, it's necessary for system bootup
-*  as device.
 * @is_u3_drd: whether port0 supports usb3.0 dual-role device or not
 * @manual_drd_enabled: it's true when supports dual-role device by debugfs
 *  to switch host/device modes depending on user input.
@@ -209,7 +206,6 @@ struct otg_switch_mtk {
struct extcon_dev *edev;
struct notifier_block vbus_nb;
struct notifier_block id_nb;
-   struct delayed_work extcon_reg_dwork;
bool is_u3_drd;
bool manual_drd_enabled;
 };
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index db7562d..80083e0 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -238,15 +238,6 @@ static int ssusb_extcon_register(struct otg_switch_mtk 
*otg_sx)
return 0;
 }
 
-static void extcon_register_dwork(struct work_struct *work)
-{
-   struct delayed_work *dwork = to_delayed_work(work);
-   struct otg_switch_mtk *otg_sx =
-   container_of(dwork, struct otg_switch_mtk, extcon_reg_dwork);
-
-   ssusb_extcon_register(otg_sx);
-}
-
 /*
  * We provide an interface via debugfs to switch between host and device modes
  * depending on user input.
@@ -407,18 +398,10 @@ int ssusb_otg_switch_init(struct ssusb_mtk *ssusb)
 {
struct otg_switch_mtk *otg_sx = >otg_switch;
 
-   if (otg_sx->manual_drd_enabled) {
+   if (otg_sx->manual_drd_enabled)
ssusb_debugfs_init(ssusb);
-   } else {
-   INIT_DELAYED_WORK(_sx->extcon_reg_dwork,
- extcon_register_dwork);
-
-   /*
-* It is enough to delay 1s for waiting for
-* host initialization
-*/
-   schedule_delayed_work(_sx->extcon_reg_dwork, HZ);
-   }
+   else
+   ssusb_extcon_register(otg_sx);
 
return 0;
 }
@@ -429,6 +412,4 @@ void ssusb_otg_switch_exit(struct ssusb_mtk *ssusb)
 
if (otg_sx->manual_drd_enabled)
ssusb_debugfs_exit(ssusb);
-   else
-   cancel_delayed_work(_sx->extcon_reg_dwork);
 }
-- 
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

[RESEND PATCH 5/5] usb: mtu3: make USB_MTU3_DUAL_ROLE depend on EXTCON but not USB_MTU3

[Chunfeng Yun]

In fact the driver depends on EXTCON only when it's configed as
USB_MTU3_DUAL_ROLE, so make USB_MTU3_DUAL_ROLE depend on EXTCON but
not USB_MTU3.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig
index 25cd619..8daf277 100644
--- a/drivers/usb/mtu3/Kconfig
+++ b/drivers/usb/mtu3/Kconfig
@@ -2,7 +2,7 @@
 
 config USB_MTU3
tristate "MediaTek USB3 Dual Role controller"
-   depends on EXTCON && (USB || USB_GADGET) && HAS_DMA
+   depends on (USB || USB_GADGET) && HAS_DMA
depends on ARCH_MEDIATEK || COMPILE_TEST
select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD
help
@@ -40,6 +40,7 @@ config USB_MTU3_GADGET
 config USB_MTU3_DUAL_ROLE
bool "Dual Role mode"
depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || 
USB_GADGET=USB_MTU3))
+   depends on (EXTCON=y || EXTCON=USB_MTU3)
help
  This is the default mode of working of MTU3 controller where
  both host and gadget features are enabled.
-- 
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

[RESEND PATCH 4/5] usb: mtu3: fix operation failure when test TEST_J/K

[Chunfeng Yun]

There is an error dialog popped up in PC when test TEST_J/K
by EHSETT tool, due to not waiting for the completion of
control transfer. Here fix it by entering test mode after
Status Stage finish.

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

diff --git a/drivers/usb/mtu3/mtu3_gadget_ep0.c 
b/drivers/usb/mtu3/mtu3_gadget_ep0.c
index d67b540..0d2b1cf 100644
--- a/drivers/usb/mtu3/mtu3_gadget_ep0.c
+++ b/drivers/usb/mtu3/mtu3_gadget_ep0.c
@@ -7,6 +7,7 @@
  * Author:  Chunfeng.Yun 
  */
 
+#include 
 #include 
 
 #include "mtu3.h"
@@ -263,6 +264,7 @@ static int handle_test_mode(struct mtu3 *mtu, struct 
usb_ctrlrequest *setup)
 {
void __iomem *mbase = mtu->mac_base;
int handled = 1;
+   u32 value;
 
switch (le16_to_cpu(setup->wIndex) >> 8) {
case TEST_J:
@@ -292,6 +294,14 @@ static int handle_test_mode(struct mtu3 *mtu, struct 
usb_ctrlrequest *setup)
if (mtu->test_mode_nr == TEST_PACKET_MODE)
ep0_load_test_packet(mtu);
 
+   /* send status before entering test mode. */
+   value = mtu3_readl(mbase, U3D_EP0CSR) & EP0_W1C_BITS;
+   mtu3_writel(mbase, U3D_EP0CSR, value | EP0_SETUPPKTRDY | EP0_DATAEND);
+
+   /* wait for ACK status sent by host */
+   readl_poll_timeout(mbase + U3D_EP0CSR, value,
+   !(value & EP0_DATAEND), 100, 5000);
+
mtu3_writel(mbase, U3D_USB2_TEST_MODE, mtu->test_mode_nr);
 
mtu->ep0_state = MU3D_EP0_STATE_SETUP;
-- 
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

[RESEND PATCH 2/5] usb: mtu3: remove repeated setting of gadget state

[Chunfeng Yun]

The usb_add_gadget_udc() will set the gadget state as
USB_STATE_NOTATTACHED, so we needn't set it again.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3_gadget.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/mtu3/mtu3_gadget.c b/drivers/usb/mtu3/mtu3_gadget.c
index f05f10f..de0de01 100644
--- a/drivers/usb/mtu3/mtu3_gadget.c
+++ b/drivers/usb/mtu3/mtu3_gadget.c
@@ -660,14 +660,10 @@ int mtu3_gadget_setup(struct mtu3 *mtu)
mtu3_gadget_init_eps(mtu);
 
ret = usb_add_gadget_udc(mtu->dev, >g);
-   if (ret) {
+   if (ret)
dev_err(mtu->dev, "failed to register udc\n");
-   return ret;
-   }
 
-   usb_gadget_set_state(>g, USB_STATE_NOTATTACHED);
-
-   return 0;
+   return ret;
 }
 
 void mtu3_gadget_cleanup(struct mtu3 *mtu)
-- 
1.9.1

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

[PATCH v2 2/2] phy: mediatek: add XS-PHY driver

[Chunfeng Yun]

Support XS-PHY for MediaTek SoCs with USB3.1 GEN2 controller

Signed-off-by: Chunfeng Yun 
---
 drivers/phy/mediatek/Kconfig |9 +
 drivers/phy/mediatek/Makefile|1 +
 drivers/phy/mediatek/phy-mtk-xsphy.c |  600 ++
 3 files changed, 610 insertions(+)
 create mode 100644 drivers/phy/mediatek/phy-mtk-xsphy.c

diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
index 88ab4e2..8857d00 100644
--- a/drivers/phy/mediatek/Kconfig
+++ b/drivers/phy/mediatek/Kconfig
@@ -12,3 +12,12 @@ config PHY_MTK_TPHY
  different banks layout, the T-PHY with shared banks between
  multi-ports is first version, otherwise is second veriosn,
  so you can easily distinguish them by banks layout.
+
+config PHY_MTK_XSPHY
+tristate "MediaTek XS-PHY Driver"
+depends on ARCH_MEDIATEK && OF
+select GENERIC_PHY
+help
+ Enable this to support the SuperSpeedPlus XS-PHY transceiver for
+ USB3.1 GEN2 controllers on MediaTek chips. The driver supports
+ multiple USB2.0, USB3.1 GEN2 ports.
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 1bdab14..ee49edc 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -4,3 +4,4 @@
 #
 
 obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
+obj-$(CONFIG_PHY_MTK_XSPHY)+= phy-mtk-xsphy.o
diff --git a/drivers/phy/mediatek/phy-mtk-xsphy.c 
b/drivers/phy/mediatek/phy-mtk-xsphy.c
new file mode 100644
index 000..020cd02
--- /dev/null
+++ b/drivers/phy/mediatek/phy-mtk-xsphy.c
@@ -0,0 +1,600 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek USB3.1 gen2 xsphy Driver
+ *
+ * Copyright (c) 2018 MediaTek Inc.
+ * Author: Chunfeng Yun 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* u2 phy banks */
+#define SSUSB_SIFSLV_MISC  0x000
+#define SSUSB_SIFSLV_U2FREQ0x100
+#define SSUSB_SIFSLV_U2PHY_COM 0x300
+
+/* u3 phy shared banks */
+#define SSPXTP_SIFSLV_DIG_GLB  0x000
+#define SSPXTP_SIFSLV_PHYA_GLB 0x100
+
+/* u3 phy banks */
+#define SSPXTP_SIFSLV_DIG_LN_TOP   0x000
+#define SSPXTP_SIFSLV_DIG_LN_TX0   0x100
+#define SSPXTP_SIFSLV_DIG_LN_RX0   0x200
+#define SSPXTP_SIFSLV_DIG_LN_DAIF  0x300
+#define SSPXTP_SIFSLV_PHYA_LN  0x400
+
+#define XSP_U2FREQ_FMCR0   ((SSUSB_SIFSLV_U2FREQ) + 0x00)
+#define P2F_RG_FREQDET_EN  BIT(24)
+#define P2F_RG_CYCLECNTGENMASK(23, 0)
+#define P2F_RG_CYCLECNT_VAL(x) ((P2F_RG_CYCLECNT) & (x))
+
+#define XSP_U2FREQ_MMONR0  ((SSUSB_SIFSLV_U2FREQ) + 0x0c)
+
+#define XSP_U2FREQ_FMMONR1 ((SSUSB_SIFSLV_U2FREQ) + 0x10)
+#define P2F_RG_FRCK_EN BIT(8)
+#define P2F_USB_FM_VALID   BIT(0)
+
+#define XSP_USBPHYACR0 ((SSUSB_SIFSLV_U2PHY_COM) + 0x00)
+#define P2A0_RG_INTR_ENBIT(5)
+
+#define XSP_USBPHYACR1 ((SSUSB_SIFSLV_U2PHY_COM) + 0x04)
+#define P2A1_RG_INTR_CAL   GENMASK(23, 19)
+#define P2A1_RG_INTR_CAL_VAL(x)((0x1f & (x)) << 19)
+#define P2A1_RG_VRT_SELGENMASK(14, 12)
+#define P2A1_RG_VRT_SEL_VAL(x) ((0x7 & (x)) << 12)
+#define P2A1_RG_TERM_SEL   GENMASK(10, 8)
+#define P2A1_RG_TERM_SEL_VAL(x)((0x7 & (x)) << 8)
+
+#define XSP_USBPHYACR5 ((SSUSB_SIFSLV_U2PHY_COM) + 0x014)
+#define P2A5_RG_HSTX_SRCAL_EN  BIT(15)
+#define P2A5_RG_HSTX_SRCTRLGENMASK(14, 12)
+#define P2A5_RG_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12)
+
+#define XSP_USBPHYACR6 ((SSUSB_SIFSLV_U2PHY_COM) + 0x018)
+#define P2A6_RG_BC11_SW_EN BIT(23)
+#define P2A6_RG_OTG_VBUSCMP_EN BIT(20)
+
+#define XSP_U2PHYDTM1  ((SSUSB_SIFSLV_U2PHY_COM) + 0x06C)
+#define P2D_FORCE_IDDIGBIT(9)
+#define P2D_RG_VBUSVALID   BIT(5)
+#define P2D_RG_SESSEND BIT(4)
+#define P2D_RG_AVALID  BIT(2)
+#define P2D_RG_IDDIG   BIT(1)
+
+#define SSPXTP_PHYA_GLB_00 ((SSPXTP_SIFSLV_PHYA_GLB) + 0x00)
+#define RG_XTP_GLB_BIAS_INTR_CTRL  GENMASK(21, 16)
+#define RG_XTP_GLB_BIAS_INTR_CTRL_VAL(x)   ((0x3f & (x)) << 16)
+
+#define SSPXTP_PHYA_LN_04  ((SSPXTP_SIFSLV_PHYA_LN) + 0x04)
+#define RG_XTP_LN0_TX_IMPSEL   GENMASK(4, 0)
+#define RG_XTP_LN0_TX_IMPSEL_VAL(x)(0x1f & (x))
+
+#define SSPXTP_PHYA_LN_14  ((SSPXTP_SIFSLV_PHYA_LN) + 0x014)
+#define RG_XTP_LN0_RX_IMPSEL   GENMASK(4, 0)
+#define RG_XTP_LN0_RX_IMPSEL_VAL(x)(0x1f & (x))
+
+#define XSP_REF_CLK26  /* MHZ */
+#define XSP_SLEW_RATE_COEF 17
+#define XSP_SR_COEF_DIVISOR1000
+#define XSP_FM_DET_CYCLE_CNT   1024
+
+struct xsphy_instance {
+   struct phy *phy;
+   void __iomem *port_base;
+   struct clk *ref_clk;/* reference clock of anolog phy */
+   u32 index;
+   u32 type;
+   /* only for HQA test */
+   int 

[PATCH v2 1/2] dt-bindings: add MediaTek XS-PHY binding

[Chunfeng Yun]

Add a DT binding documentation of XS-PHY for MediaTek SoCs
with USB3.1 GEN2 controller

Signed-off-by: Chunfeng Yun 
---
 .../devicetree/bindings/phy/phy-mtk-xsphy.txt  |  110 
 1 file changed, 110 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt

diff --git a/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt 
b/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
new file mode 100644
index 000..9a95fab
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
@@ -0,0 +1,110 @@
+MediaTek XS-PHY binding
+--
+
+The XS-PHY controller supports physical layer functionality for USB3.1
+GEN2 controller on MediaTek SoCs.
+
+Required properties (controller (parent) node):
+ - compatible  : should be "mediatek,-xsphy", "mediatek,xsphy",
+ soc-model is the name of SoC, such as mt2712 etc;
+ when using "mediatek,xsphy" compatible string, you need SoC 
specific
+ ones in addition, one of:
+ - "mediatek,mt3611-xsphy"
+
+ - #address-cells, #size-cells : should use the same values as the root node
+ - ranges: must be present
+
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple U3 ports,
+ exclude port's private register, if only U2 ports provided,
+ shouldn't use the property.
+ - mediatek,src-ref-clk-mhz: u32, frequency of reference clock for slew 
rate
+ calibrate
+ - mediatek,src-coef   : u32, coefficient for slew rate calibrate, depends on
+ SoC process
+
+Required nodes : a sub-node is required for each port the controller
+ provides. Address range information including the usual
+ 'reg' property is used inside these nodes to describe
+ the controller's topology.
+
+Required properties (port (child) node):
+- reg  : address and length of the register set for the port.
+- clocks   : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names  : must contain
+ "ref": 48M reference clock for HighSpeed analog phy; and 26M
+   reference clock for SuperSpeedPlus analog phy, 
sometimes is
+   24M, 25M or 27M, depended on platform.
+- #phy-cells   : should be 1
+ cell after port phandle is phy type from:
+   - PHY_TYPE_USB2
+   - PHY_TYPE_USB3
+
+The following optional properties are only for debug or HQA test
+Optional properties (PHY_TYPE_USB2 port (child) node):
+- mediatek,eye-src : u32, the value of slew rate calibrate
+- mediatek,eye-vrt : u32, the selection of VRT reference voltage
+- mediatek,eye-term: u32, the selection of HS_TX TERM reference voltage
+- mediatek,efuse-intr  : u32, the selection of Internal Resistor
+
+Optional properties (PHY_TYPE_USB3 port (child) node):
+- mediatek,efuse-intr  : u32, the selection of Internal Resistor
+- mediatek,efuse-tx-imp: u32, the selection of TX Impedance
+- mediatek,efuse-rx-imp: u32, the selection of RX Impedance
+
+Banks layout of xsphy
+-
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u2 port10x1000MISC
+0x1100FMREG
+0x1300U2PHY_COM
+u2 port20x2000MISC
+...
+u31 common  0x3000DIG_GLB
+0x3100PHYA_GLB
+u31 port0   0x3400DIG_LN_TOP
+0x3500DIG_LN_TX0
+0x3600DIG_LN_RX0
+0x3700DIG_LN_DAIF
+0x3800PHYA_LN
+u31 port1   0x3a00DIG_LN_TOP
+0x3b00DIG_LN_TX0
+0x3c00DIG_LN_RX0
+0x3d00DIG_LN_DAIF
+0x3e00PHYA_LN
+...
+
+DIG_GLB & PHYA_GLB are shared by U31 ports.
+
+Example:
+
+u3phy: usb-phy@11c4 {
+   compatible = "mediatek,mt3611-xsphy", "mediatek,xsphy";
+   reg = <0 0x11c43000 0 0x0200>;
+   mediatek,src-ref-clk-mhz = <26>;
+   mediatek,src-coef = <17>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   u2port0: usb-phy@11c4 {
+   reg = <0 0x11c4 0 0x0400>;
+   clocks = <>;
+   clock-names = "ref";
+   mediatek,eye-src = <4>;
+   #phy-cells = <1>;
+   };
+
+   u3port0: usb-phy@11c43000 {
+   reg = <0 0x11c43400 0 0x0500>;
+   clocks = <>;
+   clock-names = "ref";
+   mediatek,efuse-intr = <28>;
+   #phy-cells = <1>;
+   };
+};
+
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to 

[PATCH v2 0/2] Add MediaTek XS-PHY driver

[Chunfeng Yun]

>From a0814ad7725587a06d273997e0fdf5161f916fd8 Mon Sep 17 00:00:00 2001
From: Chunfeng Yun 
Date: Sat, 5 May 2018 09:56:59 +0800
Subject: [PATCH v2 0/2] Add MediaTek XS-PHY driver

This patch series support the SuperSpeedPlus XS-PHY transceiver for
USB3.1 GEN2 controller on MediaTek chips. The driver supports multiple
USB2.0, USB3.1 GEN2 ports.

v2: changes in binding (suggested by Rob)
1. list all valid SoCs for compatible
2. move required child nodes after parent optional ones
3. remove status property in example
4. move banks layout example before dts one
5. remove phy binding example
6. add #address-cells, #size-cells, ranges properties for parent node

Chunfeng Yun (2):
  dt-bindings: add MediaTek XS-PHY binding
  phy: mediatek: add XS-PHY driver

 .../devicetree/bindings/phy/phy-mtk-xsphy.txt  | 110 
 drivers/phy/mediatek/Kconfig   |   9 +
 drivers/phy/mediatek/Makefile  |   1 +
 drivers/phy/mediatek/phy-mtk-xsphy.c   | 600 +
 4 files changed, 720 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/phy-mtk-xsphy.txt
 create mode 100644 drivers/phy/mediatek/phy-mtk-xsphy.c

-- 
1.9.1


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

[PATCH v2] phy: phy-mtk-tphy: use SPDX license tag

[Chunfeng Yun]

Use SPDX-License-Identifier tag instead of the GPL license text

Signed-off-by: Chunfeng Yun 
---
v2: change subject line to fix checkpatch warning:
"A patch subject line should describe the change not
the tool that found it"
---
 drivers/phy/mediatek/Makefile   |  1 +
 drivers/phy/mediatek/phy-mtk-tphy.c | 10 +-
 2 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
index 763a92e..1bdab14 100644
--- a/drivers/phy/mediatek/Makefile
+++ b/drivers/phy/mediatek/Makefile
@@ -1,3 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
 #
 # Makefile for the phy drivers.
 #
diff --git a/drivers/phy/mediatek/phy-mtk-tphy.c 
b/drivers/phy/mediatek/phy-mtk-tphy.c
index 38c281b..b962339 100644
--- a/drivers/phy/mediatek/phy-mtk-tphy.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -1,16 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * Copyright (c) 2015 MediaTek Inc.
  * Author: Chunfeng Yun 
  *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
  */
 
 #include 
-- 
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: USB regression for Android phone and sound card in 4.14

[Nazar Mokrynskyi]

04.05.18 18:47, Alan Stern пише:

> On Fri, 4 May 2018, Alan Stern wrote:
>
>> You can try using the usbreset program from here:
>>
>>  https://marc.info/?l=linux-usb=144820655510812=2
>>
>> That program wants the usbfs pathname of the hub instead of the sysfs 
>> path.  So you would call it with
>>
>>  usbreset /dev/bus/usb/001/DDD
>>
>> where DDD is the hub's device number.  You can get this number by 
>> reading the /sys/bus/usb/devices/1-0/devnum file, but the value has to 
> Typo -- that should have been 1-9, not 1-0.
>
> Alan Stern
>
>> be zero-padded to three digits.
>>
>> The usbreset program will send a bus reset to the hub, which is 
>> stronger than a soft reinit but not as strong as unplugging it and then 
>> plugging it back in.
>>
>> Alan Stern

Tried this too, still the same result.

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

--
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: [GIT PULL] USB-serial fixes for v4.17-rc4

[Greg Kroah-Hartman]

On Fri, May 04, 2018 at 11:05:32AM +0200, Johan Hovold wrote:
> The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:
> 
>   Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
> tags/usb-serial-4.17-rc4

Pulled and pushed out, thanks.

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

Re: [PATCH v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Fri, May 4, 2018 at 2:56 PM, David R. Bild  wrote:
> 2) The second reason is that the initialization done by the driver is
> work that should be done by platform, before the kernel ever sees the
> TPM.
>
> In particular, it sets the credentials for the platform hierarchy.
> The platform hierarchy is essentially the "root" account of the TPM,
> so it's critical that those credentials be set before the TPM is
> exposed to user-space.  (The platform credentials aren't persisted in
> the TPM and must be set by the platform on every boot.)  If the driver
> registers the TPM before doing initialization, there's a chance that
> something else could access the TPM before the platform credentials
> get set.

Setting the platform hierarchy password to a random discarded value
(and the dictionary lockout reset) is really the only special work
done here. The other steps (startup, self test, etc.) are done by the
TPM subsystem if needed.

So easy option would be for the TPM subsystem to set the platform
hierarchy password to a random value during device registration, if
needed.  It could either

a) check if the platform hierarchy authorization is null and then
always set a random password

or

b) take a flag when the device is registered indicating whether to do this.

This wouldn't require a significant change to the TPM subsystem
internals and would let me drop nearly the entire second patch from
this series.  (I think the dictionary lockout reset can be done via
the already exported "tpm_send(...)" function.)

Any thoughts on this approach?

Best,
David
--
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: Threaded interrupts for USB HCD instead of tasklets

[Alan Stern]

On Fri, 4 May 2018, Sebastian Andrzej Siewior wrote:

> Hi Alan,
> 
> I posted a RFC [0] to let the HCD complete the URB in threaded-IRQ
> context to avoid the softirq/tasklet. Mauro reported that this does not
> help him and never came back after that.
> You did not oppose the approach as long as there is no performance issue
> which I did not see. Would you mind if I revisit the approach and
> convert all HCDs to threaded IRQs while at it?

I don't mind revisiting the approach, although it certainly would be 
good to find out why it doesn't help Mauro's video problem.

However, converting _all_ the HCDs to threaded IRQs is a different
story.  It should be okay to convert the ones that currently use
tasklets, but I can't approve changes to all the others.  Only the
drivers that I maintain (ohci-hcd and uhci-hcd).

And even for those two, the conversion will not be easy.  Simply
changing the giveback routines would violate the documented guarantees
for isochronous transfers.

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: ehci-usb regression on 32-bit laptops in v4.17-rc1

[Alan Stern]

On Sat, 5 May 2018, Souptick Joarder wrote:

> > What you can't see just from reading the patch is that in both cases
> > (ehci->itd_pool and ehci->sitd_pool) there are two allocation paths --
> > the two branches of an "if" statement -- and only one of the paths
> > calls dma_pool_[z]alloc.  However, the memset is needed for both paths,
> > and so it can't be eliminated.  Given that it must be present, there's
> > no advantage to calling dma_pool_zalloc rather than dma_pool_alloc.
> >
> > Can you try reverting just these portions while leaving the first part
> > unchanged?
> 
> Sorry for breaking the stability.
> 
> Alan , shall I keep the first part unchanged and revert the second part and
> send the patch new patch ?

Since Greg is going to (or already has) reverted the original commit,
you might as well submit a new patch that changes just the first
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 v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

On Fri, May 4, 2018 at 2:06 PM, Jason Gunthorpe  wrote:
>
> On Fri, May 04, 2018 at 08:00:22AM -0500, David R. Bild wrote:
> > Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
> > for performing initialization of the TPM.  For these modules, the host
> > kernel is the platform, so we perform the initialization in the driver
> > before registering the TPM with the kernel TPM subsystem.
>
> The tpm driver already does most of this stuff automatically, why
> duplicate it there and why is it coded in a way that doesn't use the
> existing TPM services to do it?

I didn't want to have to duplicate all that functionality and was
disappointed when that became the only option (due to the two reasons
outlined below) for supporting existing kernels with an out-of-tree
module.

Bringing the module in-tree opens the option of reworking some of the
TPM subsystem to support this use case.  I'm open to concrete
suggestions on how to do so.

1) The first reason is that I don't think the necessary pieces are
currently made available for reuse. I'd love to not repeat that code,
but

- some required structs and functions are declared in private headers
(drivers/char/tpm/*.h instead of include/linux/tpm.h).
- many of the required functions are not exported.

If the TPM maintainers are open to more of the API being "public", I
can look into preparing patches that export the necessary operations.

2) The second reason is that the initialization done by the driver is
work that should be done by platform, before the kernel ever sees the
TPM.

In particular, it sets the credentials for the platform hierarchy.
The platform hierarchy is essentially the "root" account of the TPM,
so it's critical that those credentials be set before the TPM is
exposed to user-space.  (The platform credentials aren't persisted in
the TPM and must be set by the platform on every boot.)  If the driver
registers the TPM before doing initialization, there's a chance that
something else could access the TPM before the platform credentials
get set.

The TPM system doesn't appear (to me; please correct me) to be
designed to support the following start-up sequence:

a) Driver registers the device with the TPM subsystem
b) Driver uses the TPM subsystem to perform platform initialization
(what the BIOS should have done...)
c) Driver tells the TPM subsystem to now perform the kernel
initialization of the TPM
d) TPM subsystem does its initialization of the TPM
e) TPM is exposed to userspace, added as hwrng, etc.

It would only support the sequence  [a, d, e, b] and we'd just have to
hope no one accesses the TPM between steps 'e' and 'b'.

Best,
David
--
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 v5 1/7] clk: msm8996-gcc: Mark halt check as no-op for USB/PCIE pipe_clk

[Doug Anderson]

Hi,

On Wed, May 2, 2018 at 2:06 PM, Manu Gautam  wrote:
> The USB and PCIE pipe clocks are sourced from external clocks
> inside the QMP USB/PCIE PHYs. Enabling or disabling of PIPE RCG
> clocks is dependent on PHY initialization sequence hence
> update halt_check to BRANCH_HALT_SKIP for these clocks so
> that clock status bit is not polled when enabling or disabling
> the clocks. It allows to simplify PHY client driver code which
> is both user and source of the pipe_clk and avoid error logging
> related status check on clk_disable/enable.
>
> Signed-off-by: Manu Gautam 
> ---
>  drivers/clk/qcom/gcc-msm8996.c | 4 
>  1 file changed, 4 insertions(+)

FWIW this matches my understanding of what Stephen and you agreed upon.  Thus:

Reviewed-by: Douglas Anderson 
--
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 v5 6/7] dt-bindings: phy-qcom-usb2: Add support to override tuning values

[Doug Anderson]

Hi,

On Wed, May 2, 2018 at 2:06 PM, Manu Gautam  wrote:
> To improve eye diagram for PHYs on different boards of same SOC,
> some parameters may need to be changed. Provide device tree
> properties to override these from board specific device tree
> files. While at it, replace "qcom,qusb2-v2-phy" with compatible
> string for USB2 PHY on sdm845 which was earlier added for
> sdm845 only.
>
> Signed-off-by: Manu Gautam 
> ---
>  .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 23 +-
>  include/dt-bindings/phy/phy-qcom-qusb2.h   | 37 
> ++
>  2 files changed, 59 insertions(+), 1 deletion(-)
>  create mode 100644 include/dt-bindings/phy/phy-qcom-qusb2.h

Thanks for adding the #defines, describing the defaults, and including
which SoCs the new properties work on.  This looks great to me now,
thanks!

Reviewed-by: Douglas Anderson 
--
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 v5 7/7] phy: qcom-qusb2: Add QUSB2 PHYs support for sdm845

[Doug Anderson]

Hi,

On Wed, May 2, 2018 at 2:06 PM, Manu Gautam  wrote:
> There are two QUSB2 PHYs present on sdm845. In order
> to improve eye diagram for both the PHYs some parameters
> need to be changed. Provide device tree properties to
> override these from board specific device tree files.
>
> Signed-off-by: Manu Gautam 
> ---
>  drivers/phy/qualcomm/phy-qcom-qusb2.c | 126 
> +++---
>  1 file changed, 118 insertions(+), 8 deletions(-)

I confirmed that all my previous comments were fixed and this looks
nice to me now.

Reviewed-by: Douglas Anderson 
--
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

Threaded interrupts for USB HCD instead of tasklets

[Sebastian Andrzej Siewior]

Hi Alan,

I posted a RFC [0] to let the HCD complete the URB in threaded-IRQ
context to avoid the softirq/tasklet. Mauro reported that this does not
help him and never came back after that.
You did not oppose the approach as long as there is no performance issue
which I did not see. Would you mind if I revisit the approach and
convert all HCDs to threaded IRQs while at it?

[0] https://lkml.kernel.org/r/20180216170450.yl5owfphuvlts...@breakpoint.cc

Sebastian
--
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 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[Jason Gunthorpe]

On Fri, May 04, 2018 at 08:00:22AM -0500, David R. Bild wrote:
> Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
> for performing initialization of the TPM.  For these modules, the host
> kernel is the platform, so we perform the initialization in the driver
> before registering the TPM with the kernel TPM subsystem.
> 
> The initialization consists of issuing the TPM startup command,
> running the TPM self-test, and setting the TPM platform hierarchy
> authorization to a random, unsaved value so that it can never be used
> after the driver has loaded.

The tpm driver already does most of this stuff automatically, why
duplicate it there and why is it coded in a way that doesn't use the
existing TPM services to do it?

Make no sense to me.

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

Bug - USB ports remain suspended after suspend/resume

[Vasil Vasilev]

ASUS UX305UA user. USB ports function normally after system boot. After the
first and any subsequent suspend/resume, the USB ports remain suspended. In
order for a newly plugged in USB device to be recognized, any autosuspended
USB device has to be toggled (autosuspend on and off).

This problem first manifested itself in kernel version 4.16. It is not
present in any kernel version before 4.16.

Commands output:
https://drive.google.com/drive/folders/10Njyl19c93jIUF-ESscYQofo2s_j3W_B?usp=sharing
--
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 v3 1/3] dt-bindings: usb: Update documentation for Qualcomm DWC3 driver

[Manu Gautam]

Existing documentation has lot of incorrect information as it
was originally added for a driver that no longer exists.

Signed-off-by: Manu Gautam 
---
 .../devicetree/bindings/usb/qcom,dwc3.txt  | 85 --
 1 file changed, 63 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt 
b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
index bc8a2fa..95afdcf 100644
--- a/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.txt
@@ -1,54 +1,95 @@
 Qualcomm SuperSpeed DWC3 USB SoC controller
 
 Required properties:
-- compatible:  should contain "qcom,dwc3"
+- compatible:  Compatible list, contains
+   "qcom,dwc3"
+   "qcom,msm8996-dwc3" for msm8996 SOC.
+   "qcom,sdm845-dwc3" for sdm845 SOC.
+- reg: Offset and length of register set for QSCRATCH wrapper
+- power-domains:   specifies a phandle to PM domain provider node
 - clocks:  A list of phandle + clock-specifier pairs for the
clocks listed in clock-names
-- clock-names: Should contain the following:
+- clock-names: Should contain the following:
   "core"   Master/Core clock, have to be >= 125 MHz for SS
operation and >= 60MHz for HS operation
+  "mock_utmi"  Mock utmi clock needed for ITP/SOF generation in
+   host mode. Its frequency should be 19.2MHz.
+  "sleep"  Sleep clock, used for wakeup when USB3 core goes
+   into low power mode (U3).
 
 Optional clocks:
-  "iface"  System bus AXI clock.  Not present on all platforms
-  "sleep"  Sleep clock, used when USB3 core goes into low
-   power mode (U3).
+  "iface"  System bus AXI clock.
+   Not present on "qcom,msm8996-dwc3" compatible.
+  "cfg_noc"System Config NOC clock.
+   Not present on "qcom,msm8996-dwc3" compatible.
+- assigned-clocks: Should be:
+   MOCK_UTMI_CLK
+   MASTER_CLK
+- assigned-clock-rates: Should be:
+19.2Mhz (19200) for MOCK_UTMI_CLK
+>=125Mhz (12500) for MASTER_CLK in SS mode
+>=60Mhz (6000) for MASTER_CLK in HS mode
+
+Optional properties:
+- resets:  Phandle to reset control that resets core and wrapper.
+- interrupts:  specifies interrupts from controller wrapper used
+   to wakeup from low power/susepnd state. Must contain
+   one or more entry for interrupt-names property
+- interrupt-names: Must include the following entries:
+   - "hs_phy_irq": The interrupt that is asserted when a
+  wakeup event is received on USB2 bus
+   - "ss_phy_irq": The interrupt that is asserted when a
+  wakeup event is received on USB3 bus
+   - "dm_hs_phy_irq" and "dp_hs_phy_irq": Separate
+  interrupts for any wakeup event on DM and DP lines
+- qcom,select-utmi-as-pipe-clk: if present, disable USB3 pipe_clk requirement.
+   Used when dwc3 operates without SSPHY and only
+   HS/FS/LS modes are supported.
 
 Required child node:
 A child node must exist to represent the core DWC3 IP block. The name of
 the node is not important. The content of the node is defined in dwc3.txt.
 
 Phy documentation is provided in the following places:
-Documentation/devicetree/bindings/phy/qcom-dwc3-usb-phy.txt
+Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt   - USB3 QMP PHY
+Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt - USB2 QUSB2 PHY
 
 Example device nodes:
 
hs_phy: phy@100f8800 {
-   compatible = "qcom,dwc3-hs-usb-phy";
-   reg = <0x100f8800 0x30>;
-   clocks = < USB30_0_UTMI_CLK>;
-   clock-names = "ref";
-   #phy-cells = <0>;
-
+   compatible = "qcom,qusb2-v2-phy";
+   ...
};
 
ss_phy: phy@100f8830 {
-   compatible = "qcom,dwc3-ss-usb-phy";
-   reg = <0x100f8830 0x30>;
-   clocks = < USB30_0_MASTER_CLK>;
-   clock-names = "ref";
-   #phy-cells = <0>;
-
+   compatible = "qcom,qmp-v3-usb3-phy";
+   ...
};
 
-   usb3_0: usb30@0 {
+   usb3_0: usb30@a6f8800 {
compatible = "qcom,dwc3";
+  

[PATCH v3 2/3] usb: dwc3: Add Qualcomm DWC3 glue driver

[Manu Gautam]

DWC3 controller on Qualcomm SOCs has a Qscratch wrapper.
Some of its uses are described below resulting in need to
have a separate glue driver instead of using dwc3-of-simple:
 - It exposes register interface to override vbus-override
   and lane0-pwr-present signals going to hardware. These
   must be updated in peripheral mode for DWC3 if vbus lines
   are not connected to hardware block. Otherwise RX termination
   in SS mode or DP pull-up is not applied by device controller.
 - pwr_events_irq_stat support to check if USB2 PHY is in L2 state
   before glue driver proceeds with suspend.
 - Support for wakeup interrupts lines that are asserted whenever
   there is any wakeup event on USB3 or USB2 bus.
 - Support to replace pip3 clock going to DWC3 with utmi clock
   for hardware configuration where SSPHY is not used with DWC3.

Signed-off-by: Manu Gautam 
---
 drivers/usb/dwc3/Kconfig  |  12 +
 drivers/usb/dwc3/Makefile |   1 +
 drivers/usb/dwc3/dwc3-of-simple.c |   1 -
 drivers/usb/dwc3/dwc3-qcom.c  | 618 ++
 4 files changed, 631 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/dwc3/dwc3-qcom.c

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index ab8c0e0..451012e 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -106,4 +106,16 @@ config USB_DWC3_ST
  inside (i.e. STiH407).
  Say 'Y' or 'M' if you have one such device.
 
+config USB_DWC3_QCOM
+   tristate "Qualcomm Platform"
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on OF
+   default USB_DWC3
+   help
+ Some Qualcomm SoCs use DesignWare Core IP for USB2/3
+ functionality.
+ This driver also handles Qscratch wrapper which is needed
+ for peripheral mode support.
+ Say 'Y' or 'M' if you have one such device.
+
 endif
diff --git a/drivers/usb/dwc3/Makefile b/drivers/usb/dwc3/Makefile
index 025bc68..5c07d8f 100644
--- a/drivers/usb/dwc3/Makefile
+++ b/drivers/usb/dwc3/Makefile
@@ -48,3 +48,4 @@ obj-$(CONFIG_USB_DWC3_PCI)+= dwc3-pci.o
 obj-$(CONFIG_USB_DWC3_KEYSTONE)+= dwc3-keystone.o
 obj-$(CONFIG_USB_DWC3_OF_SIMPLE)   += dwc3-of-simple.o
 obj-$(CONFIG_USB_DWC3_ST)  += dwc3-st.o
+obj-$(CONFIG_USB_DWC3_QCOM)+= dwc3-qcom.o
diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index cb2ee96..0fd0e8e 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -208,7 +208,6 @@ static int dwc3_of_simple_runtime_resume(struct device *dev)
 };
 
 static const struct of_device_id of_dwc3_simple_match[] = {
-   { .compatible = "qcom,dwc3" },
{ .compatible = "rockchip,rk3399-dwc3" },
{ .compatible = "xlnx,zynqmp-dwc3" },
{ .compatible = "cavium,octeon-7130-usb-uctl" },
diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
new file mode 100644
index 000..ecb2218
--- /dev/null
+++ b/drivers/usb/dwc3/dwc3-qcom.c
@@ -0,0 +1,618 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * Inspired by dwc3-of-simple.c
+ */
+#define DEBUG
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "core.h"
+
+/* USB QSCRATCH Hardware registers */
+#define QSCRATCH_HS_PHY_CTRL   0x10
+#define UTMI_OTG_VBUS_VALIDBIT(20)
+#define SW_SESSVLD_SEL BIT(28)
+
+#define QSCRATCH_SS_PHY_CTRL   0x30
+#define LANE0_PWR_PRESENT  BIT(24)
+
+#define QSCRATCH_GENERAL_CFG   0x08
+#define PIPE_UTMI_CLK_SEL  BIT(0)
+#define PIPE3_PHYSTATUS_SW BIT(3)
+#define PIPE_UTMI_CLK_DIS  BIT(8)
+
+#define PWR_EVNT_IRQ_STAT_REG  0x58
+#define PWR_EVNT_LPM_IN_L2_MASKBIT(4)
+#define PWR_EVNT_LPM_OUT_L2_MASK   BIT(5)
+
+struct dwc3_qcom {
+   struct device   *dev;
+   void __iomem*qscratch_base;
+   struct platform_device  *dwc3;
+   struct clk  **clks;
+   int num_clocks;
+   struct reset_control*resets;
+
+   int hs_phy_irq;
+   int dp_hs_phy_irq;
+   int dm_hs_phy_irq;
+   int ss_phy_irq;
+
+   struct extcon_dev   *edev;
+   struct extcon_dev   *host_edev;
+   struct notifier_block   vbus_nb;
+   struct notifier_block   host_nb;
+
+   enum usb_dr_modemode;
+   boolis_suspended;
+   boolpm_suspended;
+};
+
+static inline void dwc3_qcom_setbits(void __iomem *base, u32 offset, u32 val)
+{
+   

[PATCH v3 3/3] usb: dwc3: core: Suspend PHYs on runtime suspend in host mode

[Manu Gautam]

Some PHY drivers (e.g. for Qualcomm QUSB2 and QMP PHYs) support
runtime PM to reduce PHY power consumption during bus_suspend.
Add changes to let core auto-suspend PHYs on host bus-suspend
using GUSB2PHYCFG register if needed for a platform. Also perform
PHYs runtime suspend/resume and let platform glue drivers e.g.
dwc3-qcom handle remote wakeup during bus suspend by waking up
devices on receiving wakeup event from PHY.

Signed-off-by: Manu Gautam 
---
 drivers/usb/dwc3/core.c | 36 +---
 1 file changed, 33 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index a15648d..449a098 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1394,6 +1394,7 @@ static int dwc3_remove(struct platform_device *pdev)
 static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg)
 {
unsigned long   flags;
+   u32 reg;
 
switch (dwc->current_dr_role) {
case DWC3_GCTL_PRTCAP_DEVICE:
@@ -1403,9 +1404,25 @@ static int dwc3_suspend_common(struct dwc3 *dwc, 
pm_message_t msg)
dwc3_core_exit(dwc);
break;
case DWC3_GCTL_PRTCAP_HOST:
-   /* do nothing during host runtime_suspend */
-   if (!PMSG_IS_AUTO(msg))
+   if (!PMSG_IS_AUTO(msg)) {
dwc3_core_exit(dwc);
+   break;
+   }
+
+   /* Let controller to suspend HSPHY before PHY driver suspends */
+   if (dwc->dis_u2_susphy_quirk ||
+   dwc->dis_enblslpm_quirk) {
+   reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+   reg |=  DWC3_GUSB2PHYCFG_ENBLSLPM |
+   DWC3_GUSB2PHYCFG_SUSPHY;
+   dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+
+   /* Give some time for USB2 PHY to suspend */
+   usleep_range(5000, 6000);
+   }
+
+   phy_pm_runtime_put_sync(dwc->usb2_generic_phy);
+   phy_pm_runtime_put_sync(dwc->usb3_generic_phy);
break;
case DWC3_GCTL_PRTCAP_OTG:
/* do nothing during runtime_suspend */
@@ -1433,6 +1450,7 @@ static int dwc3_resume_common(struct dwc3 *dwc, 
pm_message_t msg)
 {
unsigned long   flags;
int ret;
+   u32 reg;
 
switch (dwc->current_dr_role) {
case DWC3_GCTL_PRTCAP_DEVICE:
@@ -1446,13 +1464,25 @@ static int dwc3_resume_common(struct dwc3 *dwc, 
pm_message_t msg)
spin_unlock_irqrestore(>lock, flags);
break;
case DWC3_GCTL_PRTCAP_HOST:
-   /* nothing to do on host runtime_resume */
if (!PMSG_IS_AUTO(msg)) {
ret = dwc3_core_init(dwc);
if (ret)
return ret;
dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
+   break;
}
+   /* Restore GUSB2PHYCFG bits that were modified in suspend */
+   reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
+   if (dwc->dis_u2_susphy_quirk)
+   reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
+
+   if (dwc->dis_enblslpm_quirk)
+   reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
+
+   dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
+
+   phy_pm_runtime_get_sync(dwc->usb2_generic_phy);
+   phy_pm_runtime_get_sync(dwc->usb3_generic_phy);
break;
case DWC3_GCTL_PRTCAP_OTG:
/* nothing to do on runtime_resume */
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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 v3 0/3] usb: dwc3: support for Qualcomm DWC3 glue

[Manu Gautam]

Add separate dwc3-qcom glue driver for Qualcomm SOCs having dwc3 core.
It is needed to support peripheral mode.
Patches also add support to invoke PHY runtime PM functions on host
mode bus-suspend.

Changes since v2:
 - Addressed Rob's comments for DT binding documentation.

Changes since v1:
 - Move dwc3 core register accesses from glue driver to dwc3 core as
   per review comment from Felipe.
 - Addressed other review comments from Felipe and Rob.
 - Some other minor code changes related to redability.
 - Add reset_control assert in driver probe to ensure core registers
   are reset to POR value in case of any initalization by boot code. 

Manu Gautam (3):
  dt-bindings: usb: Update documentation for Qualcomm DWC3 driver
  usb: dwc3: Add Qualcomm DWC3 glue driver
  usb: dwc3: core: Suspend PHYs on runtime suspend in host mode

 .../devicetree/bindings/usb/qcom,dwc3.txt  |  85 ++-
 drivers/usb/dwc3/Kconfig   |  12 +
 drivers/usb/dwc3/Makefile  |   1 +
 drivers/usb/dwc3/core.c|  36 +-
 drivers/usb/dwc3/dwc3-of-simple.c  |   1 -
 drivers/usb/dwc3/dwc3-qcom.c   | 618 +
 6 files changed, 727 insertions(+), 26 deletions(-)
 create mode 100644 drivers/usb/dwc3/dwc3-qcom.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH] usb: dwc2: debugfs: Don't touch RX FIFO during register dump

[Stefan Wahren]

Dumping the registers via debugfs makes USB on Raspberry Pi completely
unusable. The read of register GRXSTSP ("Receive Status Read and Pop
Register") is responsible for this behaviour, because it pops the RX FIFO.
So avoid this by omitting the relevant register.

CC: Mian Yousaf Kaukab 
Fixes: 563cf017c443 ("usb: dwc2: debugfs: add support for complete register 
dump")
Signed-off-by: Stefan Wahren 
---
 drivers/usb/dwc2/debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/debugfs.c b/drivers/usb/dwc2/debugfs.c
index 58c691f..d4c0589 100644
--- a/drivers/usb/dwc2/debugfs.c
+++ b/drivers/usb/dwc2/debugfs.c
@@ -368,7 +368,7 @@ static const struct debugfs_reg32 dwc2_regs[] = {
dump_register(GINTSTS),
dump_register(GINTMSK),
dump_register(GRXSTSR),
-   dump_register(GRXSTSP),
+   /* Omit GRXSTSP */
dump_register(GRXFSIZ),
dump_register(GNPTXFSIZ),
dump_register(GNPTXSTS),
-- 
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

Re: ehci-usb regression on 32-bit laptops in v4.17-rc1

[Greg KH]

On Fri, May 04, 2018 at 10:39:07AM -0400, Alan Stern wrote:
> You should have CC'ed the author of the offending commit.  Added.
> 
> On Thu, 3 May 2018, Erick Cafferata wrote:
> 
> > Starting from v4.17-rc1, I've been having problems with my laptop's
> > webcam. Immediately after attempting to open Guvcview(or any other camera
> > software), the system just stops working. No response from any input and
> > the Caps lock LED starts blinking.
> > I've been following the last three -rc and no changes, so I started
> > testing on my own. I bisected it back to
> > 
> > commit 22072e83ebd510fb6a090aef9d65ccfda9b1e7e4
> > Author: Souptick Joarder 
> > Date:   Wed Feb 14 23:18:48 2018 +0530
> > 
> > usb: host: ehci: Use dma_pool_zalloc()
> > 
> > Use dma_pool_zalloc() instead of dma_pool_alloc + memset
> > 
> > I tried reverting it on top of -rc3 and everything worked again.
> > I test this bug on four machines:
> > - 2 hp mini 210(atom n450 and n2800, respectively)
> > - 1 Sony Vaio (Core 2 Duo T7250)
> > - 1 Thinkpad T410 (some core i7..)
> > The three 32-bit laptops presented the exact same bug, however the
> > Thinkpad did not crash (the driver didn't create the /dev/videoN at
> > all, I think this might be a different issue, so disregard).
> > And reverting this commit solved the issue in all three laptops.
> > 
> > Let me know if you need any further information regarding this issue.
> > Sincerely,
> > Erick Cafferata
> 
> Right you are!  I should never have approved that patch in the first 
> place.  :-(
> 
> > commit d3c88476223b51d2a0a1bc2326760c0dcb6efd88
> > Author: Erick Cafferata 
> > Date:   Wed May 2 11:13:32 2018 -0500
> > 
> > Revert "usb: host: ehci: Use dma_pool_zalloc()"
> > 
> > This reverts commit 22072e83ebd510fb6a090aef9d65ccfda9b1e7e4.
> > 
> > diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
> > index 4c6c08b675b5..21307d862af6 100644
> > --- a/drivers/usb/host/ehci-mem.c
> > +++ b/drivers/usb/host/ehci-mem.c
> > @@ -73,9 +73,10 @@ static struct ehci_qh *ehci_qh_alloc (struct ehci_hcd 
> > *ehci, gfp_t flags)
> > if (!qh)
> > goto done;
> > qh->hw = (struct ehci_qh_hw *)
> > -   dma_pool_zalloc(ehci->qh_pool, flags, );
> > +   dma_pool_alloc(ehci->qh_pool, flags, );
> > if (!qh->hw)
> > goto fail;
> > +   memset(qh->hw, 0, sizeof *qh->hw);
> 
> In fact, this part was okay.  It does not need to be reverted.
> 
> > qh->qh_dma = dma;
> > // INIT_LIST_HEAD (>qh_list);
> > INIT_LIST_HEAD (>qtd_list);
> > diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> > index 28e2a338b481..e56db44708bc 100644
> > --- a/drivers/usb/host/ehci-sched.c
> > +++ b/drivers/usb/host/ehci-sched.c
> > @@ -1287,7 +1287,7 @@ itd_urb_transaction(
> > } else {
> >   alloc_itd:
> > spin_unlock_irqrestore(>lock, flags);
> > -   itd = dma_pool_zalloc(ehci->itd_pool, mem_flags,
> > +   itd = dma_pool_alloc(ehci->itd_pool, mem_flags,
> > _dma);
> > spin_lock_irqsave(>lock, flags);
> > if (!itd) {
> > @@ -1297,6 +1297,7 @@ itd_urb_transaction(
> > }
> > }
> >  
> > +   memset(itd, 0, sizeof(*itd));
> > itd->itd_dma = itd_dma;
> > itd->frame = NO_FRAME;
> > list_add(>itd_list, >td_list);
> > @@ -2080,7 +2081,7 @@ sitd_urb_transaction(
> > } else {
> >   alloc_sitd:
> > spin_unlock_irqrestore(>lock, flags);
> > -   sitd = dma_pool_zalloc(ehci->sitd_pool, mem_flags,
> > +   sitd = dma_pool_alloc(ehci->sitd_pool, mem_flags,
> > _dma);
> > spin_lock_irqsave(>lock, flags);
> > if (!sitd) {
> > @@ -2090,6 +2091,7 @@ sitd_urb_transaction(
> > }
> > }
> >  
> > +   memset(sitd, 0, sizeof(*sitd));
> > sitd->sitd_dma = sitd_dma;
> > sitd->frame = NO_FRAME;
> > list_add(>sitd_list, _sched->td_list);
> 
> But these parts were definitely wrong.
> 
> What you can't see just from reading the patch is that in both cases
> (ehci->itd_pool and ehci->sitd_pool) there are two allocation paths --
> the two branches of an "if" statement -- and only one of the paths
> calls dma_pool_[z]alloc.  However, the memset is needed for both paths, 
> and so it can't be eliminated.  Given that it must be present, there's 
> no advantage to calling dma_pool_zalloc rather than dma_pool_alloc.
> 
> Can you try reverting just these portions while leaving the first part 
> unchanged?

Ugh, I missed that.  I'll revert this patch for now.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to 

Re: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Mats Karrman]

On 2018-05-04 16:56, Heikki Krogerus wrote:


On Wed, May 02, 2018 at 03:13:44PM +0200, Mats Karrman wrote:

Hi Heikki,

On 2018-05-02 10:25, Heikki Krogerus wrote:


On Wed, May 02, 2018 at 11:23:35AM +0300, Heikki Krogerus wrote:

Hi Mats,

On Wed, May 02, 2018 at 12:21:07AM +0200, Mats Karrman wrote:

The current naming used for tcpc_mux_mode constants makes
too much assumptioms about the usage of the signals.
This patch replaces the names with generic names more closely
tied to the Type-C specifications and also adds some new ones.
At the same time TCPC_MUX_* defines are removed as they do not
fit the new concept and currently have no in-tree users.

I'm afraid trying to generalize the modal connector states even like
this is not going to work. We can't make any assumptions about how the
alternate modes configure the pins, or the connector in general.

The only way this will work is that every alternate mode has its own
configurations defined separately, and I'm talking about the actual
pin configurations that the specifications for each alternate mode
defines, so something like TYPEC_MUX_DP and TYPEC_MUX_DOCK will not
work for sure.

The connector states that are defined in USB Type-C specification (so
basically USB Operation and USB Safe State) can be generalized, but
those states just should not be defined in tcpm.h. We need to use
them in other drivers as well.

I'm in the middle of preparing more complete support for alternate
modes. If you check the RFC [1] I send previously, in the first patch
of the series I'm adding documentation that should explain the
plan.

Sorry, I forgot the link:

[1] https://www.spinics.net/lists/linux-usb/msg166520.html

Oh, sorry I forgot about that post in the first place... I reread it now.

Since the modal TYPEC_STATE_ are overlapping for each AM, this means that
the mux driver "set" must know which AM is active, right?

And each mux driver also need to support all possible alt modes?

There are two options for the mux drivers to link with the alternate
modes. They can use the typec API where a single mux is linked to a
single port. Alternatively they can use the notifiers from the
alternate modes themselves, which allows a single mux to be liked to
multiple alternate modes. Both methods will be available.

Is this what you were asking?


Well, sort of... My angle is from the mux driver writers side. A hardware mux
device does not care what logical signals is being muxed and neither should the
mux driver I think. But the system designer must be able to make the mux driver
respond to the correct AM:STATE.
So, do you think it would be a viable approach to let the mux driver be
configured through dt/acpi properties that link AM:STATE pairs to some internal
muxing mode of the hardware mux device?
Even so, when the mux driver "set" function is called, it will just get the
mode argument but since the mode (TYPEC_STATE_...) is overlapping for different
AMs if I understand your proposal correctly, the mux also needs to know what AM
is active.
Does this imply that the mux set function signature need to change?


I was thinking that it must be a finite number of possible routes
between the local connections of a mux and the four available SS lanes of
the cable but of course there is no theoretical limit to the number of
local connections...

Do we want to set a limitation of one mux device per port? I guess we
could and then let people write "composite" mux drivers if it should ever
be necessary.

I think I answered to this one above.


Still it's difficult to write a mux device driver that support everything,
but I'm thinking that it might be possible to write a "mode agnostic" mux
driver that uses properties to match the "AM:STATE" pairs the board needs
to support to the hardware mux device specific muxing modes available?

It would be very interesting to see a devicetree example on how you
picture things being connected to each other.

Btw. You're using "mode" and "state" interchangeably which is a bit
confusing. Could you settle for one?

OK, I'll try to be more consistent and pick one.


Thanks,



BR // Mats

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

Re: [PATCH v2 1/2] usb: dwc2: alloc dma aligned buffer for isoc split in

[Doug Anderson]

Hi,

On Wed, May 2, 2018 at 10:14 AM, wlf  wrote:
> It's a good way to allocate an extra 3 bytes in the original bounce buffer
> for this unaligned
> issue， it's similar to the tailroom of sk_buff. However, just as you said,
> we'd better find
> the special cases where we need an oversized bounce buffer, otherwise，we
> need to allocate
> a bounce buffer for all of urbs.
>
> It's hard for me to know the special cases in the
> dwc2_alloc_dma_aligned_buffer(), because
> it's called from usb_submit_urb() in the device class driver, and I hardly
> know the split state
> in this process, much less if the split transaction need aligned buffer. Do
> you have any idea?
>
> I suppose that we can't find the special cases where we need an oversized
> bounce buffer
> in the dwc2_alloc_dma_aligned_buffer(), and if we still want to re-use the
> original bounce
> buffer with extra 3 bytes, then we need to allocate a  bounce buffer for all
> of urbs, and do
> unnecessary  data copy for these urbs  whose transfer_buffer were already
> aligned.  This
> may reduce the transmission rate of USB.
>
> Can we just pre-allocate an additional aligned buffer (the size is 200
> bytes) for split transaction
> in dwc2_map_urb_for_dma for all of urbs. And if we find the split
> transaction is unaligned，
> we can easily use the pre-allocated aligned buffer.

OK, so thinking about this more...

Previously things got really slow at interrupt time because we were
trying to allocate as much as 64K at interrupt time.  That wasn't so
great.  In your case, you're only allocating 200 bytes.  As I
understand things, allocating 200 bytes at interrupt time is probably
not a huge deal.

...so I guess it come down to a tradeoff here: is it worth eating 200
bytes for each URB to save an 200 byte allocation at interrupt time in
this one rare case.

I'd certainly welcome anyone's opinion here, but I'm going to go with
saying it's fine to allocate the 200 bytes at interrupt time (like
your patch does).  ...but, I _think_ you want to use
kmem_cache_create() to create a cache and then kmem_cache_zalloc().
Since all allocations are the same size and you want this to be fast,
I think using kmem_cache is good.



>>> +   /* For non-dword aligned buffers */
>>> +   if (hsotg->params.host_dma > 0 && qh->do_split &&
>>> +   chan->ep_is_in && (chan->xfer_dma & 0x3)) {
>>
>> So what happens if were unaligned (AKA (chan->xfer_dma & 0x3)) but
>> we're not doing split or it's not an IN EP?  Do we just fail then?
>>
>> I guess the rest of this patch only handles the "in" case and maybe
>> you expect that the problems will only come about for do_split, but it
>> still might be wise to at least print a warning in the other cases?
>> >From reading dwc2_hc_init_xfer() it seems like you could run into this
>> same problem in the "out" case?
>
> Actually, I only find non-dword aligned issue in the case of split in
> transaction.
> And I think that if we're not doing split or it's an OUT EP, we can always
> get aligned buffer
> in the current code. For non-split case, the dwc2_alloc_dma_aligned_buffer()
> is enough. And for split out case, if the transaction is subdivided into
> multiple start-splits,
> each with a data payload of 188 bytes or less, so the DMA address is always
> aligned.

Can you at least print an error message if you end up with non-aligned
DMA in one of the other cases?


>>> DMA_FROM_DEVICE);
>>> +   memcpy(qtd->urb->buf + frame_desc->offset +
>>> +  qtd->isoc_split_offset, chan->qh->dw_align_buf,
>>> len);
>>
>> Assuming I'm understanding this patch correctly, I think it would be
>> better to write:
>>
>>memcpy(qtd->xfer_dma, chan->qh->dw_align_buf, len);
>
> Sorry, there's no "xfer_buf" in qtd, do you means the "chan->xfer_dma"? If
> it's, I think we can't
> do memcpy from a transfer buffer to a DMA address. Maybe chan->xfer_buf is
> more suitable,
> but it seems that the dwc2 driver doesn't update the chan->xfer_buf for isoc
> transfer with dma
> enabled in dwc2_hc_init_xfer().

Yes, I meant chan->xfer_dma.  Ah, right.  xfer_dma is a DMA address.

I guess you could in theory you could do:

memcpy(qtd->urb->buf + (chan->xfer_dma - urb->dma),
chan->qh->dw_align_buf);

That at least avoids duplicating the math.  Maybe either do that, or
if you don't like it at least add a comment saying that the math needs
to match the math in dwc2_hc_init_xfer().


>> Then if you ever end up having to align a transfer other than a split
>> you won't be doing the wrong math.  As it is it's very non-obvious
>> that you're hardcoding the same formula that's in dwc2_hc_init_xfer()
>
> Actually, I'm hardcoding the same formula from the old code which has been
> ripped out
> in the commit 3bc04e28a030 ("usb: dwc2: host: Get aligned DMA in a more
> supported way").

Ah, got it.  Well, I think the old code was just hardcoding the same
formula in two places then.  ;-)


>>> -   if (qh->desc_list)

Re: USB regression for Android phone and sound card in 4.14

[Alan Stern]

On Fri, 4 May 2018, Alan Stern wrote:

> You can try using the usbreset program from here:
> 
>   https://marc.info/?l=linux-usb=144820655510812=2
> 
> That program wants the usbfs pathname of the hub instead of the sysfs 
> path.  So you would call it with
> 
>   usbreset /dev/bus/usb/001/DDD
> 
> where DDD is the hub's device number.  You can get this number by 
> reading the /sys/bus/usb/devices/1-0/devnum file, but the value has to 

Typo -- that should have been 1-9, not 1-0.

Alan Stern

> be zero-padded to three digits.
> 
> The usbreset program will send a bus reset to the hub, which is 
> stronger than a soft reinit but not as strong as unplugging it and then 
> plugging it back in.
> 
> 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

[no subject]

[Mark Henry]

Hello
My name is Gen Henry Mark, I am US military officer,i will like to get
acquainted with you, I read your profile and I really wish to indicate
my interest, please I'll be glad if you get back to me so that i can
contact you and tell you more about my self ,i wish to hear from you
soon.
Best regards,
Gen Henry Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB regression for Android phone and sound card in 4.14

[Alan Stern]

On Fri, 4 May 2018, Nazar Mokrynskyi wrote:

> 03.05.18 23:20, Alan Stern пише:
> > On Thu, 3 May 2018, Nazar Mokrynskyi wrote:
> >
> >> 03.05.18 22:16, Alan Stern пише:
> >>> On Wed, 2 May 2018, Nazar Mokrynskyi wrote:
> >>>
> >>> As far as I know, hubs attached at boot time get initialized and
> >>> handled in exactly the same way as hubs attached afterward.
> >>>
> >>> When a device is connected to a high-speed hub, the hardware in the hub
> >>> is what determines the device's speed.  Not the software in the kernel.  
> >>> The kernel just uses whatever speed the hub says to use.
> >>>
> >>> Have you tried a different brand of hub, to see if it makes any
> >>> difference?
> >>>
> >>> Alan Stern
> >>>
> >> I had the same issue with different USB hub that was integrated into
> >> monitor. It had additional power (current hub doesn't), but I don't
> >> own that monitor anymore (I was using it when reported this issue
> >> initially).
> >>
> >> There is definitely some difference, maybe related to powering USB
> >> port at early stages of boot process, so that USB hub decides to run
> >> devices attached to it at slower speed or something tricky like that.
> > Or maybe it's a noise issue.
> >
> >> I've noticed that after boot manager (GRUB) gives control to Linux it
> >> disconnect USB devices for a short time, but I'm not familiar with
> >> how and why it happens.
> > The kernel has to reset all the attached hardware, because it doesn't 
> > know what state the firmware or boot loader left the devices in.
> >
> > Anyway, perhaps you can work around this problem with a simple script 
> > that is set to run automatically, shortly after the system boots.  The 
> > problem hub is 1-9, right?  So the script needs to do this:
> >
> > echo 0 >/sys/bus/usb/devices/1-9/bConfigurationValue
> > echo 1 >/sys/bus/usb/devices/1-9/bConfigurationValue
> >
> > That will do a soft reinit of the hub and all the devices attached to
> > it.  Hopefully the reinitialized sound card will run at high speed.
> >
> > Alan Stern
> 
> Interestingly, soft reinit doesn't change anything. Sound card is again 
> initialized at full-speed instead of high-speed.
> 
> Here is some more information about hub and its devices specifically 
> (including soft reinitialization): https://pastebin.com/DDgnWMQq

You can try using the usbreset program from here:

https://marc.info/?l=linux-usb=144820655510812=2

That program wants the usbfs pathname of the hub instead of the sysfs 
path.  So you would call it with

usbreset /dev/bus/usb/001/DDD

where DDD is the hub's device number.  You can get this number by 
reading the /sys/bus/usb/devices/1-0/devnum file, but the value has to 
be zero-padded to three digits.

The usbreset program will send a bus reset to the hub, which is 
stronger than a soft reinit but not as strong as unplugging it and then 
plugging it back in.

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: [RFC PATCH 1/7] usb: typec: Generalize mux mode names

[Heikki Krogerus]

On Wed, May 02, 2018 at 03:13:44PM +0200, Mats Karrman wrote:
> Hi Heikki,
> 
> On 2018-05-02 10:25, Heikki Krogerus wrote:
> 
> > On Wed, May 02, 2018 at 11:23:35AM +0300, Heikki Krogerus wrote:
> > > Hi Mats,
> > > 
> > > On Wed, May 02, 2018 at 12:21:07AM +0200, Mats Karrman wrote:
> > > > The current naming used for tcpc_mux_mode constants makes
> > > > too much assumptioms about the usage of the signals.
> > > > This patch replaces the names with generic names more closely
> > > > tied to the Type-C specifications and also adds some new ones.
> > > > At the same time TCPC_MUX_* defines are removed as they do not
> > > > fit the new concept and currently have no in-tree users.
> > > I'm afraid trying to generalize the modal connector states even like
> > > this is not going to work. We can't make any assumptions about how the
> > > alternate modes configure the pins, or the connector in general.
> > > 
> > > The only way this will work is that every alternate mode has its own
> > > configurations defined separately, and I'm talking about the actual
> > > pin configurations that the specifications for each alternate mode
> > > defines, so something like TYPEC_MUX_DP and TYPEC_MUX_DOCK will not
> > > work for sure.
> > > 
> > > The connector states that are defined in USB Type-C specification (so
> > > basically USB Operation and USB Safe State) can be generalized, but
> > > those states just should not be defined in tcpm.h. We need to use
> > > them in other drivers as well.
> > > 
> > > I'm in the middle of preparing more complete support for alternate
> > > modes. If you check the RFC [1] I send previously, in the first patch
> > > of the series I'm adding documentation that should explain the
> > > plan.
> > Sorry, I forgot the link:
> > 
> > [1] https://www.spinics.net/lists/linux-usb/msg166520.html
> 
> Oh, sorry I forgot about that post in the first place... I reread it now.
> 
> Since the modal TYPEC_STATE_ are overlapping for each AM, this means that
> the mux driver "set" must know which AM is active, right?
> 
> And each mux driver also need to support all possible alt modes?

There are two options for the mux drivers to link with the alternate
modes. They can use the typec API where a single mux is linked to a
single port. Alternatively they can use the notifiers from the
alternate modes themselves, which allows a single mux to be liked to
multiple alternate modes. Both methods will be available.

Is this what you were asking?

> I was thinking that it must be a finite number of possible routes
> between the local connections of a mux and the four available SS lanes of
> the cable but of course there is no theoretical limit to the number of
> local connections...
> 
> Do we want to set a limitation of one mux device per port? I guess we
> could and then let people write "composite" mux drivers if it should ever
> be necessary.

I think I answered to this one above.

> Still it's difficult to write a mux device driver that support everything,
> but I'm thinking that it might be possible to write a "mode agnostic" mux
> driver that uses properties to match the "AM:STATE" pairs the board needs
> to support to the hardware mux device specific muxing modes available?
> 
> It would be very interesting to see a devicetree example on how you
> picture things being connected to each other.
> 
> Btw. You're using "mode" and "state" interchangeably which is a bit
> confusing. Could you settle for one?

OK, I'll try to be more consistent and pick one.


Thanks,

-- 
heikki
--
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: ehci-usb regression on 32-bit laptops in v4.17-rc1

[Alan Stern]

You should have CC'ed the author of the offending commit.  Added.

On Thu, 3 May 2018, Erick Cafferata wrote:

> Starting from v4.17-rc1, I've been having problems with my laptop's
> webcam. Immediately after attempting to open Guvcview(or any other camera
> software), the system just stops working. No response from any input and
> the Caps lock LED starts blinking.
> I've been following the last three -rc and no changes, so I started
> testing on my own. I bisected it back to
> 
> commit 22072e83ebd510fb6a090aef9d65ccfda9b1e7e4
> Author: Souptick Joarder 
> Date:   Wed Feb 14 23:18:48 2018 +0530
> 
> usb: host: ehci: Use dma_pool_zalloc()
> 
> Use dma_pool_zalloc() instead of dma_pool_alloc + memset
> 
> I tried reverting it on top of -rc3 and everything worked again.
> I test this bug on four machines:
> - 2 hp mini 210(atom n450 and n2800, respectively)
> - 1 Sony Vaio (Core 2 Duo T7250)
> - 1 Thinkpad T410 (some core i7..)
> The three 32-bit laptops presented the exact same bug, however the
> Thinkpad did not crash (the driver didn't create the /dev/videoN at
> all, I think this might be a different issue, so disregard).
> And reverting this commit solved the issue in all three laptops.
> 
> Let me know if you need any further information regarding this issue.
> Sincerely,
> Erick Cafferata

Right you are!  I should never have approved that patch in the first 
place.  :-(

> commit d3c88476223b51d2a0a1bc2326760c0dcb6efd88
> Author: Erick Cafferata 
> Date:   Wed May 2 11:13:32 2018 -0500
> 
> Revert "usb: host: ehci: Use dma_pool_zalloc()"
> 
> This reverts commit 22072e83ebd510fb6a090aef9d65ccfda9b1e7e4.
> 
> diff --git a/drivers/usb/host/ehci-mem.c b/drivers/usb/host/ehci-mem.c
> index 4c6c08b675b5..21307d862af6 100644
> --- a/drivers/usb/host/ehci-mem.c
> +++ b/drivers/usb/host/ehci-mem.c
> @@ -73,9 +73,10 @@ static struct ehci_qh *ehci_qh_alloc (struct ehci_hcd 
> *ehci, gfp_t flags)
>   if (!qh)
>   goto done;
>   qh->hw = (struct ehci_qh_hw *)
> - dma_pool_zalloc(ehci->qh_pool, flags, );
> + dma_pool_alloc(ehci->qh_pool, flags, );
>   if (!qh->hw)
>   goto fail;
> + memset(qh->hw, 0, sizeof *qh->hw);

In fact, this part was okay.  It does not need to be reverted.

>   qh->qh_dma = dma;
>   // INIT_LIST_HEAD (>qh_list);
>   INIT_LIST_HEAD (>qtd_list);
> diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> index 28e2a338b481..e56db44708bc 100644
> --- a/drivers/usb/host/ehci-sched.c
> +++ b/drivers/usb/host/ehci-sched.c
> @@ -1287,7 +1287,7 @@ itd_urb_transaction(
>   } else {
>   alloc_itd:
>   spin_unlock_irqrestore(>lock, flags);
> - itd = dma_pool_zalloc(ehci->itd_pool, mem_flags,
> + itd = dma_pool_alloc(ehci->itd_pool, mem_flags,
>   _dma);
>   spin_lock_irqsave(>lock, flags);
>   if (!itd) {
> @@ -1297,6 +1297,7 @@ itd_urb_transaction(
>   }
>   }
>  
> + memset(itd, 0, sizeof(*itd));
>   itd->itd_dma = itd_dma;
>   itd->frame = NO_FRAME;
>   list_add(>itd_list, >td_list);
> @@ -2080,7 +2081,7 @@ sitd_urb_transaction(
>   } else {
>   alloc_sitd:
>   spin_unlock_irqrestore(>lock, flags);
> - sitd = dma_pool_zalloc(ehci->sitd_pool, mem_flags,
> + sitd = dma_pool_alloc(ehci->sitd_pool, mem_flags,
>   _dma);
>   spin_lock_irqsave(>lock, flags);
>   if (!sitd) {
> @@ -2090,6 +2091,7 @@ sitd_urb_transaction(
>   }
>   }
>  
> + memset(sitd, 0, sizeof(*sitd));
>   sitd->sitd_dma = sitd_dma;
>   sitd->frame = NO_FRAME;
>   list_add(>sitd_list, _sched->td_list);

But these parts were definitely wrong.

What you can't see just from reading the patch is that in both cases
(ehci->itd_pool and ehci->sitd_pool) there are two allocation paths --
the two branches of an "if" statement -- and only one of the paths
calls dma_pool_[z]alloc.  However, the memset is needed for both paths, 
and so it can't be eliminated.  Given that it must be present, there's 
no advantage to calling dma_pool_zalloc rather than dma_pool_alloc.

Can you try reverting just these portions while leaving the first part 
unchanged?

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

[TESTPATCH] xhci: Fix perceived dead host due to runtime suspend race with event handler

[Mathias Nyman]

Don't rely on event interrupt (EINT) bit alone to detect pending port
change in resume. If no change event is detected the host may be suspended
again, oterwise roothubs are resumed.

There is a lag in xHC setting EINT. If we don't notice the pending change
in resume, and the controller is runtime suspeded again, it causes the
event handler to assume host is dead as it will fail to read xHC registers
once PCI puts the controller to D3 state.

[  268.520969] xhci_hcd: xhci_resume: starting port polling.
[  268.520985] xhci_hcd: xhci_hub_status_data: stopping port polling.
[  268.521030] xhci_hcd: xhci_suspend: stopping port polling.
[  268.521040] xhci_hcd: // Setting command ring address to 0x349bd001
[  268.521139] xhci_hcd: Port Status Change Event for port 3
[  268.521149] xhci_hcd: resume root hub
[  268.521163] xhci_hcd: port resume event for port 3
[  268.521168] xhci_hcd: xHC is not running.
[  268.521174] xhci_hcd: handle_port_status: starting port polling.
[  268.596322] xhci_hcd: xhci_hc_died: xHCI host controller not responding, 
assume dead

The EINT lag is described in a additional note in xhci specs 4.19.2:

"Due to internal xHC scheduling and system delays, there will be a lag
between a change bit being set and the Port Status Change Event that it
generated being written to the Event Ring. If SW reads the PORTSC and
sees a change bit set, there is no guarantee that the corresponding Port
Status Change Event has already been written into the Event Ring."

Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 37 ++---
 drivers/usb/host/xhci.h |  4 
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9b27798..7c4ba4f 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -844,6 +844,38 @@ static void xhci_disable_port_wake_on_bits(struct xhci_hcd 
*xhci)
spin_unlock_irqrestore(>lock, flags);
 }
 
+static bool xhci_pending_portevent(struct xhci_hcd *xhci)
+{
+   int port_index;
+   u32 status;
+   u32 portsc;
+
+   status = readl(>op_regs->status);
+   if (status & STS_EINT)
+   return true;
+   /*
+* Checking STS_EINT is not enough as there is a lag between a change
+* bit being set and the Port Status Change Event that it generated
+* being written to the Event Ring. See note in xhci 1.1 section 4.19.2.
+*/
+
+   port_index = xhci->num_usb2_ports;
+   while (port_index--) {
+   portsc = readl(xhci->usb2_ports[port_index]);
+   if (portsc & PORT_CHANGE_MASK ||
+   (portsc & PORT_PLS_MASK) == XDEV_RESUME)
+   return true;
+   }
+   port_index = xhci->num_usb3_ports;
+   while (port_index--) {
+   portsc = readl(xhci->usb3_ports[port_index]);
+   if (portsc & PORT_CHANGE_MASK ||
+   (portsc & PORT_PLS_MASK) == XDEV_RESUME)
+   return true;
+   }
+   return false;
+}
+
 /*
  * Stop HC (not bus-specific)
  *
@@ -945,7 +977,7 @@ EXPORT_SYMBOL_GPL(xhci_suspend);
  */
 int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
 {
-   u32 command, temp = 0, status;
+   u32 command, temp = 0;
struct usb_hcd  *hcd = xhci_to_hcd(xhci);
struct usb_hcd  *secondary_hcd;
int retval = 0;
@@ -1069,8 +1101,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
  done:
if (retval == 0) {
/* Resume root hubs only when have pending events. */
-   status = readl(>op_regs->status);
-   if (status & STS_EINT) {
+   if (xhci_pending_portevent(xhci)) {
usb_hcd_resume_root_hub(xhci->shared_hcd);
usb_hcd_resume_root_hub(hcd);
}
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 6dfc486..9751c13 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -382,6 +382,10 @@ struct xhci_op_regs {
 #define PORT_PLC   (1 << 22)
 /* port configure error change - port failed to configure its link partner */
 #define PORT_CEC   (1 << 23)
+#define PORT_CHANGE_MASK   (PORT_CSC | PORT_PEC | PORT_WRC | PORT_OCC | \
+PORT_RC | PORT_PLC | PORT_CEC)
+
+
 /* Cold Attach Status - xHC can set this bit to report device attached during
  * Sx state. Warm port reset should be perfomed to clear this bit and move port
  * to connected state.
-- 
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

Re: USB regression for Android phone and sound card in 4.14

[Nazar Mokrynskyi]

03.05.18 23:20, Alan Stern пише:
> On Thu, 3 May 2018, Nazar Mokrynskyi wrote:
>
>> 03.05.18 22:16, Alan Stern пише:
>>> On Wed, 2 May 2018, Nazar Mokrynskyi wrote:
>>>
>>> As far as I know, hubs attached at boot time get initialized and
>>> handled in exactly the same way as hubs attached afterward.
>>>
>>> When a device is connected to a high-speed hub, the hardware in the hub
>>> is what determines the device's speed.  Not the software in the kernel.  
>>> The kernel just uses whatever speed the hub says to use.
>>>
>>> Have you tried a different brand of hub, to see if it makes any
>>> difference?
>>>
>>> Alan Stern
>>>
>> I had the same issue with different USB hub that was integrated into
>> monitor. It had additional power (current hub doesn't), but I don't
>> own that monitor anymore (I was using it when reported this issue
>> initially).
>>
>> There is definitely some difference, maybe related to powering USB
>> port at early stages of boot process, so that USB hub decides to run
>> devices attached to it at slower speed or something tricky like that.
> Or maybe it's a noise issue.
>
>> I've noticed that after boot manager (GRUB) gives control to Linux it
>> disconnect USB devices for a short time, but I'm not familiar with
>> how and why it happens.
> The kernel has to reset all the attached hardware, because it doesn't 
> know what state the firmware or boot loader left the devices in.
>
> Anyway, perhaps you can work around this problem with a simple script 
> that is set to run automatically, shortly after the system boots.  The 
> problem hub is 1-9, right?  So the script needs to do this:
>
>   echo 0 >/sys/bus/usb/devices/1-9/bConfigurationValue
>   echo 1 >/sys/bus/usb/devices/1-9/bConfigurationValue
>
> That will do a soft reinit of the hub and all the devices attached to
> it.  Hopefully the reinitialized sound card will run at high speed.
>
> Alan Stern

Interestingly, soft reinit doesn't change anything. Sound card is again 
initialized at full-speed instead of high-speed.

Here is some more information about hub and its devices specifically (including 
soft reinitialization): https://pastebin.com/DDgnWMQq

Sincerely, Nazar Mokrynskyi
github.com/nazar-pc

--
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 v3 2/2] usb: misc: xapea00x: perform platform initialization of TPM

[David R. Bild]

Normally the system platform (i.e., BIOS/UEFI for x86) is responsible
for performing initialization of the TPM.  For these modules, the host
kernel is the platform, so we perform the initialization in the driver
before registering the TPM with the kernel TPM subsystem.

The initialization consists of issuing the TPM startup command,
running the TPM self-test, and setting the TPM platform hierarchy
authorization to a random, unsaved value so that it can never be used
after the driver has loaded.

Signed-off-by: David R. Bild 
---
 drivers/usb/misc/xapea00x/Makefile|   3 +-
 drivers/usb/misc/xapea00x/xapea00x-core.c |  25 +
 drivers/usb/misc/xapea00x/xapea00x-tpm.c  | 952 ++
 3 files changed, 979 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c

diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
index c4bcd7524c31..aa3f8803cdf5 100644
--- a/drivers/usb/misc/xapea00x/Makefile
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -4,4 +4,5 @@
 #
 obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
 
-xapea00x-y += xapea00x-core.o xapea00x-bridge.o
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o xapea00x-tpm.o
+
diff --git a/drivers/usb/misc/xapea00x/xapea00x-core.c 
b/drivers/usb/misc/xapea00x/xapea00x-core.c
index 885bcda9c01d..53e82f8b38f3 100644
--- a/drivers/usb/misc/xapea00x/xapea00x-core.c
+++ b/drivers/usb/misc/xapea00x/xapea00x-core.c
@@ -280,6 +280,31 @@ static void xapea00x_tpm_probe(struct work_struct *work)
struct spi_device *tpm;
int retval;
 
+   mutex_lock(>usb_mutex);
+   if (!dev->interface) {
+   retval = -ENODEV;
+   goto out;
+   }
+   /*
+* This driver is the "platform" in TPM terminology. Before
+* passing control of the TPM to the Linux TPM subsystem, do
+* the TPM initialization normally done by the platform code
+* (e.g., BIOS).
+*/
+   retval = xapea00x_tpm_platform_initialize(dev);
+   if (retval) {
+   dev_err(>interface->dev,
+   "unable to do TPM platform initialization: %d\n",
+   retval);
+   goto err;
+   }
+
+   /*
+* Now register the TPM with the Linux TPM subsystem.  This
+* may call through to xapea00x_spi_transfer_one_message(), so
+* don't hold usb_mutex here.
+*/
+   mutex_unlock(>usb_mutex);
tpm = spi_new_device(spi_master, _board_info);
mutex_lock(>usb_mutex);
if (!dev->interface) {
diff --git a/drivers/usb/misc/xapea00x/xapea00x-tpm.c 
b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
new file mode 100644
index ..27159043ce3c
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-tpm.c
@@ -0,0 +1,952 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017-2018 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define TPM_RETRY  50
+#define TPM_TIMEOUT5// msecs
+#define TPM_TIMEOUT_RANGE_US   300  // usecs
+
+#define TIS_SHORT_TIMEOUT  750  // msecs
+#define TIS_LONG_TIMEOUT   2000 // msecs
+
+#define TIS_MAX_BUF1024 // byte
+#define TIS_HEADER_LEN 10   // byte
+
+#define TPM2_TIMEOUT_A 750  // msecs
+#define TPM2_TIMEOUT_B 2000 // msecs
+#define TPM2_TIMEOUT_C 200  // msecs
+#define TPM2_TIMEOUT_D 30   // msecs
+
+#define TPM_ACCESS_0   0x
+#define TPM_STS_0  0x0018
+#define TPM_DATA_FIFO_00x0024
+
+#define TPM2_ST_NO_SESSIONS0x8001
+#define TPM2_ST_SESSIONS   0x8002
+
+#define TPM2_CC_STARTUP0x0144
+#define TPM2_CC_SHUTDOWN   0x0145
+#define TPM2_CC_SELF_TEST  0x0143
+#define TPM2_CC_GET_RANDOM 0x017B
+#define TPM2_CC_HIERARCHY_CHANGE_AUTH  0x0129
+#define TPM2_CC_DICT_ATTACK_LOCK_RST   0x0139
+
+#define TPM_RC_SUCCESS 0x000
+#define TPM_RC_INITIALIZE  0x100
+
+enum tis_access {
+   TPM_ACCESS_VALID= 0x80,
+   TPM_ACCESS_ACTIVE_LOCALITY  = 0x20,
+   TPM_ACCESS_REQUEST_PENDING  = 0x04,
+   TPM_ACCESS_REQUEST_USE  = 0x02
+};
+
+enum tis_status {
+   TPM_STS_VALID   = 0x80,
+   TPM_STS_COMMAND_READY   = 0x40,
+   TPM_STS_GO  = 0x20,
+   TPM_STS_DATA_AVAIL  = 0x10,
+   TPM_STS_DATA_EXPECT = 0x08,
+   TPM_STS_SELF_TEST_DONE  = 0x04,
+   TPM_STS_RESPONSE_RETRY  = 0x02
+};
+
+struct tpm_tis_command {
+   __be16 tag;
+   __be32 size;
+   __be32 code;
+   u8 body[0];
+} __attribute__((__packed__));
+

[PATCH v3 0/2] Add driver for Xaptum ENF Access card (XAP-EA-00x)

[David R. Bild]

This series add a driver for the Xaptum ENF Access card line
(XAP-EA-00x), a series of mini PCI-e cards containing a TPM 2.0 chip
used to authenticate IoT devices and gateways.

The hardware is essentially a USB-SPI bridge and an SPI TPM 2.0
chip. The first patch registers the bridge as an SPI controller and
the TPM as an SPI device. The second patch performs the TPM platform
initialization that would normally be done by the BIOS.

The TPM portions need review from the TPM maintainers, before Greg can
accept it in the USB tree.

Changes since v2:
 * Depend on (not select) SPI and TPM support
 * Remove noisy logging
 * Do not explicitly specify MODULE_ALIAS
 * Use KBUILD_MODNAME macro for module name
 * Clean up formatting & indentation

David R. Bild (2):
  usb: misc: xapea00x: add driver for Xaptum ENF Access Card
  usb: misc: xapea00x: perform platform initialization of TPM

 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  14 +
 drivers/usb/misc/xapea00x/Makefile  |   8 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 380 +++
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 433 +
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 196 ++
 drivers/usb/misc/xapea00x/xapea00x-tpm.c| 952 
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +++
 10 files changed, 2067 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-tpm.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

-- 
2.16.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 v3 1/2] usb: misc: xapea00x: add driver for Xaptum ENF Access Card

[David R. Bild]

This commit adds a driver for the Xaptum ENF Access Card, a TPM2.0
hardware module for authenticating IoT devices and gateways.

The card consists of a SPI TPM 2.0 chip and a USB-SPI bridge. This
driver configures the bridge, registers the bridge as an SPI
controller, and adds the TPM 2.0 as an SPI device.  The in-kernel TPM
2.0 driver is then automatically loaded to configure the TPM and
expose it to userspace.

Signed-off-by: David R. Bild 
---
 MAINTAINERS |   6 +
 drivers/usb/misc/Kconfig|   2 +
 drivers/usb/misc/Makefile   |   1 +
 drivers/usb/misc/xapea00x/Kconfig   |  14 +
 drivers/usb/misc/xapea00x/Makefile  |   7 +
 drivers/usb/misc/xapea00x/xapea00x-bridge.c | 380 ++
 drivers/usb/misc/xapea00x/xapea00x-core.c   | 408 
 drivers/usb/misc/xapea00x/xapea00x-spi.c| 196 +
 drivers/usb/misc/xapea00x/xapea00x.h|  75 +
 9 files changed, 1089 insertions(+)
 create mode 100644 drivers/usb/misc/xapea00x/Kconfig
 create mode 100644 drivers/usb/misc/xapea00x/Makefile
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-bridge.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-core.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x-spi.c
 create mode 100644 drivers/usb/misc/xapea00x/xapea00x.h

diff --git a/MAINTAINERS b/MAINTAINERS
index b1ccabd0dbc3..77d35444ef1c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14796,6 +14796,12 @@ L: linux-wirel...@vger.kernel.org
 S: Maintained
 F: drivers/net/wireless/rndis_wlan.c
 
+USB XAPEA00X DRIVER
+M: David R. Bild 
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/misc/xapea00x/
+
 USB XHCI DRIVER
 M: Mathias Nyman 
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/misc/Kconfig b/drivers/usb/misc/Kconfig
index 68d2f2cd17dd..747d7f03fb84 100644
--- a/drivers/usb/misc/Kconfig
+++ b/drivers/usb/misc/Kconfig
@@ -275,3 +275,5 @@ config USB_CHAOSKEY
 
  To compile this driver as a module, choose M here: the
  module will be called chaoskey.
+
+source "drivers/usb/misc/xapea00x/Kconfig"
diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
index 109f54f5b9aa..f3583501547c 100644
--- a/drivers/usb/misc/Makefile
+++ b/drivers/usb/misc/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_USB_HSIC_USB4604)+= usb4604.o
 obj-$(CONFIG_USB_CHAOSKEY) += chaoskey.o
 
 obj-$(CONFIG_USB_SISUSBVGA)+= sisusbvga/
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x/
 obj-$(CONFIG_USB_LINK_LAYER_TEST)  += lvstest.o
diff --git a/drivers/usb/misc/xapea00x/Kconfig 
b/drivers/usb/misc/xapea00x/Kconfig
new file mode 100644
index ..bea57c8cca53
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Kconfig
@@ -0,0 +1,14 @@
+config USB_XAPEA00X
+   tristate "Xaptum ENF Access card support (XAP-EA-00x)"
+   depends on USB_SUPPORT && SPI && TCG_TPM
+   select TCG_TIS_SPI
+   help
+ Say Y here if you want to support the Xaptum ENF Access
+ modules (XAP-EA-00x) in the USB or Mini PCI-e form
+ factors. The XAP-EA-00x module exposes a TPM 2.0 as
+ /dev/tpmX to use for authenticating with the Xaptum ENF.
+
+ To compile this driver as a module, choose M here. The
+ module will be called xapea00x.
+
+ If unsure, say M.
diff --git a/drivers/usb/misc/xapea00x/Makefile 
b/drivers/usb/misc/xapea00x/Makefile
new file mode 100644
index ..c4bcd7524c31
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Makefile for the xapea00x driver.
+#
+obj-$(CONFIG_USB_XAPEA00X) += xapea00x.o
+
+xapea00x-y += xapea00x-core.o xapea00x-bridge.o
diff --git a/drivers/usb/misc/xapea00x/xapea00x-bridge.c 
b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
new file mode 100644
index ..7071431dea96
--- /dev/null
+++ b/drivers/usb/misc/xapea00x/xapea00x-bridge.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ *  Driver for the XAP-EA-00x series of the Xaptum Edge Access Card, a
+ *  TPM 2.0-based hardware module for authenticating IoT devices and
+ *  gateways.
+ *
+ *  Copyright (c) 2017-2018 Xaptum, Inc.
+ */
+
+#include "xapea00x.h"
+
+#define XAPEA00X_BR_CMD_READ   0x00
+#define XAPEA00X_BR_CMD_WRITE  0x01
+#define XAPEA00X_BR_CMD_WRITEREAD  0x02
+
+#define XAPEA00X_BR_BREQTYP_SET0x40
+
+#define XAPEA00X_BR_BREQ_SET_GPIO_VALUES   0x21
+#define XAPEA00X_BR_BREQ_SET_GPIO_CS   0x25
+#define XAPEA00X_BR_BREQ_SET_SPI_WORD  0x31
+
+#define XAPEA00X_BR_USB_TIMEOUT1000 // msecs
+
+#define XAPEA00X_BR_CS_DISABLED0x00
+
+/***
+ * Bridge 

Re: Since Linux 4.13 tlp or powertop usage cause "xHCI host controller not responding, assume dead" on Dell 5855

[Mathias Nyman]

On 03.05.2018 21:56, Alan Stern wrote:

On Thu, 3 May 2018, Mathias Nyman wrote:


When everything is runtime suspended and start system suspend, we first suspend 
all
the usb devices, including the roothubs calling choose_wakeup() for the 
roothubs.
No flags are set yet. When pm continues suspending, and tries to suspend the 
xhci PCI
controller the PCI suspend code notices the device is runtime suspended,
it resumes it -> xhci_resume() -> usb_hcd_resume_root_hub() and WAKEUP_PENDING 
flag is set.
When PCI code then continues and tries to suspend the pci device it fails 
because the flag is set.


Okay, I get the picture.  And I just spent some time going over the
core code and some of the other drivers.

So yes, what I said earlier was wrong.  The existing code in
xhci_resume() is more or less correct; it should call
usb_hcd_resume_root_hub() _only_ when there is a pending wakeup request
from the root hub or a downstream device.

Earlier you wrote:


If the check fails, then WAKEUP_PENDING bit is not set, and runtime PM
can suspend host controller again. when xhci driver finally gets to handle the 
interrupt
the controller may be in D3 already

This should only happen if xhci_resume() is called before xhci driver sees a 
pending interrupt,
could be possible as xhci has interrupt moderation enabled.


This is the real problem.  You need to make sure that even with
interrupt moderation, if there is a pending wakeup request then you can
detect it properly.  In other words, xhci_resume() may need to
explicitly check the root-hub port statuses, because it can't rely on
the interrupt handler to inform it that a wakeup request has been
received.

Does that make sense?



It does, thanks
I'll write a testpatch that checks changes for ports in xhci_resume()

-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

Hello

[Faruk Sakawo]

I have a business to discuss with you, can we talk?


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

Re: [PATCH 2/2] xhci: hisilicon: support HiSilicon STB xHCI host controller

[Jianguo Sun]

Hi Chunfeng,

I forgot to assign the value of xhci->imod_interval.
Will add it in v2 patch. Thanks.

On 05/04/2018 05:59 PM, Chunfeng Yun wrote:

Hi Jianguo,

On Fri, 2018-05-04 at 17:20 +0800, sunj...@163.com wrote:

From: Jianguo Sun 

This commit adds support for HiSilicon STB xHCI host controller.

Signed-off-by: Jianguo Sun 
---
  drivers/usb/host/Kconfig  |   7 +
  drivers/usb/host/Makefile |   1 +
  drivers/usb/host/xhci-histb.c | 409 ++
  3 files changed, 417 insertions(+)
  create mode 100644 drivers/usb/host/xhci-histb.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5d958da..c813fc4 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -52,6 +52,13 @@ config USB_XHCI_PLATFORM
  
  	  If unsure, say N.
  
+config USB_XHCI_HISTB

+   tristate "xHCI support for HiSilicon STB SoCs"
+   depends on USB_XHCI_PLATFORM && (ARCH_HISI || COMPILE_TEST)
+   help
+ Say 'Y' to enable the support for the xHCI host controller
+ found in HiSilicon STB SoCs.
+
  config USB_XHCI_MTK
tristate "xHCI support for MediaTek SoCs"
select MFD_SYSCON
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 8a8cffe..9b669c9 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_USB_FHCI_HCD)+= fhci.o
  obj-$(CONFIG_USB_XHCI_HCD)+= xhci-hcd.o
  obj-$(CONFIG_USB_XHCI_PCI)+= xhci-pci.o
  obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_HISTB)   += xhci-histb.o
  obj-$(CONFIG_USB_XHCI_MTK)+= xhci-mtk.o
  obj-$(CONFIG_USB_XHCI_TEGRA)  += xhci-tegra.o
  obj-$(CONFIG_USB_SL811_HCD)   += sl811-hcd.o
diff --git a/drivers/usb/host/xhci-histb.c b/drivers/usb/host/xhci-histb.c
new file mode 100644
index 000..5ec549f
--- /dev/null
+++ b/drivers/usb/host/xhci-histb.c
@@ -0,0 +1,409 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * xHCI host controller driver for HiSilicon STB SoCs
+ *
+ * Copyright (C) 2017-2018 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Authors: Jianguo Sun 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.

No need anymore if SPDX-License-Identifier is provided

+ */
+
+#include 
+#include 
+#include 
+#include 

Not used

+#include 
+#include 
+#include 
+#include 
+#include 

ditto

+#include 
+
+#include "xhci.h"
+
+#define GTXTHRCFG  0xc108
+#define GRXTHRCFG  0xc10c
+#define REG_GUSB2PHYCFG0   0xc200
+#define BIT_UTMI_8_16  BIT(3)
+#define BIT_UTMI_ULPI  BIT(4)
+#define BIT_FREECLK_EXIST  BIT(30)
+
+#define REG_GUSB3PIPECTL0  0xc2c0
+#define USB3_DEEMPHASIS_MASK   GENMASK(2, 1)
+#define USB3_DEEMPHASIS0   BIT(1)
+#define USB3_TX_MARGIN1BIT(4)
+
+struct xhci_hcd_histb {
+   struct device   *dev;
+   struct usb_hcd  *hcd;
+   void __iomem*ctrl;
+   struct clk  *bus_clk;
+   struct clk  *utmi_clk;
+   struct clk  *pipe_clk;
+   struct clk  *suspend_clk;
+   struct reset_control*soft_reset;
+};
+
+static inline struct xhci_hcd_histb *hcd_to_histb(struct usb_hcd *hcd)
+{
+   return dev_get_drvdata(hcd->self.controller);
+}
+
+static int xhci_histb_config(struct xhci_hcd_histb *histb)
+{
+   struct device_node *np = histb->dev->of_node;
+   u32 regval;
+
+   if (of_property_match_string(np, "phys-names", "inno") >= 0) {
+   /* USB2 PHY chose ulpi 8bit interface */
+   regval = readl(histb->ctrl + REG_GUSB2PHYCFG0);
+   regval &= ~BIT_UTMI_ULPI;
+   regval &= ~(BIT_UTMI_8_16);
+   regval &= ~BIT_FREECLK_EXIST;
+   writel(regval, histb->ctrl + REG_GUSB2PHYCFG0);
+   }
+
+   if (of_property_match_string(np, "phys-names", "combo") >= 0) {
+   /*
+* write 0x010c0012 to GUSB3PIPECTL0
+* GUSB3PIPECTL0[5:3] = 010 : Tx Margin = 900mV ,
+* decrease TX voltage
+* GUSB3PIPECTL0[2:1] = 01 : Tx Deemphasis = -3.5dB,
+* refer to xHCI spec
+*/
+   regval = readl(histb->ctrl + REG_GUSB3PIPECTL0);
+   regval &= ~USB3_DEEMPHASIS_MASK;
+   regval |= USB3_DEEMPHASIS0;
+   regval |= USB3_TX_MARGIN1;
+   writel(regval, histb->ctrl + REG_GUSB3PIPECTL0);
+   }
+
+   writel(0x2310, histb->ctrl + GTXTHRCFG);
+   writel(0x2310, histb->ctrl + GRXTHRCFG);
+
+   return 0;
+}
+
+static int xhci_histb_clks_get(struct xhci_hcd_histb *histb)
+{
+   struct device *dev = histb->dev;
+
+   histb->bus_clk = devm_clk_get(dev, 

Re: [PATCH 2/2] xhci: hisilicon: support HiSilicon STB xHCI host controller

[Chunfeng Yun]

Hi Jianguo,

On Fri, 2018-05-04 at 17:20 +0800, sunj...@163.com wrote:
> From: Jianguo Sun 
> 
> This commit adds support for HiSilicon STB xHCI host controller.
> 
> Signed-off-by: Jianguo Sun 
> ---
>  drivers/usb/host/Kconfig  |   7 +
>  drivers/usb/host/Makefile |   1 +
>  drivers/usb/host/xhci-histb.c | 409 
> ++
>  3 files changed, 417 insertions(+)
>  create mode 100644 drivers/usb/host/xhci-histb.c
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 5d958da..c813fc4 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -52,6 +52,13 @@ config USB_XHCI_PLATFORM
>  
> If unsure, say N.
>  
> +config USB_XHCI_HISTB
> + tristate "xHCI support for HiSilicon STB SoCs"
> + depends on USB_XHCI_PLATFORM && (ARCH_HISI || COMPILE_TEST)
> + help
> +   Say 'Y' to enable the support for the xHCI host controller
> +   found in HiSilicon STB SoCs.
> +
>  config USB_XHCI_MTK
>   tristate "xHCI support for MediaTek SoCs"
>   select MFD_SYSCON
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 8a8cffe..9b669c9 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -74,6 +74,7 @@ obj-$(CONFIG_USB_FHCI_HCD)  += fhci.o
>  obj-$(CONFIG_USB_XHCI_HCD)   += xhci-hcd.o
>  obj-$(CONFIG_USB_XHCI_PCI)   += xhci-pci.o
>  obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
> +obj-$(CONFIG_USB_XHCI_HISTB) += xhci-histb.o
>  obj-$(CONFIG_USB_XHCI_MTK)   += xhci-mtk.o
>  obj-$(CONFIG_USB_XHCI_TEGRA) += xhci-tegra.o
>  obj-$(CONFIG_USB_SL811_HCD)  += sl811-hcd.o
> diff --git a/drivers/usb/host/xhci-histb.c b/drivers/usb/host/xhci-histb.c
> new file mode 100644
> index 000..5ec549f
> --- /dev/null
> +++ b/drivers/usb/host/xhci-histb.c
> @@ -0,0 +1,409 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * xHCI host controller driver for HiSilicon STB SoCs
> + *
> + * Copyright (C) 2017-2018 HiSilicon Co., Ltd. http://www.hisilicon.com
> + *
> + * Authors: Jianguo Sun 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
No need anymore if SPDX-License-Identifier is provided
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
Not used
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
ditto
> +#include 
> +
> +#include "xhci.h"
> +
> +#define GTXTHRCFG0xc108
> +#define GRXTHRCFG0xc10c
> +#define REG_GUSB2PHYCFG0 0xc200
> +#define BIT_UTMI_8_16BIT(3)
> +#define BIT_UTMI_ULPIBIT(4)
> +#define BIT_FREECLK_EXISTBIT(30)
> +
> +#define REG_GUSB3PIPECTL00xc2c0
> +#define USB3_DEEMPHASIS_MASK GENMASK(2, 1)
> +#define USB3_DEEMPHASIS0 BIT(1)
> +#define USB3_TX_MARGIN1  BIT(4)
> +
> +struct xhci_hcd_histb {
> + struct device   *dev;
> + struct usb_hcd  *hcd;
> + void __iomem*ctrl;
> + struct clk  *bus_clk;
> + struct clk  *utmi_clk;
> + struct clk  *pipe_clk;
> + struct clk  *suspend_clk;
> + struct reset_control*soft_reset;
> +};
> +
> +static inline struct xhci_hcd_histb *hcd_to_histb(struct usb_hcd *hcd)
> +{
> + return dev_get_drvdata(hcd->self.controller);
> +}
> +
> +static int xhci_histb_config(struct xhci_hcd_histb *histb)
> +{
> + struct device_node *np = histb->dev->of_node;
> + u32 regval;
> +
> + if (of_property_match_string(np, "phys-names", "inno") >= 0) {
> + /* USB2 PHY chose ulpi 8bit interface */
> + regval = readl(histb->ctrl + REG_GUSB2PHYCFG0);
> + regval &= ~BIT_UTMI_ULPI;
> + regval &= ~(BIT_UTMI_8_16);
> + regval &= ~BIT_FREECLK_EXIST;
> + writel(regval, histb->ctrl + REG_GUSB2PHYCFG0);
> + }
> +
> + if (of_property_match_string(np, "phys-names", "combo") >= 0) {
> + /*
> +  * write 0x010c0012 to GUSB3PIPECTL0
> +  * GUSB3PIPECTL0[5:3] = 010 : Tx Margin = 900mV ,
> +  * decrease TX voltage
> +  * GUSB3PIPECTL0[2:1] = 01 : Tx Deemphasis = -3.5dB,
> +  * refer to xHCI spec
> +  */
> + regval = readl(histb->ctrl + REG_GUSB3PIPECTL0);
> + regval &= ~USB3_DEEMPHASIS_MASK;
> + regval |= USB3_DEEMPHASIS0;
> + regval |= USB3_TX_MARGIN1;
> + writel(regval, histb->ctrl + REG_GUSB3PIPECTL0);
> + }
> +
> + writel(0x2310, histb->ctrl + GTXTHRCFG);
> + writel(0x2310, histb->ctrl + GRXTHRCFG);
> +
> + return 0;
> +}
> +
> +static int xhci_histb_clks_get(struct xhci_hcd_histb *histb)
> +{
> + struct device *dev = histb->dev;
> +
> + histb->bus_clk = 

Re: Kernel Oops when downloading data from a 4G modem connected via USB

[Amr Bekhit]

Thanks for your comments Minas

> Per my understanding in your system EHCI host also available. Is any
> issue seen if connected to EHCI?

It's already connected to EHCI. The hardware has a GL852GT USB hub on
board, which connects to the RK3188 SoC. The Quectel EC25-E is connected to
GL852GT. There is also Realtek 8152B Ethernet controller, also connected to
the USB hub. Below is the output of lsusb -t:

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
  |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M
  |__ Port 1: Dev 3, If 0, Class=, Driver=r8152, 480M
  |__ Port 2: Dev 4, If 0, Class=, Driver=, 480M
  |__ Port 2: Dev 4, If 1, Class=, Driver=, 480M
  |__ Port 2: Dev 4, If 2, Class=, Driver=, 480M
  |__ Port 2: Dev 4, If 3, Class=, Driver=, 480M
  |__ Port 2: Dev 4, If 4, Class=, Driver=qmi_wwan, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M

Dev 3 is the 8152B and Dev 4 are the various interfaces for the EC25-E. The
board has no direct connection to the RK3188's USB pins - the 2 USB
connectors on the board are connected to the hub.

> Actually, I didn't see any evidence which points to dwc2 as root cause
> of Kernel Oops. Transaction errors are accepted from USB spec point of
> view and dwc2 will continue initiated transfers.

It's interesting you mention that. I tried the same download test with wget
but using the 8152B ethernet interface and did not receive any errors or
any dwc2 related messages in the console. I also tried downloading via the
EC25-E but using ppp instead of QMI. Although I did get dwc2 error messages
in the console, I haven't managed to get it to kernel oops. The dmesg log
captured during the ppp download is shown below. It is possible that the
problem not with the dwc2 controller but perhaps the driver for the Quectel
EC25-E and more specifically the qmi driver. However, the dwc2 error
messages that appear in the console makes me wonder whether the dwc2 driver
may have a problem.

PPP DMESG LOG:

[ 1216.892549] dwc2 101c.usb: --Host Channel 2 Interrupt: Transaction
Error--
[ 1216.919671] dwc2 101c.usb: --Host Channel 8 Interrupt: Transaction
Error--
[ 1218.121416] dwc2 101c.usb: --Host Channel 6 Interrupt: Transaction
Error--
[ 1218.288171] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction
Error--
[ 1218.401061] dwc2 101c.usb: --Host Channel 7 Interrupt: Transaction
Error--
[ 1218.494919] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction
Error--
[ 1218.863921] dwc2 101c.usb: --Host Channel 9 Interrupt: Transaction
Error--
[ 1218.915169] dwc2 101c.usb: --Host Channel 1 Interrupt: Transaction
Error--
[ 1219.359796] dwc2 101c.usb: --Host Channel 8 Interrupt: Transaction
Error--
[ 1219.617293] dwc2 101c.usb: --Host Channel 7 Interrupt: Transaction
Error--
[ 1219.708794] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction
Error--
[ 1219.709782] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction
Error--
[ 1219.773417] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction
Error--
[ 1220.304643] dwc2 101c.usb: --Host Channel 9 Interrupt: Transaction
Error--
[ 1220.373295] dwc2 101c.usb: --Host Channel 14 Interrupt: Transaction
Error--
[ 1220.506969] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction
Error--
[ 1220.516428] dwc2 101c.usb: --Host Channel 11 Interrupt: Transaction
Error--
[ 1220.912167] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction
Error--
[ 1221.133070] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction
Error--
[ 1222.510418] dwc2 101c.usb: --Host Channel 11 Interrupt: Transaction
Error--
[ 1222.804179] dwc2 101c.usb: --Host Channel 2 Interrupt: Transaction
Error--
[ 1222.848562] dwc2 101c.usb: --Host Channel 2 Interrupt: Transaction
Error--
[ 1223.458313] dwc2 101c.usb: --Host Channel 8 Interrupt: Transaction
Error--
[ 1223.458381] dwc2 101c.usb: dwc2_hc_chhltd_intr_dma: Channel 1 -
ChHltd set, but reason is unknown
[ 1223.467241] dwc2 101c.usb: hcint 0x0002, intsts 0x04200029
[ 1223.472866] dwc2 101c.usb: --Host Channel 11 Interrupt: Frame
Overrun--
[ 1223.472897] dwc2 101c.usb: --Host Channel 15 Interrupt: Frame
Overrun--
[ 1223.694418] dwc2 101c.usb: --Host Channel 12 Interrupt: Transaction
Error--
[ 1223.939311] dwc2 101c.usb: --Host Channel 10 Interrupt: Transaction
Error--
[ 1223.939382] dwc2 101c.usb: dwc2_hc_chhltd_intr_dma: Channel 12 -
ChHltd set, but reason is unknown
[ 1223.948339] dwc2 101c.usb: hcint 0x0002, intsts 0x04200029
[ 1224.264667] dwc2 101c.usb: --Host Channel 0 Interrupt: Transaction
Error--
[ 1224.415918] dwc2 101c.usb: --Host Channel 15 Interrupt: Transaction
Error--
[ 1224.458296] dwc2 101c.usb: --Host Channel 9 Interrupt: Transaction
Error--
[ 1224.630806] dwc2 101c.usb: --Host Channel 5 Interrupt: Transaction
Error--
[ 1224.637040] dwc2 101c.usb: --Host Channel 10 

[PATCH 1/2] dt-bindings: usb: add bindings doc for HiSilicon STB xHCI host controller

[sunjg79]

From: Jianguo Sun 

This commit adds bindings doc for HiSilicon STB xHCI host controller.

Signed-off-by: Jianguo Sun 
---
 .../bindings/usb/hisilicon,histb-xhci.txt  | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/hisilicon,histb-xhci.txt

diff --git a/Documentation/devicetree/bindings/usb/hisilicon,histb-xhci.txt 
b/Documentation/devicetree/bindings/usb/hisilicon,histb-xhci.txt
new file mode 100644
index 000..628225f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/hisilicon,histb-xhci.txt
@@ -0,0 +1,40 @@
+HiSilicon STB xHCI
+
+The device node for HiSilicon STB xHCI host controller
+
+Required properties:
+ - compatible : should be "hisilicon,hi3798cv200-xhci"
+ - reg : specifies physical base address and size of the registers
+ - interrupts : interrupt used by the controller
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+   entry in clock-names
+ - clock-names : must contain
+   "bus": for bus clock
+   "utmi": for utmi clock
+   "pipe": for pipeE clock
+   "suspend": for suspend clock
+ - resets: a list of phandle and reset specifier pairs as listed in
+   reset-names property.
+ - reset-names: must contain
+   "soft": for soft reset
+ - phys : a list of phandle + phy specifier pairs
+ - phy-names: must contain one of following at least:
+   "inno": for inno phy
+   "combo": for combo phy
+
+Example:
+
+xhci0: xchi@f98a {
+   compatible = "hisilicon,hi3798cv200-xhci";
+   reg = <0xf98a 0x1>;
+   interrupts = ;
+   clocks = < HISTB_USB3_BUS_CLK>,
+< HISTB_USB3_UTMI_CLK>,
+< HISTB_USB3_PIPE_CLK>,
+< HISTB_USB3_SUSPEND_CLK>;
+   clock-names = "bus", "utmi", "pipe", "suspend";
+   resets = < 0xb0 12>;
+   reset-names = "soft";
+   phys = <_phy1_port1 0>, < PHY_TYPE_USB3>;
+   phy-names = "inno", "combo";
+};
-- 
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 2/2] xhci: hisilicon: support HiSilicon STB xHCI host controller

[sunjg79]

From: Jianguo Sun 

This commit adds support for HiSilicon STB xHCI host controller.

Signed-off-by: Jianguo Sun 
---
 drivers/usb/host/Kconfig  |   7 +
 drivers/usb/host/Makefile |   1 +
 drivers/usb/host/xhci-histb.c | 409 ++
 3 files changed, 417 insertions(+)
 create mode 100644 drivers/usb/host/xhci-histb.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 5d958da..c813fc4 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -52,6 +52,13 @@ config USB_XHCI_PLATFORM
 
  If unsure, say N.
 
+config USB_XHCI_HISTB
+   tristate "xHCI support for HiSilicon STB SoCs"
+   depends on USB_XHCI_PLATFORM && (ARCH_HISI || COMPILE_TEST)
+   help
+ Say 'Y' to enable the support for the xHCI host controller
+ found in HiSilicon STB SoCs.
+
 config USB_XHCI_MTK
tristate "xHCI support for MediaTek SoCs"
select MFD_SYSCON
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 8a8cffe..9b669c9 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_USB_FHCI_HCD)+= fhci.o
 obj-$(CONFIG_USB_XHCI_HCD) += xhci-hcd.o
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
 obj-$(CONFIG_USB_XHCI_PLATFORM) += xhci-plat-hcd.o
+obj-$(CONFIG_USB_XHCI_HISTB)   += xhci-histb.o
 obj-$(CONFIG_USB_XHCI_MTK) += xhci-mtk.o
 obj-$(CONFIG_USB_XHCI_TEGRA)   += xhci-tegra.o
 obj-$(CONFIG_USB_SL811_HCD)+= sl811-hcd.o
diff --git a/drivers/usb/host/xhci-histb.c b/drivers/usb/host/xhci-histb.c
new file mode 100644
index 000..5ec549f
--- /dev/null
+++ b/drivers/usb/host/xhci-histb.c
@@ -0,0 +1,409 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * xHCI host controller driver for HiSilicon STB SoCs
+ *
+ * Copyright (C) 2017-2018 HiSilicon Co., Ltd. http://www.hisilicon.com
+ *
+ * Authors: Jianguo Sun 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "xhci.h"
+
+#define GTXTHRCFG  0xc108
+#define GRXTHRCFG  0xc10c
+#define REG_GUSB2PHYCFG0   0xc200
+#define BIT_UTMI_8_16  BIT(3)
+#define BIT_UTMI_ULPI  BIT(4)
+#define BIT_FREECLK_EXIST  BIT(30)
+
+#define REG_GUSB3PIPECTL0  0xc2c0
+#define USB3_DEEMPHASIS_MASK   GENMASK(2, 1)
+#define USB3_DEEMPHASIS0   BIT(1)
+#define USB3_TX_MARGIN1BIT(4)
+
+struct xhci_hcd_histb {
+   struct device   *dev;
+   struct usb_hcd  *hcd;
+   void __iomem*ctrl;
+   struct clk  *bus_clk;
+   struct clk  *utmi_clk;
+   struct clk  *pipe_clk;
+   struct clk  *suspend_clk;
+   struct reset_control*soft_reset;
+};
+
+static inline struct xhci_hcd_histb *hcd_to_histb(struct usb_hcd *hcd)
+{
+   return dev_get_drvdata(hcd->self.controller);
+}
+
+static int xhci_histb_config(struct xhci_hcd_histb *histb)
+{
+   struct device_node *np = histb->dev->of_node;
+   u32 regval;
+
+   if (of_property_match_string(np, "phys-names", "inno") >= 0) {
+   /* USB2 PHY chose ulpi 8bit interface */
+   regval = readl(histb->ctrl + REG_GUSB2PHYCFG0);
+   regval &= ~BIT_UTMI_ULPI;
+   regval &= ~(BIT_UTMI_8_16);
+   regval &= ~BIT_FREECLK_EXIST;
+   writel(regval, histb->ctrl + REG_GUSB2PHYCFG0);
+   }
+
+   if (of_property_match_string(np, "phys-names", "combo") >= 0) {
+   /*
+* write 0x010c0012 to GUSB3PIPECTL0
+* GUSB3PIPECTL0[5:3] = 010 : Tx Margin = 900mV ,
+* decrease TX voltage
+* GUSB3PIPECTL0[2:1] = 01 : Tx Deemphasis = -3.5dB,
+* refer to xHCI spec
+*/
+   regval = readl(histb->ctrl + REG_GUSB3PIPECTL0);
+   regval &= ~USB3_DEEMPHASIS_MASK;
+   regval |= USB3_DEEMPHASIS0;
+   regval |= USB3_TX_MARGIN1;
+   writel(regval, histb->ctrl + REG_GUSB3PIPECTL0);
+   }
+
+   writel(0x2310, histb->ctrl + GTXTHRCFG);
+   writel(0x2310, histb->ctrl + GRXTHRCFG);
+
+   return 0;
+}
+
+static int xhci_histb_clks_get(struct xhci_hcd_histb *histb)
+{
+   struct device *dev = histb->dev;
+
+   histb->bus_clk = devm_clk_get(dev, "bus");
+   if (IS_ERR(histb->bus_clk)) {
+   dev_err(dev, "fail to get bus clk\n");
+   return PTR_ERR(histb->bus_clk);
+   }
+
+   histb->utmi_clk = devm_clk_get(dev, "utmi");
+   if (IS_ERR(histb->utmi_clk)) {
+   dev_err(dev, "fail to get utmi 

[PATCH 0/2] add support for HiSilicon STB xHCI host controller

[sunjg79]

From: Jianguo Sun 

This patch set adds bindings doc and xhci driver for xHCI host controller
on HiSilicon STB SoCs.

Jianguo Sun (2):
  dt-bindings: usb: add bindings doc for HiSilicon STB xHCI host
controller
  xhci: hisilicon: support HiSilicon STB xHCI host controller

 .../bindings/usb/hisilicon,histb-xhci.txt  |  40 ++
 drivers/usb/host/Kconfig   |   7 +
 drivers/usb/host/Makefile  |   1 +
 drivers/usb/host/xhci-histb.c  | 409 +
 4 files changed, 457 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/usb/hisilicon,histb-xhci.txt
 create mode 100644 drivers/usb/host/xhci-histb.c

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

[GIT PULL] USB-serial fixes for v4.17-rc4

[Johan Hovold]

The following changes since commit 6da6c0db5316275015e8cc2959f12a17584aeb64:

  Linux v4.17-rc3 (2018-04-29 14:17:42 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git 
tags/usb-serial-4.17-rc4

for you to fetch changes up to 4842ed5bfcb9daf6660537d70503c18d38dbdbb8:

  USB: serial: visor: handle potential invalid device configuration (2018-05-02 
09:37:19 +0200)


USB-serial fixes for v4.17-rc4

Here's a fix for a long-standing issue in the visor driver, which could
have security implications. Included is also a new modem device id.

Both commits have been in linux-next for a couple of days with no
reported issues.

Signed-off-by: Johan Hovold 


Greg Kroah-Hartman (1):
  USB: serial: visor: handle potential invalid device configuration

SZ Lin (林上智) (1):
  USB: serial: option: adding support for ublox R410M

 drivers/usb/serial/option.c |  5 
 drivers/usb/serial/visor.c  | 69 +++--
 2 files changed, 40 insertions(+), 34 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v5 01/14] dt-bindings: connector: add properties for typec

[Jun Li]

Hi
> -Original Message-
> From: Oliver Neukum [mailto:oneu...@suse.com]
> Sent: 2018年5月3日 17:18
> To: Jun Li ; robh...@kernel.org;
> heikki.kroge...@linux.intel.com; gre...@linuxfoundation.org;
> li...@roeck-us.net
> Cc: gso...@gmail.com; dl-linux-imx ; Peter Chen
> ; shufan_...@richtek.com; a.ha...@samsung.com;
> cw00.c...@samsung.com; devicet...@vger.kernel.org;
> linux-usb@vger.kernel.org
> Subject: Re: [PATCH v5 01/14] dt-bindings: connector: add properties for typec
> 
> Am Donnerstag, den 03.05.2018, 08:35 + schrieb Jun Li:
> > Hi
> > > -Original Message-
> > > From: Oliver Neukum [mailto:oneu...@suse.com]
> > > Sent: 2018年5月3日 15:27
> > > To: Jun Li ; robh...@kernel.org;
> > > heikki.kroge...@linux.intel.com; gre...@linuxfoundation.org;
> > > li...@roeck-us.net
> > > Cc: gso...@gmail.com; dl-linux-imx ; Peter Chen
> > > ; shufan_...@richtek.com;
> a.ha...@samsung.com;
> > > cw00.c...@samsung.com; devicet...@vger.kernel.org;
> > > linux-usb@vger.kernel.org
> > > Subject: Re: [PATCH v5 01/14] dt-bindings: connector: add properties
> > > for typec
> > >
> > > Am Donnerstag, den 03.05.2018, 08:24 +0800 schrieb Li Jun:
> > > > +Optional properties for usb-c-connector:
> > > > +- power-role: should be one of "source", "sink" or "dual"(DRP) if
> > > > +typec
> > > > +  connector has power support.
> > > > +- try-power-role: preferred power role if "dual"(DRP) can support
> > > > +Try.SNK
> > > > +  or Try.SRC, should be "sink" for Try.SNK or "source" for Try.SRC.
> > > > +- data-role: should be one of "host", "device", "dual"(DRD) if
> > > > +typec
> > > > +  connector supports USB data.
> > >
> > > Hi,
> > >
> > > is this really correct?
> > >
> > > Can one implement a device that can operate as either DFP or UFP,
> > > but not implements the dynamic role switch that a DRP must support?
> >
> > You mean a port with DRD on data but not DRP on power?
> >
> > The data-role is newly added as the data role is not coupled with
> > power
> 
> No, I meant data role. As far as I can tell for a DRP you need to implement 
> the
> detection logic described in chapter 4 of the spec.

Could you please point me the "detection logic" of typec spec chapter 4
you are referring to?

> I can see no reason why you couldn't build a port that can be switched between
> the data roles but not implement that logic.

I see there is dr_swap handling for data role swap in tcpm already, maybe
I misunderstood the "logic" you want here.

Regards
Li Jun
 
> 
>   Regards
>   Oliver

[PATCH 0/1] xhci fix for usb-linus

[Mathias Nyman]

Hi Greg

One xhci regression fix for usb-linus.
The original patch went to stable so this needs to be applier there as well.

-Mathias

Mathias Nyman (1):
  xhci: Fix use-after-free in xhci_free_virt_device

 drivers/usb/host/xhci.c | 1 +
 1 file changed, 1 insertion(+)

-- 
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 1/1] xhci: Fix use-after-free in xhci_free_virt_device

[Mathias Nyman]

KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e
where xhci_free_virt_device() sets slot id to 0 if udev exists:
if (dev->udev && dev->udev->slot_id)
dev->udev->slot_id = 0;

dev->udev will be true even if udev is freed because dev->udev is
not set to NULL.

set dev->udev pointer to NULL in xhci_free_dev()

The original patch went to stable so this fix needs to be applied
there as well.

Fixes: a400efe455f7 ("xhci: zero usb device slot_id member when disabling and 
freeing a xhci slot")
Cc: 
Reported-by: Guenter Roeck 
Reviewed-by: Guenter Roeck 
Tested-by: Guenter Roeck 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9b27798..711da33 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3621,6 +3621,7 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct 
usb_device *udev)
del_timer_sync(_dev->eps[i].stop_cmd_timer);
}
xhci_debugfs_remove_slot(xhci, udev->slot_id);
+   virt_dev->udev = NULL;
ret = xhci_disable_slot(xhci, udev->slot_id);
if (ret)
xhci_free_virt_device(xhci, udev->slot_id);
-- 
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