[PATCH V8 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Reviewed-by: Stephen Boyd 
Acked-by: Rob Herring 
---

Changes since v7:
 - None, just added Stephen's Reviewed-by tag.

Changes since v6:
 - Dropped 'vdd-phy-supply' that used pm8994_s2 regulator, from bindings.
   As Stephen said, the pm8994_s2 is a 'corner' regulator and it shouldn't
   be right to put it as a regulator supply.
   Work is in progress to handle these sort of power supplies.

Changes since v5:
 - Removed leading 0 from the address in 'reg' property.

Changes since v4:
 - None.

Changes since v3:
 - Added 'Acked-by' from Rob.
 - Removed 'reset-names' and 'nvmem-cell-names' from the bindings
   since we use only one cell.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..aa0fcb05acb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,43 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x7411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   nvmem-cells = <_hstx_trim>;
+};
-- 
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 V8 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

Hi Kishon,
Here's the series with fixed checkpatch warnings/checks.
Please pick it for phy/next.

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These patches have been tested on Dragon board db820c hardware with
required set of dt patches.
The tested branch[3] is based on torvald's master with greg's usb/usb-next
merged. Additionally the patches to get rpm up on msm8996 are also pulled
in.

Changes since v7:
 - Fixed 'checkpatch --strict' alignment warnings/checks, and
   added Stephen's Reviewed-by tag.

Changes since v6:
 - Rebased on phy/next and *not* including phy grouping series[4].
 - qusb2-phy: addressed Stephen's comment.
   - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
 - qmp-phy: none on functionality side.
 
Changes since v5:
 - Addressed review comments from Bjorn:
   - Removed instances of readl/wirtel_relaxed calls from the drivers.
 Instead, using simple readl/writel. Inserting a readl after a writel
 to ensure the write is through to the device.
   - Replaced regulator handling with regulator_bulk_** apis. This helps
 in cutting down a lot of regulator handling code.
   - Fixed minor return statements.

Changes since v4:
 - Addressed comment to add child nodes for qmp phy driver. Each phy lane
   now has a separate child node under the main qmp node.
 - Modified the clock and reset initialization and enable methods.
   Different phys - pcie, usb and later ufs, have varying number of clocks
   and resets that are mandatory. So adding provision for clocks and reset
   lists helps in requesting all mandatory resources for individual phys
   and handle their failure cases accordingly.

Changes since v3:
 - Addressed review comments given by Rob and Stephen for qusb2 phy
   and qmp phy bindings respectively.
 - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] https://patchwork.kernel.org/patch/9567767/
[2] https://patchwork.kernel.org/patch/9567779/
[3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
[4] https://lkml.org/lkml/2017/3/20/407

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-qcom-qmp.c | 1153 
 drivers/phy/phy-qcom-qusb2.c   |  493 +
 6 files changed, 1815 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/phy-qcom-qmp.c
 create mode 100644 drivers/phy/phy-qcom-qusb2.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 V8 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Qualcomm SOCs have QMP phy controller that provides support
to a number of controller, viz. PCIe, UFS, and USB.
Add a new driver, based on generic phy framework, for this
phy controller.

Signed-off-by: Vivek Gautam 
Tested-by: Srinivas Kandagatla 
Reviewed-by: Stephen Boyd 
---

Changes since v7:
 - Fixed 'checkpatch --strict' alignment warnings/checks.
 - Added Stephen's Reviewed-by tag.

Changes since v6:
 - Rebased on phy/next and *not* including phy grouping series.

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, added an extra readl()
   over the register in qphy_setbits() and qphy_clrbits() to ensure that
   the write is through to the device.
 - Fixed nits about return statement from probe(), phy_pipe_clk_register()
   and qcom_qmp_phy_create().

Changes since v4:
 - Added provision for child nodes representing each phy lane.
   Each of these nodes have their own register space for tx, rx and pcs
   blocks. Added provision in qcom_qmp_phy_create() to iomap these
   address spaces.
 - Added list of clocks and resets that are mandatory for each phy.
   qcom_qmp_phy_clk_init(), and qcom_qmp_phy_reset_init() methods
   request this list and maintains it with qmp.
   The clocks and resets are then enabled/de-asserted based on this list.
   This list is also updated in the binding documentation.
 - Removed qcom_qmp_phy_xlate() method as we don't need it with
   #phy-cells 0.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.
 - Updated copyright year to 2017.

Changes since v3:
 - Renamed 'struct qcom_qmp_phy' to 'struct qcom_qmp' and
   'struct qmp_phy_desc' to 'struct qmp_phy' to avoid any confusion
   in distinguishing between QMP phy block and per-lane phy which is
   the actual phy in Linux eyes (suggested by Bjorn Andersson).
 - Made error labels more idiomatic.
 - Modified status checking for phy pcs.
 - Fixed power_down_delay check.
 - Refactored phy_pipe_clk_register() to register the pipe clock source
   using devm_clk_hw_register() (suggested by Stephen).
 - qcom_qmp_phy_xlate() function:
   - Removed unnecessary 'for loop'.
   - Added additional check for '0' or -ve args_count.
 - Fixed the mixed tabs and spaces in pipe_clk_src diagram.
 - Removed instances of memset() since we use snprintf() for the
   buffers.
 - Refactored qphy_setbits() and qphy_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/Kconfig|8 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-qcom-qmp.c | 1153 
 3 files changed, 1162 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qmp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccc9178e32cd..bb8140355608 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -439,6 +439,14 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QMP
+   tristate 

[PATCH V8 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Reviewed-by: Stephen Boyd 
Acked-by: Rob Herring 
---

Changes since v7:
 - None, just added Stephen's Reviewed-by tag.

Changes since v6:
 - none.

Changes since v5:
 - Added Rob's 'Ack' for the new child nodes based bindings.
 - Dropped leading 0 from the address in 'reg' property.
 - Fixed '@xyz' part of the node name with correct address.

Changes since v4:
 - Added bindings for child nodes. Each phy lane is represented by child
   node with its own register space (for tx, rx and pcs blocks), and clocks
   and resets for power control facility.
 - Removed register space and lane offsets for tx, rx and pcs blocks from
   qmp phy node.
 - #phy-cells is now part of each child node and thus must be 0.
 - Added information on list of mandatory clocks and resets for each phy.

Changes since v3:
 - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - Added 'Acked-by' from Rob.
 - Updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - Added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..e11c563a65ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,106 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+
+ - reg: offset and length of register set for PHY's common serdes block.
+
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - #address-cells: must be 1
+ - #size-cells: must be 1
+ - ranges: must be present
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: "cfg_ahb" for phy config clock,
+   "aux" for phy aux clock,
+   "ref" for 19.2 MHz ref clk,
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+   For "qcom,msm8996-qmp-usb3-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: "phy" for reset of phy block,
+   "common" for phy common block reset,
+   "cfg" for phy's ahb cfg block reset (Optional).
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+"phy", "common", "cfg".
+   For "qcom,msm8996-qmp-usb3-phy" must contain
+"phy", "common".
+
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+   pll block.
+
+Required nodes:
+ - Each device node of QMP phy is required to have as many child nodes as
+   the number of lanes the PHY has.
+
+Required properties for child node:
+ - reg: list of offset and length pairs of register sets for PHY blocks -
+   tx, rx and pcs.
+
+ - #phy-cells: must be 0
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: Must contain following for pcie and usb qmp phys:
+"pipe" for pipe clock specific to each lane.
+
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: Must contain following for pcie qmp phys:
+"lane" for reset specific to each lane.
+
+Example:
+   phy@34000 {
+   

[PATCH V8 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam 
Reviewed-by: Stephen Boyd 
---

Changes since v7:
 - Fixed 'checkpatch --strict' alignment warnings/checks.

Changes since v6:
 - Dropped 'vdd-phy' from list of regulators.
 - Rebased on phy/next and *not* including phy grouping series.

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, using readl() over
   the register to ensure that the write is through to the device.
 - Fixed nits about return statement from probe() and qusb2_phy_poweron().

Changes since v4:
 - Updated the copyright year to 2017.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.

Changes since v3:
 - Added 'Reviewed-by' from Stephen.
 - Fixed debug message for qusb2_phy_set_tune2_param().
 - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
   since we are requesting only one reset.
 - Updated devm_nvmem_cell_get() with a NULL cell id.
 - Made error labels more idiomatic.
 - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/Kconfig  |  10 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qcom-qusb2.c | 493 +++
 3 files changed, 504 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dc5277ad1b5a..ccc9178e32cd 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -439,6 +439,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index e7b0feb1e125..0375c6a32697 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_STIH407_USB)  += phy-stih407-usb.o
+obj-$(CONFIG_PHY_QCOM_QUSB2)   += phy-qcom-qusb2.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..6c575244c0fb
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,493 @@
+/*
+ * Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms 

Re: [PATCH V7 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Stephen Boyd]

On 04/05, Vivek Gautam wrote:
> Qualcomm SOCs have QMP phy controller that provides support
> to a number of controller, viz. PCIe, UFS, and USB.
> Add a new driver, based on generic phy framework, for this
> phy controller.
> 
> Signed-off-by: Vivek Gautam 
> Tested-by: Srinivas Kandagatla 
> ---

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of 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

Re: [PATCH V7 3/4] dt-bindings: phy: Add support for QMP phy

[Stephen Boyd]

On 04/05, Vivek Gautam wrote:
> Qualcomm chipsets have QMP phy controller that provides
> support to a number of controller, viz. PCIe, UFS, and USB.
> Adding dt binding information for the same.
> 
> Signed-off-by: Vivek Gautam 
> Acked-by: Rob Herring 
> ---

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of 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

Re: [PATCH V7 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Stephen Boyd]

On 04/05, Vivek Gautam wrote:
> Qualcomm chipsets have QUSB2 phy controller that provides
> HighSpeed functionality for DWC3 controller.
> Adding dt binding information for the same.
> 
> Signed-off-by: Vivek Gautam 
> Acked-by: Rob Herring 
> ---

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of 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 v2] ARM: davinci: Add the clock for the CPPI 4.1 DMA engine

[Alexandre Bailon]

The CPPI 4.1 DMA is sharing its clock with the USB OTG,
and most of the time, the clock will be enabled by USB.
But during the init of the DMA, USB is not enabled (waiting for DMA),
and then we must enable the clock before doing anything.
Add the clock for the CPPI 4.1 DMA engine.

Signed-off-by: Alexandre Bailon 
---
 arch/arm/mach-davinci/da830.c | 6 ++
 arch/arm/mach-davinci/da850.c | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 073c458..bd88470 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -304,6 +304,11 @@ static struct clk usb20_clk = {
.gpsc   = 1,
 };
 
+static struct clk cppi41_clk = {
+   .name   = "cppi41",
+   .parent = _clk,
+};
+
 static struct clk aemif_clk = {
.name   = "aemif",
.parent = _sysclk3,
@@ -413,6 +418,7 @@ static struct clk_lookup da830_clks[] = {
CLK("davinci-mcasp.1",  NULL,   _clk),
CLK("davinci-mcasp.2",  NULL,   _clk),
CLK("musb-da8xx",   "usb20",_clk),
+   CLK("cppi41-dmaengine", NULL,   _clk),
CLK(NULL,   "aemif",_clk),
CLK(NULL,   "aintc",_clk),
CLK(NULL,   "secu_mgr", _mgr_clk),
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index ccad2f9..07d6f0e 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -401,6 +401,11 @@ static struct clk usb20_clk = {
.gpsc   = 1,
 };
 
+static struct clk cppi41_clk = {
+   .name   = "cppi41",
+   .parent = _clk,
+};
+
 static struct clk spi0_clk = {
.name   = "spi0",
.parent = _sysclk2,
@@ -560,6 +565,7 @@ static struct clk_lookup da850_clks[] = {
CLK("davinci-nand.0",   "aemif",_nand_clk),
CLK("ohci-da8xx",   "usb11",_clk),
CLK("musb-da8xx",   "usb20",_clk),
+   CLK("cppi41-dmaengine", NULL,   _clk),
CLK("spi_davinci.0",NULL,   _clk),
CLK("spi_davinci.1",NULL,   _clk),
CLK("vpif", NULL,   _clk),
-- 
2.10.2

--
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] ARM: davinci: Add the clock for the CPPI 4.1 DMA engine

[Alexandre Bailon]

On 04/04/2017 08:16 AM, Sekhar Nori wrote:

On Wednesday 29 March 2017 09:39 PM, Alexandre Bailon wrote:

The CPPI 4.1 DMA is sharing its clock with the USB OTG,
and most of the time, the clock will be enabled by USB.
But during the init of the DMA, USB is not enabled (waiting for DMA),
and then we must enable the clock before to do anything.
Add the clock for the CPPI 4.1 DMA engine.

Note:
This patch is to apply instead of:
"ARM: davinci: Make the usb20 clock available to PM runtime"

Okay, but I still liked the fact that that patch was using NULL as
con_id for MUSB clock. That makes sense because MUSB gets a single clock
input. I think you should still make that change. If not for v4.12, then
for v4.13.


Signed-off-by: Alexandre Bailon 
---
  arch/arm/mach-davinci/da830.c| 1 +
  arch/arm/mach-davinci/da850.c| 1 +
  arch/arm/mach-davinci/da8xx-dt.c | 2 ++
  3 files changed, 4 insertions(+)

diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 073c458..ae4a8a5 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -413,6 +413,7 @@ static struct clk_lookup da830_clks[] = {
CLK("davinci-mcasp.1",NULL,   _clk),
CLK("davinci-mcasp.2",NULL,   _clk),
CLK("musb-da8xx", "usb20",  _clk),
+   CLK("cppi41-dmaengine",   NULL,   _clk),

Did you try reading /sys/kernel/debug/davinci_clocks after this patch?
It will hang because of the loop created here.

I have tried and I did not get any issues.


Looks like what you want is cppi4.1 dma clock to be a child of MUSB
clock. That way, even if DMA is enabled before MUSB, it still works.

OK. I will update the patch to make cppi4.1 clock a child of usb clock.


Thanks,
Sekhar

Thanks,
Alexandre
--
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][linux-next] dmaengine: cppi41: Fix an Oops happening in cppi41_dma_probe()

[Alexandre Bailon]

This fix an Oops happening on all platforms using the old dt bindings
(all platforms but da8xx).
This update cppi41_dma_probe() to use the index variable which is
required to keep compatibility between old and new dt bindings.

Fixes: 8e3ba95f4190 ("dmaengine: cppi41: use managed functions devm_*()")
Reported-by: Tony Lindgren 
Signed-off-by: Alexandre Bailon 
---
 drivers/dma/cppi41.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 0be56c9..f7e965f 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -1038,17 +1038,17 @@ static int cppi41_dma_probe(struct platform_device 
*pdev)
if (index < 0)
return index;
 
-   mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, index);
cdd->ctrl_mem = devm_ioremap_resource(dev, mem);
if (IS_ERR(cdd->ctrl_mem))
return PTR_ERR(cdd->ctrl_mem);
 
-   mem = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, index + 1);
cdd->sched_mem = devm_ioremap_resource(dev, mem);
if (IS_ERR(cdd->sched_mem))
return PTR_ERR(cdd->sched_mem);
 
-   mem = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+   mem = platform_get_resource(pdev, IORESOURCE_MEM, index + 2);
cdd->qmgr_mem = devm_ioremap_resource(dev, mem);
if (IS_ERR(cdd->qmgr_mem))
return PTR_ERR(cdd->qmgr_mem);
-- 
2.10.2

--
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: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Tony Lindgren  [170405 06:53]:
> * Peter Ujfalusi  [170405 00:15]:
> > To be precise this is what I have tried:
> > - boot w/o cable connected
> > - boot w/ board connected to PC (device mode)
> > - boot w/ OTG-A cable with USB keyboard
> > - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> > 
> > w/ and w/o this patch I have the same flood of prints in all cases.
> 
> OK interesting that it also happens with nothing connected.
> 
> > Fwiw I have checked where the is_active is set - which causes the prints:
> > musb_core.c:musb_start()
> > 
> > if (musb->port_mode != MUSB_PORT_MODE_HOST &&
> > musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
> > (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
> > musb->is_active = 1;
> > } else {
> > devctl |= MUSB_DEVCTL_SESSION;
> > }
> > 
> > this was the only place where the is_active was set to 1.
> 
> That seems normal in musb_start(). Will try with your .config
> here.

If the the port is configured as OTG, we should not need to
try to force any states during init. The change below will stop
the warnings with your .config, needs to be tested more though
to make sure things still work in all cases.

Regards,

Tony

8< --
diff --git a/drivers/usb/musb/musb_host.c b/drivers/usb/musb/musb_host.c
--- a/drivers/usb/musb/musb_host.c
+++ b/drivers/usb/musb/musb_host.c
@@ -2780,10 +2780,11 @@ int musb_host_setup(struct musb *musb, int power_budget)
int ret;
struct usb_hcd *hcd = musb->hcd;
 
-   MUSB_HST_MODE(musb);
-   musb->xceiv->otg->default_a = 1;
-   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
-
+   if (musb->port_mode == MUSB_PORT_MODE_HOST) {
+   MUSB_HST_MODE(musb);
+   musb->xceiv->otg->default_a = 1;
+   musb->xceiv->otg->state = OTG_STATE_A_IDLE;
+   }
otg_set_host(musb->xceiv->otg, >self);
hcd->self.otg_port = 1;
musb->xceiv->otg->host = >self;
-- 
2.12.2
--
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 V7 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

Hi Kishon,


On Wed, Apr 5, 2017 at 7:08 PM, Kishon Vijay Abraham I  wrote:
> Hi Vivek,
>
> On Wednesday 05 April 2017 06:02 PM, Vivek Gautam wrote:
>> This patch series adds couple of PHY drivers for Qualcomm chipsets.
>> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
>> b) qcom-qmp phy driver: that is a combo phy providing support for
>>USB3, PCIe, UFS and few other controllers.
>>
>> The patches are based on next branch of linux-phy tree.
>>
>> These patches have been tested on Dragon board db820c hardware with
>> required set of dt patches and the patches to get rpm up on msm8996.
>> Couple of other patches [1, 2] fixing DMA config for XHCI are also
>> pulled in for testing.
>> A branch based on torvald's master is available in github [3].
>
> I get a bunch of checkpatch errors/warnings when I run checkpatch with 
> --strict
> option. Those look simple enough to be fixed. Can you respin your series 
> fixing
> those?

Sure, I am on it.
Thanks for pointing out.

Regards
Vivek

>
> Thanks
> Kishon
>
>>
>> Changes since v6:
>>  - Rebased on phy/next and *not* including phy grouping series[4].
>>  - qusb2-phy: addressed Stephen's comment.
>>- Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
>>  - qmp-phy: none on functionality side.
>>
>> Changes since v5:
>>  - Addressed review comments from Bjorn:
>>- Removed instances of readl/wirtel_relaxed calls from the drivers.
>>  Instead, using simple readl/writel. Inserting a readl after a writel
>>  to ensure the write is through to the device.
>>- Replaced regulator handling with regulator_bulk_** apis. This helps
>>  in cutting down a lot of regulator handling code.
>>- Fixed minor return statements.
>>
>> Changes since v4:
>>  - Addressed comment to add child nodes for qmp phy driver. Each phy lane
>>now has a separate child node under the main qmp node.
>>  - Modified the clock and reset initialization and enable methods.
>>Different phys - pcie, usb and later ufs, have varying number of clocks
>>and resets that are mandatory. So adding provision for clocks and reset
>>lists helps in requesting all mandatory resources for individual phys
>>and handle their failure cases accordingly.
>>
>> Changes since v3:
>>  - Addressed review comments given by Rob and Stephen for qusb2 phy
>>and qmp phy bindings respectively.
>>  - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
>>
>> Changes since v2:
>>  - Addressed review comments given by Rob and Stephen for bindings.
>>  - Addressed the review comments given by Stephen for the qusb2 and qmp
>>phy drivers.
>>
>> Changes since v1:
>>  - Moved device tree binding documentation to separate patches, as suggested
>>by Rob.
>>  - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
>>given by Rob.
>>  - Addressed review comments from Kishon.
>>  - Addressed review comments from Srinivas for QMP phy driver.
>>  - Addressed kbuild warning.
>>
>> Please see individual patches for detailed changelogs.
>>
>> [1] https://patchwork.kernel.org/patch/9567767/
>> [2] https://patchwork.kernel.org/patch/9567779/
>> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
>> [4] https://lkml.org/lkml/2017/3/20/407
>>
>> Vivek Gautam (4):
>>   dt-bindings: phy: Add support for QUSB2 phy
>>   phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
>>   dt-bindings: phy: Add support for QMP phy
>>   phy: qcom-qmp: new qmp phy driver for qcom-chipsets
>>
>>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
>>  .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
>>  drivers/phy/Kconfig|   18 +
>>  drivers/phy/Makefile   |2 +
>>  drivers/phy/phy-qcom-qmp.c | 1153 
>> 
>>  drivers/phy/phy-qcom-qusb2.c   |  491 +
>>  6 files changed, 1813 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>>  create mode 100644 drivers/phy/phy-qcom-qmp.c
>>  create mode 100644 drivers/phy/phy-qcom-qusb2.c
>>
> --
> 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



-- 
Qualcomm Innovation Center, Inc. is a member of 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

Re: [PATCH v3 1/3] usb: udc: allow adding and removing the same gadget device

[Alan Stern]

On Wed, 5 Apr 2017, Felipe Balbi wrote:

> >> >> --- a/drivers/usb/gadget/udc/core.c
> >> >> +++ b/drivers/usb/gadget/udc/core.c
> >> >> @@ -1273,6 +1273,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
> >> >> flush_work(>work);
> >> >> device_unregister(>dev);
> >> >> device_unregister(>dev);
> >> >> +   memset(>dev, 0x00, sizeof(gadget->dev));
> >> >>  }
> >> >>  EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
> >> >
> >> > Isn't this dangerous?  It's quite possible that the device_unregister() 
> >> 
> >> not on the gadget API, no.
> >> 
> >> > call on the previous line invokes the gadget->dev.release callback, 
> >> > which might deallocate gadget.  If that happens, your new memset will 
> >> > oops.
> >> 
> >> that won't happen. struct usb_gadget is a member of the UDC's private
> >> structure, like this:
> >> 
> >> struct dwc3 {
> >>[...]
> >>struct usb_gadget   gadget;
> >>struct usb_gadget_driver *gadget_driver;
> >>[...]
> >> };
> >
> > Yes.  So what?  Can't the UDC driver use the refcount inside struct 
> > usb_gadget to control the lifetime of its private structure?
> 
> nope, not being used. At least not yet.

I'm not convinced (yet)...

> > (By the way, can you tell what's going on in net2280.c?  I must be
> > missing something; it looks like gadget_release() would quickly run
> > into problems because it calls dev_get_drvdata() for >dev, but
> > net2280_probe() never calls dev_set_drvdata() for that device.  
> > Furthermore, net2280_remove() continues to reference the net2280 struct
> > after calling usb_del_gadget_udc(), and it never does seem to do a
> > final put.)
> 
> static int net2280_probe(struct pci_dev *pdev, const struct pci_device_id *id)
> {
>   struct net2280  *dev;
>   unsigned long   resource, len;
>   void__iomem *base = NULL;
>   int retval, i;
> 
>   /* alloc, and start init */
>   dev = kzalloc(sizeof(*dev), GFP_KERNEL);
>   if (dev == NULL) {
>   retval = -ENOMEM;
>   goto done;
>   }
> 
>   pci_set_drvdata(pdev, dev);
>   ^^^

That sets the driver data in the struct pci_dev, not in
dev->gadget.dev.  As far as I can see, _nothing_ in the driver sets the 
driver data in dev->gadget.dev.

(Even after all these years, I still get bothered by the way Dave 
Brownell used to call everything "dev"...  IIRC, at one time he had a 
line of code that went something like:  dev->dev.dev = >dev !)

> >> I'm actually thinking that struct usb_gadget shouldn't have a struct
> >> device at all. Just a pointer to a device, that would solve all these
> >> issues.
> >
> > A pointer to which device?  The UDC?  That would change the directory 
> > layout in sysfs.
> 
> indeed. Would that be a problem?

Possibly for some userspace tool.

> > Or a pointer to a separate dynamically allocated device (the way struct 
> > usb_hcd contains a pointer to the root hub device)?  That would work.  
> > If the UDC driver wanted to re-register the gadget, it would have to 
> > allocate a new device.
> 
> That could be done as well, if maintaining the directory structure is a
> must.

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

[PATCH 3/3] usb: dwc2: Power off the phy on shutdown

[Sjoerd Simons]

On a board with a usb->sata bridge behind a usb hub, the bridge only
appears on cold boot and becomes non-functional after a reboot. Testing
thusfar shows that it gets confused during reboot if the usb hub is left
on (Interestingly a similar setup without the usb hub in between doesn't
have the issue).  This can be avoided by turning off the phy (thus vbus)
during shutdown, which turns off the usb hub.

For devices where this isn't required, powering down the phy is harmless
so we can do this unconditionally.

Signed-off-by: Sjoerd Simons 

---

 drivers/usb/dwc2/platform.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 9564bc76c56f..b5bbc433c94d 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -348,6 +348,9 @@ static void dwc2_driver_shutdown(struct platform_device 
*dev)
 {
struct dwc2_hsotg *hsotg = platform_get_drvdata(dev);
 
+   if (hsotg->phy)
+   phy_power_off(hsotg->phy);
+
disable_irq(hsotg->irq);
 }
 
-- 
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 0/3] rockchip dwc2: Turn off vbus on shutdown

[Sjoerd Simons]

A board I'm working on seems to get its usb->sata bridge in a rather
confused state during reboot, which unfortunately can't be recovered on
the next boot (only hard reset helps).

This seems to be avoidable by turning off vbus, which turns the internal
usb hub off on shutdown.

First patch add the ability to describe vbus regulators for the rockchip
usb phy, second one starts using that on the rock2 square board and
while the final one adds the actual workaround of turning off the phy on
shutdown.


Sjoerd Simons (3):
  phy: rockchip-usb: Add vbus regulator support.
  ARM: dts: rockchip: rock2: Setup usb vbus-supply
  usb: dwc2: Power off the phy on shutdown

 .../devicetree/bindings/phy/rockchip-usb-phy.txt  |  1 +
 arch/arm/boot/dts/rk3288-rock2-square.dts |  8 
 drivers/phy/phy-rockchip-usb.c| 19 +++
 drivers/usb/dwc2/platform.c   |  3 +++
 4 files changed, 27 insertions(+), 4 deletions(-)

-- 
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 v2 24/24] usb: xhci: bInterval quirk for TI TUSB73x0

[Mathias Nyman]

From: Roger Quadros 

As per [1] issue #4,
"The periodic EP scheduler always tries to schedule the EPs
that have large intervals (interval equal to or greater than
128 microframes) into different microframes. So it maintains
an internal counter and increments for each large interval
EP added. When the counter is greater than 128, the scheduler
rejects the new EP. So when the hub re-enumerated 128 times,
it triggers this condition."

This results in Bandwidth error when devices with periodic
endpoints (ISO/INT) having bInterval > 7 are plugged and
unplugged several times on a TUSB73x0 XHCI host.

Workaround this issue by limiting the bInterval to 7
(i.e. interval to 6) for High-speed or faster periodic endpoints.

[1] - http://www.ti.com/lit/er/sllz076/sllz076.pdf

Cc: stable 
Signed-off-by: Roger Quadros 
Signed-off-by: Mathias Nyman 
---
 drivers/usb/host/xhci-mem.c | 11 +++
 drivers/usb/host/xhci-pci.c |  3 +++
 drivers/usb/host/xhci.h |  1 +
 3 files changed, 15 insertions(+)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index b88ec9a..2954b90 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1503,6 +1503,17 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
 */
max_esit_payload = xhci_get_max_esit_payload(udev, ep);
interval = xhci_get_endpoint_interval(udev, ep);
+
+   /* Periodic endpoint bInterval limit quirk */
+   if (usb_endpoint_xfer_int(>desc) ||
+   usb_endpoint_xfer_isoc(>desc)) {
+   if ((xhci->quirks & XHCI_LIMIT_ENDPOINT_INTERVAL_7) &&
+   udev->speed >= USB_SPEED_HIGH &&
+   interval >= 7) {
+   interval = 6;
+   }
+   }
+
mult = xhci_get_endpoint_mult(udev, ep);
max_packet = usb_endpoint_maxp(>desc);
max_burst = xhci_get_endpoint_max_burst(udev, ep);
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fc99f51..7b86508 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -199,6 +199,9 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
pdev->device == 0x1042)
xhci->quirks |= XHCI_BROKEN_STREAMS;
 
