[PATCH 0/2] usb: gpio-sbu-mux: add FUSB340 and enable option for orientation

[PATCH 0/2] usb: gpio-sbu-mux: add FUSB340 and enable option for orientation

[Fabrice Gasnier]

Add a new compatible for FUSB340. Also mange the enable GPIO, when used as
orientation-switch only.
It is used on STM32MP25 DK boards, as orientation-switch only for
USB SuperSpeed lines on the Type-C connector, the enable GPIO being
connected to the SoC.

- - - - SoC - - - - - - - - - - board - - - - -
                        |                 USB-C
+------+  +----------+  |                   +-+
|      |--|  USB2PHY |<-----------------HS->|*|
|      |--|    HS    |<-----------------HS->|*|
|      |  +----------+  |                   | |
|      |                |    ________       | |
+ dwc3 |  +----------+  |   /        |<-SS->|*|
|      |  |          |<--->/         |<-SS->|*|
|      |--| ComboPHY |<--->  FUSB340 |      | |
|      |  |    SS    |  |  \  __     |<-SS->|*|
+------+  +----------+  |   \_en__sw_|<-SS->|*|
                        |     ^   ^         | |
          +----------+  |     |   |         ...
          [   GPIO   ]--------+   |
          [   GPIO   ]------------+
          +----------+  |
- - - - - - - - - - - - - - - - - - - - - - --

This is a subset of STM32MP25 Type-C support [1].

[1] https://lore.kernel.org/all/20260821-ucpd-host-fusb340-v7-2-rfc-v1-0-c5e27cbc0795@foss.st.com/

---
Fabrice Gasnier (2):
      dt-bindings: usb: gpio-sbu-mux: Add compatible for FUSB340
      usb: typec: mux: gpio-sbu: enable when only used for orientation

 Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml | 1 +
 drivers/usb/typec/mux/gpio-sbu-mux.c                    | 7 +++++++
 2 files changed, 8 insertions(+)
---
base-commit: 8d3ae59288f1e7d58d76558a6ee96d533bc5019f
change-id: 20260825-usb-fusb340-v1-f060a5f84d3c

Best regards,
--  
Fabrice Gasnier <fabrice.gasnier@foss.st.com>

[PATCH 1/2] dt-bindings: usb: gpio-sbu-mux: Add compatible for FUSB340

[Fabrice Gasnier]

Add a compatible for the FUSB340 GPIO-based 2:1 SuperSpeed switch
with enable-gpios and select-gpios controls. The switch can be used
in Type-C applications where a reversible cable requires a switch.

Suggested-by: Marek Vasut <marex@nabladev.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
---
 Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
index 793662f6f3bf..c0e60848d8ab 100644
--- a/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
+++ b/Documentation/devicetree/bindings/usb/gpio-sbu-mux.yaml
@@ -22,6 +22,7 @@ properties:
           - nxp,cbdtu02043
           - onnn,fsusb42
           - onnn,fsusb43l10x
+          - onnn,fusb340
           - pericom,pi3usb102
           - ti,tmuxhs4212
       - const: gpio-sbu-mux

-- 
2.43.0

Re: [PATCH 1/2] dt-bindings: usb: gpio-sbu-mux: Add compatible for FUSB340

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[PATCH 2/2] usb: typec: mux: gpio-sbu: enable when only used for orientation

[Fabrice Gasnier]

When used as orientation-switch only (no mode-switch, e.g. no altmode),
the optional enable gpio remains disabled.
Enable it from the switch_set() routine, in this case, when the
orientation is set and the enable-gpios property has been provided.

Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
---
 drivers/usb/typec/mux/gpio-sbu-mux.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/typec/mux/gpio-sbu-mux.c b/drivers/usb/typec/mux/gpio-sbu-mux.c
index 1834f1a2dd9d..4151d78e3b8d 100644
--- a/drivers/usb/typec/mux/gpio-sbu-mux.c
+++ b/drivers/usb/typec/mux/gpio-sbu-mux.c
@@ -17,6 +17,7 @@ struct gpio_sbu_mux {
 
 	struct typec_switch_dev *sw;
 	struct typec_mux_dev *mux;
+	bool mode_switch;
 
 	struct mutex lock; /* protect enabled and swapped */
 	bool enabled;
@@ -40,9 +41,13 @@ static int gpio_sbu_switch_set(struct typec_switch_dev *sw,
 		enabled = false;
 		break;
 	case TYPEC_ORIENTATION_NORMAL:
+		if (!sbu_mux->mode_switch)
+			enabled = true;
 		swapped = false;
 		break;
 	case TYPEC_ORIENTATION_REVERSE:
+		if (!sbu_mux->mode_switch)
+			enabled = true;
 		swapped = true;
 		break;
 	}
@@ -125,6 +130,8 @@ static int gpio_sbu_mux_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(sbu_mux->sw),
 				     "failed to register typec switch\n");
 
