[PATCH v2 0/4] Add i.MX8MP-EVK USB Gadget Support

[PATCH v2 0/4] Add i.MX8MP-EVK USB Gadget Support

[Marco Felsch]

Hi all,

this adds the usb gadget support to the i.MX8MP-EVK. This Series is
based on [1] and therefore it is already a v2. Thanks to Li and Andreas
for the very useful feedback.

Patch1-3: Add the mssing support for USB-SS GPIO muxes. This is required
          to have proper USB-SS support on the EVK.

Patch4: Adds the devicetree integration.

[1] https://lore.kernel.org/all/20230323105826.2058003-1-m.felsch@pengutronix.de/

Regards,
  Marco

---
Marco Felsch (4):
      dt-bindings: usb: gpio-sbu-mux: add support for ss-data lanes mux
      usb: typec: mux: gpio-sbu-mux: add support for ss data lane muxing
      usb: typec: tcpci: clear the fault status bit
      arm64: dts: imx8mp-evk: add dual-role usb port1 support

 .../devicetree/bindings/usb/gpio-sbu-mux.yaml      | 82 +++++++++++++++++---
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts       | 88 ++++++++++++++++++++++
 drivers/usb/typec/mux/Kconfig                      |  5 +-
 drivers/usb/typec/mux/gpio-sbu-mux.c               | 18 ++++-
 drivers/usb/typec/tcpm/tcpci.c                     |  5 ++
 include/linux/usb/tcpci.h                          |  1 +
 6 files changed, 185 insertions(+), 14 deletions(-)
---
base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
change-id: 20230504-b4-v6-3-topic-boards-imx8mp-evk-dual-role-usb-8dcf6274d9df

Best regards,
-- 
Marco Felsch <m.felsch@pengutronix.de>

[PATCH v2 1/4] dt-bindings: usb: gpio-sbu-mux: add support for ss-data lanes mux

[Marco Felsch]

This adds the support for GPIO based USB-C SS data lane muxing.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 .../devicetree/bindings/usb/gpio-sbu-mux.yaml      | 82 +++++++++++++++++++---
 1 file changed, 71 insertions(+), 11 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
index bf4b1d016e1f..796f3283ac02 100644
--- a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
+++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
@@ -4,24 +4,26 @@
 $id: "http://devicetree.org/schemas/usb/gpio-sbu-mux.yaml#"
 $schema: "http://devicetree.org/meta-schemas/core.yaml#"
 
-title: GPIO-based SBU mux
+title: GPIO-based SS/SBU mux
 
 maintainers:
   - Bjorn Andersson <andersson@kernel.org>
 
 description:
-  In USB Type-C applications the SBU lines needs to be connected, disconnected
-  and swapped depending on the altmode and orientation. This binding describes
-  a family of hardware solutions which switches between these modes using GPIO
-  signals.
+  In USB Type-C applications the SS/SBU lines needs to be connected,
+  disconnected and swapped depending on the altmode and orientation. This
+  binding describes a family of hardware solutions which switches between these
+  modes using GPIO signals.
 
 properties:
   compatible:
-    items:
-      - enum:
-          - onnn,fsusb43l10x
-          - pericom,pi3usb102
-      - const: gpio-sbu-mux
+    oneOf:
+      - items:
+          - enum:
+              - onnn,fsusb43l10x
+              - pericom,pi3usb102
+          - const: gpio-sbu-mux
+      - const: gpio-ss-mux
 
   enable-gpios:
     description: Switch enable GPIO
@@ -50,10 +52,18 @@ required:
   - compatible
   - enable-gpios
   - select-gpios
-  - mode-switch
   - orientation-switch
   - port
 
+if:
+  properties:
+    compatible:
+      contains:
+        const: gpio-sbu-mux
+then:
+  required:
+    - mode-switch
+
 additionalProperties: false
 
 examples:
@@ -107,4 +117,54 @@ examples:
             };
         };
     };
+
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+
+    tcpm {
+        connector {
+            compatible = "usb-c-connector";
+
+            ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                    reg = <0>;
+                    tcpm_hs_out: endpoint {
+                        remote-endpoint = <&usb_hs_phy_in>;
+                    };
+                };
+
+                port@1 {
+                    reg = <1>;
+                    tcpm_ss_out: endpoint {
+                        remote-endpoint = <&usb_ss_phy_in>;
+                    };
+                };
+
+                port@2 {
+                    reg = <2>;
+                    tcpm_ss_mux_out: endpoint {
+                        remote-endpoint = <&ss_mux_in>;
+                    };
+                };
+            };
+        };
+    };
+
+    usb-ss-mux {
+        compatible = "gpio-ss-mux";
+
+        enable-gpios = <&tlmm 101 GPIO_ACTIVE_LOW>;
+        select-gpios = <&tlmm 164 GPIO_ACTIVE_HIGH>;
+
+        orientation-switch;
+
+        port {
+            ss_mux_in: endpoint {
+                remote-endpoint = <&tcpm_ss_mux_out>;
+            };
+        };
+    };
 ...

-- 
2.39.2

Re: [PATCH v2 1/4] dt-bindings: usb: gpio-sbu-mux: add support for ss-data lanes mux