+   if (pdev->vendor == PCI_VENDOR_ID_TI && pdev->device == 0x8241)
+   xhci->quirks |= XHCI_LIMIT_ENDPOINT_INTERVAL_7;
+
if (xhci->quirks & XHCI_RESET_ON_RESUME)
xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
"QUIRK: Resetting on resume");
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index dbe8ba9..914968c 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1820,6 +1820,7 @@ struct xhci_hcd {
 #define XHCI_MISSING_CAS   (1 << 24)
 /* For controller with a broken Port Disable implementation */
 #define XHCI_BROKEN_PORT_PED   (1 << 25)
+#define XHCI_LIMIT_ENDPOINT_INTERVAL_7 (1 << 26)
 
unsigned intnum_active_eps;
unsigned intlimit_active_eps;
-- 
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 v2 3/6] usb: usbip tool: Add ncontrollers in vhci_driver structure

[Krzysztof Opasiak]

On 04/05/2017 04:03 AM, Yuyang Du wrote:

On Wed, Apr 05, 2017 at 11:46:06AM +0200, Krzysztof Opasiak wrote:



On 04/04/2017 09:08 PM, Yuyang Du wrote:

Hi Krzysztof,

On Tue, Apr 04, 2017 at 04:52:32PM +0200, Krzysztof Opasiak wrote:



On 03/31/2017 02:28 AM, Yuyang Du wrote:

A new field ncontrollers is added to the vhci_driver structure.
And this field is stored by scanning the vhci_hcd* dirs in the
platform udev.

Suggested-by: Krzysztof Opasiak 
Signed-off-by: Yuyang Du 
---
tools/usb/usbip/libsrc/vhci_driver.c | 32 +++-
tools/usb/usbip/libsrc/vhci_driver.h |  1 +
2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index f659c14..ccecd47 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -7,6 +7,7 @@
#include 
#include 
#include 
+#include 
#include "sysfs_utils.h"

#undef  PROGNAME
@@ -134,6 +135,33 @@ static int get_nports(void)
return (int)strtoul(attr_nports, NULL, 10);
}

+static int vhci_hcd_filter(const struct dirent *dirent)
+{
+   return strcmp(dirent->d_name, "vhci_hcd") >= 0 ? 1: 0;


The ? operator may be omitted here as according to doc we need to
return nonzero not 1 exactly.


No, it can't. strcmp() would return negative if not containing "vhci_hcd". E.g.,

strcmp("!@#", "vhci_hcd") ==> -1
strcmp("v", "vhci_hcd") ==> -1


I meant, just to drop the ? itself but leave >= 0

return strcmp(dirent->d_name, "vhci_hcd") >= 0;


Oh, that's doable :)

Send a Reviewed-by ?


I will review also the next version and then give the Reviewed-by as 
there was also some error handling missing in this patch.


Best regards
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
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: document that URB transfer_buffer should be aligned

[Mauro Carvalho Chehab]

Several host controllers, commonly found on ARM, like dwc2,
require buffers that are CPU-word aligned for they to work.

Failing to do that will cause buffer overflows at the caller
drivers, with could cause data corruption.

Such data corruption was found, in practice, with the uvcdriver.

Document it.

Signed-off-by: Mauro Carvalho Chehab 
---

Note: this patch is based on my previous patch series with
converts URB.txt to ReST:

Subject: [PATCH v2 00/21] Convert USB documentation to ReST format
Date: Wed,  5 Apr 2017 10:22:54 -0300
https://marc.info/?l=linux-doc=149139868231095=2

This patch, together with the ones above can be found on this tree:
 
   https://git.linuxtv.org/mchehab/experimental.git/log/?h=usb-docs-v2

 Documentation/driver-api/usb/URB.rst | 12 
 drivers/usb/core/message.c   | 15 +++
 include/linux/usb.h  | 12 
 3 files changed, 39 insertions(+)

diff --git a/Documentation/driver-api/usb/URB.rst 
b/Documentation/driver-api/usb/URB.rst
index 61a54da9fce9..8d3f362fbe82 100644
--- a/Documentation/driver-api/usb/URB.rst
+++ b/Documentation/driver-api/usb/URB.rst
@@ -271,6 +271,18 @@ If you specify your own start frame, make sure it's 
several frames in advance
 of the current frame.  You might want this model if you're synchronizing
 ISO data with some other event stream.
 
+ .. warning::
+
+   Several host drivers have a 32-bits or 64-bits DMA transfer word size,
+   with usually matches the CPU word. Due to such restriction, you should
+   warrant that the @transfer_buffer is DWORD aligned, on 32 bits system, or
+   QDWORD aligned, on 64 bits system. You should also ensure that the
+   buffer has enough space for PAD bits.
+
+   This condition is satisfied if you pass a buffer directly allocated by
+   kmalloc(), but this may not be the case if the driver allocates a bigger
+   buffer and point to a random place inside it.
+
 
 How to start interrupt (INT) transfers?
 ===
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 4c38ea41ae96..1662a4446475 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -128,6 +128,21 @@ static int usb_internal_control_msg(struct usb_device 
*usb_dev,
  * make sure your disconnect() method can wait for it to complete. Since you
  * don't have a handle on the URB used, you can't cancel the request.
  *
+ * .. note::
+ *
+ *   Several host drivers require that the @data buffer to be aligned
+ *   with the CPU word size (e. g. DWORD for 32 bits, QDWORD for 64 bits).
+ *   It is up to USB drivers should ensure that they'll only pass buffers
+ *   with such alignments.
+ *
+ *   Please also notice that, due to such restriction, the host driver
+ *   may also override PAD bytes at the end of the @data buffer, up to the
+ *   size of the CPU word.
+ *
+ *   Such word alignment condition is normally ensured if the buffer is
+ *   allocated with kmalloc(), but this may not be the case if the driver
+ *   allocates a bigger buffer and point to a random place inside it.
+ *
  * Return: If successful, the number of bytes transferred. Otherwise, a 
negative
  * error number.
  */
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 7e68259360de..5739d4422343 100644
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -1373,6 +1373,18 @@ typedef void (*usb_complete_t)(struct urb *);
  * capable, assign NULL to it, so that usbmon knows not to use the value.
  * The setup_packet must always be set, so it cannot be located in highmem.
  *
+ * .. warning::
+ *
+ *   Several host drivers have a 32-bits or 64-bits DMA transfer word size,
+ *   with usually matches the CPU word. Due to such restriction, you should
+ *   warrant that the @transfer_buffer is DWORD aligned, on 32 bits system, or
+ *   QDWORD aligned, on 64 bits system. You should also ensure that the
+ *   buffer has enough space for PAD bits.
+ *
+ *   This condition is satisfied if you pass a buffer directly allocated by
+ *   kmalloc(), but this may not be the case if the driver allocates a bigger
+ *   buffer and point to a random place inside it.
+ *
  * Initialization:
  *
  * All URBs submitted must initialize the dev, pipe, transfer_flags (may be
-- 
2.9.3


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

Re: usb: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Tony Lindgren]

* Peter Ujfalusi  [170405 00:15]:
> Tony,
> 
> On 2017-04-05 03:36, Tony Lindgren wrote:
> > * Tony Lindgren  [170404 07:06]:
> > > * Bin Liu  [170404 05:30]:
> > > > On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:
> > > > > Tony,
> > > > > 
> > > > > since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
> > > > > is compiled in. The kernel will stuck printing:
> > > > > 
> > > > > ** 206 printk messages dropped ** [8.926727] musb_bus_suspend
> > > > > 2584: trying to suspend as a_idle while active
> > > 
> > > OK so compiled in. Do you have something connected also when
> > > booting?
> > > 
> > > > Does it sound a similar issue to
> > > > http://marc.info/?l=linux-usb=149036531809506=2
> > > 
> > > Yup.
> > > 
> > > > > The bisect (log is [1]) points to:
> > > > > d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order 
> > > > > error
> > > > > 
> > > > > and reverting the d8e5f0eca1e8 makes the board to boot up fine
> > > > > (Linux 4.11-rc5 and next-20170331).
> > > 
> > > OK thanks for bisecting it.
> > > 
> > > > > any idea on how to fix this w/o reverting the commit?
> > > 
> > > I'll take a look.
> > 
> > OK I was able to reproduce this with loadable modules by reloading
> > the modules while having OTG-A cable inserted with a hub and USB
> > drive connected.
> > 
> > Peter, care to check if the following fixes the problem for you?
> > There should no longer be much any musb core tinkering happening
> > in the glue layers..
> 
> I had similar hunch first, but did not worked. I have tested this patch and
> did not helped.
> 
> To be precise this is what I have tried:
> - boot w/o cable connected
> - boot w/ board connected to PC (device mode)
> - boot w/ OTG-A cable with USB keyboard
> - boot w/ OTG-A cable connected to powered USB hub and the same keyboard
> 
> w/ and w/o this patch I have the same flood of prints in all cases.

OK interesting that it also happens with nothing connected.

> Fwiw I have checked where the is_active is set - which causes the prints:
> musb_core.c:musb_start()
> 
> if (musb->port_mode != MUSB_PORT_MODE_HOST &&
>   musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
>   (devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
>   musb->is_active = 1;
> } else {
>   devctl |= MUSB_DEVCTL_SESSION;
> }
> 
> this was the only place where the is_active was set to 1.

That seems normal in musb_start(). Will try with your .config
here.

Regards,

Tony
--
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 V7 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Kishon Vijay Abraham I]

Hi Vivek,

On Wednesday 05 April 2017 06:02 PM, Vivek Gautam wrote:
> This patch series adds couple of PHY drivers for Qualcomm chipsets.
> a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
> b) qcom-qmp phy driver: that is a combo phy providing support for
>USB3, PCIe, UFS and few other controllers.
> 
> The patches are based on next branch of linux-phy tree.
> 
> These patches have been tested on Dragon board db820c hardware with
> required set of dt patches and the patches to get rpm up on msm8996.
> Couple of other patches [1, 2] fixing DMA config for XHCI are also
> pulled in for testing.
> A branch based on torvald's master is available in github [3].

I get a bunch of checkpatch errors/warnings when I run checkpatch with --strict
option. Those look simple enough to be fixed. Can you respin your series fixing
those?

Thanks
Kishon

> 
> Changes since v6:
>  - Rebased on phy/next and *not* including phy grouping series[4].
>  - qusb2-phy: addressed Stephen's comment.
>- Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
>  - qmp-phy: none on functionality side.
>  
> Changes since v5:
>  - Addressed review comments from Bjorn:
>- Removed instances of readl/wirtel_relaxed calls from the drivers.
>  Instead, using simple readl/writel. Inserting a readl after a writel
>  to ensure the write is through to the device.
>- Replaced regulator handling with regulator_bulk_** apis. This helps
>  in cutting down a lot of regulator handling code.
>- Fixed minor return statements.
> 
> Changes since v4:
>  - Addressed comment to add child nodes for qmp phy driver. Each phy lane
>now has a separate child node under the main qmp node.
>  - Modified the clock and reset initialization and enable methods.
>Different phys - pcie, usb and later ufs, have varying number of clocks
>and resets that are mandatory. So adding provision for clocks and reset
>lists helps in requesting all mandatory resources for individual phys
>and handle their failure cases accordingly.
> 
> Changes since v3:
>  - Addressed review comments given by Rob and Stephen for qusb2 phy
>and qmp phy bindings respectively.
>  - Addressed review comments given by Stephen and Bjorn for qmp phy driver.
> 
> Changes since v2:
>  - Addressed review comments given by Rob and Stephen for bindings.
>  - Addressed the review comments given by Stephen for the qusb2 and qmp
>phy drivers.
> 
> Changes since v1:
>  - Moved device tree binding documentation to separate patches, as suggested
>by Rob.
>  - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
>given by Rob.
>  - Addressed review comments from Kishon.
>  - Addressed review comments from Srinivas for QMP phy driver.
>  - Addressed kbuild warning.
> 
> Please see individual patches for detailed changelogs.
> 
> [1] https://patchwork.kernel.org/patch/9567767/
> [2] https://patchwork.kernel.org/patch/9567779/
> [3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
> [4] https://lkml.org/lkml/2017/3/20/407
> 
> Vivek Gautam (4):
>   dt-bindings: phy: Add support for QUSB2 phy
>   phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
>   dt-bindings: phy: Add support for QMP phy
>   phy: qcom-qmp: new qmp phy driver for qcom-chipsets
> 
>  .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
>  .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
>  drivers/phy/Kconfig|   18 +
>  drivers/phy/Makefile   |2 +
>  drivers/phy/phy-qcom-qmp.c | 1153 
> 
>  drivers/phy/phy-qcom-qusb2.c   |  491 +
>  6 files changed, 1813 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
>  create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
>  create mode 100644 drivers/phy/phy-qcom-qmp.c
>  create mode 100644 drivers/phy/phy-qcom-qusb2.c
> 
--
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 21/21] docs-rst: fix usb cross-references

[Mauro Carvalho Chehab]

As some USB documentation files got moved, adjust their
cross-references to their new place.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/ABI/stable/sysfs-bus-usb| 2 +-
 Documentation/driver-api/usb/URB.rst  | 2 ++
 Documentation/driver-api/usb/callbacks.rst| 4 ++--
 Documentation/driver-api/usb/error-codes.rst  | 2 ++
 Documentation/driver-api/usb/persist.rst  | 2 ++
 Documentation/driver-api/usb/power-management.rst | 2 +-
 Documentation/driver-api/usb/usb.rst  | 4 ++--
 Documentation/power/swsusp.txt| 2 +-
 drivers/staging/most/hdm-usb/hdm_usb.c| 2 +-
 drivers/usb/core/Kconfig  | 2 +-
 10 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/Documentation/ABI/stable/sysfs-bus-usb 
b/Documentation/ABI/stable/sysfs-bus-usb
index 831f15d9672f..b832eeff 100644
--- a/Documentation/ABI/stable/sysfs-bus-usb
+++ b/Documentation/ABI/stable/sysfs-bus-usb
@@ -9,7 +9,7 @@ Description:
hubs this facility is always enabled and their device
directories will not contain this file.
 
-   For more information, see Documentation/usb/persist.txt.
+   For more information, see 
Documentation/driver-api/usb/persist.rst.
 
 What:  /sys/bus/usb/devices/.../power/autosuspend
 Date:  March 2007
diff --git a/Documentation/driver-api/usb/URB.rst 
b/Documentation/driver-api/usb/URB.rst
index c4a141f29477..61a54da9fce9 100644
--- a/Documentation/driver-api/usb/URB.rst
+++ b/Documentation/driver-api/usb/URB.rst
@@ -1,3 +1,5 @@
+.. _usb-urb:
+
 USB Request Block (URB)
 ~~~
 
diff --git a/Documentation/driver-api/usb/callbacks.rst 
b/Documentation/driver-api/usb/callbacks.rst
index 93a8d53e27e7..2b80cf54bcc3 100644
--- a/Documentation/driver-api/usb/callbacks.rst
+++ b/Documentation/driver-api/usb/callbacks.rst
@@ -8,7 +8,7 @@ Usbcore will call into a driver through callbacks defined in 
the driver
 structure and through the completion handler of URBs a driver submits.
 Only the former are in the scope of this document. These two kinds of
 callbacks are completely independent of each other. Information on the
-completion callback can be found in Documentation/usb/URB.txt.
+completion callback can be found in :ref:`usb-urb`.
 
 The callbacks defined in the driver structure are:
 
@@ -53,7 +53,7 @@ The callbacks defined in the driver structure are:
 
 The ioctl interface (2) should be used only if you have a very good
 reason. Sysfs is preferred these days. The PM callbacks are covered
-separately in Documentation/usb/power-management.txt.
+separately in :ref:`usb-power-management`.
 
 Calling conventions
 ===
diff --git a/Documentation/driver-api/usb/error-codes.rst 
b/Documentation/driver-api/usb/error-codes.rst
index 9c11a0fd16cb..a3e84bfac776 100644
--- a/Documentation/driver-api/usb/error-codes.rst
+++ b/Documentation/driver-api/usb/error-codes.rst
@@ -1,3 +1,5 @@
+.. _usb-error-codes:
+
 USB Error codes
 ~~~
 
diff --git a/Documentation/driver-api/usb/persist.rst 
b/Documentation/driver-api/usb/persist.rst
index ea1b43f0559e..08cafc6292c1 100644
--- a/Documentation/driver-api/usb/persist.rst
+++ b/Documentation/driver-api/usb/persist.rst
@@ -1,3 +1,5 @@
+.. _usb-persist:
+
 USB device persistence during system suspend
 
 
diff --git a/Documentation/driver-api/usb/power-management.rst 
b/Documentation/driver-api/usb/power-management.rst
index c068257f6d27..79beb807996b 100644
--- a/Documentation/driver-api/usb/power-management.rst
+++ b/Documentation/driver-api/usb/power-management.rst
@@ -328,7 +328,7 @@ possible to work around the hibernation-forces-disconnect 
problem by
 using the USB Persist facility.)
 
 The ``reset_resume`` method is used by the USB Persist facility (see
-``Documentation/usb/persist.txt``) and it can also be used under certain
+:ref:`usb-persist`) and it can also be used under certain
 circumstances when ``CONFIG_USB_PERSIST`` is not enabled.  Currently, if a
 device is reset during a resume and the driver does not have a
 ``reset_resume`` method, the driver won't receive any notification about
diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index 5ebaf669704c..6824089ef4c8 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -424,8 +424,8 @@ header.
 Unless noted otherwise, the ioctl requests described here will update
 the modification time on the usbfs file to which they are applied
 (unless they fail). A return of zero indicates success; otherwise, a
-standard USB error code is returned. (These are documented in
-``Documentation/usb/error-codes.txt`` in your kernel sources.)
+standard USB error code is returned (These are documented in
+:ref:`usb-error-codes`).
 
 Each of these files multiplexes 

[PATCH v2 13/21] error-codes.rst: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/error-codes.rst | 205 +++
 Documentation/driver-api/usb/index.rst   |   1 +
 Documentation/usb/error-codes.txt| 175 ---
 3 files changed, 206 insertions(+), 175 deletions(-)
 create mode 100644 Documentation/driver-api/usb/error-codes.rst
 delete mode 100644 Documentation/usb/error-codes.txt

diff --git a/Documentation/driver-api/usb/error-codes.rst 
b/Documentation/driver-api/usb/error-codes.rst
new file mode 100644
index ..9c11a0fd16cb
--- /dev/null
+++ b/Documentation/driver-api/usb/error-codes.rst
@@ -0,0 +1,205 @@
+USB Error codes
+~~~
+
+:Revised: 2004-Oct-21
+
+This is the documentation of (hopefully) all possible error codes (and
+their interpretation) that can be returned from usbcore.
+
+Some of them are returned by the Host Controller Drivers (HCDs), which
+device drivers only see through usbcore.  As a rule, all the HCDs should
+behave the same except for transfer speed dependent behaviors and the
+way certain faults are reported.
+
+
+Error codes returned by :c:func:`usb_submit_urb`
+
+
+Non-USB-specific:
+
+
+=== ===
+0  URB submission went fine
+
+``-ENOMEM``no memory for allocation of internal structures
+=== ===
+
+USB-specific:
+
+===
===
+``-EBUSY`` The URB is already active.
+
+``-ENODEV``specified USB-device or bus doesn't exist
+
+``-ENOENT``specified interface or endpoint does not exist or
+   is not enabled
+
+``-ENXIO`` host controller driver does not support queuing of
+   this type of urb.  (treat as a host controller bug.)
+
+``-EINVAL``a) Invalid transfer type specified (or not supported)
+   b) Invalid or unsupported periodic transfer interval
+   c) ISO: attempted to change transfer interval
+   d) ISO: ``number_of_packets`` is < 0
+   e) various other cases
+
+``-EXDEV`` ISO: ``URB_ISO_ASAP`` wasn't specified and all the
+   frames the URB would be scheduled in have already
+   expired.
+
+``-EFBIG`` Host controller driver can't schedule that many ISO
+   frames.
+
+``-EPIPE`` The pipe type specified in the URB doesn't match the
+   endpoint's actual type.
+
+``-EMSGSIZE``  (a) endpoint maxpacket size is zero; it is not usable
+   in the current interface altsetting.
+   (b) ISO packet is larger than the endpoint maxpacket.
+   (c) requested data transfer length is invalid: negative
+   or too large for the host controller.
+
+``-ENOSPC``This request would overcommit the usb bandwidth reserved
+   for periodic transfers (interrupt, isochronous).
+
+``-ESHUTDOWN`` The device or host controller has been disabled due to
+   some problem that could not be worked around.
+
+``-EPERM`` Submission failed because ``urb->reject`` was set.
+
+``-EHOSTUNREACH``  URB was rejected because the device is suspended.
+
+``-ENOEXEC``   A control URB doesn't contain a Setup packet.
+===
===
+
+Error codes returned by ``in urb->status`` or in ``iso_frame_desc[n].status`` 
(for ISO)
+===
+
+USB device drivers may only test urb status values in completion handlers.
+This is because otherwise there would be a race between HCDs updating
+these values on one CPU, and device drivers testing them on another CPU.
+
+A transfer's actual_length may be positive even when an error has been
+reported.  That's because transfers often involve several packets, so that
+one or more packets could finish before an error stops further endpoint I/O.
+
+For isochronous URBs, the urb status value is non-zero only if the URB is
+unlinked, the device is removed, the host controller is disabled, or the total
+transferred length is less than the requested length and the
+``URB_SHORT_NOT_OK`` flag is set.  Completion handlers for isochronous URBs
+should only see ``urb->status`` set to zero, ``-ENOENT``, ``-ECONNRESET``,
+``-ESHUTDOWN``, or ``-EREMOTEIO``. Individual frame descriptor status fields
+may report more status codes.
+
+
+===

[PATCH v2 08/21] usb/anchors.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../anchors.txt => driver-api/usb/anchors.rst} | 36 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 21 insertions(+), 16 deletions(-)
 rename Documentation/{usb/anchors.txt => driver-api/usb/anchors.rst} (75%)

diff --git a/Documentation/usb/anchors.txt 
b/Documentation/driver-api/usb/anchors.rst
similarity index 75%
rename from Documentation/usb/anchors.txt
rename to Documentation/driver-api/usb/anchors.rst
index fe6a99a32bbd..4b248e691bd6 100644
--- a/Documentation/usb/anchors.txt
+++ b/Documentation/driver-api/usb/anchors.rst
@@ -1,3 +1,6 @@
+USB Anchors
+~~~
+
 What is anchor?
 ===
 
@@ -13,7 +16,7 @@ Allocation and Initialisation
 =
 
 There's no API to allocate an anchor. It is simply declared
-as struct usb_anchor. init_usb_anchor() must be called to
+as struct usb_anchor. :c:func:`init_usb_anchor` must be called to
 initialise the data structure.
 
 Deallocation
@@ -26,52 +29,53 @@ Association and disassociation of URBs with anchors
 ===
 
 An association of URBs to an anchor is made by an explicit
-call to usb_anchor_urb(). The association is maintained until
+call to :c:func:`usb_anchor_urb`. The association is maintained until
 an URB is finished by (successful) completion. Thus disassociation
 is automatic. A function is provided to forcibly finish (kill)
 all URBs associated with an anchor.
-Furthermore, disassociation can be made with usb_unanchor_urb()
+Furthermore, disassociation can be made with :c:func:`usb_unanchor_urb`
 
 Operations on multitudes of URBs
 
 
-usb_kill_anchored_urbs()
-
+:c:func:`usb_kill_anchored_urbs`
+
 
 This function kills all URBs associated with an anchor. The URBs
 are called in the reverse temporal order they were submitted.
 This way no data can be reordered.
 
-usb_unlink_anchored_urbs()
---
+:c:func:`usb_unlink_anchored_urbs`
+--
+
 
 This function unlinks all URBs associated with an anchor. The URBs
 are processed in the reverse temporal order they were submitted.
-This is similar to usb_kill_anchored_urbs(), but it will not sleep.
+This is similar to :c:func:`usb_kill_anchored_urbs`, but it will not sleep.
 Therefore no guarantee is made that the URBs have been unlinked when
 the call returns. They may be unlinked later but will be unlinked in
 finite time.
 
-usb_scuttle_anchored_urbs()

+:c:func:`usb_scuttle_anchored_urbs`
+---
 
 All URBs of an anchor are unanchored en masse.
 
-usb_wait_anchor_empty_timeout()

+:c:func:`usb_wait_anchor_empty_timeout`
+---
 
 This function waits for all URBs associated with an anchor to finish
 or a timeout, whichever comes first. Its return value will tell you
 whether the timeout was reached.
 
-usb_anchor_empty()
---
+:c:func:`usb_anchor_empty`
+--
 
 Returns true if no URBs are associated with an anchor. Locking
 is the caller's responsibility.
 
-usb_get_from_anchor()
--
+:c:func:`usb_get_from_anchor`
+-
 
 Returns the oldest anchored URB of an anchor. The URB is unanchored
 and returned with a reference. As you may mix URBs to several
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index cf2fa2e8d236..5dfb04b2d730 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -6,6 +6,7 @@ Linux USB API
 
usb
gadget
+   anchors
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

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

[PATCH v2 04/21] usb.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

- use the proper warning and note markups;
- add references for parts of the document that will be
  cross-referenced on other USB docs;
- some minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/usb.rst | 48 +---
 1 file changed, 17 insertions(+), 31 deletions(-)

diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index b856abb3200e..7e820768ee4f 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -102,6 +102,8 @@ disconnect testing (while the device is active) with each 
different host
 controller driver, to make sure drivers don't have bugs of their own as
 well as to make sure they aren't relying on some HCD-specific behavior.
 
+.. _usb_chapter9:
+
 USB-Standard Types
 ==
 
@@ -112,6 +114,8 @@ USB, and in APIs including this host side API, gadget APIs, 
and usbfs.
 .. kernel-doc:: include/linux/usb/ch9.h
:internal:
 
+.. _usb_header:
+
 Host-Side Data Types and Macros
 ===
 
@@ -209,7 +213,7 @@ library that wraps it. Such libraries include
 `libusb `__ for C/C++, and
 `jUSB `__ for Java.
 
-**Note**
+.. note::
 
 This particular documentation is incomplete, especially with respect
 to the asynchronous mode. As of kernel 2.5.66 the code and this
@@ -319,9 +323,7 @@ files. For information about the current format of this 
file, see the
 sources.
 
 This file, in combination with the poll() system call, can also be used
-to detect when devices are added or removed:
-
-::
+to detect when devices are added or removed::
 
 int fd;
 struct pollfd pfd;
@@ -407,9 +409,7 @@ The ioctl() Requests
 
 
 To use these ioctls, you need to include the following headers in your
-userspace program:
-
-::
+userspace program::
 
 #include 
 #include 
@@ -458,9 +458,7 @@ USBDEVFS_CLAIMINTERFACE
 
 USBDEVFS_CONNECTINFO
 Says whether the device is lowspeed. The ioctl parameter points to a
-structure like this:
-
-::
+structure like this::
 
struct usbdevfs_connectinfo {
unsigned int   devnum;
@@ -477,9 +475,7 @@ USBDEVFS_CONNECTINFO
 USBDEVFS_GETDRIVER
 Returns the name of the kernel driver bound to a given interface (a
 string). Parameter is a pointer to this structure, which is
-modified:
-
-::
+modified::
 
struct usbdevfs_getdriver {
unsigned int  interface;
@@ -490,9 +486,7 @@ USBDEVFS_GETDRIVER
 
 USBDEVFS_IOCTL
 Passes a request from userspace through to a kernel driver that has
-an ioctl entry in the *struct usb_driver* it registered.
-
-::
+an ioctl entry in the *struct usb_driver* it registered::
 
struct usbdevfs_ioctl {
int ifno;
@@ -534,7 +528,7 @@ USBDEVFS_RELEASEINTERFACE
 the number of the interface (bInterfaceNumber from descriptor); File
 modification time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*No security check is made to ensure that the task which made
the claim is the one which is releasing it. This means that user
@@ -574,9 +568,7 @@ a time.
 
 USBDEVFS_BULK
 Issues a bulk read or write request to the device. The ioctl
-parameter is a pointer to this structure:
-
-::
+parameter is a pointer to this structure::
 
struct usbdevfs_bulktransfer {
unsigned int  ep;
@@ -606,9 +598,7 @@ USBDEVFS_CLEAR_HALT
 
 USBDEVFS_CONTROL
 Issues a control request to the device. The ioctl parameter points
-to a structure like this:
-
-::
+to a structure like this::
 
struct usbdevfs_ctrltransfer {
__u8   bRequestType;
@@ -638,7 +628,7 @@ USBDEVFS_RESET
 the reset, this rebinds all device interfaces. File modification
 time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
@@ -646,9 +636,7 @@ USBDEVFS_RESET
 
 USBDEVFS_SETINTERFACE
 Sets the alternate setting for an interface. The ioctl parameter is
-a pointer to a structure like this:
-
-::
+a pointer to a structure like this::
 
struct usbdevfs_setinterface {
unsigned int  interface;
@@ -669,7 +657,7 @@ USBDEVFS_SETCONFIGURATION
 configuration (bConfigurationValue from descriptor). File
 modification time is not updated by this request.
 
-   **Warning**
+.. warning::
 
*Avoid using this call* until some usbcore bugs get fixed, since
it does not fully synchronize device, interface, and driver (not
@@ -702,9 +690,7 @@ When usbfs returns these urbs, the status value is updated, 
and the
 buffer 

[PATCH v2 02/21] driver-api/basics.rst: add device table header

[Mauro Carvalho Chehab]

The structs there at device table are used by other documentation
at the Kernel. So, add it to the driver API.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/basics.rst | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/driver-api/basics.rst 
b/Documentation/driver-api/basics.rst
index 935b9b8d456c..472e7a664d13 100644
--- a/Documentation/driver-api/basics.rst
+++ b/Documentation/driver-api/basics.rst
@@ -7,6 +7,12 @@ Driver Entry and Exit points
 .. kernel-doc:: include/linux/init.h
:internal:
 
+Driver device table
+---
+
+.. kernel-doc:: include/linux/mod_devicetable.h
+   :internal:
+
 Atomic and pointer manipulation
 ---
 
-- 
2.9.3

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

[PATCH v2 09/21] usb/bulk-streams.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../bulk-streams.txt => driver-api/usb/bulk-streams.rst}| 13 +
 Documentation/driver-api/usb/index.rst  |  1 +
 2 files changed, 10 insertions(+), 4 deletions(-)
 rename Documentation/{usb/bulk-streams.txt => driver-api/usb/bulk-streams.rst} 
(94%)

diff --git a/Documentation/usb/bulk-streams.txt 
b/Documentation/driver-api/usb/bulk-streams.rst
similarity index 94%
rename from Documentation/usb/bulk-streams.txt
rename to Documentation/driver-api/usb/bulk-streams.rst
index ffc02021863e..99b515babdeb 100644
--- a/Documentation/usb/bulk-streams.txt
+++ b/Documentation/driver-api/usb/bulk-streams.rst
@@ -1,3 +1,6 @@
+USB bulk streams
+
+
 Background
 ==
 
@@ -25,7 +28,9 @@ time.
 Driver implications
 ===
 
-int usb_alloc_streams(struct usb_interface *interface,
+::
+
+  int usb_alloc_streams(struct usb_interface *interface,
struct usb_host_endpoint **eps, unsigned int num_eps,
unsigned int num_streams, gfp_t mem_flags);
 
@@ -53,7 +58,7 @@ controller driver, and may change in the future.
 
 
 Picking new Stream IDs to use
-
+=
 
 Stream ID 0 is reserved, and should not be used to communicate with devices.  
If
 usb_alloc_streams() returns with a value of N, you may use streams 1 though N.
@@ -68,9 +73,9 @@ Clean up
 
 
 If a driver wishes to stop using streams to communicate with the device, it
-should call
+should call::
 
-void usb_free_streams(struct usb_interface *interface,
+  void usb_free_streams(struct usb_interface *interface,
struct usb_host_endpoint **eps, unsigned int num_eps,
gfp_t mem_flags);
 
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 5dfb04b2d730..6fe7611f7332 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -7,6 +7,7 @@ Linux USB API
usb
gadget
anchors
+   bulk-streams
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

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

[PATCH v2 12/21] usb/dma.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../{usb/dma.txt => driver-api/usb/dma.rst}| 51 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 28 insertions(+), 24 deletions(-)
 rename Documentation/{usb/dma.txt => driver-api/usb/dma.rst} (79%)

diff --git a/Documentation/usb/dma.txt b/Documentation/driver-api/usb/dma.rst
similarity index 79%
rename from Documentation/usb/dma.txt
rename to Documentation/driver-api/usb/dma.rst
index 444651e70d95..59d5aee89e37 100644
--- a/Documentation/usb/dma.txt
+++ b/Documentation/driver-api/usb/dma.rst
@@ -1,16 +1,19 @@
+USB DMA
+~~~
+
 In Linux 2.5 kernels (and later), USB device drivers have additional control
 over how DMA may be used to perform I/O operations.  The APIs are detailed
 in the kernel usb programming guide (kerneldoc, from the source code).
 
-
-API OVERVIEW
+API overview
+
 
 The big picture is that USB drivers can continue to ignore most DMA issues,
 though they still must provide DMA-ready buffers (see
-Documentation/DMA-API-HOWTO.txt).  That's how they've worked through
-the 2.4 (and earlier) kernels.
+``Documentation/DMA-API-HOWTO.txt``).  That's how they've worked through
+the 2.4 (and earlier) kernels, or they can now be DMA-aware.
 
-OR:  they can now be DMA-aware.
+DMA-aware usb drivers:
 
 - New calls enable DMA-aware drivers, letting them allocate dma buffers and
   manage dma mappings for existing dma-ready buffers (see below).
@@ -20,15 +23,15 @@ OR:  they can now be DMA-aware.
   drivers must not use it.)
 
 - "usbcore" will map this DMA address, if a DMA-aware driver didn't do
-  it first and set URB_NO_TRANSFER_DMA_MAP.  HCDs
+  it first and set ``URB_NO_TRANSFER_DMA_MAP``.  HCDs
   don't manage dma mappings for URBs.
 
 - There's a new "generic DMA API", parts of which are usable by USB device
   drivers.  Never use dma_set_mask() on any USB interface or device; that
   would potentially break all devices sharing that bus.
 
-
-ELIMINATING COPIES
+Eliminating copies
+==
 
 It's good to avoid making CPUs copy data needlessly.  The costs can add up,
 and effects like cache-trashing can impose subtle penalties.
@@ -41,7 +44,7 @@ and effects like cache-trashing can impose subtle penalties.
   For those specific cases, USB has primitives to allocate less expensive
   memory.  They work like kmalloc and kfree versions that give you the right
   kind of addresses to store in urb->transfer_buffer and urb->transfer_dma.
-  You'd also set URB_NO_TRANSFER_DMA_MAP in urb->transfer_flags:
+  You'd also set ``URB_NO_TRANSFER_DMA_MAP`` in urb->transfer_flags::
 
void *usb_alloc_coherent (struct usb_device *dev, size_t size,
int mem_flags, dma_addr_t *dma);
@@ -49,15 +52,15 @@ and effects like cache-trashing can impose subtle penalties.
void usb_free_coherent (struct usb_device *dev, size_t size,
void *addr, dma_addr_t dma);
 
-  Most drivers should *NOT* be using these primitives; they don't need
+  Most drivers should **NOT** be using these primitives; they don't need
   to use this type of memory ("dma-coherent"), and memory returned from
-  kmalloc() will work just fine.
+  :c:func:`kmalloc` will work just fine.
 
   The memory buffer returned is "dma-coherent"; sometimes you might need to
   force a consistent memory access ordering by using memory barriers.  It's
   not using a streaming DMA mapping, so it's good for small transfers on
   systems where the I/O would otherwise thrash an IOMMU mapping.  (See
-  Documentation/DMA-API-HOWTO.txt for definitions of "coherent" and
+  ``Documentation/DMA-API-HOWTO.txt`` for definitions of "coherent" and
   "streaming" DMA mappings.)
 
   Asking for 1/Nth of a page (as well as asking for N pages) is reasonably
@@ -75,15 +78,15 @@ and effects like cache-trashing can impose subtle penalties.
   way to expose these capabilities ... and in any case, HIGHMEM is mostly a
   design wart specific to x86_32.  So your best bet is to ensure you never
   pass a highmem buffer into a USB driver.  That's easy; it's the default
-  behavior.  Just don't override it; e.g. with NETIF_F_HIGHDMA.
+  behavior.  Just don't override it; e.g. with ``NETIF_F_HIGHDMA``.
 
   This may force your callers to do some bounce buffering, copying from
   high memory to "normal" DMA memory.  If you can come up with a good way
   to fix this issue (for x86_32 machines with over 1 GByte of memory),
   feel free to submit patches.
 
-
-WORKING WITH EXISTING BUFFERS
+Working with existing buffers
+=
 
 Existing buffers aren't usable for DMA without first being mapped into the
 DMA address space of the device.  However, most buffers passed to your
@@ -92,7 +95,7 @@ of Documentation/DMA-API-HOWTO.txt, titled "What memory is 
DMA-able?")
 
