Re: [PATCH v4 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Hi Felipe,

On 27 July 2017 at 13:14, Baolin Wang  wrote:
> Currently the Linux kernel does not provide any standard integration of this
> feature that integrates the USB subsystem with the system power regulation
> provided by PMICs meaning that either vendors must add this in their kernels
> or USB gadget devices based on Linux (such as mobile phones) may not behave
> as they should. Thus provide a standard USB charger support in USB phy core
> for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger.
> In future we will also cnvert below power drivers:
> drivers/power/supply/axp288_charger.c
> drivers/power/supply/bq24190_charger.c
> drivers/power/supply/charger-manager.c
> drivers/power/supply/qcom_smbb.c
>
> Changes since v3:
>  - Bail out errors when failed to find usb phy for wm831x_power driver.
> Changes since v2:
>  - Add DT binding documentation for wm831x_power driver.
>  - Change 'usb-phy' as one optional property for wm831x_power driver.
> Changes since v1:
>  - Fix building errors.

Do you have any comments about usb charger support in usb phy core? Thanks.

>
> Baolin Wang (3):
>   include: uapi: usb: Introduce USB charger type and state definition
>   usb: phy: Add USB charger support
>   power: wm831x_power: Support USB charger current limit management
>
>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>  drivers/power/supply/wm831x_power.c  |   72 ++
>  drivers/usb/phy/phy.c|  272 
> ++
>  include/linux/usb/phy.h  |   49 
>  include/uapi/linux/usb/charger.h |   31 +++
>  5 files changed, 425 insertions(+)
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> --
> 1.7.9.5
>



-- 
Baolin.wang
Best Regards
--
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 4/4] dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file

[Chunfeng Yun]

add support for PCIe and SATA, also add some new compatibles.

due to phy-mt65xx-usb.txt holds the bindings for all mediatek SoCs
with T-PHY controller, change the name to phy-mtk-tphy.txt to
reflect that.

Signed-off-by: Chunfeng Yun 
---
 .../phy/{phy-mt65xx-usb.txt => phy-mtk-tphy.txt}| 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)
 rename Documentation/devicetree/bindings/phy/{phy-mt65xx-usb.txt => 
phy-mtk-tphy.txt} (88%)

diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt 
b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
similarity index 88%
rename from Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
rename to Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
index 0acc5a9..faf1808 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mtk-tphy.txt
@@ -1,13 +1,18 @@
-mt65xx USB3.0 PHY binding
+MediaTek T-PHY binding
 --
 
-This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC.
+T-phy controller supports physical layer functionality for a number of
+controllers on MediaTek SoCs, such as, USB2.0, USB3.0, PCIe, and SATA.
 
 Required properties (controller (parent) node):
  - compatible  : should be one of
- "mediatek,mt2701-u3phy"
- "mediatek,mt2712-u3phy"
- "mediatek,mt8173-u3phy"
+ "mediatek,generic-tphy-v1"
+ "mediatek,generic-tphy-v2"
+ "mediatek,mt2701-u3phy" (deprecated)
+ "mediatek,mt2712-u3phy" (deprecated)
+ "mediatek,mt8173-u3phy";
+ make use of "mediatek,generic-tphy-v1" on mt2701 instead and
+ "mediatek,generic-tphy-v2" on mt2712 instead.
  - clocks  : (deprecated, use port's clocks instead) a list of phandle +
  clock-specifier pairs, one for each entry in clock-names
  - clock-names : (deprecated, use port's one instead) must contain
@@ -35,6 +40,8 @@ Required properties (port (child) node):
  cell after port phandle is phy type from:
- PHY_TYPE_USB2
- PHY_TYPE_USB3
+   - PHY_TYPE_PCIE
+   - PHY_TYPE_SATA
 
 Example:
 
-- 
1.9.1

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

[PATCH v2 1/4] phy: phy-mt65xx-usb3: add PCIe PHY support

[Chunfeng Yun]

From: Ryder Lee 

This patch adds PCIe PHY setting part.

Signed-off-by: Ryder Lee 
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 228 ++
 1 file changed, 206 insertions(+), 22 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index 59b110f..a9a85fa 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -29,7 +29,7 @@
 #define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
 /* u2 phy bank */
 #define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
-/* u3 phy banks */
+/* u3/pcie phy banks */
 #define SSUSB_SIFSLV_V1_U3PHYD 0x000
 #define SSUSB_SIFSLV_V1_U3PHYA 0x200
 
@@ -99,6 +99,23 @@
 #define P2C_RG_SESSEND BIT(4)
 #define P2C_RG_AVALID  BIT(2)
 
+#define U3P_U3_CHIP_GPIO_CTLD  0x0c
+#define P3C_REG_IP_SW_RST  BIT(31)
+#define P3C_MCU_BUS_CK_GATE_EN BIT(30)
+#define P3C_FORCE_IP_SW_RSTBIT(29)
+
+#define U3P_U3_CHIP_GPIO_CTLE  0x10
+#define P3C_RG_SWRST_U3_PHYD   BIT(25)
+#define P3C_RG_SWRST_U3_PHYD_FORCE_EN  BIT(24)
+
+#define U3P_U3_PHYA_REG0   0x000
+#define P3A_RG_CLKDRV_OFF  GENMASK(3, 2)
+#define P3A_RG_CLKDRV_OFF_VAL(x)   ((0x3 & (x)) << 2)
+
+#define U3P_U3_PHYA_REG1   0x004
+#define P3A_RG_CLKDRV_AMP  GENMASK(31, 29)
+#define P3A_RG_CLKDRV_AMP_VAL(x)   ((0x7 & (x)) << 29)
+
 #define U3P_U3_PHYA_REG6   0x018
 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
 #define P3A_RG_TX_EIDLE_CM_VAL(x)  ((0xf & (x)) << 28)
@@ -108,9 +125,40 @@
 #define P3A_RG_RX_DAC_MUX_VAL(x)   ((0x1f & (x)) << 1)
 
 #define U3P_U3_PHYA_DA_REG00x100
+#define P3A_RG_XTAL_EXT_PE2H   GENMASK(17, 16)
+#define P3A_RG_XTAL_EXT_PE2H_VAL(x)((0x3 & (x)) << 16)
+#define P3A_RG_XTAL_EXT_PE1H   GENMASK(13, 12)
+#define P3A_RG_XTAL_EXT_PE1H_VAL(x)((0x3 & (x)) << 12)
 #define P3A_RG_XTAL_EXT_EN_U3  GENMASK(11, 10)
 #define P3A_RG_XTAL_EXT_EN_U3_VAL(x)   ((0x3 & (x)) << 10)
 
+#define U3P_U3_PHYA_DA_REG40x108
+#define P3A_RG_PLL_DIVEN_PE2H  GENMASK(21, 19)
+#define P3A_RG_PLL_BC_PE2H GENMASK(7, 6)
+#define P3A_RG_PLL_BC_PE2H_VAL(x)  ((0x3 & (x)) << 6)
+
+#define U3P_U3_PHYA_DA_REG50x10c
+#define P3A_RG_PLL_BR_PE2H GENMASK(29, 28)
+#define P3A_RG_PLL_BR_PE2H_VAL(x)  ((0x3 & (x)) << 28)
+#define P3A_RG_PLL_IC_PE2H GENMASK(15, 12)
+#define P3A_RG_PLL_IC_PE2H_VAL(x)  ((0xf & (x)) << 12)
+
+#define U3P_U3_PHYA_DA_REG60x110
+#define P3A_RG_PLL_IR_PE2H GENMASK(19, 16)
+#define P3A_RG_PLL_IR_PE2H_VAL(x)  ((0xf & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG70x114
+#define P3A_RG_PLL_BP_PE2H GENMASK(19, 16)
+#define P3A_RG_PLL_BP_PE2H_VAL(x)  ((0xf & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG20   0x13c
+#define P3A_RG_PLL_DELTA1_PE2H GENMASK(31, 16)
+#define P3A_RG_PLL_DELTA1_PE2H_VAL(x)  ((0x & (x)) << 16)
+
+#define U3P_U3_PHYA_DA_REG25   0x148
+#define P3A_RG_PLL_DELTA_PE2H  GENMASK(15, 0)
+#define P3A_RG_PLL_DELTA_PE2H_VAL(x)   (0x & (x))
+
 #define U3P_U3_PHYD_LFPS1  0x00c
 #define P3D_RG_FWAKE_THGENMASK(21, 16)
 #define P3D_RG_FWAKE_TH_VAL(x) ((0x3f & (x)) << 16)
@@ -322,8 +370,8 @@ static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, instance->index);
 }
 