+	sbu_mux->mode_switch = device_property_read_bool(dev, "mode-switch");
+
 	mux_desc.drvdata = sbu_mux;
 	mux_desc.fwnode = dev_fwnode(dev);
 	mux_desc.set = gpio_sbu_mux_set;

-- 
2.43.0

Re: [PATCH 2/2] usb: typec: mux: gpio-sbu: enable when only used for orientation

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [Medium] The `mode_switch` property is initialized after the Type-C switch device is registered, creating a race window where concurrent callbacks use an uninitialized value.
- [Medium] The SBU lines are briefly enabled in the wrong orientation before being swapped, potentially causing a signal glitch or reversed polarity.

Pre-existing issues:
- [High] Concurrent callbacks may access freed memory if probe fails or during device removal because devres frees `sbu_mux` before active consumer references are revoked.
--

--- Patch [2]: [PATCH 2/2] usb: typec: mux: gpio-sbu: enable when only used for orientation ---
commit fb130c070f4886abd845b89bf6f060523ddd0aaf
Author: Fabrice Gasnier <fabrice.gasnier@foss.st.com>

usb: typec: mux: gpio-sbu: enable when only used for orientation

When used as orientation-switch only (no mode-switch, e.g. no altmode),
the optional enable gpio remains disabled.
Enable it from the switch_set() routine, in this case, when the
orientation is set and the enable-gpios property has been provided.

> diff --git a/drivers/usb/typec/mux/gpio-sbu-mux.c b/drivers/usb/typec/mux/gpio-sbu-mux.c
> index 1834f1a2dd9dd..4151d78e3b8d6 100644
> --- a/drivers/usb/typec/mux/gpio-sbu-mux.c
> +++ b/drivers/usb/typec/mux/gpio-sbu-mux.c

[ ... ]

> @@ -40,9 +41,13 @@ static int gpio_sbu_switch_set(struct typec_switch_dev *sw,
>  		enabled = false;
>  		break;
>  	case TYPEC_ORIENTATION_NORMAL:
> +		if (!sbu_mux->mode_switch)
> +			enabled = true;
>  		swapped = false;
>  		break;
>  	case TYPEC_ORIENTATION_REVERSE:
> +		if (!sbu_mux->mode_switch)
> +			enabled = true;
>  		swapped = true;
>  		break;
>  	}

[Severity: Medium]
Does this result in a signal glitch?

Later in gpio_sbu_switch_set(), the code updates the enable_gpio before
the select_gpio:

	if (enabled != sbu_mux->enabled)
		gpiod_set_value_cansleep(sbu_mux->enable_gpio, enabled);

	if (swapped != sbu_mux->swapped)
		gpiod_set_value_cansleep(sbu_mux->select_gpio, swapped);

If both enabled and swapped transition to true here, the switch will
briefly be enabled in the normal orientation before it is swapped to the
reverse orientation. 

Would it be safer to configure the swap GPIO before enabling the switch?

[ ... ]

> @@ -125,6 +130,8 @@ static int gpio_sbu_mux_probe(struct platform_device *pdev)
>  		return dev_err_probe(dev, PTR_ERR(sbu_mux->sw),
>  				     "failed to register typec switch\n");
>  
> +	sbu_mux->mode_switch = device_property_read_bool(dev, "mode-switch");
> +

[Severity: Medium]
Can this create a race window during initialization?

At this point, typec_switch_register() has already been called and the
device is exposed to consumers. 

If a concurrent consumer (like TCPM) invokes gpio_sbu_switch_set() right
after registration but before this property is read, it will see
sbu_mux->mode_switch as false.

Would it be better to read this property before registering the switch?

[Severity: High]
This is a pre-existing issue, but does the error path handling just below
this lead to a use-after-free?

If typec_mux_register() fails later in probe, the code unregisters the
switch but doesn't seem to synchronize with active consumers:

	sbu_mux->mux = typec_mux_register(dev, &mux_desc);
	if (IS_ERR(sbu_mux->mux)) {
		typec_switch_unregister(sbu_mux->sw);
		return dev_err_probe(...);
	}

If a concurrent consumer invokes gpio_sbu_switch_set() before the
reference is revoked, and devres synchronously frees sbu_mux after probe
returns the error, the callback will dereference the freed sbu_mux memory
when it attempts to acquire sbu_mux->lock.

A similar situation appears to happen during device removal in
gpio_sbu_mux_remove().

>  	mux_desc.drvdata = sbu_mux;
>  	mux_desc.fwnode = dev_fwnode(dev);
>  	mux_desc.set = gpio_sbu_mux_set;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260825-usb-fusb340-v1-v1-0-2191179b0661@foss.st.com?part=2