 - When you're using scatterlists, you can 

[PATCH v2 17/21] usb.rst: get rid of some Sphinx errors

[Mauro Carvalho Chehab]

Get rid of those warnings:

Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_type".
Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_dir".
Documentation/driver-api/usb/usb.rst:615: ERROR: Unknown target name: 
"usb_recip".
Documentation/driver-api/usb/usb.rst:679: ERROR: Unknown target name: 
"usbdevfs_urb_type".

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/usb.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/driver-api/usb/usb.rst 
b/Documentation/driver-api/usb/usb.rst
index d15ab8ae5239..5ebaf669704c 100644
--- a/Documentation/driver-api/usb/usb.rst
+++ b/Documentation/driver-api/usb/usb.rst
@@ -615,8 +615,8 @@ USBDEVFS_CONTROL
 The first eight bytes of this structure are the contents of the
 SETUP packet to be sent to the device; see the USB 2.0 specification
 for details. The bRequestType value is composed by combining a
-USB_TYPE_\* value, a USB_DIR_\* value, and a USB_RECIP_\*
-value (from **). If wLength is nonzero, it describes
+``USB_TYPE_*`` value, a ``USB_DIR_*`` value, and a ``USB_RECIP_*``
+value (from ``linux/usb.h``). If wLength is nonzero, it describes
 the length of the data buffer, which is either written to the device
 (USB_DIR_OUT) or read from the device (USB_DIR_IN).
 
@@ -678,7 +678,7 @@ the blocking is separate.
 
 These requests are packaged into a structure that resembles the URB used
 by kernel device drivers. (No POSIX Async I/O support here, sorry.) It
-identifies the endpoint type (USBDEVFS_URB_TYPE_\*), endpoint
+identifies the endpoint type (``USBDEVFS_URB_TYPE_*``), endpoint
 (number, masked with USB_DIR_IN as appropriate), buffer and length,
 and a user "context" value serving to uniquely identify each request.
 (It's usually a pointer to per-request data.) Flags can modify requests
-- 
2.9.3

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

[PATCH v2 18/21] usb: get rid of some ReST doc build errors

[Mauro Carvalho Chehab]

We need an space before a numbered list to avoid those warnings:

./drivers/usb/core/message.c:478: ERROR: Unexpected indentation.
./drivers/usb/core/message.c:479: WARNING: Block quote ends without a blank 
line; unexpected unindent.
./include/linux/usb/composite.h:455: ERROR: Unexpected indentation.
./include/linux/usb/composite.h:456: WARNING: Block quote ends without a blank 
line; unexpected unindent.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/usb/core/message.c| 1 +
 include/linux/usb/composite.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 2184ef40a82a..4c38ea41ae96 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -474,6 +474,7 @@ EXPORT_SYMBOL_GPL(usb_sg_init);
  * significantly improve USB throughput.
  *
  * There are three kinds of completion for this function.
+ *
  * (1) success, where io->status is zero.  The number of io->bytes
  * transferred is as requested.
  * (2) error, where io->status is a negative errno value.  The number
diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 4616a49a1c2e..30a063e98c19 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -451,6 +451,7 @@ static inline struct usb_composite_driver *to_cdriver(
  * sure doing that won't hurt too much.
  *
  * One notion for how to handle Wireless USB devices involves:
+ *
  * (a) a second gadget here, discovery mechanism TBD, but likely
  * needing separate "register/unregister WUSB gadget" calls;
  * (b) updates to usb_gadget to include flags "is it wireless",
-- 
2.9.3

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

[PATCH v2 19/21] usb: composite.h: fix two warnings when building docs

[Mauro Carvalho Chehab]

By definition, we use /* private: */ tag when we won't be documenting
a parameter. However, those two parameters are documented:

./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef 
member 'setup_pending' description in 'usb_composite_dev'
./include/linux/usb/composite.h:510: warning: Excess struct/union/enum/typedef 
member 'os_desc_pending' description in 'usb_composite_dev'

So, we need to use /* public: */ to avoid a warning.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/usb/composite.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/usb/composite.h b/include/linux/usb/composite.h
index 30a063e98c19..f665d2ceac20 100644
--- a/include/linux/usb/composite.h
+++ b/include/linux/usb/composite.h
@@ -504,8 +504,9 @@ struct usb_composite_dev {
/* protects deactivations and delayed_status counts*/
spinlock_t  lock;
 
-   unsignedsetup_pending:1;
-   unsignedos_desc_pending:1;
+   /* public: */
+   unsigned intsetup_pending:1;
+   unsigned intos_desc_pending:1;
 };
 
 extern int usb_string_id(struct usb_composite_dev *c);
-- 
2.9.3

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

[PATCH v2 15/21] usb/persist.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/index.rst |  1 +
 .../persist.txt => driver-api/usb/persist.rst} | 22 +-
 2 files changed, 14 insertions(+), 9 deletions(-)
 rename Documentation/{usb/persist.txt => driver-api/usb/persist.rst} (94%)

diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 43f0a8b72b11..3f08cb5d5feb 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -12,6 +12,7 @@ Linux USB API
dma
power-management
hotplug
+   persist
error-codes
writing_usb_driver
writing_musb_glue_layer
diff --git a/Documentation/usb/persist.txt 
b/Documentation/driver-api/usb/persist.rst
similarity index 94%
rename from Documentation/usb/persist.txt
rename to Documentation/driver-api/usb/persist.rst
index 35d70eda9ad6..ea1b43f0559e 100644
--- a/Documentation/usb/persist.txt
+++ b/Documentation/driver-api/usb/persist.rst
@@ -1,11 +1,12 @@
-   USB device persistence during system suspend
+USB device persistence during system suspend
+
 
-  Alan Stern 
+:Author: Alan Stern 
+:Date: September 2, 2006 (Updated February 25, 2008)
 
-   September 2, 2006 (Updated February 25, 2008)
 
-
-   What is the problem?
+What is the problem?
+
 
 According to the USB specification, when a USB bus is suspended the
 bus must continue to supply suspend current (around 1-5 mA).  This
@@ -63,7 +64,8 @@ suspended -- but it will crash as soon as it wakes up, which 
isn't
 much better.)
 
 
-   What is the solution?
+What is the solution?
+=
 
 The kernel includes a feature called USB-persist.  It tries to work
 around these issues by allowing the core USB device data structures to
@@ -99,7 +101,7 @@ now a good and happy place.
 
 Note that the "USB-persist" feature will be applied only to those
 devices for which it is enabled.  You can enable the feature by doing
-(as root):
+(as root)::
 
echo 1 >/sys/bus/usb/devices/.../power/persist
 
@@ -110,7 +112,8 @@ doesn't even exist, so you only have to worry about setting 
it for
 devices where it really matters.
 
 
-   Is this the best solution?
+Is this the best solution?
+==
 
 Perhaps not.  Arguably, keeping track of mounted filesystems and
 memory mappings across device disconnects should be handled by a
@@ -130,7 +133,8 @@ just mass-storage devices.  It might turn out to be equally 
useful for
 other device types, such as network interfaces.
 
 
-   WARNING: USB-persist can be dangerous!!
+WARNING: USB-persist can be dangerous!!
+===
 
 When recovering an interrupted power session the kernel does its best
 to make sure the USB device hasn't been changed; that is, the same
-- 
2.9.3

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

[PATCH v2 10/21] usb/callbacks.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../callbacks.txt => driver-api/usb/callbacks.rst} | 61 +++---
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 43 insertions(+), 19 deletions(-)
 rename Documentation/{usb/callbacks.txt => driver-api/usb/callbacks.rst} (78%)

diff --git a/Documentation/usb/callbacks.txt 
b/Documentation/driver-api/usb/callbacks.rst
similarity index 78%
rename from Documentation/usb/callbacks.txt
rename to Documentation/driver-api/usb/callbacks.rst
index 9e85846bdb98..93a8d53e27e7 100644
--- a/Documentation/usb/callbacks.txt
+++ b/Documentation/driver-api/usb/callbacks.rst
@@ -1,3 +1,6 @@
+USB core callbacks
+~~
+
 What callbacks will usbcore do?
 ===
 
@@ -11,30 +14,42 @@ The callbacks defined in the driver structure are:
 
 1. Hotplugging callbacks:
 
- * @probe: Called to see if the driver is willing to manage a particular
- * interface on a device.
- * @disconnect: Called when the interface is no longer accessible, usually
- * because its device has been (or is being) disconnected or the
- * driver module is being unloaded.
+ - @probe:
+   Called to see if the driver is willing to manage a particular
+   interface on a device.
+
+ - @disconnect:
+   Called when the interface is no longer accessible, usually
+   because its device has been (or is being) disconnected or the
+   driver module is being unloaded.
 
 2. Odd backdoor through usbfs:
 
- * @ioctl: Used for drivers that want to talk to userspace through
- * the "usbfs" filesystem.  This lets devices provide ways to
- * expose information to user space regardless of where they
- * do (or don't) show up otherwise in the filesystem.
+ - @ioctl:
+   Used for drivers that want to talk to userspace through
+   the "usbfs" filesystem.  This lets devices provide ways to
+   expose information to user space regardless of where they
+   do (or don't) show up otherwise in the filesystem.
 
 3. Power management (PM) callbacks:
 
- * @suspend: Called when the device is going to be suspended.
- * @resume: Called when the device is being resumed.
- * @reset_resume: Called when the suspended device has been reset instead
- * of being resumed.
+ - @suspend:
+   Called when the device is going to be suspended.
+
+ - @resume:
+   Called when the device is being resumed.
+
+ - @reset_resume:
+   Called when the suspended device has been reset instead
+   of being resumed.
 
 4. Device level operations:
 
- * @pre_reset: Called when the device is about to be reset.
- * @post_reset: Called after the device has been reset
+ - @pre_reset:
+   Called when the device is about to be reset.
+
+ - @post_reset:
+   Called after the device has been reset
 
 The ioctl interface (2) should be used only if you have a very good
 reason. Sysfs is preferred these days. The PM callbacks are covered
@@ -58,7 +73,9 @@ an interface. A driver's bond to an interface is exclusive.
 The probe() callback
 
 
-int (*probe) (struct usb_interface *intf,
+::
+
+  int (*probe) (struct usb_interface *intf,
const struct usb_device_id *id);
 
 Accept or decline an interface. If you accept the device return 0,
@@ -75,7 +92,9 @@ initialisation that doesn't take too long is a good idea here.
 The disconnect() callback
 -
 
-void (*disconnect) (struct usb_interface *intf);
+::
+
+  void (*disconnect) (struct usb_interface *intf);
 
 This callback is a signal to break any connection with an interface.
 You are not allowed any IO to a device after returning from this
@@ -93,7 +112,9 @@ Device level callbacks
 pre_reset
 -
 
-int (*pre_reset)(struct usb_interface *intf);
+::
+
+  int (*pre_reset)(struct usb_interface *intf);
 
 A driver or user space is triggering a reset on the device which
 contains the interface passed as an argument. Cease IO, wait for all
@@ -107,7 +128,9 @@ are in atomic context.
 post_reset
 --
 
-int (*post_reset)(struct usb_interface *intf);
+::
+
+  int (*post_reset)(struct usb_interface *intf);
 
 The reset has completed.  Restore any saved device state and begin
 using the device again.
diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 6fe7611f7332..441c5dacdf27 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -8,6 +8,7 @@ Linux USB API
gadget
anchors
bulk-streams
+   callbacks
writing_usb_driver
writing_musb_glue_layer
 
-- 
2.9.3

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

[PATCH v2 14/21] usb/hotplug.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core features. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../hotplug.txt => driver-api/usb/hotplug.rst} | 66 --
 Documentation/driver-api/usb/index.rst |  1 +
 2 files changed, 37 insertions(+), 30 deletions(-)
 rename Documentation/{usb/hotplug.txt => driver-api/usb/hotplug.rst} (76%)

diff --git a/Documentation/usb/hotplug.txt 
b/Documentation/driver-api/usb/hotplug.rst
similarity index 76%
rename from Documentation/usb/hotplug.txt
rename to Documentation/driver-api/usb/hotplug.rst
index 5b243f315b2c..79663e653ca1 100644
--- a/Documentation/usb/hotplug.txt
+++ b/Documentation/driver-api/usb/hotplug.rst
@@ -1,4 +1,9 @@
-LINUX HOTPLUGGING
+USB hotplugging
+~~~
+
+Linux Hotplugging
+=
+
 
 In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
 into the bus with power on.  In most cases, users expect the devices to become
@@ -30,11 +35,11 @@ Because some of those actions rely on information about 
drivers (metadata)
 that is currently available only when the drivers are dynamically linked,
 you get the best hotplugging when you configure a highly modular system.
 
+Kernel Hotplug Helper (``/sbin/hotplug``)
+=
 
-KERNEL HOTPLUG HELPER (/sbin/hotplug)
-
-There is a kernel parameter: /proc/sys/kernel/hotplug, which normally
-holds the pathname "/sbin/hotplug".  That parameter names a program
+There is a kernel parameter: ``/proc/sys/kernel/hotplug``, which normally
+holds the pathname ``/sbin/hotplug``.  That parameter names a program
 which the kernel may invoke at various times.
 
 The /sbin/hotplug program can be invoked by any subsystem as part of its
@@ -51,26 +56,26 @@ Hotplug software and other resources is available at:
 Mailing list information is also available at that site.
 
 
---
+USB Policy Agent
+
 
-
-USB POLICY AGENT
-
-The USB subsystem currently invokes /sbin/hotplug when USB devices
+The USB subsystem currently invokes ``/sbin/hotplug`` when USB devices
 are added or removed from system.  The invocation is done by the kernel
 hub workqueue [hub_wq], or else as part of root hub initialization
 (done by init, modprobe, kapmd, etc).  Its single command line parameter
 is the string "usb", and it passes these environment variables:
 
-ACTION ... "add", "remove"
-PRODUCT ... USB vendor, product, and version codes (hex)
-TYPE ... device class codes (decimal)
-INTERFACE ... interface 0 class codes (decimal)
+== 
+ACTION ``add``, ``remove``
+PRODUCTUSB vendor, product, and version codes (hex)
+TYPE   device class codes (decimal)
+INTERFACE  interface 0 class codes (decimal)
+== 
 
 If "usbdevfs" is configured, DEVICE and DEVFS are also passed.  DEVICE is
 the pathname of the device, and is useful for devices with multiple and/or
 alternate interfaces that complicate driver selection.  By design, USB
-hotplugging is independent of "usbdevfs":  you can do most essential parts
+hotplugging is independent of ``usbdevfs``:  you can do most essential parts
 of USB device setup without using that filesystem, and without running a
 user mode daemon to detect changes in system configuration.
 
@@ -79,19 +84,20 @@ modules, and can invoke driver-specific setup scripts.  The 
newest ones
 leverage USB module-init-tools support.  Later agents might unload drivers.
 
 
-USB MODUTILS SUPPORT
+USB Modutils Support
+
 
-Current versions of module-init-tools will create a "modules.usbmap" file
-which contains the entries from each driver's MODULE_DEVICE_TABLE.  Such
+Current versions of module-init-tools will create a ``modules.usbmap`` file
+which contains the entries from each driver's ``MODULE_DEVICE_TABLE``.  Such
 files can be used by various user mode policy agents to make sure all the
 right driver modules get loaded, either at boot time or later.
 
-See  for full information about such table entries; or look
+See ``linux/usb.h`` for full information about such table entries; or look
 at existing drivers.  Each table entry describes one or more criteria to
 be used when matching a driver to a device or class of devices.  The
 specific criteria are identified by bits set in "match_flags", paired
 with field values.  You can construct the criteria directly, or with
-macros such as these, and use driver_info to store more information.
+macros such as these, and use driver_info to store more information::
 
 USB_DEVICE (vendorId, productId)
... matching devices with specified vendor and product ids
@@ -103,7 +109,7 @@ macros such as these, and use driver_info to store more 
information.
... matching specified device class info
 
 A short example, 

[PATCH v2 01/21] tmplcvt: make the tool more robust

[Mauro Carvalho Chehab]

Currently, the script just assumes to be called at
Documentation/sphinx/. Change it to work on any directory,
and make it abort if something gets wrong.

Also, be sure that both parameters are specified.

That should avoid troubles like this:

$ Documentation/sphinx/tmplcvt Documentation/DocBook/writing_usb_driver.tmpl
sed: couldn't open file convert_template.sed: No such file or directory

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/sphinx/tmplcvt | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/sphinx/tmplcvt b/Documentation/sphinx/tmplcvt
index 909a73065e0a..6848f0a26fa5 100755
--- a/Documentation/sphinx/tmplcvt
+++ b/Documentation/sphinx/tmplcvt
@@ -7,13 +7,22 @@
 # fix \_
 # title line?
 #
+set -eu
+
+if [ "$#" != "2" ]; then
+   echo "$0  "
+   exit
+fi
+
+DIR=$(dirname $0)
 
 in=$1
 rst=$2
 tmp=$rst.tmp
 
 cp $in $tmp
-sed --in-place -f convert_template.sed $tmp
+sed --in-place -f $DIR/convert_template.sed $tmp
 pandoc -s -S -f docbook -t rst -o $rst $tmp
-sed --in-place -f post_convert.sed $rst
+sed --in-place -f $DIR/post_convert.sed $rst
 rm $tmp
+echo "book writen to $rst"
-- 
2.9.3

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

[PATCH v2 20/21] usb: gadget.h: be consistent at kernel doc macros

[Mauro Carvalho Chehab]

There's one value that use spaces instead of tabs to ident.
That causes the following warning:

./include/linux/usb/gadget.h:193: ERROR: Unexpected indentation.

Signed-off-by: Mauro Carvalho Chehab 
---
 include/linux/usb/gadget.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e4516e9ded0f..fbc22a39e7bc 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -188,7 +188,7 @@ struct usb_ep_caps {
  * @caps:The structure describing types and directions supported by endoint.
  * @maxpacket:The maximum packet size used on this endpoint.  The initial
  * value can sometimes be reduced (hardware allowing), according to
- *  the endpoint descriptor used to configure the endpoint.
+ * the endpoint descriptor used to configure the endpoint.
  * @maxpacket_limit:The maximum packet size value which can be handled by this
  * endpoint. It's set once by UDC driver when endpoint is initialized, and
  * should not be changed. Should not be confused with maxpacket.
-- 
2.9.3

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

[PATCH v2 00/21] Convert USB documentation to ReST format

[Mauro Carvalho Chehab]

Currently, there are several USB core documents that are at either
written in plain text or in DocBook format. Convert them to ReST
and add to the driver-api book.

Mauro Carvalho Chehab (21):
  tmplcvt: make the tool more robust
  driver-api/basics.rst: add device table header
  docs-rst: convert usb docbooks to ReST
  usb.rst: Enrich its ReST representation
  gadget.rst: Enrich its ReST representation and add kernel-doc tag
  writing_usb_driver.rst: Enrich its ReST representation
  writing_musb_glue_layer.rst: Enrich its ReST representation
  usb/anchors.txt: convert to ReST and add to driver-api book
  usb/bulk-streams.txt: convert to ReST and add to driver-api book
  usb/callbacks.txt: convert to ReST and add to driver-api book
  usb/power-management.txt: convert to ReST and add to driver-api book
  usb/dma.txt: convert to ReST and add to driver-api book
  error-codes.rst: convert to ReST and add to driver-api book
  usb/hotplug.txt: convert to ReST and add to driver-api book
  usb/persist.txt: convert to ReST and add to driver-api book
  usb/URB.txt: convert to ReST and update it
  usb.rst: get rid of some Sphinx errors
  usb: get rid of some ReST doc build errors
  usb: composite.h: fix two warnings when building docs
  usb: gadget.h: be consistent at kernel doc macros
  docs-rst: fix usb cross-references

 Documentation/ABI/stable/sysfs-bus-usb |   2 +-
 Documentation/DocBook/Makefile |   7 +-
 Documentation/DocBook/gadget.tmpl  | 793 ---
 Documentation/DocBook/writing_musb_glue_layer.tmpl | 873 -
 Documentation/DocBook/writing_usb_driver.tmpl  | 412 --
 Documentation/driver-api/basics.rst|   6 +
 Documentation/driver-api/index.rst |   2 +-
 .../{usb/URB.txt => driver-api/usb/URB.rst}| 223 +++---
 .../anchors.txt => driver-api/usb/anchors.rst} |  36 +-
 .../usb/bulk-streams.rst}  |  13 +-
 .../callbacks.txt => driver-api/usb/callbacks.rst} |  65 +-
 .../{usb/dma.txt => driver-api/usb/dma.rst}|  51 +-
 Documentation/driver-api/usb/error-codes.rst   | 207 +
 Documentation/driver-api/usb/gadget.rst| 510 
 .../hotplug.txt => driver-api/usb/hotplug.rst} |  66 +-
 Documentation/driver-api/usb/index.rst |  26 +
 .../persist.txt => driver-api/usb/persist.rst} |  22 +-
 .../usb/power-management.rst}  | 404 +-
 Documentation/driver-api/{ => usb}/usb.rst | 222 +++---
 .../driver-api/usb/writing_musb_glue_layer.rst | 723 +
 .../driver-api/usb/writing_usb_driver.rst  | 326 
 Documentation/power/swsusp.txt |   2 +-
 Documentation/sphinx/tmplcvt   |  13 +-
 Documentation/usb/error-codes.txt  | 175 -
 drivers/staging/most/hdm-usb/hdm_usb.c |   2 +-
 drivers/usb/core/Kconfig   |   2 +-
 drivers/usb/core/message.c |   1 +
 include/linux/usb/composite.h  |   6 +-
 include/linux/usb/gadget.h |   2 +-
 29 files changed, 2417 insertions(+), 2775 deletions(-)
 delete mode 100644 Documentation/DocBook/gadget.tmpl
 delete mode 100644 Documentation/DocBook/writing_musb_glue_layer.tmpl
 delete mode 100644 Documentation/DocBook/writing_usb_driver.tmpl
 rename Documentation/{usb/URB.txt => driver-api/usb/URB.rst} (50%)
 rename Documentation/{usb/anchors.txt => driver-api/usb/anchors.rst} (75%)
 rename Documentation/{usb/bulk-streams.txt => driver-api/usb/bulk-streams.rst} 
(94%)
 rename Documentation/{usb/callbacks.txt => driver-api/usb/callbacks.rst} (76%)
 rename Documentation/{usb/dma.txt => driver-api/usb/dma.rst} (79%)
 create mode 100644 Documentation/driver-api/usb/error-codes.rst
 create mode 100644 Documentation/driver-api/usb/gadget.rst
 rename Documentation/{usb/hotplug.txt => driver-api/usb/hotplug.rst} (76%)
 create mode 100644 Documentation/driver-api/usb/index.rst
 rename Documentation/{usb/persist.txt => driver-api/usb/persist.rst} (94%)
 rename Documentation/{usb/power-management.txt => 
driver-api/usb/power-management.rst} (69%)
 rename Documentation/driver-api/{ => usb}/usb.rst (85%)
 create mode 100644 Documentation/driver-api/usb/writing_musb_glue_layer.rst
 create mode 100644 Documentation/driver-api/usb/writing_usb_driver.rst
 delete mode 100644 Documentation/usb/error-codes.txt

-- 
2.9.3


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

[PATCH v2 05/21] gadget.rst: Enrich its ReST representation and add kernel-doc tag

[Mauro Carvalho Chehab]

The pandoc conversion is not perfect. Do handwork in order to:

- add a title to this chapter;
- use the proper warning and note markups;
- use kernel-doc to include Kernel header and c files;
- remove legacy notes with regards to DocBook;
- some other minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/gadget.rst | 127 +---
 1 file changed, 52 insertions(+), 75 deletions(-)

diff --git a/Documentation/driver-api/usb/gadget.rst 
b/Documentation/driver-api/usb/gadget.rst
index 52b299b1ca6d..3e8a3809c0b8 100644
--- a/Documentation/driver-api/usb/gadget.rst
+++ b/Documentation/driver-api/usb/gadget.rst
@@ -38,7 +38,7 @@ address a number of important problems, including:
resources.
 