-static void phy_instance_init(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_init(struct mt65xx_u3phy *u3phy,
+struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -384,8 +432,8 @@ static void phy_instance_init(struct mt65xx_u3phy *u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
 }
 
-static void phy_instance_power_on(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_power_on(struct mt65xx_u3phy *u3phy,
+struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -420,8 +468,8 @@ static void phy_instance_power_on(struct mt65xx_u3phy 
*u3phy,
dev_dbg(u3phy->dev, "%s(%d)\n", __func__, index);
 }
 
-static void phy_instance_power_off(struct mt65xx_u3phy *u3phy,
-   struct mt65xx_phy_instance *instance)
+static void u2_phy_instance_power_off(struct mt65xx_u3phy *u3phy,
+ struct mt65xx_phy_instance *instance)
 {
struct u2phy_banks *u2_banks = >u2_banks;
void __iomem *com = u2_banks->com;
@@ -458,8 +506,8 @@ static void phy_instance_power_off(struct mt65xx_u3phy 
*u3phy,

[PATCH v2 3/4] phy: phy-mt65xx-usb3: add mediatek directory and rename file

[Chunfeng Yun]

The driver is actually for T-PHY which supports USB3.0, PCIe and SATA,
and supports more SoCs now, but not just only for series of mt65xx SoCs,
so the name of file, data struct, functions etc with 'mt65xx' may cause
misunderstanding when new SoCs are supported. Here rename them to reflect
the real functions and also enhance readability.

And also update MAINTAINERS file to reflect the correct driver

Signed-off-by: Chunfeng Yun 
---
 MAINTAINERS|   2 +-
 drivers/phy/Kconfig|   9 +-
 drivers/phy/Makefile   |   2 +-
 drivers/phy/mediatek/Kconfig   |  14 ++
 drivers/phy/mediatek/Makefile  |   5 +
 .../{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c} | 273 ++---
 6 files changed, 158 insertions(+), 147 deletions(-)
 create mode 100644 drivers/phy/mediatek/Kconfig
 create mode 100644 drivers/phy/mediatek/Makefile
 rename drivers/phy/{phy-mt65xx-usb3.c => mediatek/phy-mtk-tphy.c} (81%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 205d397..428e5d0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1599,7 +1599,7 @@ M:Chunfeng Yun 
 L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
 L: linux-media...@lists.infradead.org (moderated for non-subscribers)
 S: Maintained
-F: drivers/phy/phy-mt65xx-usb3.c
+F: drivers/phy/mediatek/phy-mtk-tphy.c
 
 ARM/MICREL KS8695 ARCHITECTURE
 M: Greg Ungerer 
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c1807d4..d16704e 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -26,14 +26,6 @@ config PHY_LPC18XX_USB_OTG
  This driver is need for USB0 support on LPC18xx/43xx and takes
  care of enabling and clock setup.
 
-config PHY_MT65XX_USB3
-   tristate "Mediatek USB3.0 PHY Driver"
-   depends on ARCH_MEDIATEK && OF
-   select GENERIC_PHY
-   help
- Say 'Y' here to add support for Mediatek USB3.0 PHY driver,
- it supports multiple usb2.0 and usb3.0 ports.
-
 config PHY_PISTACHIO_USB
tristate "IMG Pistachio USB2.0 PHY driver"
depends on MACH_PISTACHIO
@@ -53,6 +45,7 @@ source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
 source "drivers/phy/hisilicon/Kconfig"
 source "drivers/phy/marvell/Kconfig"
+source "drivers/phy/mediatek/Kconfig"
 source "drivers/phy/motorola/Kconfig"
 source "drivers/phy/qualcomm/Kconfig"
 source "drivers/phy/renesas/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index f252201..1c68189 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -4,12 +4,12 @@
 
 obj-$(CONFIG_GENERIC_PHY)  += phy-core.o
 obj-$(CONFIG_PHY_LPC18XX_USB_OTG)  += phy-lpc18xx-usb-otg.o
-obj-$(CONFIG_PHY_MT65XX_USB3)  += phy-mt65xx-usb3.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
 
 obj-$(CONFIG_ARCH_SUNXI)   += allwinner/
 obj-$(CONFIG_ARCH_MESON)   += amlogic/
+obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
 obj-$(CONFIG_ARCH_RENESAS) += renesas/
 obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/
 obj-$(CONFIG_ARCH_TEGRA)   += tegra/
diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
new file mode 100644
index 000..be2a846
--- /dev/null
+++ b/drivers/phy/mediatek/Kconfig
@@ -0,0 +1,14 @@
+#
+# Phy drivers for MediaTek devices
+#
+config PHY_MTK_TPHY
+tristate "MediaTek T-PHY Driver"
+depends on ARCH_MEDIATEK && OF
+select GENERIC_PHY
+help
+  Enable this to add support for MediaTek T-PHY driver,
+  it supports physical layer functionality for usb2.0, usb3.0,
+  PCIe and SATA, and meanwhile supports two version T-PHY which
+  have 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.
diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
new file mode 100644
index 000..763a92e
--- /dev/null
+++ b/drivers/phy/mediatek/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the phy drivers.
+#
+
+obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/mediatek/phy-mtk-tphy.c
similarity index 81%
rename from drivers/phy/phy-mt65xx-usb3.c
rename to drivers/phy/mediatek/phy-mtk-tphy.c
index 5e9a415..1ca7fe3 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/mediatek/phy-mtk-tphy.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -38,7 +39,7 @@
 #define SSUSB_SIFSLV_V2_MISC   0x000
 #define SSUSB_SIFSLV_V2_U2FREQ 0x100
 #define SSUSB_SIFSLV_V2_U2PHY_COM  0x300
-/* u3 phy banks */
+/* u3/pcie/sata 

[PATCH v2 2/4] phy: phy-mt65xx-usb3: add SATA PHY support

[Chunfeng Yun]

From: Ryder Lee 

This patch adds SATA setting part.

Signed-off-by: Ryder Lee 
Signed-off-by: Chunfeng Yun 
---
 drivers/phy/phy-mt65xx-usb3.c | 133 --
 1 file changed, 129 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index a9a85fa..5e9a415 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -29,7 +29,7 @@
 #define SSUSB_SIFSLV_V1_U2FREQ 0x100   /* shared by u2 phys */
 /* u2 phy bank */
 #define SSUSB_SIFSLV_V1_U2PHY_COM  0x000
-/* u3/pcie phy banks */
+/* u3/pcie/sata phy banks */
 #define SSUSB_SIFSLV_V1_U3PHYD 0x000
 #define SSUSB_SIFSLV_V1_U3PHYA 0x200
 
@@ -199,6 +199,65 @@
 #define U3P_SR_COEF_DIVISOR1000
 #define U3P_FM_DET_CYCLE_CNT   1024
 
+/* SATA register setting */
+#define PHYD_CTRL_SIGNAL_MODE4 0x1c
+/* CDR Charge Pump P-path current adjustment */
+#define RG_CDR_BICLTD1_GEN1_MSKGENMASK(23, 20)
+#define RG_CDR_BICLTD1_GEN1_VAL(x) ((0xf & (x)) << 20)
+#define RG_CDR_BICLTD0_GEN1_MSKGENMASK(11, 8)
+#define RG_CDR_BICLTD0_GEN1_VAL(x) ((0xf & (x)) << 8)
+
+#define PHYD_DESIGN_OPTION20x24
+/* Symbol lock count selection */
+#define RG_LOCK_CNT_SEL_MSKGENMASK(5, 4)
+#define RG_LOCK_CNT_SEL_VAL(x) ((0x3 & (x)) << 4)
+
+#define PHYD_DESIGN_OPTION90x40
+/* COMWAK GAP width window */
+#define RG_TG_MAX_MSK  GENMASK(20, 16)
+#define RG_TG_MAX_VAL(x)   ((0x1f & (x)) << 16)
+/* COMINIT GAP width window */
+#define RG_T2_MAX_MSK  GENMASK(13, 8)
+#define RG_T2_MAX_VAL(x)   ((0x3f & (x)) << 8)
+/* COMWAK GAP width window */
+#define RG_TG_MIN_MSK  GENMASK(7, 5)
+#define RG_TG_MIN_VAL(x)   ((0x7 & (x)) << 5)
+/* COMINIT GAP width window */
+#define RG_T2_MIN_MSK  GENMASK(4, 0)
+#define RG_T2_MIN_VAL(x)   (0x1f & (x))
+
+#define ANA_RG_CTRL_SIGNAL10x4c
+/* TX driver tail current control for 0dB de-empahsis mdoe for Gen1 speed */
+#define RG_IDRV_0DB_GEN1_MSK   GENMASK(13, 8)
+#define RG_IDRV_0DB_GEN1_VAL(x)((0x3f & (x)) << 8)
+
+#define ANA_RG_CTRL_SIGNAL40x58
+#define RG_CDR_BICLTR_GEN1_MSK GENMASK(23, 20)
+#define RG_CDR_BICLTR_GEN1_VAL(x)  ((0xf & (x)) << 20)
+/* Loop filter R1 resistance adjustment for Gen1 speed */
+#define RG_CDR_BR_GEN2_MSK GENMASK(10, 8)
+#define RG_CDR_BR_GEN2_VAL(x)  ((0x7 & (x)) << 8)
+
+#define ANA_RG_CTRL_SIGNAL60x60
+/* I-path capacitance adjustment for Gen1 */
+#define RG_CDR_BC_GEN1_MSK GENMASK(28, 24)
+#define RG_CDR_BC_GEN1_VAL(x)  ((0x1f & (x)) << 24)
+#define RG_CDR_BIRLTR_GEN1_MSK GENMASK(4, 0)
+#define RG_CDR_BIRLTR_GEN1_VAL(x)  (0x1f & (x))
+
+#define ANA_EQ_EYE_CTRL_SIGNAL10x6c
+/* RX Gen1 LEQ tuning step */
+#define RG_EQ_DLEQ_LFI_GEN1_MSKGENMASK(11, 8)
+#define RG_EQ_DLEQ_LFI_GEN1_VAL(x) ((0xf & (x)) << 8)
+
+#define ANA_EQ_EYE_CTRL_SIGNAL40xd8
+#define RG_CDR_BIRLTD0_GEN1_MSKGENMASK(20, 16)
+#define RG_CDR_BIRLTD0_GEN1_VAL(x) ((0x1f & (x)) << 16)
+
+#define ANA_EQ_EYE_CTRL_SIGNAL50xdc
+#define RG_CDR_BIRLTD0_GEN3_MSKGENMASK(4, 0)
+#define RG_CDR_BIRLTD0_GEN3_VAL(x) (0x1f & (x))
+
 enum mt_phy_version {
MT_PHY_V1 = 1,
MT_PHY_V2,
@@ -630,6 +689,64 @@ static void pcie_phy_instance_power_off(struct 
mt65xx_u3phy *u3phy,
writel(tmp, bank->chip + U3P_U3_CHIP_GPIO_CTLE);
 }
 
+static void sata_phy_instance_init(struct mt65xx_u3phy *u3phy,
+  struct mt65xx_phy_instance *instance)
+{
+   struct u3phy_banks *u3_banks = >u3_banks;
+   void __iomem *phyd = u3_banks->phyd;
+   u32 tmp;
+
+   /* charge current adjustment */
+   tmp = readl(phyd + ANA_RG_CTRL_SIGNAL6);
+   tmp &= ~(RG_CDR_BIRLTR_GEN1_MSK | RG_CDR_BC_GEN1_MSK);
+   tmp |= RG_CDR_BIRLTR_GEN1_VAL(0x6) | RG_CDR_BC_GEN1_VAL(0x1a);
+   writel(tmp, phyd + ANA_RG_CTRL_SIGNAL6);
+
+   tmp = readl(phyd + ANA_EQ_EYE_CTRL_SIGNAL4);
+   tmp &= ~RG_CDR_BIRLTD0_GEN1_MSK;
+   tmp |= RG_CDR_BIRLTD0_GEN1_VAL(0x18);
+   writel(tmp, phyd + ANA_EQ_EYE_CTRL_SIGNAL4);
+
+   tmp = readl(phyd + ANA_EQ_EYE_CTRL_SIGNAL5);
+   tmp &= ~RG_CDR_BIRLTD0_GEN3_MSK;
+   tmp |= RG_CDR_BIRLTD0_GEN3_VAL(0x06);
+   writel(tmp, phyd + ANA_EQ_EYE_CTRL_SIGNAL5);
+
+   tmp = readl(phyd + ANA_RG_CTRL_SIGNAL4);
+   tmp &= ~(RG_CDR_BICLTR_GEN1_MSK | RG_CDR_BR_GEN2_MSK);
+   tmp |= RG_CDR_BICLTR_GEN1_VAL(0x0c) | RG_CDR_BR_GEN2_VAL(0x07);
+   writel(tmp, phyd + ANA_RG_CTRL_SIGNAL4);
+
+   tmp = readl(phyd + PHYD_CTRL_SIGNAL_MODE4);
+   tmp &= ~(RG_CDR_BICLTD0_GEN1_MSK | RG_CDR_BICLTD1_GEN1_MSK);
+   tmp |= 

Re: new usb LTE modem device

[Lars Melin]

On 8/9/2017 02:33, Bjørn Mork wrote:





The qmi_wwan part looks fine to me. But you
will need to split it in two patches since the two
drivers are parts of different subsystems.

The option driver use interface blacklists
instead of multiple match entries. You should
probably follow the same style there. But this
is up to Johan...

Use the get_maintainer script to figure out
where the patches should be sent.


Bjørn



Whitelisting all 6 interfaces in the option driver and
then blacklist 4 of them (3 qmi + 1 Android debug) is
not efficient when you so easily can selectively whitelist
the ones (0 and 2) that the option driver should handle.
Giuseppe is doing it the right way imho.


/http://vger.kernel.org/majordomo-info.html

Re: [PATCH net,stable] qmi_wwan: fix NULL deref on disconnect

[David Miller]

From: Bjørn Mork 
Date: Tue,  8 Aug 2017 18:02:11 +0200

> qmi_wwan_disconnect is called twice when disconnecting devices with
> separate control and data interfaces.  The first invocation will set
> the interface data to NULL for both interfaces to flag that the
> disconnect has been handled.  But the matching NULL check was left
> out when qmi_wwan_disconnect was added, resulting in this oops:
> 
>   usb 2-1.4: USB disconnect, device number 4
>   qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' 
> usb-:00:1d.0-1.4, WWAN/QMI device
>   BUG: unable to handle kernel NULL pointer dereference at 00e0
>   IP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
>   PGD 0
>   P4D 0
>   Oops:  [#1] SMP
>   Modules linked in: 
>   CPU: 2 PID: 33 Comm: kworker/2:1 Tainted: GE   
> 4.12.3-nr44-normandy-r1500619820+ #1
>   Hardware name: LENOVO 4291LR7/4291LR7, BIOS CBET4000 4.6-810-g50522254fb 
> 07/21/2017
>   Workqueue: usb_hub_wq hub_event [usbcore]
>   task: 8c882b716040 task.stack: b8e800d84000
>   RIP: 0010:qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
>   RSP: 0018:b8e800d87b38 EFLAGS: 00010246
>   RAX:  RBX:  RCX: 
>   RDX: 0001 RSI: 8c8824f3f1d0 RDI: 8c8824ef6400
>   RBP: 8c8824ef6400 R08:  R09: 
>   R10: b8e800d87780 R11: 0011 R12: c07ea0e8
>   R13: 8c8824e2e000 R14: 8c8824e2e098 R15: 
>   FS:  () GS:8c883530() knlGS:
>   CS:  0010 DS:  ES:  CR0: 80050033
>   CR2: 00e0 CR3: 000229ca5000 CR4: 000406e0
>   Call Trace:
>? usb_unbind_interface+0x71/0x270 [usbcore]
>? device_release_driver_internal+0x154/0x210
>? qmi_wwan_unbind+0x6d/0xc0 [qmi_wwan]
>? usbnet_disconnect+0x6c/0xf0 [usbnet]
>? qmi_wwan_disconnect+0x87/0xc0 [qmi_wwan]
>? usb_unbind_interface+0x71/0x270 [usbcore]
>? device_release_driver_internal+0x154/0x210
> 
> Reported-and-tested-by: Nathaniel Roach 
> Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support")
> Cc: Daniele Palmas 
> Signed-off-by: Bjørn Mork 

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

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

[Lu Baolu]

Hi,

On 08/08/2017 02:14 PM, Felipe Balbi wrote:
> Hi,
>
> Lu Baolu  writes:
>>> Lu Baolu  writes:
 The component u_serial provides a glue layer between TTY layer
 and a USB gadget device needed to provide a basic serial port
 functionality. Currently, u_serial sits under gadget/function
 and depends on CONFIG_USB_GADGET to be compiled and used.

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

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

 Signed-off-by: Lu Baolu 
>>> NAK, u_serial uses the gadget API. It's definitely not COMMON.
>>>
>> Okay. It seems that I can't use u_serial anyway. I will implement
>> a new tty glue for my case.
> have you looked at drivers/usb/serial/?
>

Yes, I've checked that. I think usb-serial framework is too complex
for this case. XHCI debug capability is a simple gadget attached to
xHCI host.

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

[PATCH v2] usb: dwc2: skip L2 state of hcd if work in device mode

[Meng Dongyang]

The gadget may fail to enqueue request if the controller has enter L2
state. This patch prevent enter L2 state in hcd driver if the controller
works in device mode.

Change in v2:None, resend to addition maintainer

Meng Dongyang (1):
  usb: dwc2: skip L2 state of hcd if controller work in device mode

 drivers/usb/dwc2/hcd.c | 6 ++
 1 file changed, 6 insertions(+)

-- 
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] usb: dwc2: skip L2 state of hcd if controller work in device mode

[Meng Dongyang]

In the case hcd autosuspend is enabled, the hcd will enter L2 state
if no device connected. But if the controller works in otg mode, the
gadget driver still works in L0 state if connected with host. This
may result in transfer fail when gadget enqueue new request but the
hcd driver has set the global state into L2. This patch prevent the
hcd enter L2 state if the controller work in device mode.

Signed-off-by: Meng Dongyang 
---

Changes in v2:None

 drivers/usb/dwc2/hcd.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 740c7e8..c263114 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4388,6 +4388,9 @@ static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
 
spin_lock_irqsave(>lock, flags);
 
+   if (dwc2_is_device_mode(hsotg))
+   goto unlock;
+
if (hsotg->lx_state != DWC2_L0)
goto unlock;
 
@@ -4446,6 +4449,9 @@ static int _dwc2_hcd_resume(struct usb_hcd *hcd)
 
spin_lock_irqsave(>lock, flags);
 
+   if (dwc2_is_device_mode(hsotg))
+   goto unlock;
+
if (hsotg->lx_state != DWC2_L2)
goto unlock;
 
-- 
1.9.1


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

Re: [PATCH 4/4] dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file

[Chunfeng Yun]

On Tue, 2017-08-08 at 17:44 +0530, Kishon Vijay Abraham I wrote:
> Chunfeng
> 
> On Thursday 03 August 2017 03:50 PM, Chunfeng Yun wrote:
> > hi,
> > 
> > I made a mistake, please ignore the patches with Change-Id, very sorry
> 
> No problem. However can you resend the series after fixing all checkpatch 
> warnings?
Ok
> 
> Thanks
> Kishon


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

[PATCH] usb: ehci-omap: fix error return code in ehci_hcd_omap_probe()

[Gustavo A. R. Silva]

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

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

Print and propagate the return value of platform_get_irq on failure.

This issue was detected with the help of Coccinelle.

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

diff --git a/drivers/usb/host/ehci-omap.c b/drivers/usb/host/ehci-omap.c
index 94ea9ff..4d30853 100644
--- a/drivers/usb/host/ehci-omap.c
+++ b/drivers/usb/host/ehci-omap.c
@@ -130,8 +130,8 @@ static int ehci_hcd_omap_probe(struct platform_device *pdev)
 
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
-   dev_err(dev, "EHCI irq failed\n");
-   return -ENODEV;
+   dev_err(dev, "EHCI irq failed: %d\n", irq);
+   return irq;
}
 
res =  platform_get_resource(pdev, IORESOURCE_MEM, 0);
-- 
2.5.0

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

[PATCH] usb: gadget: udc: renesas_usb3: fix error return code in renesas_usb3_probe()

[Gustavo A. R. Silva]

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

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

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

This issue was detected with the help of Coccinelle.

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

diff --git a/drivers/usb/gadget/udc/renesas_usb3.c 
b/drivers/usb/gadget/udc/renesas_usb3.c
index e1de8fe..616d053 100644
--- a/drivers/usb/gadget/udc/renesas_usb3.c
+++ b/drivers/usb/gadget/udc/renesas_usb3.c
@@ -2468,8 +2468,10 @@ static int renesas_usb3_probe(struct platform_device 
*pdev)
priv = match->data;
 
irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
-   return -ENODEV;
+   if (irq < 0) {
+   dev_err(>dev, "Failed to get IRQ: %d\n", irq);
+   return irq;
+   }
 
usb3 = devm_kzalloc(>dev, sizeof(*usb3), GFP_KERNEL);
if (!usb3)
-- 
2.5.0

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

Re: AW: new usb LTE modem device

[Dan Williams]

On Tue, 2017-08-08 at 22:22 +0200, Giuseppe Lippolis wrote:
> > The option driver use interface blacklists instead of multiple
> > match entries.
> > You should probably follow the same style there. But this is up to
> > Johan...
> 
> Can I ask what ist he difference between .sendsetup and .reserved and
> how to use the bitmask in drivers/usb/serial/option.c ?

The "blacklists" (which they really aren't anymore, just quirks) say
which USB interfaces have that specific quick.

sendsetup is to prevent the driver from sending a specific USB control
message for setting up serial parameters, which some devices ignore and
cause the driver to stall.

reserved is what you're looking for.  This one tells option not to bind
to the given USB interfaces.

So for example, ".reserved = BIT(3)" tells the option driver to ignore
USB interface 3 on that device.  ".reserved = BIT(3) | BIT(5)" tells it
to ignore both interfaces 3 and 5.

For your device, you'll want to set "reserved" in option.c to all the
interfaces that qmi_wwan is going to claim, to make sure option doesn't
claim them.  option by default is a greedy driver.

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

AW: new usb LTE modem device

[Giuseppe Lippolis]

> The option driver use interface blacklists instead of multiple match entries.
> You should probably follow the same style there. But this is up to Johan...

Can I ask what ist he difference between .sendsetup and .reserved and how to 
use the bitmask in drivers/usb/serial/option.c ?

Thanks,
Bye.

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

[PATCH] USB: serial: pl2303: add new ATEN device id

[Greg KH]

This adds a new ATEN device id for a new pl2303-based device.

Reported-by: Peter Kuo 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 

---

Peter, can you test this patch and verify it works for you?  Is there a
better name I can give this device other than ATEN_PRODUCT_ID3?

Johan, any objection for me to take this through my tree once Peter
verifies it?

thanks,

greg k-h



diff --git a/drivers/usb/serial/pl2303.c b/drivers/usb/serial/pl2303.c
index c9ebefd8f35f..4b124c645175 100644
--- a/drivers/usb/serial/pl2303.c
+++ b/drivers/usb/serial/pl2303.c
@@ -53,6 +53,8 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID),
.driver_info = PL2303_QUIRK_ENDPOINT_HACK },
{ USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID2) },
+   { USB_DEVICE(ATEN_VENDOR_ID, ATEN_PRODUCT_ID3),
+   .driver_info = PL2303_QUIRK_ENDPOINT_HACK },
{ USB_DEVICE(ATEN_VENDOR_ID2, ATEN_PRODUCT_ID) },
{ USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID) },
{ USB_DEVICE(ELCOM_VENDOR_ID, ELCOM_PRODUCT_ID_UCSGT) },
diff --git a/drivers/usb/serial/pl2303.h b/drivers/usb/serial/pl2303.h
index 09d9be88209e..dc55e3f2343c 100644
--- a/drivers/usb/serial/pl2303.h
+++ b/drivers/usb/serial/pl2303.h
@@ -28,6 +28,7 @@
 #define ATEN_VENDOR_ID20x0547
 #define ATEN_PRODUCT_ID0x2008
 #define ATEN_PRODUCT_ID2   0x2118
+#define ATEN_PRODUCT_ID3   0x2021
 
 #define IODATA_VENDOR_ID   0x04bb
 #define IODATA_PRODUCT_ID  0x0a03

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

Re: BUG/PATCH: cp210x.c - reenable support for chips which don't report a partnum

[Greg KH]

On Tue, Aug 08, 2017 at 08:59:01PM +0200, Sebastian Frei wrote:
> Hi,
> 
> I own a data cable for Siemens mobile phones:
> 10ab:10c5 USI Co., Ltd Sony-Ericsson / Samsung DataCable
> 
> The cp210x chip of this cable seems to not give an answer to the 
> CP210X_GET_PARTNUM command. So since this commit:
> 
> 2016-10-24 USB: serial: cp210x: Adding GPIO support for CP2105
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/serial/cp210x.c?id=cf5276ce7867d6d87c02fbe4977646ed342e323a
> 
> the driver aborts while loading:
> 
> [  242.446506] usb 1-5.1: new full-speed USB device number 7 using xhci_hcd
> [  242.682993] usb 1-5.1: New USB device found, idVendor=10ab, idProduct=10c5
> [  242.682996] usb 1-5.1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [  242.682998] usb 1-5.1: Product: usb data cable
> [  242.682999] usb 1-5.1: Manufacturer: Silicon Labs
> [  242.683000] usb 1-5.1: SerialNumber: 0001
> [  242.711590] usbcore: registered new interface driver usbserial
> [  242.711602] usbcore: registered new interface driver usbserial_generic
> [  242.711611] usbserial: USB Serial support registered for generic
> [  242.712947] usbcore: registered new interface driver cp210x
> [  242.712958] usbserial: USB Serial support registered for cp210x
> [  242.712981] cp210x 1-5.1:1.0: cp210x converter detected
> [  242.716630] cp210x 1-5.1:1.0: failed to get vendor val 0x370b size 1: -32
> [  242.716645] cp210x: probe of 1-5.1:1.0 failed with error -5
> 
> I'm proposing a patch to continue loading but skip the GPIO initialization:
> 
> --- drivers/usb/serial/cp210x.c.orig  2017-08-08 20:11:34.327209672 +0200
> +++ drivers/usb/serial/cp210x.c   2017-08-08 20:12:57.735833959 +0200
> @@ -1480,31 +1480,31 @@
>  static int cp210x_attach(struct usb_serial *serial)
>  {
>   int result;
>   struct cp210x_serial_private *priv;
>  
>   priv = kzalloc(sizeof(*priv), GFP_KERNEL);
>   if (!priv)
>   return -ENOMEM;
>  
> + usb_set_serial_data(serial, priv);
> +
>   result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
> CP210X_GET_PARTNUM, >partnum,
> sizeof(priv->partnum));
> - if (result < 0)
> - goto err_free_priv;
>  
> - usb_set_serial_data(serial, priv);
> + if (result < 0) {
> + dev_err(>interface->dev,
> + "querying part number failed, continuing without GPIO 
> support\n");
> + return 0;
> + }
>  
>   if (priv->partnum == CP210X_PARTNUM_CP2105) {
>   result = cp2105_shared_gpio_init(serial);
>   if (result < 0) {
>   dev_err(>interface->dev,
>   "GPIO initialisation failed, continuing without 
> GPIO support\n");
>   }
>   }
>  
>   return 0;
> -err_free_priv:
> - kfree(priv);
> -
> - return result;
>  }
>  
> Signed-off-by: Sebastian Frei 
> 
> Output now with the patch:
> [  298.994093] usb 1-5.1: new full-speed USB device number 8 using xhci_hcd
> [  299.230631] usb 1-5.1: New USB device found, idVendor=10ab, idProduct=10c5
> [  299.230634] usb 1-5.1: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [  299.230635] usb 1-5.1: Product: usb data cable
> [  299.230637] usb 1-5.1: Manufacturer: Silicon Labs
> [  299.230638] usb 1-5.1: SerialNumber: 0001
> [  299.247270] cp210x: no symbol version for module_layout
> [  299.247750] usbcore: registered new interface driver cp210x
> [  299.247764] usbserial: USB Serial support registered for cp210x
> [  299.247793] cp210x 1-5.1:1.0: cp210x converter detected
> [  299.251637] cp210x 1-5.1:1.0: failed to get vendor val 0x370b size 1: -32
> [  299.251642] cp210x 1-5.1:1.0: querying part number failed, continuing 
> without GPIO support
> [  299.271749] usb 1-5.1: cp210x converter now attached to ttyUSB0
> 
> The cable is working, TX & RX sends and receives data.

Seems reasonable, can you fix it up and resend it in a format that we
can apply it in?

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: new usb LTE modem device

[Bjørn Mork]

On August 8, 2017 9:22:29 PM CEST, Giuseppe Lippolis  
wrote:
>> But we already have many Sierra devices with 2 QMI interfaces (the
>3rd one
>> is documented and verified non-functional for unknown reasons). And
>these
>> tend to come with multiple OEM device IDs.  So a whitelist method
>could
>> reduce the number of matching entries considerably.  Feel free to
>submit
>> patches if you like :-)
>
>Dear Bjorg,
>I'm going to prepare the following patch. 
>If you think it is ok, I will build and test it and if working I will
>submit it.

The qmi_wwan part looks fine to me. But you
will need to split it in two patches since the two
drivers are parts of different subsystems.

The option driver use interface blacklists
instead of multiple match entries. You should
probably follow the same style there. But this
is up to Johan...

Use the get_maintainer script to figure out
where the patches should be sent.


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

AW: new usb LTE modem device

[Giuseppe Lippolis]

> But we already have many Sierra devices with 2 QMI interfaces (the 3rd one
> is documented and verified non-functional for unknown reasons). And these
> tend to come with multiple OEM device IDs.  So a whitelist method could
> reduce the number of matching entries considerably.  Feel free to submit
> patches if you like :-)

Dear Bjorg,
I'm going to prepare the following patch. 
If you think it is ok, I will build and test it and if working I will submit it.
Bye.

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 5894e3c..c708a8f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1100,6 +1100,9 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)},/* Huawei E173 */
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)},/* Huawei E1820 */
+{QMI_FIXED_INTF(0x1435, 0xd181, 3)},/* D18, WNC VID, d181-3 */
+{QMI_FIXED_INTF(0x1435, 0xd181, 4)},/* D18, WNC VID, d181-4 */
+{QMI_FIXED_INTF(0x1435, 0xd181, 5)},/* D18, WNC VID, d181-5 */
{QMI_FIXED_INTF(0x16d8, 0x6003, 0)},/* CMOTech 6003 */
{QMI_FIXED_INTF(0x16d8, 0x6007, 0)},/* CMOTech CHE-628S */
{QMI_FIXED_INTF(0x16d8, 0x6008, 0)},/* CMOTech CMU-301 */
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index ebe51f11..6944e87 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -2035,6 +2035,8 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(WETELECOM_VENDOR_ID, 
WETELECOM_PRODUCT_6802, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(WETELECOM_VENDOR_ID, 
WETELECOM_PRODUCT_WMD300, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x421d, 0xff, 0xff, 0xff) }, /* 
HP lt2523 (Novatel E371) */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1435, 0xd181, 0)},/* D18, WNC VID, 
d181-0 */
+   {USB_DEVICE_INTERFACE_NUMBER(0x1435, 0xd181, 2)},/* D18, WNC VID, 
d181-2 */
{ } /* Terminating entry */
 };
 MODULE_DEVICE_TABLE(usb, option_ids);