[Rob Herring]

On Thu, 04 May 2023 15:46:50 +0200, Marco Felsch wrote:
> This adds the support for GPIO based USB-C SS data lane muxing.
> 
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
>  .../devicetree/bindings/usb/gpio-sbu-mux.yaml      | 82 +++++++++++++++++++---
>  1 file changed, 71 insertions(+), 11 deletions(-)
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/usb/gpio-sbu-mux.example.dts:96.47-98.27: ERROR (duplicate_label): /example-1/tcpm/connector/ports/port@0/endpoint: Duplicate label 'tcpm_hs_out' on /example-1/tcpm/connector/ports/port@0/endpoint and /example-0/tcpm/connector/ports/port@0/endpoint
Documentation/devicetree/bindings/usb/gpio-sbu-mux.example.dts:103.47-105.27: ERROR (duplicate_label): /example-1/tcpm/connector/ports/port@1/endpoint: Duplicate label 'tcpm_ss_out' on /example-1/tcpm/connector/ports/port@1/endpoint and /example-0/tcpm/connector/ports/port@1/endpoint
ERROR: Input tree has errors, aborting (use -f to force output)
make[1]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/usb/gpio-sbu-mux.example.dtb] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:1512: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20230504-b4-v6-3-topic-boards-imx8mp-evk-dual-role-usb-v2-1-3889b1b2050c@pengutronix.de

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH v2 1/4] dt-bindings: usb: gpio-sbu-mux: add support for ss-data lanes mux

[Marco Felsch]

On 23-05-04, Rob Herring wrote:
> 
> On Thu, 04 May 2023 15:46:50 +0200, Marco Felsch wrote:
> > This adds the support for GPIO based USB-C SS data lane muxing.
> > 
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > ---
> >  .../devicetree/bindings/usb/gpio-sbu-mux.yaml      | 82 +++++++++++++++++++---
> >  1 file changed, 71 insertions(+), 11 deletions(-)
> > 
> 
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Documentation/devicetree/bindings/usb/gpio-sbu-mux.example.dts:96.47-98.27: ERROR (duplicate_label): /example-1/tcpm/connector/ports/port@0/endpoint: Duplicate label 'tcpm_hs_out' on /example-1/tcpm/connector/ports/port@0/endpoint and /example-0/tcpm/connector/ports/port@0/endpoint
> Documentation/devicetree/bindings/usb/gpio-sbu-mux.example.dts:103.47-105.27: ERROR (duplicate_label): /example-1/tcpm/connector/ports/port@1/endpoint: Duplicate label 'tcpm_ss_out' on /example-1/tcpm/connector/ports/port@1/endpoint and /example-0/tcpm/connector/ports/port@1/endpoint
> ERROR: Input tree has errors, aborting (use -f to force output)
> make[1]: *** [scripts/Makefile.lib:419: Documentation/devicetree/bindings/usb/gpio-sbu-mux.example.dtb] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [Makefile:1512: dt_binding_check] Error 2

While adding the example I thought about the need for it. Is it okay for
you if I drop the example since most of it is just copy'n'paste.

Regards,
  Marco

Re: [PATCH v2 1/4] dt-bindings: usb: gpio-sbu-mux: add support for ss-data lanes mux

[Rob Herring]

On Thu, May 04, 2023 at 03:46:50PM +0200, Marco Felsch wrote:
> This adds the support for GPIO based USB-C SS data lane muxing.
> 
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
>  .../devicetree/bindings/usb/gpio-sbu-mux.yaml      | 82 +++++++++++++++++++---
>  1 file changed, 71 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> index bf4b1d016e1f..796f3283ac02 100644
> --- a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> +++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
> @@ -4,24 +4,26 @@
>  $id: "http://devicetree.org/schemas/usb/gpio-sbu-mux.yaml#"
>  $schema: "http://devicetree.org/meta-schemas/core.yaml#"
>  
> -title: GPIO-based SBU mux
> +title: GPIO-based SS/SBU mux
>  
>  maintainers:
>    - Bjorn Andersson <andersson@kernel.org>
>  
>  description:
> -  In USB Type-C applications the SBU lines needs to be connected, disconnected
> -  and swapped depending on the altmode and orientation. This binding describes
> -  a family of hardware solutions which switches between these modes using GPIO
> -  signals.
> +  In USB Type-C applications the SS/SBU lines needs to be connected,
> +  disconnected and swapped depending on the altmode and orientation. This
> +  binding describes a family of hardware solutions which switches between these
> +  modes using GPIO signals.

Consider whether the mux-control binding would work for this purpose. 
Then what controls the muxing can be anything.