 Most Linux developers will not be able to use this API, since they have
-USB "host" hardware in a PC, workstation, or server. Linux users with
+USB ``host`` hardware in a PC, workstation, or server. Linux users with
 embedded systems are more likely to have USB peripheral hardware. To
 distinguish drivers running inside such hardware from the more familiar
 Linux "USB device drivers", which are host side proxies for the real USB
@@ -64,7 +64,7 @@ Structure of Gadget Drivers
 
 A system running inside a USB peripheral normally has at least three
 layers inside the kernel to handle USB protocol processing, and may have
-additional layers in user space code. The "gadget" API is used by the
+additional layers in user space code. The ``gadget`` API is used by the
 middle layer to interact with the lowest level (which directly handles
 hardware).
 
@@ -143,13 +143,13 @@ In Linux, from the bottom up, these layers are:
 *Additional Layers*
 Other layers may exist. These could include kernel layers, such as
 network protocol stacks, as well as user mode applications building
-on standard POSIX system call APIs such as *open()*, *close()*,
-*read()* and *write()*. On newer systems, POSIX Async I/O calls may
+on standard POSIX system call APIs such as ``open()``, ``close()``,
+``read()`` and ``write()``. On newer systems, POSIX Async I/O calls may
 be an option. Such user mode code will not necessarily be subject to
 the GNU General Public License (GPL).
 
 OTG-capable systems will also need to include a standard Linux-USB host
-side stack, with *usbcore*, one or more *Host Controller Drivers*
+side stack, with ``usbcore``, one or more *Host Controller Drivers*
 (HCDs), *USB Device Drivers* to support the OTG "Targeted Peripheral
 List", and so forth. There will also be an *OTG Controller Driver*,
 which is visible to gadget and device driver developers only indirectly.
@@ -174,24 +174,20 @@ combined, to implement composite devices.
 Kernel Mode Gadget API
 ==
 
-Gadget drivers declare themselves through a *struct
-usb_gadget_driver*, which is responsible for most parts of enumeration
-for a *struct usb_gadget*. The response to a set_configuration usually
-involves enabling one or more of the *struct usb_ep* objects exposed by
-the gadget, and submitting one or more *struct usb_request* buffers to
+Gadget drivers declare themselves through a struct
+:c:type:`usb_gadget_driver`, which is responsible for most parts of enumeration
+for a struct :c:type:`usb_gadget`. The response to a set_configuration usually
+involves enabling one or more of the struct :c:type:`usb_ep` objects exposed by
+the gadget, and submitting one or more struct :c:type:`usb_request` buffers to
 transfer data. Understand those four data types, and their operations,
 and you will understand how this API works.
 
-**Note**
+.. Note::
 
-This documentation was prepared using the standard Linux kernel
-``docproc`` tool, which turns text and in-code comments into SGML
-DocBook and then into usable formats such as HTML or PDF. Other than
-the "Chapter 9" data types, most of the significant data types and
-functions are described here.
+Other than the "Chapter 9" data types, most of the significant data
+types and functions are described here.
 
-However, docproc does not understand all the C constructs that are
-used, so some relevant information is likely omitted from what you
+However, some relevant information is likely omitted from what you
 are reading. One example of such information is endpoint
 autoconfiguration. You'll have to read the header file, and use
 example source code (such as that for "Gadget Zero"), to fully
@@ -199,10 +195,10 @@ and you will understand how this API works.
 
 The part of the API implementing some basic driver capabilities is
 specific to the version of the Linux kernel that's in use. The 2.6
-kernel includes a *driver model* framework that has no analogue on
-earlier kernels; so those parts of the gadget API are not fully
-portable. (They are implemented on 2.4 

[PATCH v2 11/21] usb/power-management.txt: convert to ReST and add to driver-api book

[Mauro Carvalho Chehab]

This document describe some USB core functions. Add it to the
driver-api book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/usb/index.rst |   1 +
 .../usb/power-management.rst}  | 404 +++--
 2 files changed, 214 insertions(+), 191 deletions(-)
 rename Documentation/{usb/power-management.txt => 
driver-api/usb/power-management.rst} (69%)

diff --git a/Documentation/driver-api/usb/index.rst 
b/Documentation/driver-api/usb/index.rst
index 441c5dacdf27..23c76c17fc19 100644
--- a/Documentation/driver-api/usb/index.rst
+++ b/Documentation/driver-api/usb/index.rst
@@ -9,6 +9,7 @@ Linux USB API
anchors
bulk-streams
callbacks
+   power-management
writing_usb_driver
writing_musb_glue_layer
 
diff --git a/Documentation/usb/power-management.txt 
b/Documentation/driver-api/usb/power-management.rst
similarity index 69%
rename from Documentation/usb/power-management.txt
rename to Documentation/driver-api/usb/power-management.rst
index 00e706997130..c068257f6d27 100644
--- a/Documentation/usb/power-management.txt
+++ b/Documentation/driver-api/usb/power-management.rst
@@ -1,10 +1,12 @@
-   Power Management for USB
+.. _usb-power-management:
 
-Alan Stern 
-
-  Last-updated: February 2014
+Power Management for USB
+
 
+:Author: Alan Stern 
+:Date: Last-updated: February 2014
 
+..
Contents:
-
* What is Power Management?
@@ -25,14 +27,14 @@
* Suggested Userspace Port Power Policy
 
 
-   What is Power Management?
-   -
+What is Power Management?
+-
 