--
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/PATCH: cp210x.c - reenable support for chips which don't report a partnum

[Sebastian Frei]

Hi,

I own a data cable for Siemens mobile phones:
10ab:10c5 USI Co., Ltd Sony-Ericsson / Samsung DataCable

The cp210x chip of this cable seems to not give an answer to the 
CP210X_GET_PARTNUM command. So since this commit:

2016-10-24 USB: serial: cp210x: Adding GPIO support for CP2105
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/serial/cp210x.c?id=cf5276ce7867d6d87c02fbe4977646ed342e323a

the driver aborts while loading:

[  242.446506] usb 1-5.1: new full-speed USB device number 7 using xhci_hcd
[  242.682993] usb 1-5.1: New USB device found, idVendor=10ab, idProduct=10c5
[  242.682996] usb 1-5.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[  242.682998] usb 1-5.1: Product: usb data cable
[  242.682999] usb 1-5.1: Manufacturer: Silicon Labs
[  242.683000] usb 1-5.1: SerialNumber: 0001
[  242.711590] usbcore: registered new interface driver usbserial
[  242.711602] usbcore: registered new interface driver usbserial_generic
[  242.711611] usbserial: USB Serial support registered for generic
[  242.712947] usbcore: registered new interface driver cp210x
[  242.712958] usbserial: USB Serial support registered for cp210x
[  242.712981] cp210x 1-5.1:1.0: cp210x converter detected
[  242.716630] cp210x 1-5.1:1.0: failed to get vendor val 0x370b size 1: -32
[  242.716645] cp210x: probe of 1-5.1:1.0 failed with error -5