>  
>  properties:
>    compatible:
> -    items:
> -      - enum:
> -          - onnn,fsusb43l10x
> -          - pericom,pi3usb102
> -      - const: gpio-sbu-mux
> +    oneOf:
> +      - items:
> +          - enum:
> +              - onnn,fsusb43l10x
> +              - pericom,pi3usb102
> +          - const: gpio-sbu-mux
> +      - const: gpio-ss-mux
>  
>    enable-gpios:
>      description: Switch enable GPIO
> @@ -50,10 +52,18 @@ required:
>    - compatible
>    - enable-gpios
>    - select-gpios
> -  - mode-switch
>    - orientation-switch
>    - port
>  
> +if:
> +  properties:
> +    compatible:
> +      contains:
> +        const: gpio-sbu-mux
> +then:
> +  required:
> +    - mode-switch
> +
>  additionalProperties: false
>  
>  examples:
> @@ -107,4 +117,54 @@ examples:
>              };
>          };
>      };
> +
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +
> +    tcpm {
> +        connector {
> +            compatible = "usb-c-connector";
> +
> +            ports {
> +                #address-cells = <1>;
> +                #size-cells = <0>;
> +
> +                port@0 {
> +                    reg = <0>;
> +                    tcpm_hs_out: endpoint {
> +                        remote-endpoint = <&usb_hs_phy_in>;
> +                    };
> +                };
> +
> +                port@1 {
> +                    reg = <1>;
> +                    tcpm_ss_out: endpoint {
> +                        remote-endpoint = <&usb_ss_phy_in>;
> +                    };
> +                };
> +
> +                port@2 {
> +                    reg = <2>;
> +                    tcpm_ss_mux_out: endpoint {
> +                        remote-endpoint = <&ss_mux_in>;
> +                    };
> +                };

port@2 already has a defined use for SBU signals. You can't use it. 
port@1 corresponds to the SS signals.

> +            };
> +        };
> +    };
> +
> +    usb-ss-mux {
> +        compatible = "gpio-ss-mux";
> +
> +        enable-gpios = <&tlmm 101 GPIO_ACTIVE_LOW>;
> +        select-gpios = <&tlmm 164 GPIO_ACTIVE_HIGH>;
> +
> +        orientation-switch;
> +
> +        port {

This is a mux device. It needs an output port and N input ports.

Please present a complete picture of your USB-C related h/w. It's hard 
to review with just 'I have a GPIO controlling the SS muxing'.

Rob

[PATCH v2 2/4] usb: typec: mux: gpio-sbu-mux: add support for ss data lane muxing

[Marco Felsch]

The commit adds the support to handle gpio based usb-c ss data lanes
muxes as well. The only difference is the data lanes enable handling.
The data lanes don't depend on the alt-mode settings instead they depend
on the usb-c cable orientation (connected, not connected).

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 drivers/usb/typec/mux/Kconfig        |  5 +++--
 drivers/usb/typec/mux/gpio-sbu-mux.c | 18 +++++++++++++++++-
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/typec/mux/Kconfig b/drivers/usb/typec/mux/Kconfig
index c46fa4f9d3df..68438e7722d0 100644
--- a/drivers/usb/typec/mux/Kconfig
+++ b/drivers/usb/typec/mux/Kconfig
@@ -13,10 +13,11 @@ config TYPEC_MUX_FSA4480
 	  If compiled as a module, the module will be named fsa4480.
 
 config TYPEC_MUX_GPIO_SBU
-	tristate "Generic GPIO based SBU mux for USB Type-C applications"
+	tristate "Generic GPIO based SS/SBU mux for USB Type-C applications"
 	help
 	  Say Y or M if your system uses a GPIO based mux for managing the
-	  connected state and the swapping of the SBU lines in a Type-C port.
+	  connected state and the swapping of the SS or SBU lines in a Type-C
+	  port.
 
 config TYPEC_MUX_PI3USB30532
 	tristate "Pericom PI3USB30532 Type-C cross switch driver"
diff --git a/drivers/usb/typec/mux/gpio-sbu-mux.c b/drivers/usb/typec/mux/gpio-sbu-mux.c
index f62516dafe8f..a1a560a085b8 100644
--- a/drivers/usb/typec/mux/gpio-sbu-mux.c
+++ b/drivers/usb/typec/mux/gpio-sbu-mux.c
@@ -14,12 +14,18 @@
 #include <linux/usb/typec_dp.h>
 #include <linux/usb/typec_mux.h>
 
+enum gpio_sbu_mux_type {
+	MUX_TYPE_SBU,
+	MUX_TYPE_SS,
+};
+
 struct gpio_sbu_mux {
 	struct gpio_desc *enable_gpio;
 	struct gpio_desc *select_gpio;
 
 	struct typec_switch_dev *sw;
 	struct typec_mux_dev *mux;
+	enum gpio_sbu_mux_type type;
 
 	struct mutex lock; /* protect enabled and swapped */
 	bool enabled;
@@ -38,6 +44,13 @@ static int gpio_sbu_switch_set(struct typec_switch_dev *sw,
 	enabled = sbu_mux->enabled;
 	swapped = sbu_mux->swapped;
 
+	/*
+	 * In case of muxing the SS data lanes the enable status depends only on
+	 * the orientation and not on the TYPEC_DP_STATE_*
+	 */
+	if (sbu_mux->type == MUX_TYPE_SS)
+		enabled = true;
+
 	switch (orientation) {
 	case TYPEC_ORIENTATION_NONE:
 		enabled = false;
@@ -103,6 +116,8 @@ static int gpio_sbu_mux_probe(struct platform_device *pdev)
 	if (!sbu_mux)
 		return -ENOMEM;
 
+	sbu_mux->type = (enum gpio_sbu_mux_type)device_get_match_data(&pdev->dev);
+
 	mutex_init(&sbu_mux->lock);
 
 	sbu_mux->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
@@ -153,7 +168,8 @@ static int gpio_sbu_mux_remove(struct platform_device *pdev)
 }
 
 static const struct of_device_id gpio_sbu_mux_match[] = {
-	{ .compatible = "gpio-sbu-mux", },
+	{ .compatible = "gpio-sbu-mux", .data = (void *)MUX_TYPE_SBU },
+	{ .compatible = "gpio-ss-mux", .data = (void *)MUX_TYPE_SS },
 	{}
 };
 MODULE_DEVICE_TABLE(of, gpio_sbu_mux_match);

-- 
2.39.2

Re: [PATCH v2 2/4] usb: typec: mux: gpio-sbu-mux: add support for ss data lane muxing

[kernel test robot]

Hi Marco,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 457391b0380335d5e9a5babdec90ac53928b23b4]

url:    https://github.com/intel-lab-lkp/linux/commits/Marco-Felsch/dt-bindings-usb-gpio-sbu-mux-add-support-for-ss-data-lanes-mux/20230504-214927
base:   457391b0380335d5e9a5babdec90ac53928b23b4
patch link:    https://lore.kernel.org/r/20230504-b4-v6-3-topic-boards-imx8mp-evk-dual-role-usb-v2-2-3889b1b2050c%40pengutronix.de
patch subject: [PATCH v2 2/4] usb: typec: mux: gpio-sbu-mux: add support for ss data lane muxing
config: riscv-randconfig-r042-20230501 (https://download.01.org/0day-ci/archive/20230504/202305042306.TmTuYCAJ-lkp@intel.com/config)
compiler: clang version 17.0.0 (https://github.com/llvm/llvm-project b1465cd49efcbc114a75220b153f5a055ce7911f)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install riscv cross compiling tool for clang build
        # apt-get install binutils-riscv64-linux-gnu
        # https://github.com/intel-lab-lkp/linux/commit/8cbffd4f358b26347855cb2dcae31dd8c012226f
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Marco-Felsch/dt-bindings-usb-gpio-sbu-mux-add-support-for-ss-data-lanes-mux/20230504-214927
        git checkout 8cbffd4f358b26347855cb2dcae31dd8c012226f
        # save the config file
        mkdir build_dir && cp config build_dir/.config
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=riscv olddefconfig
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=riscv SHELL=/bin/bash drivers/usb/typec/mux/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202305042306.TmTuYCAJ-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/usb/typec/mux/gpio-sbu-mux.c:119:18: warning: cast to smaller integer type 'enum gpio_sbu_mux_type' from 'const void *' [-Wvoid-pointer-to-enum-cast]
           sbu_mux->type = (enum gpio_sbu_mux_type)device_get_match_data(&pdev->dev);
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   1 warning generated.


vim +119 drivers/usb/typec/mux/gpio-sbu-mux.c

   107	
   108	static int gpio_sbu_mux_probe(struct platform_device *pdev)
   109	{
   110		struct typec_switch_desc sw_desc = { };
   111		struct typec_mux_desc mux_desc = { };
   112		struct device *dev = &pdev->dev;
   113		struct gpio_sbu_mux *sbu_mux;
   114	
   115		sbu_mux = devm_kzalloc(dev, sizeof(*sbu_mux), GFP_KERNEL);
   116		if (!sbu_mux)
   117			return -ENOMEM;
   118	
 > 119		sbu_mux->type = (enum gpio_sbu_mux_type)device_get_match_data(&pdev->dev);
   120	
   121		mutex_init(&sbu_mux->lock);
   122	
   123		sbu_mux->enable_gpio = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
   124		if (IS_ERR(sbu_mux->enable_gpio))
   125			return dev_err_probe(dev, PTR_ERR(sbu_mux->enable_gpio),
   126					     "unable to acquire enable gpio\n");
   127	
   128		sbu_mux->select_gpio = devm_gpiod_get(dev, "select", GPIOD_OUT_LOW);
   129		if (IS_ERR(sbu_mux->select_gpio))
   130			return dev_err_probe(dev, PTR_ERR(sbu_mux->select_gpio),
   131					     "unable to acquire select gpio\n");
   132	
   133		sw_desc.drvdata = sbu_mux;
   134		sw_desc.fwnode = dev_fwnode(dev);
   135		sw_desc.set = gpio_sbu_switch_set;
   136	
   137		sbu_mux->sw = typec_switch_register(dev, &sw_desc);
   138		if (IS_ERR(sbu_mux->sw))
   139			return dev_err_probe(dev, PTR_ERR(sbu_mux->sw),
   140					     "failed to register typec switch\n");
   141	
   142		mux_desc.drvdata = sbu_mux;
   143		mux_desc.fwnode = dev_fwnode(dev);
   144		mux_desc.set = gpio_sbu_mux_set;
   145	
   146		sbu_mux->mux = typec_mux_register(dev, &mux_desc);
   147		if (IS_ERR(sbu_mux->mux)) {
   148			typec_switch_unregister(sbu_mux->sw);
   149			return dev_err_probe(dev, PTR_ERR(sbu_mux->mux),
   150					     "failed to register typec mux\n");
   151		}
   152	
   153		platform_set_drvdata(pdev, sbu_mux);
   154	
   155		return 0;
   156	}
   157	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests

[PATCH v2 3/4] usb: typec: tcpci: clear the fault status bit

[Marco Felsch]

According the "USB Type-C Port Controller Interface Specification v2.0"
the TCPC sets the fault status register bit-7
(AllRegistersResetToDefault) once the registers have been reseted to
their default values.

This triggers an alert(-irq) on PTN5110 devices albeit we do mask the
fault-irq. Fix this gernally by writing a one to the correspondig
bit-7.

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 drivers/usb/typec/tcpm/tcpci.c | 5 +++++
 include/linux/usb/tcpci.h      | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
index 8da23240afbe..15632d023e4c 100644
--- a/drivers/usb/typec/tcpm/tcpci.c
+++ b/drivers/usb/typec/tcpm/tcpci.c
@@ -602,6 +602,11 @@ static int tcpci_init(struct tcpc_dev *tcpc)
 	if (time_after(jiffies, timeout))
 		return -ETIMEDOUT;
 
+	regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &reg);
+	if (reg & TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT)
+		tcpci_write16(tcpci, TCPC_FAULT_STATUS,
+			      TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT);
+
 	/* Handle vendor init */
 	if (tcpci->data->init) {
 		ret = tcpci->data->init(tcpci, tcpci->data);
diff --git a/include/linux/usb/tcpci.h b/include/linux/usb/tcpci.h
index 85e95a3251d3..83376473ac76 100644
--- a/include/linux/usb/tcpci.h
+++ b/include/linux/usb/tcpci.h
@@ -103,6 +103,7 @@
 #define TCPC_POWER_STATUS_SINKING_VBUS	BIT(0)
 
 #define TCPC_FAULT_STATUS		0x1f
+#define TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT BIT(7)
 
 #define TCPC_ALERT_EXTENDED		0x21
 

-- 
2.39.2

Re: [PATCH v2 3/4] usb: typec: tcpci: clear the fault status bit

[Guenter Roeck]

On 5/4/23 06:46, Marco Felsch wrote:
> According the "USB Type-C Port Controller Interface Specification v2.0"
> the TCPC sets the fault status register bit-7
> (AllRegistersResetToDefault) once the registers have been reseted to

cleared ? set ?

> their default values.
> 
> This triggers an alert(-irq) on PTN5110 devices albeit we do mask the
> fault-irq. Fix this gernally by writing a one to the correspondig

generically ?

corresponding

> bit-7.
> 
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> ---
>   drivers/usb/typec/tcpm/tcpci.c | 5 +++++
>   include/linux/usb/tcpci.h      | 1 +
>   2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
> index 8da23240afbe..15632d023e4c 100644
> --- a/drivers/usb/typec/tcpm/tcpci.c
> +++ b/drivers/usb/typec/tcpm/tcpci.c
> @@ -602,6 +602,11 @@ static int tcpci_init(struct tcpc_dev *tcpc)
>   	if (time_after(jiffies, timeout))
>   		return -ETIMEDOUT;
>   
> +	regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &reg);

Needs error check.

Also, I am not sure if this is the correct place for this code. The alert
status is cleared after vendor initialization. Should the same be done
here ? Also, why not just write the bit unconditionally, similar
to TCPC_ALERT ?

Thanks,
Guenter

> +	if (reg & TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT)
> +		tcpci_write16(tcpci, TCPC_FAULT_STATUS,
> +			      TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT);
> +
>   	/* Handle vendor init */
>   	if (tcpci->data->init) {
>   		ret = tcpci->data->init(tcpci, tcpci->data);
> diff --git a/include/linux/usb/tcpci.h b/include/linux/usb/tcpci.h
> index 85e95a3251d3..83376473ac76 100644
> --- a/include/linux/usb/tcpci.h
> +++ b/include/linux/usb/tcpci.h
> @@ -103,6 +103,7 @@
>   #define TCPC_POWER_STATUS_SINKING_VBUS	BIT(0)
>   
>   #define TCPC_FAULT_STATUS		0x1f
> +#define TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT BIT(7)
>   
>   #define TCPC_ALERT_EXTENDED		0x21
>   
> 

Re: [PATCH v2 3/4] usb: typec: tcpci: clear the fault status bit

[Marco Felsch]

On 23-05-04, Guenter Roeck wrote:
> On 5/4/23 06:46, Marco Felsch wrote:
> > According the "USB Type-C Port Controller Interface Specification v2.0"
> > the TCPC sets the fault status register bit-7
> > (AllRegistersResetToDefault) once the registers have been reseted to
> 
> cleared ? set ?

Sry. I don't get this.

> > their default values.
> > 
> > This triggers an alert(-irq) on PTN5110 devices albeit we do mask the
> > fault-irq. Fix this gernally by writing a one to the correspondig
> 
> generically ?

Sure, thanks.

> corresponding

Of course!

> > bit-7.
> > 
> > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > ---
> >   drivers/usb/typec/tcpm/tcpci.c | 5 +++++
> >   include/linux/usb/tcpci.h      | 1 +
> >   2 files changed, 6 insertions(+)
> > 
> > diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
> > index 8da23240afbe..15632d023e4c 100644
> > --- a/drivers/usb/typec/tcpm/tcpci.c
> > +++ b/drivers/usb/typec/tcpm/tcpci.c
> > @@ -602,6 +602,11 @@ static int tcpci_init(struct tcpc_dev *tcpc)
> >   	if (time_after(jiffies, timeout))
> >   		return -ETIMEDOUT;
> > +	regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &reg);
> 
> Needs error check.

I will add this.

> Also, I am not sure if this is the correct place for this code. The alert
> status is cleared after vendor initialization. Should the same be done
> here ?

According the spec the bit must be cleared before the TCPC_ALERT is
cleared. Of course the vendor-init can (re-)trigger the bit, therefore
we should move behind the vendor init and right before the TCPC_ALERT
clear.

> Also, why not just write the bit unconditionally, similar
> to TCPC_ALERT ?

Thought about this too.. I will change it in the v3.

Thanks for the feedback,
  Marco

> 
> Thanks,
> Guenter
> 
> > +	if (reg & TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT)
> > +		tcpci_write16(tcpci, TCPC_FAULT_STATUS,
> > +			      TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT);
> > +
> >   	/* Handle vendor init */
> >   	if (tcpci->data->init) {
> >   		ret = tcpci->data->init(tcpci, tcpci->data);
> > diff --git a/include/linux/usb/tcpci.h b/include/linux/usb/tcpci.h
> > index 85e95a3251d3..83376473ac76 100644
> > --- a/include/linux/usb/tcpci.h
> > +++ b/include/linux/usb/tcpci.h
> > @@ -103,6 +103,7 @@
> >   #define TCPC_POWER_STATUS_SINKING_VBUS	BIT(0)
> >   #define TCPC_FAULT_STATUS		0x1f
> > +#define TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT BIT(7)
> >   #define TCPC_ALERT_EXTENDED		0x21
> > 
> 
> 

Re: [PATCH v2 3/4] usb: typec: tcpci: clear the fault status bit

[Guenter Roeck]

On 5/4/23 07:27, Marco Felsch wrote:
> On 23-05-04, Guenter Roeck wrote:
>> On 5/4/23 06:46, Marco Felsch wrote:
>>> According the "USB Type-C Port Controller Interface Specification v2.0"
>>> the TCPC sets the fault status register bit-7
>>> (AllRegistersResetToDefault) once the registers have been reseted to
>>
>> cleared ? set ?
> 
> Sry. I don't get this.
> 

instead of "reseted" which isn't really a word.

>>> their default values.
>>>
>>> This triggers an alert(-irq) on PTN5110 devices albeit we do mask the
>>> fault-irq. Fix this gernally by writing a one to the correspondig
>>
>> generically ?
> 
> Sure, thanks.
> 
>> corresponding
> 
> Of course!
> 
>>> bit-7.
>>>
>>> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
>>> ---
>>>    drivers/usb/typec/tcpm/tcpci.c | 5 +++++
>>>    include/linux/usb/tcpci.h      | 1 +
>>>    2 files changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c
>>> index 8da23240afbe..15632d023e4c 100644
>>> --- a/drivers/usb/typec/tcpm/tcpci.c
>>> +++ b/drivers/usb/typec/tcpm/tcpci.c
>>> @@ -602,6 +602,11 @@ static int tcpci_init(struct tcpc_dev *tcpc)
>>>    	if (time_after(jiffies, timeout))
>>>    		return -ETIMEDOUT;
>>> +	regmap_read(tcpci->regmap, TCPC_FAULT_STATUS, &reg);
>>
>> Needs error check.
> 
> I will add this.
> 
>> Also, I am not sure if this is the correct place for this code. The alert
>> status is cleared after vendor initialization. Should the same be done
>> here ?
> 
> According the spec the bit must be cleared before the TCPC_ALERT is
> cleared. Of course the vendor-init can (re-)trigger the bit, therefore
> we should move behind the vendor init and right before the TCPC_ALERT
> clear.
> 
>> Also, why not just write the bit unconditionally, similar
>> to TCPC_ALERT ?
> 
> Thought about this too.. I will change it in the v3.
> 
> Thanks for the feedback,
>    Marco
> 
>>
>> Thanks,
>> Guenter
>>
>>> +	if (reg & TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT)
>>> +		tcpci_write16(tcpci, TCPC_FAULT_STATUS,
>>> +			      TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT);
>>> +
>>>    	/* Handle vendor init */
>>>    	if (tcpci->data->init) {
>>>    		ret = tcpci->data->init(tcpci, tcpci->data);
>>> diff --git a/include/linux/usb/tcpci.h b/include/linux/usb/tcpci.h
>>> index 85e95a3251d3..83376473ac76 100644
>>> --- a/include/linux/usb/tcpci.h
>>> +++ b/include/linux/usb/tcpci.h
>>> @@ -103,6 +103,7 @@
>>>    #define TCPC_POWER_STATUS_SINKING_VBUS	BIT(0)
>>>    #define TCPC_FAULT_STATUS		0x1f
>>> +#define TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT BIT(7)
>>>    #define TCPC_ALERT_EXTENDED		0x21
>>>
>>
>>

Re: [PATCH v2 3/4] usb: typec: tcpci: clear the fault status bit

[Marco Felsch]

On 23-05-04, Guenter Roeck wrote:
> On 5/4/23 07:27, Marco Felsch wrote:
> > On 23-05-04, Guenter Roeck wrote:
> > > On 5/4/23 06:46, Marco Felsch wrote:
> > > > According the "USB Type-C Port Controller Interface Specification v2.0"
> > > > the TCPC sets the fault status register bit-7
> > > > (AllRegistersResetToDefault) once the registers have been reseted to
> > > 
> > > cleared ? set ?
> > 
> > Sry. I don't get this.
> > 
> 
> instead of "reseted" which isn't really a word.

Sure, thanks.

Regards,
  Marco

Re: [PATCH v2 3/4] usb: typec: tcpci: clear the fault status bit

[Fabio Estevam]

Hi Marco,

On Thu, May 4, 2023 at 11:27 AM Marco Felsch <m.felsch@pengutronix.de> wrote:

> > Also, why not just write the bit unconditionally, similar
> > to TCPC_ALERT ?
>
> Thought about this too.. I will change it in the v3.

Was there ever a v3 for this patch?

Thanks

Re: [PATCH v2 3/4] usb: typec: tcpci: clear the fault status bit

[Marco Felsch]

On 23-08-16, Fabio Estevam wrote:
> Hi Marco,
> 
> On Thu, May 4, 2023 at 11:27 AM Marco Felsch <m.felsch@pengutronix.de> wrote:
> 
> > > Also, why not just write the bit unconditionally, similar
> > > to TCPC_ALERT ?
> >
> > Thought about this too.. I will change it in the v3.
> 
> Was there ever a v3 for this patch?

Nope, thanks for sending it separate :)

Regards,
  Marco

[PATCH v2 4/4] arm64: dts: imx8mp-evk: add dual-role usb port1 support

[Marco Felsch]

The i.MX8MP-EVK has a dual-role usb-type-c port marked as PORT1. By this
commit the dual-role support is added which allows the user-space to
assign usb-gadget functions to it via the configFS.

Below is the test results of a basic usbgadget-ethernet test using by
iperf3.

Accepted connection from 192.168.60.1, port 48172
[  5] local 192.168.60.2 port 5201 connected to 192.168.60.1 port 48176
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   101 MBytes   850 Mbits/sec
[  5]   1.00-2.00   sec   105 MBytes   883 Mbits/sec
[  5]   2.00-3.00   sec   105 MBytes   885 Mbits/sec

...

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-100.04 sec  10.3 GBytes   882 Mbits/sec                  receiver

Accepted connection from 192.168.60.1, port 42104
[  5] local 192.168.60.2 port 5201 connected to 192.168.60.1 port 42110
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   110 MBytes   925 Mbits/sec    0    540 KBytes
[  5]   1.00-2.00   sec   112 MBytes   938 Mbits/sec    0    566 KBytes
[  5]   2.00-3.00   sec   115 MBytes   969 Mbits/sec    0    566 KBytes

...

- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-37.00  sec  4.27 GBytes   990 Mbits/sec    0             sender

Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
---
 arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 88 ++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
index 7816853162b3..20c3c41d6209 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
@@ -5,7 +5,9 @@
 
 /dts-v1/;
 
+#include <dt-bindings/interrupt-controller/irq.h>
 #include <dt-bindings/phy/phy-imx8-pcie.h>
+#include <dt-bindings/usb/pd.h>
 #include "imx8mp.dtsi"
 
 / {
@@ -83,6 +85,22 @@ reg_usdhc2_vmmc: regulator-usdhc2 {
 		gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
 		enable-active-high;
 	};
+
+	usb-ss-mux {
+		compatible = "gpio-ss-mux";
+		enable-gpios = <&gpio2 20 GPIO_ACTIVE_LOW>;
+		select-gpios = <&gpio4 20 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_usb_ss_mux>;
+
+		orientation-switch;
+
+		port {
+			usb_ss_mux: endpoint {
+				remote-endpoint = <&usb_con_ss_mux>;
+			};
+		};
+	};
 };
 
 &flexspi {
@@ -336,6 +354,40 @@ &i2c2 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_i2c2>;
 	status = "okay";
+
+	tcpc@50 {
+		compatible = "nxp,ptn5110";
+		reg = <0x50>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&pinctrl_tcpc>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
+
+		connector {
+			compatible = "usb-c-connector";
+			label = "USB-C";
+			power-role = "dual";
+			data-role = "dual";
+			try-power-role = "sink";
+			source-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+			sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
+				     PDO_VAR(5000, 20000, 3000)>;
+			op-sink-microwatt = <15000000>;
+			self-powered;
+
+			port {
+				usb_con_ss_mux: endpoint {
+					remote-endpoint = <&usb_ss_mux>;
+				};
+			};
+		};
+
+		port {
+			usb_con_ss: endpoint {
+				remote-endpoint = <&usb_dwc3_0_drd>;
+			};
+		};
+	};
 };
 
 &i2c3 {
@@ -442,14 +494,37 @@ &uart2 {
 	status = "okay";
 };
 
+&usb3_phy0 {
+	status = "okay";
+};
+
 &usb3_phy1 {
 	status = "okay";
 };
 
+&usb3_0 {
+	status = "okay";
+};
+
 &usb3_1 {
 	status = "okay";
 };
 
+&usb_dwc3_0 {
+	dr_mode = "otg";
+	hnp-disable;
+	srp-disable;
+	adp-disable;
+	usb-role-switch;
+	status = "okay";
+
+	port {
+		usb_dwc3_0_drd: endpoint {
+			remote-endpoint = <&usb_con_ss>;
+		};
+	};
+};
+
 &usb_dwc3_1 {
 	pinctrl-names = "default";
 	pinctrl-0 = <&pinctrl_usb1_vbus>;
@@ -659,6 +734,12 @@ MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19	0x40
 		>;
 	};
 
+	pinctrl_tcpc: tcpcgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SAI1_TXD7__GPIO4_IO19	0x1e0
+		>;
+	};
+
 	pinctrl_uart1: uart1grp {
 		fsl,pins = <
 			MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX	0x140
@@ -690,6 +771,13 @@ MX8MP_IOMUXC_ECSPI1_MISO__UART3_DCE_CTS		0x140
 		>;
 	};
 
+	pinctrl_usb_ss_mux: usbssmuxgrp {
+		fsl,pins = <
+			MX8MP_IOMUXC_SD2_WP__GPIO2_IO20		0x104
+			MX8MP_IOMUXC_SAI1_MCLK__GPIO4_IO20	0x144
+		>;
+	};
+
 	pinctrl_usdhc2: usdhc2grp {
 		fsl,pins = <
 			MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK	0x190

-- 
2.39.2

Re: [PATCH v2 0/4] Add i.MX8MP-EVK USB Gadget Support

[Shawn Guo]

On Thu, May 04, 2023 at 03:46:49PM +0200, Marco Felsch wrote:
> Hi all,
> 
> this adds the usb gadget support to the i.MX8MP-EVK. This Series is
> based on [1] and therefore it is already a v2. Thanks to Li and Andreas
> for the very useful feedback.
> 
> Patch1-3: Add the mssing support for USB-SS GPIO muxes. This is required
>           to have proper USB-SS support on the EVK.
> 
> Patch4: Adds the devicetree integration.

Please send the DTS change separately afterwards, as we do not want
Greg's tool to pick it up into USB tree.

Shawn

> 
> [1] https://lore.kernel.org/all/20230323105826.2058003-1-m.felsch@pengutronix.de/
> 
> Regards,
>   Marco
> 
> ---
> Marco Felsch (4):
>       dt-bindings: usb: gpio-sbu-mux: add support for ss-data lanes mux
>       usb: typec: mux: gpio-sbu-mux: add support for ss data lane muxing
>       usb: typec: tcpci: clear the fault status bit
>       arm64: dts: imx8mp-evk: add dual-role usb port1 support
> 
>  .../devicetree/bindings/usb/gpio-sbu-mux.yaml      | 82 +++++++++++++++++---
>  arch/arm64/boot/dts/freescale/imx8mp-evk.dts       | 88 ++++++++++++++++++++++
>  drivers/usb/typec/mux/Kconfig                      |  5 +-
>  drivers/usb/typec/mux/gpio-sbu-mux.c               | 18 ++++-
>  drivers/usb/typec/tcpm/tcpci.c                     |  5 ++
>  include/linux/usb/tcpci.h                          |  1 +
>  6 files changed, 185 insertions(+), 14 deletions(-)
> ---
> base-commit: 457391b0380335d5e9a5babdec90ac53928b23b4
> change-id: 20230504-b4-v6-3-topic-boards-imx8mp-evk-dual-role-usb-8dcf6274d9df
> 
> Best regards,
> -- 
> Marco Felsch <m.felsch@pengutronix.de>
> 

Re: [PATCH v2 0/4] Add i.MX8MP-EVK USB Gadget Support

[Greg Kroah-Hartman]

On Sun, May 14, 2023 at 09:21:22PM +0800, Shawn Guo wrote:
> On Thu, May 04, 2023 at 03:46:49PM +0200, Marco Felsch wrote:
> > Hi all,
> > 
> > this adds the usb gadget support to the i.MX8MP-EVK. This Series is
> > based on [1] and therefore it is already a v2. Thanks to Li and Andreas
> > for the very useful feedback.
> > 
> > Patch1-3: Add the mssing support for USB-SS GPIO muxes. This is required
> >           to have proper USB-SS support on the EVK.
> > 
> > Patch4: Adds the devicetree integration.
> 
> Please send the DTS change separately afterwards, as we do not want
> Greg's tool to pick it up into USB tree.

"Greg's tool" is the standard `b4` tool that lots of kernel maintainers
are now using.  So this isn't some magic thing that is unique to me...

thanks,

greg k-h