 Power Management (PM) is the practice of saving energy by suspending
 parts of a computer system when they aren't being used.  While a
-component is "suspended" it is in a nonfunctional low-power state; it
+component is ``suspended`` it is in a nonfunctional low-power state; it
 might even be turned off completely.  A suspended component can be
-"resumed" (returned to a functional full-power state) when the kernel
+``resumed`` (returned to a functional full-power state) when the kernel
 needs to use it.  (There also are forms of PM in which components are
 placed in a less functional but still usable state instead of being
 suspended; an example would be reducing the CPU's clock rate.  This
@@ -44,22 +46,25 @@ device is turned off while the system as a whole remains 
running, we
 call it a "dynamic suspend" (also known as a "runtime suspend" or
 "selective suspend").  This document concentrates mostly on how
 dynamic PM is implemented in the USB subsystem, although system PM is
-covered to some extent (see Documentation/power/*.txt for more
+covered to some extent (see ``Documentation/power/*.txt`` for more
 information about system PM).
 
-System PM support is present only if the kernel was built with CONFIG_SUSPEND
-or CONFIG_HIBERNATION enabled.  Dynamic PM support for USB is present whenever
-the kernel was built with CONFIG_PM enabled.
+System PM support is present only if the kernel was built with
+``CONFIG_SUSPEND`` or ``CONFIG_HIBERNATION`` enabled.  Dynamic PM support
+
+for USB is present whenever
+the kernel was built with ``CONFIG_PM`` enabled.
 
 [Historically, dynamic PM support for USB was present only if the
-kernel had been built with CONFIG_USB_SUSPEND enabled (which depended on
-CONFIG_PM_RUNTIME).  Starting with the 3.10 kernel release, dynamic PM support
-for USB was present whenever the kernel was built with CONFIG_PM_RUNTIME
-enabled.  The CONFIG_USB_SUSPEND option had been eliminated.]
+kernel had been built with ``CONFIG_USB_SUSPEND`` enabled (which depended on
+``CONFIG_PM_RUNTIME``).  Starting with the 3.10 kernel release, dynamic PM
+support for USB was present whenever the kernel was built with
+``CONFIG_PM_RUNTIME`` enabled.  The ``CONFIG_USB_SUSPEND`` option had been
+eliminated.]
 
 
-   What is Remote Wakeup?
-   --
+What is Remote Wakeup?
+--
 
 When a device has been suspended, it generally doesn't resume until
 the computer tells it to.  Likewise, if the entire computer has been
@@ -76,8 +81,8 @@ event.  Examples include a suspended keyboard resuming when a 
key is
 pressed, or a suspended USB hub resuming when a device is plugged in.
 
 
-   When is a USB device idle?
-   --
+When is a USB device idle?
+--
 
 A device is idle whenever the kernel thinks it's not busy doing
 anything important and thus is a candidate for being suspended.  The
@@ -92,11 +97,11 @@ If a USB device has no driver, its usbfs file isn't open, 
and it isn't
 being accessed through sysfs, then it definitely is idle.
 
 
-   Forms of dynamic PM
-   ---
+Forms of dynamic PM
+---
 
 

[PATCH v2 07/21] writing_musb_glue_layer.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

This file is actually quite complex, and required several
manual handwork:

- add a title for the document;
- use the right tags for monospaced fonts;
- use c references where needed;
- adjust cross-reference to writing_usb_driver.rst
- hightlight cross-referenced lines.

With regards to C code snippet line highlights, the better would be
to use :linenos: for the C code snippets that are referenced by
the line number. However, at least with Sphinx 1.4.9, enabling
it cause the line number to be misaligned with the code,
making it even more confusing. So, instead, let's use
:emphasize-lines: tag to mark the lines that are referenced
at the text.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../driver-api/usb/writing_musb_glue_layer.rst | 598 ++---
 1 file changed, 292 insertions(+), 306 deletions(-)

diff --git a/Documentation/driver-api/usb/writing_musb_glue_layer.rst 
b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
index 52700c7031f9..e90e8fa95600 100644
--- a/Documentation/driver-api/usb/writing_musb_glue_layer.rst
+++ b/Documentation/driver-api/usb/writing_musb_glue_layer.rst
@@ -1,6 +1,6 @@
-==
-Writing an MUSB Glue Layer
-==
+=
+Writing a MUSB Glue Layer
+=
 
 :Author: Apelete Seketeli
 
@@ -21,10 +21,12 @@ design.
 As a self-taught exercise I have written an MUSB glue layer for the
 Ingenic JZ4740 SoC, modelled after the many MUSB glue layers in the
 kernel source tree. This layer can be found at
-drivers/usb/musb/jz4740.c. In this documentation I will walk through the
-basics of the jz4740.c glue layer, explaining the different pieces and
+``drivers/usb/musb/jz4740.c``. In this documentation I will walk through the
+basics of the ``jz4740.c`` glue layer, explaining the different pieces and
 what needs to be done in order to write your own device glue layer.
 
+.. _musb-basics:
+
 Linux MUSB Basics
 =
 
@@ -39,33 +41,30 @@ USB Device Drivers documentation (again, see Resources).
 
 Linux USB stack is a layered architecture in which the MUSB controller
 hardware sits at the lowest. The MUSB controller driver abstract the
-MUSB controller hardware to the Linux USB stack.
+MUSB controller hardware to the Linux USB stack::
 
-::
-
-  
-  |  | <--- drivers/usb/gadget
-  | Linux USB Core Stack | <--- drivers/usb/host
-  |  | <--- drivers/usb/core
-  
- ⬍
- --
- || <-- drivers/usb/musb/musb_gadget.c
- | MUSB Controller driver | <-- drivers/usb/musb/musb_host.c
- || <-- drivers/usb/musb/musb_core.c
- --
- ⬍
+ 
+ |  | <--- drivers/usb/gadget
+ | Linux USB Core Stack | <--- drivers/usb/host
+ |  | <--- drivers/usb/core
+ 
+⬍
+--
+|| <-- drivers/usb/musb/musb_gadget.c
+| MUSB Controller driver | <-- drivers/usb/musb/musb_host.c
+|| <-- drivers/usb/musb/musb_core.c
+--
+⬍
   -
   | MUSB Platform Specific Driver |
   |   | <-- drivers/usb/musb/jz4740.c
   |   aka "Glue Layer"|
   -
- ⬍
+⬍
   -
   |   MUSB Controller Hardware|
   -
 
-
 As outlined above, the glue layer is actually the platform specific code
 sitting in between the controller driver and the controller hardware.
 
@@ -78,37 +77,32 @@ about an embedded controller chip here, so no insertion or 
removal at
 run-time.
 
 All of this information is passed to the MUSB controller driver through
-a platform_driver structure defined in the glue layer as:
-
-::
+a :c:type:`platform_driver` structure defined in the glue layer as::
 
 static struct platform_driver jz4740_driver = {
-.probe  = jz4740_probe,
-.remove = jz4740_remove,
-.driver = {
-.name   = "musb-jz4740",
-},
+   .probe  = jz4740_probe,
+   .remove = jz4740_remove,
+   .driver = {
+   .name   = "musb-jz4740",
+   },
 };
 
-
 The probe and remove function pointers are called when a matching device
 is detected and, respectively, released. The name string describes the
 device supported by this glue layer. In the current case it matches a

[PATCH v2 16/21] usb/URB.txt: convert to ReST and update it

[Mauro Carvalho Chehab]

The URB doc describes the Kernel mechanism that do USB transfers.
While the functions are already described at urb.h, there are a
number of concepts and theory that are important for USB driver
developers.

Convert it to ReST and use C ref links to point to the places
at usb.h where each function and struct is located.

A few of those descriptions were incomplete. While here, update
to reflect the current API status.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../{usb/URB.txt => driver-api/usb/URB.rst}| 221 -
 Documentation/driver-api/usb/index.rst |   1 +
 Documentation/driver-api/usb/usb.rst   |   2 +
 3 files changed, 127 insertions(+), 97 deletions(-)
 rename Documentation/{usb/URB.txt => driver-api/usb/URB.rst} (50%)

diff --git a/Documentation/usb/URB.txt b/Documentation/driver-api/usb/URB.rst
similarity index 50%
rename from Documentation/usb/URB.txt
rename to Documentation/driver-api/usb/URB.rst
index 50da0d455444..c4a141f29477 100644
--- a/Documentation/usb/URB.txt
+++ b/Documentation/driver-api/usb/URB.rst
@@ -1,28 +1,35 @@
-Revised: 2000-Dec-05.
-Again:   2002-Jul-06
-Again:   2005-Sep-19
+USB Request Block (URB)
+~~~
 
-NOTE:
+:Revised: 2000-Dec-05
+:Again:   2002-Jul-06
+:Again:   2005-Sep-19
+:Again:   2017-Mar-29
 
-The USB subsystem now has a substantial section in "The Linux Kernel API"
-guide (in Documentation/DocBook), generated from the current source
-code.  This particular documentation file isn't particularly current or
-complete; don't rely on it except for a quick overview.
 
+.. note::
 
-1.1. Basic concept or 'What is an URB?'
+The USB subsystem now has a substantial section at :ref:`usb-hostside-api`
+section, generated from the current source code.
+This particular documentation file isn't complete and may not be
+updated to the last version; don't rely on it except for a quick
+overview.
 
-The basic idea of the new driver is message passing, the message itself is 
-called USB Request Block, or URB for short. 
+Basic concept or 'What is an URB?'
+==
 
-- An URB consists of all relevant information to execute any USB transaction 
-  and deliver the data and status back. 
+The basic idea of the new driver is message passing, the message itself is
+called USB Request Block, or URB for short.
 
-- Execution of an URB is inherently an asynchronous operation, i.e. the 
-  usb_submit_urb(urb) call returns immediately after it has successfully
+- An URB consists of all relevant information to execute any USB transaction
+  and deliver the data and status back.
+
+- Execution of an URB is inherently an asynchronous operation, i.e. the
+  :c:func:`usb_submit_urb` call returns immediately after it has successfully
   queued the requested action.
 
-- Transfers for one URB can be canceled with usb_unlink_urb(urb) at any time. 
+- Transfers for one URB can be canceled with :c:func:`usb_unlink_urb`
+  at any time.
 
 - Each URB has a completion handler, which is called after the action
   has been successfully completed or canceled. The URB also contains a
@@ -35,53 +42,55 @@ called USB Request Block, or URB for short.
   of data to (or from) devices when using periodic transfer modes.
 
 
-1.2. The URB structure
+The URB structure
+=
 
-Some of the fields in an URB are:
+Some of the fields in struct :c:type:`urb` are::
 
-struct urb
-{
-// (IN) device and pipe specify the endpoint queue
+  struct urb
+  {
+  // (IN) device and pipe specify the endpoint queue
struct usb_device *dev; // pointer to associated USB device
unsigned int pipe;  // endpoint information
 
-   unsigned int transfer_flags;// ISO_ASAP, SHORT_NOT_OK, etc.
+   unsigned int transfer_flags;// URB_ISO_ASAP, URB_SHORT_NOT_OK, etc.
 
-// (IN) all urbs need completion routines
+  // (IN) all urbs need completion routines
void *context;  // context for completion routine
-   void (*complete)(struct urb *); // pointer to completion routine
+   usb_complete_t complete;// pointer to completion routine
 
-// (OUT) status after each completion
+  // (OUT) status after each completion
int status; // returned status
 
-// (IN) buffer used for data transfers
+  // (IN) buffer used for data transfers
void *transfer_buffer;  // associated data buffer
-   int transfer_buffer_length; // data buffer length
+   u32 transfer_buffer_length; // data buffer length
int number_of_packets;  // size of iso_frame_desc
 
-// (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
-   int actual_length;  // actual data buffer length
+  // (OUT) sometimes only part of CTRL/BULK/INTR transfer_buffer is used
+   u32 actual_length;  // actual data buffer length
 

[PATCH v2 06/21] writing_usb_driver.rst: Enrich its ReST representation

[Mauro Carvalho Chehab]

The pandoc conversion is not perfect. Do handwork in order to:

- add a title to this chapter;
- adjust function and struct references;
- use monospaced fonts for C code names;
- some other minor adjustments to make it better to read in
  text mode and in html.

Signed-off-by: Mauro Carvalho Chehab 
---
 .../driver-api/usb/writing_usb_driver.rst  | 182 ++---
 1 file changed, 82 insertions(+), 100 deletions(-)

diff --git a/Documentation/driver-api/usb/writing_usb_driver.rst 
b/Documentation/driver-api/usb/writing_usb_driver.rst
index c18dbd74152b..69f077dcdb78 100644
--- a/Documentation/driver-api/usb/writing_usb_driver.rst
+++ b/Documentation/driver-api/usb/writing_usb_driver.rst
@@ -1,3 +1,5 @@
+.. _writing-usb-driver:
+
 ==
 Writing USB Device Drivers
 ==
@@ -48,25 +50,23 @@ The first thing a Linux USB driver needs to do is register 
itself with
 the Linux USB subsystem, giving it some information about which devices
 the driver supports and which functions to call when a device supported
 by the driver is inserted or removed from the system. All of this
-information is passed to the USB subsystem in the usb_driver structure.
-The skeleton driver declares a usb_driver as:
-
-::
+information is passed to the USB subsystem in the :c:type:`usb_driver`
+structure. The skeleton driver declares a :c:type:`usb_driver` as::
 
 static struct usb_driver skel_driver = {
-.name= "skeleton",
-.probe   = skel_probe,
-.disconnect  = skel_disconnect,
-.fops= _fops,
-.minor   = USB_SKEL_MINOR_BASE,
-.id_table= skel_table,
+   .name= "skeleton",
+   .probe   = skel_probe,
+   .disconnect  = skel_disconnect,
+   .fops= _fops,
+   .minor   = USB_SKEL_MINOR_BASE,
+   .id_table= skel_table,
 };
 
 
 The variable name is a string that describes the driver. It is used in
 informational messages printed to the system log. The probe and
 disconnect function pointers are called when a device that matches the
-information provided in the id_table variable is either seen or
+information provided in the ``id_table`` variable is either seen or
 removed.
 
 The fops and minor variables are optional. Most USB drivers hook into
@@ -76,78 +76,70 @@ subsystem, and any user-space interactions are provided 
through that
 interface. But for drivers that do not have a matching kernel subsystem,
 such as MP3 players or scanners, a method of interacting with user space
 is needed. The USB subsystem provides a way to register a minor device
-number and a set of file_operations function pointers that enable this
-user-space interaction. The skeleton driver needs this kind of
+number and a set of :c:type:`file_operations` function pointers that enable
+this user-space interaction. The skeleton driver needs this kind of
 interface, so it provides a minor starting number and a pointer to its
-file_operations functions.
+:c:type:`file_operations` functions.
 
-The USB driver is then registered with a call to usb_register, usually
-in the driver's init function, as shown here:
-
-::
+The USB driver is then registered with a call to :c:func:`usb_register`,
+usually in the driver's init function, as shown here::
 
 static int __init usb_skel_init(void)
 {
-int result;
+   int result;
 
-/* register this driver with the USB subsystem */
-result = usb_register(_driver);
-if (result < 0) {
-err("usb_register failed for the "__FILE__ "driver."
-"Error number %d", result);
-return -1;
-}
+   /* register this driver with the USB subsystem */
+   result = usb_register(_driver);
+   if (result < 0) {
+   err("usb_register failed for the "__FILE__ "driver."
+   "Error number %d", result);
+   return -1;
+   }
 
-return 0;
+   return 0;
 }
 module_init(usb_skel_init);
 
 
 When the driver is unloaded from the system, it needs to deregister
-itself with the USB subsystem. This is done with the usb_deregister
-function:
-
-::
+itself with the USB subsystem. This is done with the :c:func:`usb_deregister`
+function::
 
 static void __exit usb_skel_exit(void)
 {
-/* deregister this driver with the USB subsystem */
-usb_deregister(_driver);
+   /* deregister this driver with the USB subsystem */
+   usb_deregister(_driver);
 }
 module_exit(usb_skel_exit);
 
 
 To enable the linux-hotplug system to load the driver automatically when
-the device is plugged in, you need to create a MODULE_DEVICE_TABLE.
+the device is plugged in, you need to create a ``MODULE_DEVICE_TABLE``.
 The following 

Re: dwc2_hc_chhltd_intr_dma - ChHltd set errors?

[Minas Harutyunyan]

Hi,

On 4/4/2017 11:03 PM, John Stultz wrote:
> On Tue, Apr 4, 2017 at 12:38 AM, Felipe Balbi
>  wrote:
>>
>> Hi,
>>
>> Minas Harutyunyan  writes:
   We've noticed that when using usb ethernet adapters on HiKey, we
 occasionally see errors like:

 dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set,
 but reason is unknown
 dwc2 f72c.usb: hcint 0x0002, intsts 0x06200029

 dwc2 f72c.usb: dwc2_hc_chhltd_intr_dma: Channel 11 - ChHltd set,
 but reason is unknown
 dwc2 f72c.usb: hcint 0x0002, intsts 0x04200029

 Sometimes followed up by a usb error in the driver, something like:
 asix 1-1.2:1.0 eth0: asix_rx_fixup() Bad Header Length 0x36000807, 
 offset 68

 Curious if you've seen any reports like this?
>
> The core version is less than 2.71a, am I right?

 So it looks like its reporting 0x4f54300a for hsotg->regs + GSNPSID
 which looks like DWC2_CORE_REV_3_00a

> Please send full debug log to do more investigation.

 Full dmesg, or is there special debugging you want me to enable?
>>>
>>> Full dmesg around issue.

> Also send us regdump after connecting ethernet adapter.

 Sorry, can you clarify how to generate this?
>>>
>>> cat regdump. To locate dwc2 regdump file: cd /; find -name regdump
>>
>> this won't work if his distro doesn't mount debugfs. Please give
>> complete instructions ;-)
>>
>> # mkdir -p /d
>> # mount -t debugfs none /d
>> # cd /d
>> # find . -name regdump
>>
>> The directory name is the same name as the dwc2 device name, AFAICT. So,
>> check your DTS for the name of the device.
>
> Thanks for the extra details! I didn't have DEBUG_FS built in, so this
> helped clue me in.
>
> Attached are dmesg including the issue and the regdump.
>
> I did notice when cating the regdump file, I saw:
> dwc2 f72c.usb: Mode Mismatch Interrupt: currently in Host mode
> twice. (You'll see it 4 times in the dmesg around 1077 as I cat'ed
> regdump again to verify it wasn't just chance).
>
> Let me know if there is anything else you need!
>
> thanks
> -john
>

Could you please apply attached patch and try again.

Thanks,
Minas
From 412bf7e3dad8a20af937f3682a08116b654deb02 Mon Sep 17 00:00:00 2001
Message-Id: 
<412bf7e3dad8a20af937f3682a08116b654deb02.1491410224.git.hmi...@synopsys.com>
From: Minas Harutyunyan 
Date: Mon, 11 Jul 2016 03:31:17 -0700
Subject: [PATCH] usb: dwc2: hcd: Fix host channel halt flow

According databook in Buffer and External DMA mode
non-split periodic channels can't be halted.

Change-Id: I7c7c4e16309dda7a3b5af34020d46366c357ed49
Signed-off-by: Minas Harutyunyan 
---
 drivers/usb/dwc2/hcd.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index f4ef159b538e..4e6ee398efb7 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -979,6 +979,25 @@ void dwc2_hc_halt(struct dwc2_hsotg *hsotg, struct 
dwc2_host_chan *chan,
 
if (dbg_hc(chan))
dev_vdbg(hsotg->dev, "%s()\n", __func__);
+
+   /*
+* In buffer DMA or external DMA mode channel can't be halted
+* for non-split periodic channels. At the end of the next
+* uframe/frame (in the worst case), the core generates a channel
+* halted and disables the channel automatically.
+*/
+   if ((hsotg->core_params->dma_enable > 0 &&
+hsotg->core_params->dma_desc_enable <= 0) ||
+   (hsotg->hw_params.arch == GHWCFG2_EXT_DMA_ARCH)) {
+   if (!chan->do_split &&
+   (chan->ep_type == USB_ENDPOINT_XFER_ISOC ||
+chan->ep_type == USB_ENDPOINT_XFER_INT)) {
+   dev_err(hsotg->dev, "%s() Channel can't be halted\n",
+   __func__);
+   return;
+   }
+   }
+
if (halt_status == DWC2_HC_XFER_NO_HALT_STATUS)
dev_err(hsotg->dev, "!!! halt_status = %d !!!\n", halt_status);
 
-- 
2.11.0

Re: [PATCH v2 01/22] tmplcvt: make the tool more robust

[Mauro Carvalho Chehab]

Em Sun, 2 Apr 2017 15:32:31 -0600
Jonathan Corbet  escreveu:

> On Thu, 30 Mar 2017 07:45:35 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > Currently, the script just assumes to be called at
> > Documentation/sphinx/. Change it to work on any directory,
> > and make it abort if something gets wrong.
> > 
> > Also, be sure that both parameters are specified.
> > 
> > That should avoid troubles like this:
> > 
> > $ Documentation/sphinx/tmplcvt Documentation/DocBook/writing_usb_driver.tmpl
> > sed: couldn't open file convert_template.sed: No such file or directory  
> 
> What's the status of this patch set?  I saw that Jani had one comment
> that, I think, hasn't been addressed?

I'm resending it today, rebased on the top of docs-next.

I'll send the last patch in separate, as it is unrelated to the
doc conversion.

Regards,
Mauro
--
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 linux-next v3 2/4] usb: gadget: udc: atmel: Minor code cleanup

[Felipe Balbi]

Hi,

cristian.bir...@microchip.com writes:
> From: Cristian Birsan 
>
> Minor code cleanup based on feedback received on mailinglist.
>
> Signed-off-by: Cristian Birsan 
> Acked-by: Nicolas Ferre 

patch 1 applied fine, patch 2 didn't. Please rebase on testing/next

-- 
balbi


signature.asc
Description: PGP signature

[PATCH V7 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets

[Vivek Gautam]

Qualcomm SOCs have QMP phy controller that provides support
to a number of controller, viz. PCIe, UFS, and USB.
Add a new driver, based on generic phy framework, for this
phy controller.

Signed-off-by: Vivek Gautam 
Tested-by: Srinivas Kandagatla 
---

Changes since v6:
 - Rebased on phy/next and *not* including phy grouping series.

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, added an extra readl()
   over the register in qphy_setbits() and qphy_clrbits() to ensure that
   the write is through to the device.
 - Fixed nits about return statement from probe(), phy_pipe_clk_register()
   and qcom_qmp_phy_create().

Changes since v4:
 - Added provision for child nodes representing each phy lane.
   Each of these nodes have their own register space for tx, rx and pcs
   blocks. Added provision in qcom_qmp_phy_create() to iomap these
   address spaces.
 - Added list of clocks and resets that are mandatory for each phy.
   qcom_qmp_phy_clk_init(), and qcom_qmp_phy_reset_init() methods
   request this list and maintains it with qmp.
   The clocks and resets are then enabled/de-asserted based on this list.
   This list is also updated in the binding documentation.
 - Removed qcom_qmp_phy_xlate() method as we don't need it with
   #phy-cells 0.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.
 - Updated copyright year to 2017.

Changes since v3:
 - Renamed 'struct qcom_qmp_phy' to 'struct qcom_qmp' and
   'struct qmp_phy_desc' to 'struct qmp_phy' to avoid any confusion
   in distinguishing between QMP phy block and per-lane phy which is
   the actual phy in Linux eyes (suggested by Bjorn Andersson).
 - Made error labels more idiomatic.
 - Modified status checking for phy pcs.
 - Fixed power_down_delay check.
 - Refactored phy_pipe_clk_register() to register the pipe clock source
   using devm_clk_hw_register() (suggested by Stephen).
 - qcom_qmp_phy_xlate() function:
   - Removed unnecessary 'for loop'.
   - Added additional check for '0' or -ve args_count.
 - Fixed the mixed tabs and spaces in pipe_clk_src diagram.
 - Removed instances of memset() since we use snprintf() for the
   buffers.
 - Refactored qphy_setbits() and qphy_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Using readl_poll_timeout() to simplify pcs ready status polling.
   Also fixed the polling condition for pcs block ready status:
   'Common block ready status bit is set on phy init completion, while
   PCS block ready status bit (PHYSTATUS) is reset on phy init
   completion.'
 - Moved out the per-lane phy creation from probe() to separate
   function.
 - Registering pipe clock source as a fixed rate clock that comes
   out of the PLL block of QMP phy. These source clocks serve as
   parent to 'pipe_clks' that are requested by pcie or usb3 phys.
 - Using of_device_get_match_data() to get match data.
 - Fixed sparse warnings for 'static' and 'const'.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - Fixed missing mutex_unlock() calls in error cases, reported by
   Julia Lawall.
 - Selecting CONFIG_RESET_CONTROLLER when this driver is enabled.
 - Added a boolean property to check if the phy has individual lane
   reset available.
 - Took care or EPROBE_DEFER, dev_vdbg() and other minor nits.
 - Removed references to non-lkml links from commit message.
 - Moved to use separate iomem resources for each lanes.
   Tx, Rx and PCS offsets per lane can now come from dt bindings.

 drivers/phy/Kconfig|8 +
 drivers/phy/Makefile   |1 +
 drivers/phy/phy-qcom-qmp.c | 1153 
 3 files changed, 1162 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qmp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index ccc9178e32cd..bb8140355608 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -439,6 +439,14 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QMP
+   tristate "Qualcomm QMP PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the QMP PHY 

[PATCH V7 3/4] dt-bindings: phy: Add support for QMP phy

[Vivek Gautam]

Qualcomm chipsets have QMP phy controller that provides
support to a number of controller, viz. PCIe, UFS, and USB.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v6:
 - none.

Changes since v5:
 - Added Rob's 'Ack' for the new child nodes based bindings.
 - Dropped leading 0 from the address in 'reg' property.
 - Fixed '@xyz' part of the node name with correct address.

Changes since v4:
 - Added bindings for child nodes. Each phy lane is represented by child
   node with its own register space (for tx, rx and pcs blocks), and clocks
   and resets for power control facility.
 - Removed register space and lane offsets for tx, rx and pcs blocks from
   qmp phy node.
 - #phy-cells is now part of each child node and thus must be 0.
 - Added information on list of mandatory clocks and resets for each phy.

Changes since v3:
 - Added #clock-cells = <1>, indicating that phy is a clock provider.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Using 'phy' for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qmp: new qmp phy driver for qcom-chipsets"
 - Added 'Acked-by' from Rob.
 - Updated bindings to include mem resource as a list of
   offset - length pair for serdes block and for each lane.
 - Added a new binding for 'lane-offsets' that contains offsets
   to tx, rx and pcs blocks from each lane base address.

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   | 106 +
 1 file changed, 106 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
new file mode 100644
index ..e11c563a65ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
@@ -0,0 +1,106 @@
+Qualcomm QMP PHY controller
+===
+
+QMP phy controller supports physical layer functionality for a number of
+controllers on Qualcomm chipsets, such as, PCIe, UFS, and USB.
+
+Required properties:
+ - compatible: compatible list, contains:
+  "qcom,msm8996-qmp-pcie-phy" for 14nm PCIe phy on msm8996,
+  "qcom,msm8996-qmp-usb3-phy" for 14nm USB3 phy on msm8996.
+
+ - reg: offset and length of register set for PHY's common serdes block.
+
+ - #clock-cells: must be 1
+- Phy pll outputs a bunch of clocks for Tx, Rx and Pipe
+  interface (for pipe based PHYs). These clock are then gate-controlled
+  by gcc.
+ - #address-cells: must be 1
+ - #size-cells: must be 1
+ - ranges: must be present
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: "cfg_ahb" for phy config clock,
+   "aux" for phy aux clock,
+   "ref" for 19.2 MHz ref clk,
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+   For "qcom,msm8996-qmp-usb3-phy" must contain:
+   "aux", "cfg_ahb", "ref".
+
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: "phy" for reset of phy block,
+   "common" for phy common block reset,
+   "cfg" for phy's ahb cfg block reset (Optional).
+   For "qcom,msm8996-qmp-pcie-phy" must contain:
+"phy", "common", "cfg".
+   For "qcom,msm8996-qmp-usb3-phy" must contain
+"phy", "common".
+
+ - vdda-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+
+Optional properties:
+ - vddp-ref-clk-supply: Phandle to a regulator supply to any specific refclk
+   pll block.
+
+Required nodes:
+ - Each device node of QMP phy is required to have as many child nodes as
+   the number of lanes the PHY has.
+
+Required properties for child node:
+ - reg: list of offset and length pairs of register sets for PHY blocks -
+   tx, rx and pcs.
+
+ - #phy-cells: must be 0
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: Must contain following for pcie and usb qmp phys:
+"pipe" for pipe clock specific to each lane.
+
+ - resets: a list of phandles and reset controller specifier pairs,
+  one for each entry in reset-names.
+ - reset-names: Must contain following for pcie qmp phys:
+"lane" for reset specific to each lane.
+
+Example:
+   phy@34000 {
+   compatible = "qcom,msm8996-qmp-pcie-phy";
+   reg = <0x34000 0x488>;
+   

[PATCH V7 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

Qualcomm chipsets have QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller.
Adding dt binding information for the same.

Signed-off-by: Vivek Gautam 
Acked-by: Rob Herring 
---

Changes since v6:
 - Dropped 'vdd-phy-supply' that used pm8994_s2 regulator, from bindings.
   As Stephen said, the pm8994_s2 is a 'corner' regulator and it shouldn't
   be right to put it as a regulator supply.
   Work is in progress to handle these sort of power supplies.

Changes since v5:
 - Removed leading 0 from the address in 'reg' property.

Changes since v4:
 - None.

Changes since v3:
 - Added 'Acked-by' from Rob.
 - Removed 'reset-names' and 'nvmem-cell-names' from the bindings
   since we use only one cell.

Changes since v2:
 - Removed binding for "ref_clk_src" since we don't request this
   clock in the driver.
 - Addressed s/vdda-phy-dpdm/vdda-phy-dpdm-supply.
 - Addressed s/ref_clk/ref. Don't need to add '_clk' suffix to clock names.
 - Addressed s/tune2_hstx_trim_efuse/tune2_hstx_trim. Don't need to add
   'efuse' suffix to nvmem cell.
 - Addressed s/qusb2phy/phy for the node name.

Changes since v1:
 - New patch, forked out of the original driver patch:
   "phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips"
 - Updated dt bindings to remove 'hstx-trim-bit-offset' and
   'hstx-trim-bit-len' bindings.

 .../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 ++
 1 file changed, 43 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..aa0fcb05acb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,43 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x7411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdda-pll-supply = <_l12>;
+   vdda-phy-dpdm-supply = <_l24>;
+
+   resets = < GCC_QUSB2PHY_PRIM_BCR>;
+   nvmem-cells = <_hstx_trim>;
+};
-- 
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 V7 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips

[Vivek Gautam]

PHY transceiver driver for QUSB2 phy controller that provides
HighSpeed functionality for DWC3 controller present on
Qualcomm chipsets.

Signed-off-by: Vivek Gautam 
Reviewed-by: Stephen Boyd 
---

Changes since v6:
 - Dropped 'vdd-phy' from list of regulators.
 - Rebased on phy/next and *not* including phy grouping series.

Changes since v5:
 - Rebased on top of phy grouping series. So the driver now sits in
   drivers/phy/qualcomm/
 - Removed instances of readl_relaxed() and writel_relaxed(), and using
   readl() and writel() instead.
 - Replaced regulator handling with regulator_bulk() apis, so that
   qusb2_phy_toggle_power() method is completely dropped.
 - Removed memory barriers from the driver. Instead, using readl() over
   the register to ensure that the write is through to the device.
 - Fixed nits about return statement from probe() and qusb2_phy_poweron().

Changes since v4:
 - Updated the copyright year to 2017.
 - Removed unnecessary of_match_ptr() cast for the match table,
   since the driver is compiled for CONFIG_OF.

Changes since v3:
 - Added 'Reviewed-by' from Stephen.
 - Fixed debug message for qusb2_phy_set_tune2_param().
 - Replaced devm_reset_control_get() with devm_reset_control_get_by_index()
   since we are requesting only one reset.
 - Updated devm_nvmem_cell_get() with a NULL cell id.
 - Made error labels more idiomatic.
 - Refactored qusb2_setbits() and qusb2_clrbits() a little bit to accept
   base address and register offset as two separate arguments.

Changes since v2:
 - Removed selecting 'RESET_CONTROLLER' config.
 - Added error handling for clk_prepare_enable paths.
 - Removed explicitly setting ref_clk rate to 19.2 MHz. Don't need to
   do that since 'xo' is modeled as parent to this clock.
 - Removed 'ref_clk_src' handling. Driver doesn't need to request and
   handle this clock.
 - Moved nvmem_cell_get() to probe function.
 - Simplified phy pll status handling.
 - Using of_device_get_match_data() to get match data.
 - Uniformly using lowercase for hex numbers.
 - Fixed sparse warnings.
 - Using shorter variable names in structure and in functions.
 - Handling various comment style shortcomings.

Changes since v1:
 - removed reference to clk_enabled/pwr_enabled.
 - moved clock and regulator enable code to phy_power_on/off() callbacks.
 - fixed return on EPROBE_DEFER in qusb2_phy_probe().
 - fixed phy create and phy register ordering.
 - removed references to non-lkml links from commit message.
 - took care of other minor nits.
 - Fixed coccinelle warnings -
   'PTR_ERR applied after initialization to constant'
 - Addressed review comment, regarding qfprom access for tune2 param value.
   This driver is now based on qfprom patch[1] that allows byte access now.

 drivers/phy/Kconfig  |  10 +
 drivers/phy/Makefile |   1 +
 drivers/phy/phy-qcom-qusb2.c | 491 +++
 3 files changed, 502 insertions(+)
 create mode 100644 drivers/phy/phy-qcom-qusb2.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index dc5277ad1b5a..ccc9178e32cd 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -439,6 +439,16 @@ config PHY_STIH407_USB
  Enable this support to enable the picoPHY device used by USB2
  and USB3 controllers on STMicroelectronics STiH407 SoC families.
 
+config PHY_QCOM_QUSB2
+   tristate "Qualcomm QUSB2 PHY Driver"
+   depends on OF && (ARCH_QCOM || COMPILE_TEST)
+   select GENERIC_PHY
+   help
+ Enable this to support the HighSpeed QUSB2 PHY transceiver for USB
+ controllers on Qualcomm chips. This driver supports the high-speed
+ PHY which is usually paired with either the ChipIdea or Synopsys DWC3
+ USB IPs on MSM SOCs.
+
 config PHY_QCOM_UFS
tristate "Qualcomm UFS PHY driver"
depends on OF && ARCH_QCOM
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index e7b0feb1e125..0375c6a32697 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)  += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_STIH407_USB)  += phy-stih407-usb.o
+obj-$(CONFIG_PHY_QCOM_QUSB2)   += phy-qcom-qusb2.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-20nm.o
 obj-$(CONFIG_PHY_QCOM_UFS) += phy-qcom-ufs-qmp-14nm.o
diff --git a/drivers/phy/phy-qcom-qusb2.c b/drivers/phy/phy-qcom-qusb2.c
new file mode 100644
index ..045b0743a033
--- /dev/null
+++ b/drivers/phy/phy-qcom-qusb2.c
@@ -0,0 +1,491 @@
+/*
+ * Copyright (c) 2017, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as 

Re: [PATCH v2 1/2] usb: gadget: udc: avoid use of freed pointer

[Felipe Balbi]

Hi,

"Gustavo A. R. Silva"  writes:
> Rewrite udc_free_dma_chain() function to avoid use of pointer after free.
>
> Addresses-Coverity-ID: 1091172
> Acked-by: Michal Nazarewicz 
> Reviewed-by: Greg Kroah-Hartman 
> Signed-off-by: Gustavo A. R. Silva 

doesn't apply to testing/next. Care to rebase?

-- 
balbi


signature.asc
Description: PGP signature

[PATCH V7 0/4] phy: USB and PCIe phy drivers for Qcom chipsets

[Vivek Gautam]

This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
   USB3, PCIe, UFS and few other controllers.

The patches are based on next branch of linux-phy tree.

These patches have been tested on Dragon board db820c hardware with
required set of dt patches and the patches to get rpm up on msm8996.
Couple of other patches [1, 2] fixing DMA config for XHCI are also
pulled in for testing.
A branch based on torvald's master is available in github [3].

Changes since v6:
 - Rebased on phy/next and *not* including phy grouping series[4].
 - qusb2-phy: addressed Stephen's comment.
   - Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
 - qmp-phy: none on functionality side.
 
Changes since v5:
 - Addressed review comments from Bjorn:
   - Removed instances of readl/wirtel_relaxed calls from the drivers.
 Instead, using simple readl/writel. Inserting a readl after a writel
 to ensure the write is through to the device.
   - Replaced regulator handling with regulator_bulk_** apis. This helps
 in cutting down a lot of regulator handling code.
   - Fixed minor return statements.

Changes since v4:
 - Addressed comment to add child nodes for qmp phy driver. Each phy lane
   now has a separate child node under the main qmp node.
 - Modified the clock and reset initialization and enable methods.
   Different phys - pcie, usb and later ufs, have varying number of clocks
   and resets that are mandatory. So adding provision for clocks and reset
   lists helps in requesting all mandatory resources for individual phys
   and handle their failure cases accordingly.

Changes since v3:
 - Addressed review comments given by Rob and Stephen for qusb2 phy
   and qmp phy bindings respectively.
 - Addressed review comments given by Stephen and Bjorn for qmp phy driver.

Changes since v2:
 - Addressed review comments given by Rob and Stephen for bindings.
 - Addressed the review comments given by Stephen for the qusb2 and qmp
   phy drivers.

Changes since v1:
 - Moved device tree binding documentation to separate patches, as suggested
   by Rob.
 - Addressed review comment regarding qfprom accesses by qusb2 phy driver,
   given by Rob.
 - Addressed review comments from Kishon.
 - Addressed review comments from Srinivas for QMP phy driver.
 - Addressed kbuild warning.

Please see individual patches for detailed changelogs.

[1] https://patchwork.kernel.org/patch/9567767/
[2] https://patchwork.kernel.org/patch/9567779/
[3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
[4] https://lkml.org/lkml/2017/3/20/407

Vivek Gautam (4):
  dt-bindings: phy: Add support for QUSB2 phy
  phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
  dt-bindings: phy: Add support for QMP phy
  phy: qcom-qmp: new qmp phy driver for qcom-chipsets

 .../devicetree/bindings/phy/qcom-qmp-phy.txt   |  106 ++
 .../devicetree/bindings/phy/qcom-qusb2-phy.txt |   43 +
 drivers/phy/Kconfig|   18 +
 drivers/phy/Makefile   |2 +
 drivers/phy/phy-qcom-qmp.c | 1153 
 drivers/phy/phy-qcom-qusb2.c   |  491 +
 6 files changed, 1813 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
 create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
 create mode 100644 drivers/phy/phy-qcom-qmp.c
 create mode 100644 drivers/phy/phy-qcom-qusb2.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

Re: [PATCH v4 0/3] phy: Group phy drivers based on vendor listing

[Kishon Vijay Abraham I]

Hi Vivek,

On Wednesday 05 April 2017 05:07 PM, Vivek Gautam wrote:
> Hi Kishon,
> 
> 
> On 04/05/2017 04:34 PM, Kishon Vijay Abraham I wrote:
>> Hi Vivek,
>>
>> On Monday 20 March 2017 06:49 PM, Vivek Gautam wrote:
>>> This is the next version to an earlier posted series [1].
>>> Missed Cc'ing the first patch of the previous series [1] to lkml.
>>> Posting out this series now after addressing comments
>>> and after adding the received 'Acked-by' and 'Reviewed-by'
>>> tags.
>>>
>>> This series is based on linux-phy/next branch.
>>>
>>> [1] https://www.spinics.net/lists/arm-kernel/msg568370.html
>>>
>>> Signed-off-by: Vivek Gautam 
>>> Cc: Kishon Vijay Abraham I 
>>> Cc: linux-arm-ker...@lists.infradead.org
>>> Cc: linux-arm-...@vger.kernel.org
>>> Cc: linux-ker...@vger.kernel.org
>>> Cc: linux-usb@vger.kernel.org
>> The best time to merge this would be immediately after -rc1 is tagged. Can 
>> you
>> resend when 4.12-rc1 is tagged?
> 
> Sure, I will send the series when 4.12-rc1 is out.
> I am also planning to send qcom phy's next version and i had rebased the
> earlier version on this patch series. Should i just rebase those patches on
> top of phy/next, or on this series?

phy/next please..

-Kishon

> 
> 
> Best Regards
> Vivek
> 
>>
>> Thanks
>> Kishon
>>
>>> -- 
>>> Vivek Gautam (3):
>>>phy: qcom-usb: Remove unused ulpi phy header
>>>phy: Move ULPI phy header out of drivers to include path
>>>phy: Group vendor specific phy drivers
>>>
>>>   MAINTAINERS|  18 +-
>>>   drivers/phy/Kconfig| 471
>>> +
>>>   drivers/phy/Makefile   |  67 +--
>>>   drivers/phy/allwinner/Kconfig  |  31 ++
>>>   drivers/phy/allwinner/Makefile |   2 +
>>>   drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
>>>   drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
>>>   drivers/phy/broadcom/Kconfig   |  64 +++
>>>   drivers/phy/broadcom/Makefile  |   7 +
>>>   drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
>>>   drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
>>>   drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
>>>   drivers/phy/hisilicon/Kconfig  |  20 +
>>>   drivers/phy/hisilicon/Makefile |   2 +
>>>   drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
>>>   drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
>>>   drivers/phy/marvell/Kconfig|  50 +++
>>>   drivers/phy/marvell/Makefile   |   6 +
>>>   drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
>>>   drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
>>>   drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
>>>   drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
>>>   drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
>>>   drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
>>>   drivers/phy/qualcomm/Kconfig   |  38 ++
>>>   drivers/phy/qualcomm/Makefile  |   7 +
>>>   drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
>>>   drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   2 -
>>>   drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   2 -
>>>   drivers/phy/renesas/Kconfig|  17 +
>>>   drivers/phy/renesas/Makefile   |   2 +
>>>   drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
>>>   drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
>>>   drivers/phy/rockchip/Kconfig   |  51 +++
>>>   drivers/phy/rockchip/Makefile  |   6 +
>>>   drivers/phy/{ => rockchip}/phy-rockchip-dp.c   |   0
>>>   drivers/phy/{ => rockchip}/phy-rockchip-emmc.c |   0
>>>   .../phy/{ => rockchip}/phy-rockchip-inno-usb2.c|   0
>>>   drivers/phy/{ => rockchip}/phy-rockchip-pcie.c |   0
>>>   drivers/phy/{ => rockchip}/phy-rockchip-typec.c|   0
>>>   drivers/phy/{ => rockchip}/phy-rockchip-usb.c  |   0
>>>   drivers/phy/samsung/Kconfig|  96 +
>>>   drivers/phy/samsung/Makefile   |  

Re: [PATCH v3 0/3] add support of usb2-phy for rk3328

[Kishon Vijay Abraham I]

On Monday 06 March 2017 06:59 AM, Meng Dongyang wrote:
> The config information of RK3328 about address and port property
> is different from other platform. So adds config information in the
> data of match table and the device tree bindings description for
> usb2-phy.
> 
> Changes in v2:
>  - move usb2-phy grf specification to 
> .../devicetree/bindings/soc/rockchip/grf.txt
>  - add otg port config information of rk3328
> Changes in v3:
>  - remove tuning function and id pin configs
>  - delete example of usb2-phy grf in grf.txt

removed the version history in commit log and merged the series.

Thanks
Kishon
> 
> Meng Dongyang (3):
>   dt-bindings: phy: add assign clock property in usb2-phy node
>   dt-bindings: phy: add DT bindings for usb2-phy grf
>   phy: rockchip-inno-usb2: add support of usb2-phy for rk3328
> 
>  .../bindings/phy/phy-rockchip-inno-usb2.txt|  6 +++
>  .../devicetree/bindings/soc/rockchip/grf.txt   |  4 ++
>  drivers/phy/phy-rockchip-inno-usb2.c   | 44 
> ++
>  3 files changed, 54 insertions(+)
> 
--
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: Fw: New Defects reported by Coverity Scan for Linux

[Oliver Neukum]

Am Dienstag, den 04.04.2017, 13:55 +0200 schrieb Bjørn Mork:
> Oliver Neukum  writes:
> > 
> > Am Montag, den 03.04.2017, 12:48 -0700 schrieb Stephen Hemminger:
> > > 
> > > Looks like new warnings in usbnet
> > > 
> > > 
> > > ** CID 751368:  Null pointer dereferences  (FORWARD_NULL)
> > > /drivers/net/usb/usbnet.c: 1925 in __usbnet_read_cmd()
> > 
> > Hi Stephen,
> > 
> > I am afraid I don't see the problem. Yes, we are passing
> > a NULL pointer down, but only if size==0. In that case it
> > is allowed.
> > Could you shed some light on the meaning of the report?
> > I might be overlooking something, but to me it looks
> > like a false positive.
> 
> I wonder if the problem is the unvalidated assumption that
> "data == NULL" implies "size == 0".
> 
> We don't actually test for "size == 0".  Maybe we should?

Yes, I think the test is incorrect. I will change it.

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 v4 0/3] phy: Group phy drivers based on vendor listing

[Kishon Vijay Abraham I]

Hi Vivek,

On Monday 20 March 2017 06:49 PM, Vivek Gautam wrote:
> This is the next version to an earlier posted series [1].
> Missed Cc'ing the first patch of the previous series [1] to lkml.
> Posting out this series now after addressing comments
> and after adding the received 'Acked-by' and 'Reviewed-by'
> tags.
> 
> This series is based on linux-phy/next branch.
> 
> [1] https://www.spinics.net/lists/arm-kernel/msg568370.html
> 
> Signed-off-by: Vivek Gautam 
> Cc: Kishon Vijay Abraham I 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org

The best time to merge this would be immediately after -rc1 is tagged. Can you
resend when 4.12-rc1 is tagged?

Thanks
Kishon

> 
> --
> Vivek Gautam (3):
>   phy: qcom-usb: Remove unused ulpi phy header
>   phy: Move ULPI phy header out of drivers to include path
>   phy: Group vendor specific phy drivers
> 
>  MAINTAINERS|  18 +-
>  drivers/phy/Kconfig| 471 
> +
>  drivers/phy/Makefile   |  67 +--
>  drivers/phy/allwinner/Kconfig  |  31 ++
>  drivers/phy/allwinner/Makefile |   2 +
>  drivers/phy/{ => allwinner}/phy-sun4i-usb.c|   0
>  drivers/phy/{ => allwinner}/phy-sun9i-usb.c|   0
>  drivers/phy/broadcom/Kconfig   |  64 +++
>  drivers/phy/broadcom/Makefile  |   7 +
>  drivers/phy/{ => broadcom}/phy-bcm-cygnus-pcie.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-kona-usb2.c |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns-usb2.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns-usb3.c   |   0
>  drivers/phy/{ => broadcom}/phy-bcm-ns2-pcie.c  |   0
>  drivers/phy/{ => broadcom}/phy-bcm-nsp-usb3.c  |   0
>  drivers/phy/{ => broadcom}/phy-brcm-sata.c |   0
>  drivers/phy/hisilicon/Kconfig  |  20 +
>  drivers/phy/hisilicon/Makefile |   2 +
>  drivers/phy/{ => hisilicon}/phy-hi6220-usb.c   |   0
>  drivers/phy/{ => hisilicon}/phy-hix5hd2-sata.c |   0
>  drivers/phy/marvell/Kconfig|  50 +++
>  drivers/phy/marvell/Makefile   |   6 +
>  drivers/phy/{ => marvell}/phy-armada375-usb2.c |   0
>  drivers/phy/{ => marvell}/phy-berlin-sata.c|   0
>  drivers/phy/{ => marvell}/phy-berlin-usb.c |   0
>  drivers/phy/{ => marvell}/phy-mvebu-sata.c |   0
>  drivers/phy/{ => marvell}/phy-pxa-28nm-hsic.c  |   0
>  drivers/phy/{ => marvell}/phy-pxa-28nm-usb2.c  |   0
>  drivers/phy/qualcomm/Kconfig   |  38 ++
>  drivers/phy/qualcomm/Makefile  |   7 +
>  drivers/phy/{ => qualcomm}/phy-qcom-apq8064-sata.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ipq806x-sata.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-i.h|   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-14nm.h |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.c |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs-qmp-20nm.h |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-ufs.c  |   0
>  drivers/phy/{ => qualcomm}/phy-qcom-usb-hs.c   |   2 -
>  drivers/phy/{ => qualcomm}/phy-qcom-usb-hsic.c |   2 -
>  drivers/phy/renesas/Kconfig|  17 +
>  drivers/phy/renesas/Makefile   |   2 +
>  drivers/phy/{ => renesas}/phy-rcar-gen2.c  |   0
>  drivers/phy/{ => renesas}/phy-rcar-gen3-usb2.c |   0
>  drivers/phy/rockchip/Kconfig   |  51 +++
>  drivers/phy/rockchip/Makefile  |   6 +
>  drivers/phy/{ => rockchip}/phy-rockchip-dp.c   |   0
>  drivers/phy/{ => rockchip}/phy-rockchip-emmc.c |   0
>  .../phy/{ => rockchip}/phy-rockchip-inno-usb2.c|   0
>  drivers/phy/{ => rockchip}/phy-rockchip-pcie.c |   0
>  drivers/phy/{ => rockchip}/phy-rockchip-typec.c|   0
>  drivers/phy/{ => rockchip}/phy-rockchip-usb.c  |   0
>  drivers/phy/samsung/Kconfig|  96 +
>  drivers/phy/samsung/Makefile   |  11 +
>  drivers/phy/{ => samsung}/phy-exynos-dp-video.c|   0
>  drivers/phy/{ => samsung}/phy-exynos-mipi-video.c  |   0
>  drivers/phy/{ => samsung}/phy-exynos-pcie.c|   0
>  drivers/phy/{ => samsung}/phy-exynos4210-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-exynos4x12-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-exynos5-usbdrd.c |   0
>  drivers/phy/{ => samsung}/phy-exynos5250-sata.c|   0
>  drivers/phy/{ => samsung}/phy-exynos5250-usb2.c|   0
>  drivers/phy/{ => samsung}/phy-s5pv210-usb2.c   |   0
>  drivers/phy/{ => samsung}/phy-samsung-usb2.c   |   0
>  drivers/phy/{ => samsung}/phy-samsung-usb2.h   |   0
>  

Re: [PATCH v2 3/6] usb: usbip tool: Add ncontrollers in vhci_driver structure

[Yuyang Du]

On Wed, Apr 05, 2017 at 11:46:06AM +0200, Krzysztof Opasiak wrote:
> 
> 
> On 04/04/2017 09:08 PM, Yuyang Du wrote:
> >Hi Krzysztof,
> >
> >On Tue, Apr 04, 2017 at 04:52:32PM +0200, Krzysztof Opasiak wrote:
> >>
> >>
> >>On 03/31/2017 02:28 AM, Yuyang Du wrote:
> >>>A new field ncontrollers is added to the vhci_driver structure.
> >>>And this field is stored by scanning the vhci_hcd* dirs in the
> >>>platform udev.
> >>>
> >>>Suggested-by: Krzysztof Opasiak 
> >>>Signed-off-by: Yuyang Du 
> >>>---
> >>>tools/usb/usbip/libsrc/vhci_driver.c | 32 +++-
> >>>tools/usb/usbip/libsrc/vhci_driver.h |  1 +
> >>>2 files changed, 32 insertions(+), 1 deletion(-)
> >>>
> >>>diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
> >>>b/tools/usb/usbip/libsrc/vhci_driver.c
> >>>index f659c14..ccecd47 100644
> >>>--- a/tools/usb/usbip/libsrc/vhci_driver.c
> >>>+++ b/tools/usb/usbip/libsrc/vhci_driver.c
> >>>@@ -7,6 +7,7 @@
> >>>#include 
> >>>#include 
> >>>#include 
> >>>+#include 
> >>>#include "sysfs_utils.h"
> >>>
> >>>#undef  PROGNAME
> >>>@@ -134,6 +135,33 @@ static int get_nports(void)
> >>>   return (int)strtoul(attr_nports, NULL, 10);
> >>>}
> >>>
> >>>+static int vhci_hcd_filter(const struct dirent *dirent)
> >>>+{
> >>>+  return strcmp(dirent->d_name, "vhci_hcd") >= 0 ? 1: 0;
> >>
> >>The ? operator may be omitted here as according to doc we need to
> >>return nonzero not 1 exactly.
> >
> >No, it can't. strcmp() would return negative if not containing "vhci_hcd". 
> >E.g.,
> >
> >strcmp("!@#", "vhci_hcd") ==> -1
> >strcmp("v", "vhci_hcd") ==> -1
> 
> I meant, just to drop the ? itself but leave >= 0
> 
> return strcmp(dirent->d_name, "vhci_hcd") >= 0;

Oh, that's doable :)

Send a Reviewed-by ?

Thanks,
Yuyang
--
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: Periodic reconnects of USB mouse on Dell PowerEdge R730

[Oliver Neukum]

Am Mittwoch, den 05.04.2017, 11:14 +0200 schrieb Paul Menzel:

Hi,

> 
> > but did anything come out of this? Do we need to add a quirk?
> 
> Dell said they tried to reproduce this, and couldn’t. Maybe it’s mouse 
> dependent, there are different revisions, and the ID stays the same.

Could you test the same mice on another system with the same revision
of USB?

> Therefore, I wouldn’t add any quirk, until somebody else hits this 
> problem too.

Generally if you run X you are unlikely to hit that problem.

> What would be nice though, is to add a module parameter allowing to 
> enable that quirk.

That has been done with the generic "quirk" module parameter.
We were to hasty when we said that this requires a recompilation.
The quirk you need is

include/linux/hid.h:#define HID_QUIRK_ALWAYS_POLL   
0x0400

HTH
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: Periodic reconnects of USB mouse on Dell PowerEdge R730

[Johan Hovold]

On Wed, Apr 05, 2017 at 11:14:49AM +0200, Paul Menzel wrote:

> On 04/05/17 10:31, Oliver Neukum wrote:

> > but did anything come out of this? Do we need to add a quirk?
> 
> Dell said they tried to reproduce this, and couldn’t. Maybe it’s mouse 
> dependent, there are different revisions, and the ID stays the same.
> 
> Therefore, I wouldn’t add any quirk, until somebody else hits this 
> problem too.
> 
> What would be nice though, is to add a module parameter allowing to 
> enable that quirk.

But you did confirm that enabling the quirk made the problem you had go
away?

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

Re: Periodic reconnects of USB mouse on Dell PowerEdge R730

[Paul Menzel]

Dear Johan,


On 04/05/17 11:49, Johan Hovold wrote:

On Wed, Apr 05, 2017 at 11:14:49AM +0200, Paul Menzel wrote:


On 04/05/17 10:31, Oliver Neukum wrote:



but did anything come out of this? Do we need to add a quirk?


Dell said they tried to reproduce this, and couldn’t. Maybe it’s mouse
dependent, there are different revisions, and the ID stays the same.

Therefore, I wouldn’t add any quirk, until somebody else hits this
problem too.

What would be nice though, is to add a module parameter allowing to
enable that quirk.


But you did confirm that enabling the quirk made the problem you had go
away?


No, I am sorry, I did not get to this yet. Hopefully, I’ll be able to do 
it this week.



Kind regards,

Paul
--
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 3/6] usb: usbip tool: Add ncontrollers in vhci_driver structure

[Krzysztof Opasiak]

On 04/04/2017 09:08 PM, Yuyang Du wrote:

Hi Krzysztof,

On Tue, Apr 04, 2017 at 04:52:32PM +0200, Krzysztof Opasiak wrote:



On 03/31/2017 02:28 AM, Yuyang Du wrote:

A new field ncontrollers is added to the vhci_driver structure.
And this field is stored by scanning the vhci_hcd* dirs in the
platform udev.

Suggested-by: Krzysztof Opasiak 
Signed-off-by: Yuyang Du 
---
tools/usb/usbip/libsrc/vhci_driver.c | 32 +++-
tools/usb/usbip/libsrc/vhci_driver.h |  1 +
2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/tools/usb/usbip/libsrc/vhci_driver.c 
b/tools/usb/usbip/libsrc/vhci_driver.c
index f659c14..ccecd47 100644
--- a/tools/usb/usbip/libsrc/vhci_driver.c
+++ b/tools/usb/usbip/libsrc/vhci_driver.c
@@ -7,6 +7,7 @@
#include 
#include 
#include 
+#include 
#include "sysfs_utils.h"

#undef  PROGNAME
@@ -134,6 +135,33 @@ static int get_nports(void)
return (int)strtoul(attr_nports, NULL, 10);
}

+static int vhci_hcd_filter(const struct dirent *dirent)
+{
+   return strcmp(dirent->d_name, "vhci_hcd") >= 0 ? 1: 0;


The ? operator may be omitted here as according to doc we need to
return nonzero not 1 exactly.


No, it can't. strcmp() would return negative if not containing "vhci_hcd". E.g.,

strcmp("!@#", "vhci_hcd") ==> -1
strcmp("v", "vhci_hcd") ==> -1


I meant, just to drop the ? itself but leave >= 0

return strcmp(dirent->d_name, "vhci_hcd") >= 0;

Cheers,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
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: Periodic reconnects of USB mouse on Dell PowerEdge R730

[Paul Menzel]

Dear Oliver,


On 04/05/17 10:31, Oliver Neukum wrote:

Am Donnerstag, den 09.02.2017, 17:30 +0100 schrieb Paul Menzel:



On 02/08/17 17:54, Johan Hovold wrote:


On Wed, Feb 08, 2017 at 05:41:33PM +0100, Paul Menzel wrote:


On 02/08/17 16:50, Johan Hovold wrote:


On Wed, Feb 08, 2017 at 04:15:02PM +0100, Paul Menzel wrote:


On 02/08/17 14:02, Greg KH wrote:


On Wed, Feb 08, 2017 at 12:16:44PM +0100, Paul Menzel wrote:


On the server Dell PowerEdge R730 with firmware 2.3.4, and Linux 4.9.2, the
connected USB mouse disconnects and connects again periodically. This can be
reproduced with two different (Logitech) mice.

```
$ more /proc/version
Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version
6.3.0 20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 (2017-01-12)
$ journalctl -o short-precise -k -f
[…]
Feb 08 12:00:16.193817 poweredger730 kernel: usb 3-2: USB disconnect, device
number 84


Looks like a hardware issue, the kernel can not cause a device to
disconnect itself.

Especially as this happens with two different mice, you might want to
see if there's something wrong with that port.


With three devices of the Logitech model 046d:c077 (Logitech, Inc. M105
Optical Mouse) the problem could be reproduced on each USB port.


Have you tried enabling the always-poll HID-quirk, which is needed for
certain devices to prevent issues like this?

See commit bfe3c873e978 ("HID: usbhid: enable always-poll quirk for Elan
Touchscreen") for an example.


No, I have not. Is this run-time configurable, or do I need to build the
Linux kernel myself.


You'd need to rebuild the kernel.



sorry to reheat an old thread,


No, Thank you for following up on it.


but did anything come out of this? Do we need to add a quirk?


Dell said they tried to reproduce this, and couldn’t. Maybe it’s mouse 
dependent, there are different revisions, and the ID stays the same.


Therefore, I wouldn’t add any quirk, until somebody else hits this 
problem too.


What would be nice though, is to add a module parameter allowing to 
enable that quirk.



Kind regards,

Paul
--
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 v6 1/4] dt-bindings: phy: Add support for QUSB2 phy

[Vivek Gautam]

On 04/04/2017 11:58 PM, Stephen Boyd wrote:

On 03/20, Vivek Gautam wrote:

diff --git a/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt 
b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
new file mode 100644
index ..a6d19acde9e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
@@ -0,0 +1,45 @@
+Qualcomm QUSB2 phy controller
+=
+
+QUSB2 controller supports LS/FS/HS usb connectivity on Qualcomm chipsets.
+
+Required properties:
+ - compatible: compatible list, contains "qcom,msm8996-qusb2-phy".
+ - reg: offset and length of the PHY register set.
+ - #phy-cells: must be 0.
+
+ - clocks: a list of phandles and clock-specifier pairs,
+  one for each entry in clock-names.
+ - clock-names: must be "cfg_ahb" for phy config clock,
+   "ref" for 19.2 MHz ref clk,
+   "iface" for phy interface clock (Optional).
+
+ - vdd-phy-supply: Phandle to a regulator supply to PHY core block.
+ - vdda-pll-supply: Phandle to 1.8V regulator supply to PHY refclk pll block.
+ - vdda-phy-dpdm-supply: Phandle to 3.1V regulator supply to Dp/Dm port 
signals.
+
+ - resets: Phandle to reset to phy block.
+
+Optional properties:
+ - nvmem-cells: Phandle to nvmem cell that contains 'HS Tx trim'
+   tuning parameter value for qusb2 phy.
+
+ - qcom,tcsr-syscon: Phandle to TCSR syscon register region.
+
+Example:
+   hsusb_phy: phy@7411000 {
+   compatible = "qcom,msm8996-qusb2-phy";
+   reg = <0x7411000 0x180>;
+   #phy-cells = <0>;
+
+   clocks = < GCC_USB_PHY_CFG_AHB2PHY_CLK>,
+   < GCC_RX1_USB2_CLKREF_CLK>,
+   clock-names = "cfg_ahb", "ref";
+
+   vdd-phy-supply = <_s2>;

pm8994_s2 is a "corner" regulator. I'm not sure how we're going
to have it listed here as something like a regulator supply in
the binding. We probably should leave it out for now and let the
power domain + pm_qos stuff for corners work out. From what I see
in the downstream driver the code is setting the corner to '4'
when active, and '1' when inactive.


Sure, let's allow power domain and corner voltage work handle
this. I will drop this regulator entry from bindings, and the driver.


Best regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of 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

Re: [PATCH 24/24] usb: xhci: bInterval quirk for TI TUSB73x0

[Oliver Neukum]

Am Dienstag, den 04.04.2017, 15:55 +0300 schrieb Mathias Nyman:
> From: Roger Quadros 
> 
> This results in Bandwidth error when devices with periodic
> endpoints (ISO/INT) having bInterval > 7 are plugged and
> unplugged several times on a TUSB73x0 XHCI host.
> 
> Workaround this issue by limiting the bInterval to 7
> (i.e. interval to 6) for High-speed or faster periodic endpoints.
> 
> [1] - http://www.ti.com/lit/er/sllz076/sllz076.pdf
> 
> Signed-off-by: Roger Quadros 
> Signed-off-by: Mathias Nyman 

Hi,

this should go into the stable tree.
Could you add a CC?

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 v3 1/3] usb: udc: allow adding and removing the same gadget device

[Felipe Balbi]

Hi,

Alan Stern  writes:
>> >> allow usb_del_gadget_udc() and usb add_gadget_udc() to be called
>> >> repeatedly on the same gadget->dev structure.
>> >> 
>> >> We need to clear the gadget->dev structure so that kobject_init()
>> >> doesn't complain about already initialized object.
>> >> 
>> >> Signed-off-by: Roger Quadros 
>> >> ---
>> >>  drivers/usb/gadget/udc/core.c | 1 +
>> >>  1 file changed, 1 insertion(+)
>> >> 
>> >> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
>> >> index d685d82..efce68e 100644
>> >> --- a/drivers/usb/gadget/udc/core.c
>> >> +++ b/drivers/usb/gadget/udc/core.c
>> >> @@ -1273,6 +1273,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
>> >>   flush_work(>work);
>> >>   device_unregister(>dev);
>> >>   device_unregister(>dev);
>> >> + memset(>dev, 0x00, sizeof(gadget->dev));
>> >>  }
>> >>  EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
>> >
>> > Isn't this dangerous?  It's quite possible that the device_unregister() 
>> 
>> not on the gadget API, no.
>> 
>> > call on the previous line invokes the gadget->dev.release callback, 
>> > which might deallocate gadget.  If that happens, your new memset will 
>> > oops.
>> 
>> that won't happen. struct usb_gadget is a member of the UDC's private
>> structure, like this:
>> 
>> struct dwc3 {
>>  [...]
>>  struct usb_gadget   gadget;
>>  struct usb_gadget_driver *gadget_driver;
>>  [...]
>> };
>
> Yes.  So what?  Can't the UDC driver use the refcount inside struct 
> usb_gadget to control the lifetime of its private structure?

nope, not being used. At least not yet.

> (By the way, can you tell what's going on in net2280.c?  I must be
> missing something; it looks like gadget_release() would quickly run
> into problems because it calls dev_get_drvdata() for >dev, but
> net2280_probe() never calls dev_set_drvdata() for that device.  
> Furthermore, net2280_remove() continues to reference the net2280 struct
> after calling usb_del_gadget_udc(), and it never does seem to do a
> final put.)

static int net2280_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct net2280  *dev;
unsigned long   resource, len;
void__iomem *base = NULL;
int retval, i;

/* alloc, and start init */
dev = kzalloc(sizeof(*dev), GFP_KERNEL);
if (dev == NULL) {
retval = -ENOMEM;
goto done;
}

pci_set_drvdata(pdev, dev);
^^^

>> I'm actually thinking that struct usb_gadget shouldn't have a struct
>> device at all. Just a pointer to a device, that would solve all these
>> issues.
>
> A pointer to which device?  The UDC?  That would change the directory 
> layout in sysfs.

indeed. Would that be a problem?

> Or a pointer to a separate dynamically allocated device (the way struct 
> usb_hcd contains a pointer to the root hub device)?  That would work.  
> If the UDC driver wanted to re-register the gadget, it would have to 
> allocate a new device.

That could be done as well, if maintaining the directory structure is a
must.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH] usb: dwc3: gadget: skip Set/Clear Halt when invalid

[Felipe Balbi]

Hi,

John Youn  writes:
>> Felipe Balbi  writes:
>>> At least macOS seems to be sending
>>> ClearFeature(ENDPOINT_HALT) to endpoints which
>>> aren't Halted. This makes DWC3's CLEARSTALL command
>>> time out which causes several issues for the driver.
>>>
>>> Instead, let's just return 0 and bail out early.
>>>
>>> Cc: 
>>> Signed-off-by: Felipe Balbi 
>>> ---
>>>
>>> this falls into "has never worked before" category, so I'll be sending
>>> it together with other patches for v4.11 merge window. Still, it's a
>>> valid bug that's likely needed for stable trees.
>>>
>>>  drivers/usb/dwc3/gadget.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>> index 6faf484e5dfc..0a664d8eba3f 100644
>>> --- a/drivers/usb/dwc3/gadget.c
>>> +++ b/drivers/usb/dwc3/gadget.c
>>> @@ -1379,6 +1379,9 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, 
>>> int value, int protocol)
>>> unsigned transfer_in_flight;
>>> unsigned started;
>>>
>>> +   if (dep->flags & DWC3_EP_STALL)
>>> +   return 0;
>>> +
>>> if (dep->number > 1)
>>> trb = dwc3_ep_prev_trb(dep, dep->trb_enqueue);
>>> else
>>> @@ -1400,6 +1403,8 @@ int __dwc3_gadget_ep_set_halt(struct dwc3_ep *dep, 
>>> int value, int protocol)
>>> else
>>> dep->flags |= DWC3_EP_STALL;
>>> } else {
>>> +   if (!(dep->flags & DWC3_EP_STALL))
>>> +   return 0;
>>>
>>> ret = dwc3_send_clear_stall_ep_cmd(dep);
>>> if (ret)
>>
>> Reviving this old thread here. While $subject allowed dwc3 to work when
>> attached to macOS Host, I fear that we might have more issues than not
>> in the future. The reason is that USB20 spec allows hosts to use
>> ClearFeature(ENDPOINT_HALT) as a "Reset Data Toggle/SeqN" hint.
>>
>> With this, we're basically blocking that possibility. Still, without
>> $subject, ClearStall commands were timing out. I'll try to do a local
>> revert here and check what happens in this case, but would you have any
>> idea why ClearStall would time out like that?
>>
>
> Hi Felipe,
>
> I think Thinh Nguyen e-mailed you about this before saying it caused a
> regression for us. But he has not had time to look into it further and
> follow-up yet.
>
> No idea about the timing out on Mac though. We can try to reproduce
> this when we have some time and take a look. Do you have a USB trace?

not anymore, but as soon I have some free time, I can revert the patch
locally and try to reproduce. I'll also implement a little libusb-based
test to issue that request hundreds of times in a row and see if I can
force the problem to happen ;-)