I'm proposing a patch to continue loading but skip the GPIO initialization:

--- drivers/usb/serial/cp210x.c.orig2017-08-08 20:11:34.327209672 +0200
+++ drivers/usb/serial/cp210x.c 2017-08-08 20:12:57.735833959 +0200
@@ -1480,31 +1480,31 @@
 static int cp210x_attach(struct usb_serial *serial)
 {
int result;
struct cp210x_serial_private *priv;
 
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
 
+   usb_set_serial_data(serial, priv);
+
result = cp210x_read_vendor_block(serial, REQTYPE_DEVICE_TO_HOST,
  CP210X_GET_PARTNUM, >partnum,
  sizeof(priv->partnum));
-   if (result < 0)
-   goto err_free_priv;
 
-   usb_set_serial_data(serial, priv);
+   if (result < 0) {
+   dev_err(>interface->dev,
+   "querying part number failed, continuing without GPIO 
support\n");
+   return 0;
+   }
 
if (priv->partnum == CP210X_PARTNUM_CP2105) {
result = cp2105_shared_gpio_init(serial);
if (result < 0) {
dev_err(>interface->dev,
"GPIO initialisation failed, continuing without 
GPIO support\n");
}
}
 
return 0;
-err_free_priv:
-   kfree(priv);
-
-   return result;
 }
 
Signed-off-by: Sebastian Frei 

Output now with the patch:
[  298.994093] usb 1-5.1: new full-speed USB device number 8 using xhci_hcd
[  299.230631] usb 1-5.1: New USB device found, idVendor=10ab, idProduct=10c5
[  299.230634] usb 1-5.1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[  299.230635] usb 1-5.1: Product: usb data cable
[  299.230637] usb 1-5.1: Manufacturer: Silicon Labs
[  299.230638] usb 1-5.1: SerialNumber: 0001
[  299.247270] cp210x: no symbol version for module_layout
[  299.247750] usbcore: registered new interface driver cp210x
[  299.247764] usbserial: USB Serial support registered for cp210x
[  299.247793] cp210x 1-5.1:1.0: cp210x converter detected
[  299.251637] cp210x 1-5.1:1.0: failed to get vendor val 0x370b size 1: -32
[  299.251642] cp210x 1-5.1:1.0: querying part number failed, continuing 
without GPIO support
[  299.271749] usb 1-5.1: cp210x converter now attached to ttyUSB0

The cable is working, TX & RX sends and receives data.

Best regards
Sebastian Frei
--
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] dma-mapping: skip USB devices when configuring DMA during probe

[Johan Hovold]

On Sat, Aug 05, 2017 at 10:38:07AM +0200, Christoph Hellwig wrote:
> I think the root problem is that the code added by
> " of/acpi: Configure dma operations at probe time for platform/amba/pci bus
> devices"
> 
> is completely bogus and needs to be reverted.  We can't simply iterate
> over all devices in the system and set up dma for them.  We'll need
> to ask the firmware / OF what root port this applies to and only
> apply it to those buses.

I'm afraid I haven't had time to look any more at this, and now I'll be
offline for the next two weeks.

It sounded like Robin was working on a fix for the broken DMA-mask on
RPI3 and that should address Hans's ethernet regression too even if we
ultimately need to fix dma_configure() as well.

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

[PATCH 10/35] net: usb: catc: constify usb_device_id and fix space before '[' error

[Arvind Yadav]

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

Fix checkpatch.pl error:
ERROR: space prohibited before open square bracket '['.

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/catc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/catc.c b/drivers/net/usb/catc.c
index fce92f0..01cd17e 100644
--- a/drivers/net/usb/catc.c
+++ b/drivers/net/usb/catc.c
@@ -961,7 +961,7 @@ static void catc_disconnect(struct usb_interface *intf)
  * Module functions and tables.
  */
 
-static struct usb_device_id catc_id_table [] = {
+static const struct usb_device_id catc_id_table[] = {
{ USB_DEVICE(0x0423, 0xa) },/* CATC Netmate, Belkin F5U011 */
{ USB_DEVICE(0x0423, 0xc) },/* CATC Netmate II, Belkin F5U111 */
{ USB_DEVICE(0x08d1, 0x1) },/* smartBridges smartNIC */
-- 
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 12/35] net: usb: ipheth: constify usb_device_id

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/ipheth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/ipheth.c b/drivers/net/usb/ipheth.c
index 0f213ea..d49c710 100644
--- a/drivers/net/usb/ipheth.c
+++ b/drivers/net/usb/ipheth.c
@@ -87,7 +87,7 @@
 #define IPHETH_CARRIER_CHECK_TIMEOUT round_jiffies_relative(1 * HZ)
 #define IPHETH_CARRIER_ON   0x04
 
-static struct usb_device_id ipheth_table[] = {
+static const struct usb_device_id ipheth_table[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(
USB_VENDOR_APPLE, USB_PRODUCT_IPHONE,
IPHETH_USBINTF_CLASS, IPHETH_USBINTF_SUBCLASS,
-- 
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 11/35] net: usb: cdc-phonet: constify usb_device_id

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/cdc-phonet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc-phonet.c b/drivers/net/usb/cdc-phonet.c
index 2952cb5..288ecd9 100644
--- a/drivers/net/usb/cdc-phonet.c
+++ b/drivers/net/usb/cdc-phonet.c
@@ -304,7 +304,7 @@ static void usbpn_setup(struct net_device *dev)
 /*
  * USB driver callbacks
  */
-static struct usb_device_id usbpn_ids[] = {
+static const struct usb_device_id usbpn_ids[] = {
{
.match_flags = USB_DEVICE_ID_MATCH_VENDOR
| USB_DEVICE_ID_MATCH_INT_CLASS
-- 
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 net,stable] qmi_wwan: fix NULL deref on disconnect

[Bjørn Mork]

qmi_wwan_disconnect is called twice when disconnecting devices with
separate control and data interfaces.  The first invocation will set
the interface data to NULL for both interfaces to flag that the
disconnect has been handled.  But the matching NULL check was left
out when qmi_wwan_disconnect was added, resulting in this oops:

  usb 2-1.4: USB disconnect, device number 4
  qmi_wwan 2-1.4:1.6 wwp0s29u1u4i6: unregister 'qmi_wwan' usb-:00:1d.0-1.4, 
WWAN/QMI device
  BUG: unable to handle kernel NULL pointer dereference at 00e0
  IP: qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
  PGD 0
  P4D 0
  Oops:  [#1] SMP
  Modules linked in: 
  CPU: 2 PID: 33 Comm: kworker/2:1 Tainted: GE   
4.12.3-nr44-normandy-r1500619820+ #1
  Hardware name: LENOVO 4291LR7/4291LR7, BIOS CBET4000 4.6-810-g50522254fb 
07/21/2017
  Workqueue: usb_hub_wq hub_event [usbcore]
  task: 8c882b716040 task.stack: b8e800d84000
  RIP: 0010:qmi_wwan_disconnect+0x25/0xc0 [qmi_wwan]
  RSP: 0018:b8e800d87b38 EFLAGS: 00010246
  RAX:  RBX:  RCX: 
  RDX: 0001 RSI: 8c8824f3f1d0 RDI: 8c8824ef6400
  RBP: 8c8824ef6400 R08:  R09: 
  R10: b8e800d87780 R11: 0011 R12: c07ea0e8
  R13: 8c8824e2e000 R14: 8c8824e2e098 R15: 
  FS:  () GS:8c883530() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 00e0 CR3: 000229ca5000 CR4: 000406e0
  Call Trace:
   ? usb_unbind_interface+0x71/0x270 [usbcore]
   ? device_release_driver_internal+0x154/0x210
   ? qmi_wwan_unbind+0x6d/0xc0 [qmi_wwan]
   ? usbnet_disconnect+0x6c/0xf0 [usbnet]
   ? qmi_wwan_disconnect+0x87/0xc0 [qmi_wwan]
   ? usb_unbind_interface+0x71/0x270 [usbcore]
   ? device_release_driver_internal+0x154/0x210

Reported-and-tested-by: Nathaniel Roach 
Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support")
Cc: Daniele Palmas 
Signed-off-by: Bjørn Mork 
---
Needed for v4.12 and later


 drivers/net/usb/qmi_wwan.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index ff6f39fe6c00..8c3733608271 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1341,10 +1341,14 @@ static int qmi_wwan_probe(struct usb_interface *intf,
 static void qmi_wwan_disconnect(struct usb_interface *intf)
 {
struct usbnet *dev = usb_get_intfdata(intf);
-   struct qmi_wwan_state *info = (void *)>data;
+   struct qmi_wwan_state *info;
struct list_head *iter;
struct net_device *ldev;
 
+   /* called twice if separate control and data intf */
+   if (!dev)
+   return;
+   info = (void *)>data;
if (info->flags & QMI_WWAN_FLAG_MUX) {
if (!rtnl_trylock()) {
restart_syscall();
-- 
2.11.0

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

[PATCH 13/35] net: usb: kaweth: constify usb_device_id

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/kaweth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c
index 92e4fd2..f160583 100644
--- a/drivers/net/usb/kaweth.c
+++ b/drivers/net/usb/kaweth.c
@@ -125,7 +125,7 @@ static int kaweth_resume(struct usb_interface *intf);
 /
  * usb_device_id
  /
-static struct usb_device_id usb_klsi_table[] = {
+static const struct usb_device_id usb_klsi_table[] = {
{ USB_DEVICE(0x03e8, 0x0008) }, /* AOX Endpoints USB Ethernet */
{ USB_DEVICE(0x04bb, 0x0901) }, /* I-O DATA USB-ET/T */
{ USB_DEVICE(0x0506, 0x03e8) }, /* 3Com 3C19250 */
-- 
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 14/35] net: usb: r8152: constify usb_device_id

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/r8152.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 6cfffef..ceb78e2 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -5303,7 +5303,7 @@ static void rtl8152_disconnect(struct usb_interface *intf)
.bInterfaceProtocol = USB_CDC_PROTO_NONE
 
 /* table of devices that work with this driver */
-static struct usb_device_id rtl8152_table[] = {
+static const struct usb_device_id rtl8152_table[] = {
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8050)},
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8152)},
{REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, 0x8153)},
-- 
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 15/35] net: usb: rtl8150: constify usb_device_id

[Arvind Yadav]

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

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/rtl8150.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index daaa88a..5f565bd 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -112,7 +112,7 @@
 #undef EEPROM_WRITE
 
 /* table of devices that work with this driver */
-static struct usb_device_id rtl8150_table[] = {
+static const struct usb_device_id rtl8150_table[] = {
{USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8150)},
{USB_DEVICE(VENDOR_ID_MELCO, PRODUCT_ID_LUAKTX)},
{USB_DEVICE(VENDOR_ID_MICRONET, PRODUCT_ID_SP128AR)},
-- 
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: [PATCH] usb: gadget: f_uac2: calculate wMaxPacketSize before endpoint match

[Sekhar Nori]

On Tuesday 08 August 2017 07:50 PM, Roger Quadros wrote:
> On 17/05/17 11:15, Sekhar Nori wrote:
>> Calculate wMaxPacketSize before endpoint matching the
>> descriptor is found.
>>
>> This allows audio gadget to be used with controllers
>> which have a shortage or unavailability of endpoints
>> that can handle max packet size of 1023 (FS) or 1024
>> (HS).
>>
>> With this audio gadget can be used on TI's OMAP-L138 SoC
>> which has a MUSB HS controller with endpoints having max
>> packet size much less than 1023 or 1024. See mode_2_cfg in
>> drivers/usb/musb/musb_core.c
>>
>> Signed-off-by: Sekhar Nori 
> 
> Acked-by: Roger Quadros 

Thanks Roger! This has already made it to upstream as commit
0db56e43359c47ff184ceaf8b04b664d997bff88.

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

Re: [PATCH] usb: gadget: f_uac2: calculate wMaxPacketSize before endpoint match

[Roger Quadros]

On 17/05/17 11:15, Sekhar Nori wrote:
> Calculate wMaxPacketSize before endpoint matching the
> descriptor is found.
> 
> This allows audio gadget to be used with controllers
> which have a shortage or unavailability of endpoints
> that can handle max packet size of 1023 (FS) or 1024
> (HS).
> 
> With this audio gadget can be used on TI's OMAP-L138 SoC
> which has a MUSB HS controller with endpoints having max
> packet size much less than 1023 or 1024. See mode_2_cfg in
> drivers/usb/musb/musb_core.c
> 
> Signed-off-by: Sekhar Nori 

Acked-by: Roger Quadros 

> ---
>  drivers/usb/gadget/function/f_uac2.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_uac2.c 
> b/drivers/usb/gadget/function/f_uac2.c
> index f6a0d3a1311b..5a7ba058d947 100644
> --- a/drivers/usb/gadget/function/f_uac2.c
> +++ b/drivers/usb/gadget/function/f_uac2.c
> @@ -1065,6 +1065,12 @@ afunc_bind(struct usb_configuration *cfg, struct 
> usb_function *fn)
>   agdev->as_in_intf = ret;
>   agdev->as_in_alt = 0;
>  
> + /* Calculate wMaxPacketSize according to audio bandwidth */
> + set_ep_max_packet_size(uac2_opts, _epin_desc, 1000, true);
> + set_ep_max_packet_size(uac2_opts, _epout_desc, 1000, false);
> + set_ep_max_packet_size(uac2_opts, _epin_desc, 8000, true);
> + set_ep_max_packet_size(uac2_opts, _epout_desc, 8000, false);
> +
>   agdev->out_ep = usb_ep_autoconfig(gadget, _epout_desc);
>   if (!agdev->out_ep) {
>   dev_err(dev, "%s:%d Error!\n", __func__, __LINE__);
> @@ -1080,12 +1086,6 @@ afunc_bind(struct usb_configuration *cfg, struct 
> usb_function *fn)
>   uac2->p_prm.uac2 = uac2;
>   uac2->c_prm.uac2 = uac2;
>  
> - /* Calculate wMaxPacketSize according to audio bandwidth */
> - set_ep_max_packet_size(uac2_opts, _epin_desc, 1000, true);
> - set_ep_max_packet_size(uac2_opts, _epout_desc, 1000, false);
> - set_ep_max_packet_size(uac2_opts, _epin_desc, 8000, true);
> - set_ep_max_packet_size(uac2_opts, _epout_desc, 8000, false);
> -
>   hs_epout_desc.bEndpointAddress = fs_epout_desc.bEndpointAddress;
>   hs_epin_desc.bEndpointAddress = fs_epin_desc.bEndpointAddress;
>  
> 

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

Re: [PATCH v2 2/3] usb: chipidea: Hook into mux framework to toggle usb switch

[Peter Rosin]

On 2017-08-08 03:51, Stephen Boyd wrote:
> Quoting Peter Rosin (2017-07-31 03:33:22)
>> On 2017-07-14 23:40, Stephen Boyd wrote:
>>> @@ -1964,16 +1965,26 @@ void ci_hdrc_gadget_destroy(struct ci_hdrc *ci)
>>>  
>>>  static int udc_id_switch_for_device(struct ci_hdrc *ci)
>>>  {
>>> + int ret = 0;
>>> +
>>>   if (ci->is_otg)
>>>   /* Clear and enable BSV irq */
>>>   hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
>>>   OTGSC_BSVIS | OTGSC_BSVIE);
>>>  
>>> - return 0;
>>> + if (!ci_otg_is_fsm_mode(ci))
>>> + ret = mux_control_select(ci->platdata->usb_switch, 0);
>>> +
>>> + if (ci->is_otg && ret)
>>> + hw_write_otgsc(ci, OTGSC_BSVIE | OTGSC_BSVIS, OTGSC_BSVIS);
>>> +
>>> + return ret;
>>>  }
>>>  
>>>  static void udc_id_switch_for_host(struct ci_hdrc *ci)
>>>  {
>>> + mux_control_deselect(ci->platdata->usb_switch);
>>> +
>>
>> This looks broken. You conditionally lock the mux and you unconditionally
>> unlock it. Quoting the mux_control_deselect doc:
>>
>>  * It is required that a single call is made to mux_control_deselect() for
>>  * each and every successful call made to either of mux_control_select() or
>>  * mux_control_try_select().
>>
>> Think of the mux as a semaphore with a max count of one. If you lock it,
>> you have to unlock it when you're done. If you didn't lock it, you have
>> zero business unlocking it. If you try to lock it but fail, you also have
>> no business unlocking it. Just like a semaphore.
> 
> Good catch. I've added a if (!ci_otg_is_fsm_mode()) check here.
> 
>>
>> Another point: I do not know if udc_id_switch_for_host is *only* called
>> when there has been a prior call to udc_id_switch_for_device that
>> succeeded or how this works exactly. But this all looks fragile. Using
>> mux_control_select and mux_control_deselect *must* be done in pairs.
>> If you want a mux to be locked for "a while", such as in this case, you
>> have to make sure you stay within the rules. There is no room for half
>> measures, or you will likely cause a deadlock when something unexpected
>> happens.
>>
> 
> Can you elaborate? Is it bad that we keep it "locked" while we're in
> host or device mode?

No no, that's good. You do not want some other consumer of the same mux
controller to clobber your state (in case it's shared), so you absolutely
want to have the mux locked when you want it to remain in a specific
position.

>  It looked like we paired the start/stop ops with
> each other so that the mux is properly managed across these ops.

Yes, it *looks* ok...

>  My
> testing hasn't shown a problem, but maybe there's some corner case
> you're thinking of? I'll double check the code.

...but since I do not know the usb code, I can't tell. What I worry about
is the usb core calling udc_id_switch_for_host or udc_id_switch_for_device
more than once without any call to the other in between. Maybe that is a
guarantee that the usb core makes? Or maybe it isn't? If e.g. there is a
third mode (or if one is added in the future), then the calls to
mux_control_select and mux_control_deselect would not be paired correctly.
Ok, sure, a third mode probably doesn't exist and will probably not be
added, but but but...

Also, what happens if udc_id_switch_for_device fails? Is it certain that
it will be called again before udc_id_switch_for_host is called, or is
the failure simply logged? If the latter, you might have a call to
mux_control_deselect without a preceding (and successful) call to
mux_control_select. That's fatal.

I have similar worries for host_start/host_stop, but for that case
host_stop is not allowed to fail, and it seems like a safe bet that
host_stop will only be called if host_start succeeds. So, I'm not as
worried there.

In other words, the question is if the usb core is designed to allow
this kind of "raw" resource administration in udc_id_switch_for_host and
udc_id_switch_for_device, or if you need to keep a local record of the
state so that you do not do double resource acquisition or attempt to
free resources you don't have?

I think I would feel better if the muxing for the device mode could
be done in a start/stop pair of function just like the host mode is
doing. Again, I don't know the usb code and don't know if such hooks
exist or not?

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

Re: [PATCH 4/4] dt-bindings: phy-mt65xx-usb: supports PCIe, SATA and rename file

[Kishon Vijay Abraham I]

Chunfeng

On Thursday 03 August 2017 03:50 PM, Chunfeng Yun wrote:
> hi,
> 
> I made a mistake, please ignore the patches with Change-Id, very sorry

No problem. However can you resend the series after fixing all checkpatch 
warnings?

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

[PATCH] usb/dwc3:constify dev_pm_ops

[Doug Wilson]

 dev_pm_ops is not supposed to change at runtime. Marking it
 constant.

Signed-off-by: Doug Wilson 
---
 drivers/usb/dwc3/dwc3-pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 7e995df..54343fb 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -345,7 +345,7 @@ static int dwc3_pci_resume(struct device *dev)
 }
 #endif /* CONFIG_PM_SLEEP */
 
-static struct dev_pm_ops dwc3_pci_dev_pm_ops = {
+static const struct dev_pm_ops dwc3_pci_dev_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(dwc3_pci_suspend, dwc3_pci_resume)
SET_RUNTIME_PM_OPS(dwc3_pci_runtime_suspend, dwc3_pci_runtime_resume,
NULL)
-- 
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 v3] usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter

[Kai-Heng Feng]

Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
connect to Realtek r8153.

The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
can make it work.

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

Signed-off-by: Kai-Heng Feng 
---
v3: Update comment to reflect the quirk is for the hub.

v2: Clarify that the adapter uses a hub internally.

 drivers/usb/core/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 3116edfcdc18..65a87efc100e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -150,6 +150,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
 
+   /* Genesys Logic hub, internally used by Moshi USB to Ethernet Adapter 
*/
+   { USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
+
/* Avision AV600U */
{ USB_DEVICE(0x0638, 0x0a13), .driver_info =
  USB_QUIRK_STRING_FETCH_255 },
-- 
2.14.0

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

RE: [PATCH v2 1/1] usbip: auto retry for concurrent attach

[fx IWATA NOBUO]

Hello,

> -Original Message-
> From: Shuah Khan [mailto:sh...@kernel.org]
> Sent: Thursday, August 03, 2017 2:27 AM
> To: fx IWATA NOBUO ;
> valentina.mane...@gmail.com; gre...@linuxfoundation.org;
> linux-usb@vger.kernel.org
> Cc: fx MICHIMURA TADAO ; Shuah
> Khan ; Shuah Khan 
> Subject: Re: [PATCH v2 1/1] usbip: auto retry for concurrent attach
> 
> Hi Nobuo Iwata,
> 
> Sorry for the delay. This one got lost in my Inbox.
> 
> On 05/28/2017 08:31 PM, Nobuo Iwata wrote:
> > This patch adds recovery from false busy state on concurrent attach
> > operation.
> >
> > The procedure of attach operation is as below.
> >
> > 1) Find an unused port in /sys/devices/platform/vhci_hcd/status.
> > (userspace)
> >
> > 2) Request attach found port to driver through
> > /sys/devices/platform/vhci_hcd/attach. (userspace)
> >
> > 3) Lock table, reserve requested port and unlock table. (vhci driver)
> >
> > Attaching more than one remote devices concurrently, same unused port
> > number will be found in step-1. Then one request will succeed and
> > others will fail even though there are some unused ports.
> >
> > It is possible to avoid this fail by introdocing userspace exclusive
> > control. But it's exaggerated for this special condition. The locking
> > itself is done in driver.
> 
> Please spell check the change log.

I will.

> > With this patch, driver returns EBUSY when requested port has already
> > been used. In this case, attach command retries from step-1: finding
> > another unused port. If there's no unused port, the attach operation
> > will fail. Othrwise it retries automatically using new free port.
> >
> > Currunt userspace src/usbip_attach.c:import_device() doesn't use the
> > errno.
> >
> > vhci-hcd's interface (only errno) is changed as following.
> >
> > Current errno   New errno   Condition
> > EINVAL  same as leftspecified port numbre is in
> invalid
> > range
> > EAGAIN  same as leftplatform_get_drvdata() failed
> > EINVAL  same as leftspecified socket fd is not valid
> > EINVAL  EBUSY   specified port status is not free
> >
> > ---
> > Version information
> >
> > v2)
> > Gathered usbip_vhci_driver_close() for errors under an exit label.
> 
> Greg KH already pointed this out. Please fix this.

OK.

> > Signed-off-by: Nobuo Iwata 
> > ---
> >  drivers/usb/usbip/vhci_sysfs.c |  8 ++--
> >  tools/usb/usbip/src/usbip_attach.c | 33
> +-
> >  2 files changed, 25 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/usb/usbip/vhci_sysfs.c
> b/drivers/usb/usbip/vhci_sysfs.c
> > index b96e5b1..5d4be4b 100644
> > --- a/drivers/usb/usbip/vhci_sysfs.c
> > +++ b/drivers/usb/usbip/vhci_sysfs.c
> > @@ -214,7 +214,7 @@ static ssize_t store_detach(struct device *dev,
> struct device_attribute *attr,
> >
> > ret = vhci_port_disconnect(hcd_to_vhci(hcd), rhport);
> > if (ret < 0)
> > -   return -EINVAL;
> > +   return ret;
> 
> Why are you changing the return value here? vhci_port_disconnect()
> currently only returns -EINVAL, however of that changes, userspace
> will see a different value. If the correct retunr value in this failure
> path is -EINVAL, let's not change that, unless there are good reasons
> do so.

Attach operation is done by searching a free port via sysfs and attach
specifying found free port with the port number.

If 2 processes try to attach concurrently, they will find same port
number and one will fail. In this failed case, it can restart from
searching a free port and it will be successfully attached if there's
another free port.

But other cases, specified port number is in invalid range (EINVAL),
platform_get_drvdata() failed (EAGAIN) or specified socket fd is not
valid (EINVAL), should not be retried.

To distinguish the cases, the different errno (EBUSY) is need for the
case if port number is valid range but used.

There may be other solutions:
Assigning port number in kernel module and return it to userspace.
Introducing exclusive control to userspace.
I think they need much difference in interface and functionality than this
patch.

> The rest looks good to me.
> 
> >
> > usbip_dbg_vhci_sysfs("Leave\n");
> >
> > @@ -314,7 +314,11 @@ static ssize_t store_attach(struct device *dev,
> struct device_attribute *attr,
> > sockfd_put(socket);
> >
> > dev_err(dev, "port %d already used\n", rhport);
> > -   return -EINVAL;
> > +   /*
> > +* Will be retried from userspace
> > +* if there's another free port.
> > +*/
> > +   return -EBUSY;
> > }
> >
> > dev_info(dev, "pdev(%u) rhport(%u) sockfd(%d)\n",
> > diff --git a/tools/usb/usbip/src/usbip_attach.c
> b/tools/usb/usbip/src/usbip_attach.c
> > index 70a6b50..f1e7ddd 100644
> 

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

[Kai-Heng Feng]

On Tue, Aug 8, 2017 at 4:28 PM, Oliver Neukum  wrote:
> Am Dienstag, den 08.08.2017, 14:32 +0800 schrieb Kai-Heng Feng:
>> Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
>> connect to Realtek r8153.
>>
>> The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
>> can make it work.
>>
>> Since another r8153 dongle at my hand does not have the issue, so add
>> the quirk to the hub instead.
>
> But in the comment you say you add it to the device!
> This makes no sense.

You are right, I forgot to update the comment. My bad.

>
> [..]
>> + /* Moshi USB to Ethernet Adapter */
>> + { USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
>> +
>
> Now is this a hub or a device? If this is a Genesys Logic hub,
> you need to say that clearly and state that it is an internal hub.

It's the Genesys Logic hub that being used internally.

I'll update the comment more clearly.

Thanks.

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

Re: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1 Toughbook

[Bjørn Mork]

Johan Hovold  writes:

> On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
>> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
>> From: Oleg Kokorin 
>> Date: Mon, 7 Aug 2017 15:35:53 +0200
>> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
>>  Toughbook
>
> Please use
>
>   USB: serial: qcserial: add support for Panasonic CF-U1 Toughbook
>
> as Subject (patch summary), and also add a commit message here (e.g.
> your current summary).
>
>> Signed-off-by: Oleg Kokorin 
>> ---
>>  drivers/usb/serial/qcserial.c | 2 ++
>>  1 file changed, 2 insertions(+)
>> 
>> diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
>> index ebc0bee..53786ce 100644
>> --- a/drivers/usb/serial/qcserial.c
>> +++ b/drivers/usb/serial/qcserial.c
>> @@ -76,6 +76,8 @@ static const struct usb_device_id id_table[] = {
>> {DEVICE_G1K(0x1bc7, 0x900e)},   /* Telit Gobi QDL device */
>>  
>> /* Gobi 2000 devices */
>> +   {USB_DEVICE(0x04da, 0x250e)},   /* Panasonic Gobi 2000 QDL device */
>> +   {USB_DEVICE(0x04da, 0x250f)},   /* Panasonic Gobi 2000 Modem device 
>> */
>
> This patch is whitespace-damaged and does not apply. Please try sending
> the patch to yourself first (e.g. using git-send-email) and make sure
> you can apply it it with git am. Running checkpatch on the result is
> also a good idea.

And please send a patch for qmi_wwan too, assuming this really is a Gobi
2000 modem. Thanks.


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

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

[Oliver Neukum]

Am Dienstag, den 08.08.2017, 14:32 +0800 schrieb Kai-Heng Feng:
> Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
> connect to Realtek r8153.
> 
> The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
> can make it work.
> 
> Since another r8153 dongle at my hand does not have the issue, so add
> the quirk to the hub instead.

But in the comment you say you add it to the device!
This makes no sense.

[..]
> + /* Moshi USB to Ethernet Adapter */
> + { USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
> +

Now is this a hub or a device? If this is a Genesys Logic hub,
you need to say that clearly and state that it is an internal hub.

Regards
Oliver

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

Re: new usb LTE modem device

[Bjørn Mork]

"Giuseppe Lippolis"  writes:

> Hi all,
> I'm working to port OpenWRT/LEDE on a new router with embedded usb LTE
> modem.
> The modem have 3 qmi_wwan interfaces and 2 option.
>
> I would like to prepare the patch, but before I would like to know if using
> the QMI_FIXED_INTF macro is the best way to identify the interface or if
> there is a better way.

That is currently the only implemented way, so it's definitely
simplest. And most likely the only method suitable for stable backports.

I agree that it is very inefficient to add 3 match lines for a single
device. We could consider adding an alternative matching method for this
kind of device, using an interface whitelist or blacklist.  I guess we
should if there are many more of these.

But we already have many Sierra devices with 2 QMI interfaces (the 3rd
one is documented and verified non-functional for unknown reasons). And
these tend to come with multiple OEM device IDs.  So a whitelist method
could reduce the number of matching entries considerably.  Feel free to
submit patches if you like :-)


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


Two questions: Did you verify that all 3 QMI interfaces work as
expected?  What is the storage function (last interface) good for on an
embedded USB modem?


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

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

[Kai-Heng Feng]

Moshi USB to Ethernet Adapter internally uses a Genesys Logic hub to
connect to Realtek r8153.

The Realtek r8153 ethernet does not work on the internal hub, no-lpm quirk
can make it work.

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

Signed-off-by: Kai-Heng Feng 
---
v2: Clarify that the adapter uses a hub internally.

 drivers/usb/core/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 3116edfcdc18..c96daf34431e 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -150,6 +150,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* appletouch */
{ USB_DEVICE(0x05ac, 0x021a), .driver_info = USB_QUIRK_RESET_RESUME },
 
+   /* Moshi USB to Ethernet Adapter */
+   { USB_DEVICE(0x05e3, 0x0616), .driver_info = USB_QUIRK_NO_LPM },
+
/* Avision AV600U */
{ USB_DEVICE(0x0638, 0x0a13), .driver_info =
  USB_QUIRK_STRING_FETCH_255 },
-- 
2.13.4

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

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

[Felipe Balbi]

Hi,

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

have you looked at drivers/usb/serial/?

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