Thanks for responding so quickly :-)

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

Re: Periodic reconnects of USB mouse on Dell PowerEdge R730

[Oliver Neukum]

Am Donnerstag, den 09.02.2017, 17:30 +0100 schrieb Paul Menzel:
> Dear Johan,
> 
> 
> On 02/08/17 17:54, Johan Hovold wrote:
> > 
> > On Wed, Feb 08, 2017 at 05:41:33PM +0100, Paul Menzel wrote:
> > > 
> > > On 02/08/17 16:50, Johan Hovold wrote:
> > > > 
> > > > On Wed, Feb 08, 2017 at 04:15:02PM +0100, Paul Menzel wrote:
> > > > > 
> > > > > On 02/08/17 14:02, Greg KH wrote:
> > > > > > 
> > > > > > On Wed, Feb 08, 2017 at 12:16:44PM +0100, Paul Menzel wrote:
> > > > > > > 
> > > > > > > On the server Dell PowerEdge R730 with firmware 2.3.4, and Linux 
> > > > > > > 4.9.2, the
> > > > > > > connected USB mouse disconnects and connects again periodically. 
> > > > > > > This can be
> > > > > > > reproduced with two different (Logitech) mice.
> > > > > > > 
> > > > > > > ```
> > > > > > > $ more /proc/version
> > > > > > > Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc 
> > > > > > > version
> > > > > > > 6.3.0 20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 
> > > > > > > (2017-01-12)
> > > > > > > $ journalctl -o short-precise -k -f
> > > > > > > […]
> > > > > > > Feb 08 12:00:16.193817 poweredger730 kernel: usb 3-2: USB 
> > > > > > > disconnect, device
> > > > > > > number 84
> > > > > > 
> > > > > > Looks like a hardware issue, the kernel can not cause a device to
> > > > > > disconnect itself.
> > > > > > 
> > > > > > Especially as this happens with two different mice, you might want 
> > > > > > to
> > > > > > see if there's something wrong with that port.
> > > > > 
> > > > > With three devices of the Logitech model 046d:c077 (Logitech, Inc. 
> > > > > M105
> > > > > Optical Mouse) the problem could be reproduced on each USB port.
> > > > 
> > > > Have you tried enabling the always-poll HID-quirk, which is needed for
> > > > certain devices to prevent issues like this?
> > > > 
> > > > See commit bfe3c873e978 ("HID: usbhid: enable always-poll quirk for Elan
> > > > Touchscreen") for an example.
> > > 
> > > No, I have not. Is this run-time configurable, or do I need to build the
> > > Linux kernel myself.
> > 
> > You'd need to rebuild the kernel.

Hi,

sorry to reheat an old thread, but did anything come out of this?
Do we need to add a quirk?

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 v7 2/3] usb: musb: Add support of CPPI 4.1 DMA controller to DA8xx

[Alexandre Bailon]

On 04/03/2017 04:59 PM, Bin Liu wrote:

On Wed, Mar 29, 2017 at 06:24:31PM +0200, Alexandre Bailon wrote:

Currently, only the PIO mode is supported.
This add support of CPPI 4.1 to DA8xx.
As the In DA8xx the CPPI 4.1 DMA is a part of the USB.
Create the CPPI 4.1 device as a child of USB.

Signed-off-by: Alexandre Bailon 
---
  drivers/usb/musb/Kconfig |  4 ++--
  drivers/usb/musb/da8xx.c | 43 ++-
  2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index 72a2a50..5506a9c 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -160,8 +160,8 @@ config USB_TI_CPPI_DMA
  Enable DMA transfers when TI CPPI DMA is available.
  
  config USB_TI_CPPI41_DMA

-   bool 'TI CPPI 4.1 (AM335x)'
-   depends on ARCH_OMAP && DMADEVICES
+   bool 'TI CPPI 4.1'
+   depends on (ARCH_OMAP || ARCH_DAVINCI_DA8XX) && DMADEVICES
select TI_CPPI41

TI_CPPI41 also should depend on ARCH_DAVINCI_DA8XX due to this patch.  You
might need the following change for dma Kconfig as well.
This change has been done in the series "dmaengine: cppi41: Add dma 
support to da8xx".


diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d01d59812cf3..15e31bfae9f9 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -514,8 +514,8 @@ config TIMB_DMA
   Enable support for the Timberdale FPGA DMA engine.
  
  config TI_CPPI41

-   tristate "AM33xx CPPI41 DMA support"
-   depends on ARCH_OMAP
+   tristate "CPPI41 DMA support"
+   depends on ARCH_OMAP || ARCH_DAVINCI_DA8XX
 select DMA_ENGINE
 help
   The Communications Port Programming Interface (CPPI) 4.1 DMA engine

Regards,
-Bin.

Regards,
Alexandre
--
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: [1/2] wireless: ath9k_htc: fix NULL-deref at probe

[Kalle Valo]

Johan Hovold  wrote:
> Make sure to check the number of endpoints to avoid dereferencing a
> NULL-pointer or accessing memory beyond the endpoint array should a
> malicious device lack the expected endpoints.
> 
> Fixes: 36bcce430657 ("ath9k_htc: Handle storage devices")
> Cc: Sujith Manoharan 
> Signed-off-by: Johan Hovold 

Patch applied to ath-next branch of ath.git, thanks.

ebeb36670eca ath9k_htc: fix NULL-deref at probe

-- 
https://patchwork.kernel.org/patch/9620723/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

--
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: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Peter Ujfalusi]

On 2017-04-05 10:13, Peter Ujfalusi wrote:

I had similar hunch first, but did not worked. I have tested this patch
and did not helped.

To be precise this is what I have tried:
- boot w/o cable connected
- boot w/ board connected to PC (device mode)
- boot w/ OTG-A cable with USB keyboard
- boot w/ OTG-A cable connected to powered USB hub and the same keyboard

w/ and w/o this patch I have the same flood of prints in all cases.


the config I have for linux-next:
https://pastebin.com/KixvyiRR



Fwiw I have checked where the is_active is set - which causes the prints:
musb_core.c:musb_start()

if (musb->port_mode != MUSB_PORT_MODE_HOST &&
musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
(devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
musb->is_active = 1;
} else {
devctl |= MUSB_DEVCTL_SESSION;
}

this was the only place where the is_active was set to 1.



Regards,

Tony

8< ---
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb
*musb, int is_on)
 }

 otg_set_vbus(otg, 1);
-} else {
-musb->is_active = 1;
-otg->default_a = 1;
-musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
-devctl |= MUSB_DEVCTL_SESSION;
-MUSB_HST_MODE(musb);
 }
 } else {
 musb->is_active = 0;


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


- Péter
--
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: musb: regression since 4.9 on omap4-panda-es (caused by d8e5f0eca1e8)

[Peter Ujfalusi]

Tony,

On 2017-04-05 03:36, Tony Lindgren wrote:

* Tony Lindgren  [170404 07:06]:

* Bin Liu  [170404 05:30]:

On Tue, Apr 04, 2017 at 10:09:50AM +0300, Peter Ujfalusi wrote:

Tony,

since 4.9 (4.8 was fine) I can not boot omap4-panda-es if the musb
is compiled in. The kernel will stuck printing:

** 206 printk messages dropped ** [8.926727] musb_bus_suspend
2584: trying to suspend as a_idle while active


OK so compiled in. Do you have something connected also when
booting?


Does it sound a similar issue to
http://marc.info/?l=linux-usb=149036531809506=2


Yup.


The bisect (log is [1]) points to:
d8e5f0eca1e8 usb: musb: Fix hardirq-safe hardirq-unsafe lock order error

and reverting the d8e5f0eca1e8 makes the board to boot up fine
(Linux 4.11-rc5 and next-20170331).


OK thanks for bisecting it.


any idea on how to fix this w/o reverting the commit?


I'll take a look.


OK I was able to reproduce this with loadable modules by reloading
the modules while having OTG-A cable inserted with a hub and USB
drive connected.

Peter, care to check if the following fixes the problem for you?
There should no longer be much any musb core tinkering happening
in the glue layers..


I had similar hunch first, but did not worked. I have tested this patch 
and did not helped.


To be precise this is what I have tried:
- boot w/o cable connected
- boot w/ board connected to PC (device mode)
- boot w/ OTG-A cable with USB keyboard
- boot w/ OTG-A cable connected to powered USB hub and the same keyboard

w/ and w/o this patch I have the same flood of prints in all cases.

Fwiw I have checked where the is_active is set - which causes the prints:
musb_core.c:musb_start()

if (musb->port_mode != MUSB_PORT_MODE_HOST &&
musb->xceiv->otg->state != OTG_STATE_A_WAIT_BCON &&
(devctl & MUSB_DEVCTL_VBUS) == MUSB_DEVCTL_VBUS) {
musb->is_active = 1;
} else {
devctl |= MUSB_DEVCTL_SESSION;
}

this was the only place where the is_active was set to 1.



Regards,

Tony

8< ---
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -91,12 +91,6 @@ static void omap2430_musb_set_vbus(struct musb *musb, int 
is_on)
}

otg_set_vbus(otg, 1);
-   } else {
-   musb->is_active = 1;
-   otg->default_a = 1;
-   musb->xceiv->otg->state = OTG_STATE_A_WAIT_VRISE;
-   devctl |= MUSB_DEVCTL_SESSION;
-   MUSB_HST_MODE(musb);
}
} else {
musb->is_active = 0;


- Péter
--
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] reset: Add APIs to manage array of resets

[Vivek Gautam]

Hi Philipp,


On 04/04/2017 06:17 PM, Philipp Zabel wrote:

Hi Vivek,

On Tue, 2017-04-04 at 16:09 +0530, Vivek Gautam wrote:
[...]

I'd prefer to mirror the gpiod API a little, and to have the number
contained in the array structure, similar to struct gpio_descs:

[...]

Alright, i can update this.
I took regulator_bulk interface as the reference, but now i see
gpio_descs has a smaller footprint.

Ok, understood.
I think the smaller footprint API is more convenient for the user.

[...]

+ * Returns 0 on success or error number on failure
+ */
+static int reset_control_array_get(struct device *dev, int num_rsts,
+   struct reset_control_array *resets,
+   bool shared, bool optional)

Can we make this count and return a pointer to the newly created array?

static struct reset_controls *
reset_control_array_get(struct device *dev, bool shared, bool optional)
{
...

That way the consumer doesn't have to care about counting and array
allocation.

Just trying to think again in line with the regulator bulk APIs.
Can't a user provide a list of reset controls as data and thus
request reset controls with a "id" and num_resets available.

e.g.
 const char * const rst_names[] = {
   "rst1", "rst2" ...
 };
 xyz_data = {
   .resets = rst_names;
   .num = ARRAY_SIZE(rst_names);
 };
and then the driver making use of reset_control_array APIs
to request this list of reset controls and assert/deassert them.

I am assuming this case when one user driver is used across a bunch
of platforms with different number of resets available.
We may not want to rely solely on the device tree entries, since
the resets can be mandatory in few cases and we may want to
return failure.

The way I understood the array API was as a method of handling a list of
anonymous resets, specified as

resets = < 1>, < 2>, < 3>;
// reset-names = "rst1", "rst2", "rst3"; /* don't care */

in the device tree.

Now if you want to handle a partial list of those as an unordered list,
with special consideration for others, that could be added as a separate
API when there is use for it. But I expect that most potential users of
this array API will not have to make such a distinction.


Alright, I will modify the array APIs as suggested to handle an
unordered list of resets passed from the device tree.
As you said, we can handle the special cases when the need arise.




@@ -85,6 +107,39 @@ static inline struct reset_control 
*__devm_reset_control_get(
return -ENOTSUPP;
   }
   
+static inline int reset_control_array_assert(int num_rsts,

+   struct reset_control_array *resets)
+{
+   return 0;
+}
+
+static inline int reset_control_array_deassert(int num_rsts,
+   struct reset_control_array *resets)
+{
+   return 0;
+}

Is this missing a stub for reset_control_array_get?

No, that's supposed to be a static function.

Oh right, it is static. Please ignore.


Thanks


regards
Philipp



Best Regards
Vivek

--
The Qualcomm Innovation Center, Inc. is a member of 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