[PATCH v2 0/4] USB-PD TCPM improvements

[PATCH v2 0/4] USB-PD TCPM improvements

[Sebastian Reichel]

Hi,

I have a couple of fixes/improvements for the TCPM code. Three are fixing
actual problems I noticed on the Rock 5B, which prevented booting up the
system. One of them simply adds an error print before potentially committing
hara-kiri by triggering a hard reset, which helps people understanding
why their boards reset themself in case there are more problems. I've
recently added the same print to the kernel TCPM code.

Changes since PATCHv1:
 * https://lore.kernel.org/u-boot/20241031175404.114773-5-sebastian.reichel@collabora.com/
 * rebased to v2025.04-rc3 (no changes needed)

Greetings,

-- Sebastian

Sebastian Reichel (4):
  usb: tcpm: improve handling of some power-supplies
  usb: tcpm: avoid resets for missing source capability messages
  usb: tcpm: print error on hard reset
  usb: tcpm: improve data role mismatch error recovery

 drivers/usb/tcpm/tcpm-internal.h |  1 +
 drivers/usb/tcpm/tcpm.c          | 95 ++++++++++++++++++++++++++++----
 2 files changed, 85 insertions(+), 11 deletions(-)

-- 
2.47.2

[PATCH v2 1/4] usb: tcpm: improve handling of some power-supplies

[Sebastian Reichel]

When the Rock 5B is booted with the current TCPM with its power supplied
by a "Cambrionix PDSync-C4" port it reaches the power-supply ready state.
Once that has happened the hub starts sending GetSinkCap messages, but
U-Boot already stopped processing PD messages. After retrying a bunch of
times the hub instead sends soft resets. Since U-Boot will also not
react to them, the USB hub will follow-up with a hard reset and that
cuts off the supply voltage.

Since the state machine is already prepared to handle GetSinkCap
messages, try to avoid this by handling incoming messages for another
50ms after reaching the ready state.

Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
 drivers/usb/tcpm/tcpm.c | 31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/tcpm/tcpm.c b/drivers/usb/tcpm/tcpm.c
index 0aee57cb2f4a..b754b4dcd0b5 100644
--- a/drivers/usb/tcpm/tcpm.c
+++ b/drivers/usb/tcpm/tcpm.c
@@ -2229,6 +2229,17 @@ static int tcpm_port_init(struct udevice *dev)
 	return 0;
 }
 
+static inline void tcpm_poll_one_event(struct udevice *dev)
+{
+	const struct dm_tcpm_ops *drvops = dev_get_driver_ops(dev);
+	struct tcpm_port *port = dev_get_uclass_plat(dev);
+
+	drvops->poll_event(dev);
+	port->poll_event_cnt++;
+	udelay(500);
+	tcpm_check_and_run_delayed_work(dev);
+}
+
 static void tcpm_poll_event(struct udevice *dev)
 {
 	const struct dm_tcpm_ops *drvops = dev_get_driver_ops(dev);
@@ -2242,15 +2253,25 @@ static void tcpm_poll_event(struct udevice *dev)
 		    (port->state == SNK_READY || port->state == SRC_READY))
 			break;
 
-		drvops->poll_event(dev);
-		port->poll_event_cnt++;
-		udelay(500);
-		tcpm_check_and_run_delayed_work(dev);
+		tcpm_poll_one_event(dev);
 	}
 
-	if (port->state != SNK_READY && port->state != SRC_READY)
+	/*
+	 * Some power-supplies send GetSinkCap shortly after they are ready.
+	 * If they do not receive a response after a few retries they will issue
+	 * a soft-reset followed by a hard reset, which kills the board power.
+	 * Let's poll for 50ms after reaching the ready state to check if the
+	 * power-supply wants something from us.
+	 */
+	if (port->state == SNK_READY) {
+		port->poll_event_cnt = 0;
+
+		while (port->poll_event_cnt < 100)
+			tcpm_poll_one_event(dev);
+	} else {
 		dev_warn(dev, "TCPM: exit in state %s\n",
 			 tcpm_states[port->state]);
+	}
 
 	/*
 	 * At this time, call the callback function of the respective pd chip
-- 
2.47.2

[PATCH v2 2/4] usb: tcpm: avoid resets for missing source capability messages

[Sebastian Reichel]

The current TCPM code implements source capability message handling
according to the USB-PD specification. Unfortunately some USB PD
sources do not properly follow the specification and do not send
source capability messages after a soft reset when they already
negotiated a specific contract before. The currently implemented way
(and what is described in the specificiation) to resolve this problem
is triggering a hard reset.

But a hard reset is fatal on batteryless platforms powered via USB-C PD,
since that removes VBUS for some time. Since this is triggered at boot
time, the system may get stuck in a boot loop.

For example I noticed the following behaviour on a Radxa Rock 5B
combined with an affected power-supply:

1. The system is booted up with current code
2. A reboot is requested
3. U-Boot TCPM / fusb302 driver sends soft reset and waits for the
   source capability message
4. No new source capability message is send by the power-supply
   after the soft reset
5. U-Boot sends a hard reset
6. The board resets, but the fusb302 registers are not reset. This
   is because of a hardware glitch. The serial pins are high when
   no data is exchanged. Apparently the RK3588 has protection diodes,
   which leak some voltage into the power-domain. The Rock 5B serial
   pins and the fusb302 are using the same 3.3V power domain and the
   leaked voltage is enough to keep the fusb302 registers alive.
7. After the hard reset the power-supply sends another source capability
   message, which is auto-acked by fusb302 (because the register state
   is kept) even though the U-Boot driver has not yet probed. Once the
   U-Boot driver probes it sends another soft reset and waits for a new
   source capability message, which never arrives.

Fortunately the affected power-supplies (I have two setups showing this
behaviour) support sending a source capability message when explicitly
being asked. Thus an easy workaround to handle this is deviating from
the USB-PD specification and sending a Get_Source_Cap message and
waiting some time longer before doing the hard reset.

Note, that I recently added the same workaround to the Linux kernel
with a slightly different rationale (since it needs to take over from
U-Boot).

Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
 drivers/usb/tcpm/tcpm-internal.h |  1 +
 drivers/usb/tcpm/tcpm.c          | 32 +++++++++++++++++++++++++++++---
 2 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/tcpm/tcpm-internal.h b/drivers/usb/tcpm/tcpm-internal.h
index 561442090027..4861f4d13866 100644
--- a/drivers/usb/tcpm/tcpm-internal.h
+++ b/drivers/usb/tcpm/tcpm-internal.h
@@ -30,6 +30,7 @@
 	S(SNK_DISCOVERY_DEBOUNCE),		\
 	S(SNK_DISCOVERY_DEBOUNCE_DONE),		\
 	S(SNK_WAIT_CAPABILITIES),		\
+	S(SNK_WAIT_CAPABILITIES_TIMEOUT),	\
 	S(SNK_NEGOTIATE_CAPABILITIES),		\
 	S(SNK_TRANSITION_SINK),			\
 	S(SNK_TRANSITION_SINK_VBUS),		\
diff --git a/drivers/usb/tcpm/tcpm.c b/drivers/usb/tcpm/tcpm.c
index b754b4dcd0b5..786d92fa4c6f 100644
--- a/drivers/usb/tcpm/tcpm.c
+++ b/drivers/usb/tcpm/tcpm.c
@@ -1424,7 +1424,8 @@ static inline enum tcpm_state hard_reset_state(struct tcpm_port *port)
 		return ERROR_RECOVERY;
 	if (port->pwr_role == TYPEC_SOURCE)
 		return SRC_UNATTACHED;
-	if (port->state == SNK_WAIT_CAPABILITIES)
+	if (port->state == SNK_WAIT_CAPABILITIES ||
+	    port->state == SNK_WAIT_CAPABILITIES_TIMEOUT)
 		return SNK_READY;
 	return SNK_UNATTACHED;
 }
@@ -1650,10 +1651,35 @@ static void run_state_machine(struct udevice *dev)
 			tcpm_set_state(dev, SOFT_RESET_SEND,
 				       PD_T_SINK_WAIT_CAP);
 		} else {
-			tcpm_set_state(dev, hard_reset_state(port),
-				       PD_T_SINK_WAIT_CAP);
+			if (!port->self_powered)
+				tcpm_set_state(dev, SNK_WAIT_CAPABILITIES_TIMEOUT,
+					       PD_T_SINK_WAIT_CAP);
+			else
+				tcpm_set_state(dev, hard_reset_state(port),
+					       PD_T_SINK_WAIT_CAP);
 		}
 		break;
+	case SNK_WAIT_CAPABILITIES_TIMEOUT:
+		/*
+		 * There are some USB PD sources in the field, which do not
+		 * properly implement the specification and fail to start
+		 * sending Source Capability messages after a soft reset. The
+		 * specification suggests to do a hard reset when no Source
+		 * capability message is received within PD_T_SINK_WAIT_CAP,
+		 * but that might effectively kil the machine's power source.
+		 *
+		 * This slightly diverges from the specification and tries to
+		 * recover from this by explicitly asking for the capabilities
+		 * using the Get_Source_Cap control message before falling back
+		 * to a hard reset. The control message should also be supported
+		 * and handled by all USB PD source and dual role devices
+		 * according to the specification.
+		 */
+		if (tcpm_pd_send_control(dev, PD_CTRL_GET_SOURCE_CAP))
+			tcpm_set_state_cond(dev, hard_reset_state(port), 0);
+		else
+			tcpm_set_state(dev, hard_reset_state(port), PD_T_SINK_WAIT_CAP);
+		break;
 	case SNK_NEGOTIATE_CAPABILITIES:
 		port->pd_capable = true;
 		port->hard_reset_count = 0;
-- 
2.47.2

[PATCH v2 3/4] usb: tcpm: print error on hard reset

[Sebastian Reichel]

A USB-PD hard reset involves removing the voltage from VBUS for some
time. So basically it has the same effect as removing the USB-C plug
for a short moment. If the machine is powered from the USB-C port and
does not have a fallback supply (e.g. a battery), this will result in
a full machine reset due to power loss.

Ideally we want to avoid triggering a hard reset on these boards. A
non-working USB-C port is probably better than unplanned reboots. But
boards with a backup supply should do the hard reset to get everything
working again.

In theory it would be enough to check the self_powered property, but
it seems the property might not be configured consistently enough in
system firmwares.

USB-PD hard resets should happen rarely in general, so let's at least
print an error message before the potential board reset happens. This
is also useful, since it immediately gives away which device triggered
the hard reset.

Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
 drivers/usb/tcpm/tcpm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/tcpm/tcpm.c b/drivers/usb/tcpm/tcpm.c
index 786d92fa4c6f..909fe2ef4fcb 100644
--- a/drivers/usb/tcpm/tcpm.c
+++ b/drivers/usb/tcpm/tcpm.c
@@ -1711,6 +1711,8 @@ static void run_state_machine(struct udevice *dev)
 
 	/* Hard_Reset states */
 	case HARD_RESET_SEND:
+		if (!port->self_powered && port->port_type == TYPEC_PORT_SNK)
+			dev_err(dev, "Initiating hard-reset, which might result in machine power-loss.\n");
 		tcpm_pd_transmit(dev, TCPC_TX_HARD_RESET, NULL);
 		tcpm_set_state(dev, HARD_RESET_START, 0);
 		port->wait_dr_swap_message = false;
-- 
2.47.2

[PATCH v2 4/4] usb: tcpm: improve data role mismatch error recovery

[Sebastian Reichel]

On Radxa ROCK 5B I managed to get U-Boot into an endless loop of
printing

fusb302 usb-typec@22: TCPM: data role mismatch, initiating error recovery

messages by changing the data role in Linux and then rebooting the
system. This is happening because the external device (A cheap USB-C hub
powered through a USB-C PD power-supply) kept its state and the error
recovery path for non self-powered devices is not enough to change it.

Avoid this by swapping our own data role when the error recovery stage
is reached for a port, which is not self-powered. Right now data support
is limited anyways and once proper support is added we can use the data
role swap request to get the desired data direction after the initial
negotiation completed.

Fixes: 1db4c0ac77e3 ("usb: tcpm: add core framework")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
 drivers/usb/tcpm/tcpm.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/tcpm/tcpm.c b/drivers/usb/tcpm/tcpm.c
index 909fe2ef4fcb..12d66d470f9a 100644
--- a/drivers/usb/tcpm/tcpm.c
+++ b/drivers/usb/tcpm/tcpm.c
@@ -833,6 +833,28 @@ static void tcpm_pd_ctrl_request(struct udevice *dev,
 	}
 }
 
+static void tcpm_recover_data_role_mismatch(struct udevice *dev)
+{
+	struct tcpm_port *port = dev_get_uclass_plat(dev);
+
+	dev_err(dev, "TCPM: data role mismatch, initiating error recovery\n");
+	if (port->self_powered) {
+		tcpm_set_state(dev, ERROR_RECOVERY, 0);
+		return;
+	}
+
+	/*
+	 * The error recovery will not help for devices, which are not
+	 * self-powered because the error recovery avoids killing the board
+	 * power. Since this can happen early on sending
+	 * a DR_SWAP request is not sensible. Instead let's change our own
+	 * data role. It can be swapped back once USB-PD reached the ready
+	 * state.
+	 */
+	tcpm_set_roles(dev, true, port->pwr_role,
+		       port->data_role == TYPEC_HOST ? TYPEC_DEVICE : TYPEC_HOST);
+}
+
 static void tcpm_pd_rx_handler(struct udevice *dev,
 			       const struct pd_message *msg)
 {
@@ -867,9 +889,11 @@ static void tcpm_pd_rx_handler(struct udevice *dev,
 		remote_is_host = !!(le16_to_cpu(msg->header) & PD_HEADER_DATA_ROLE);
 		local_is_host = port->data_role == TYPEC_HOST;
 		if (remote_is_host == local_is_host) {
-			dev_err(dev, "TCPM: data role mismatch, initiating error recovery\n");
-			tcpm_set_state(dev, ERROR_RECOVERY, 0);
-		} else {
+			tcpm_recover_data_role_mismatch(dev);
+			local_is_host = port->data_role == TYPEC_HOST;
+		}
+
+		if (remote_is_host != local_is_host) {
 			if (cnt)
 				tcpm_pd_data_request(dev, msg);
 			else
-- 
2.47.2

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Anand Moon]

Hi Sebastian,

On Thu, 27 Feb 2025 at 00:15, Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> Hi,
>
> I have a couple of fixes/improvements for the TCPM code. Three are fixing
> actual problems I noticed on the Rock 5B, which prevented booting up the
> system. One of them simply adds an error print before potentially committing
> hara-kiri by triggering a hard reset, which helps people understanding
> why their boards reset themself in case there are more problems. I've
> recently added the same print to the kernel TCPM code.
>
I have encountered issues with the Raspberry Pi Type C power supply on
a few occasions.
Thanks for these changes, but it dose not resolve the issue completely.

Do you have plans to add a device tree node for this board?

> Changes since PATCHv1:
>  * https://lore.kernel.org/u-boot/20241031175404.114773-5-sebastian.reichel@collabora.com/
>  * rebased to v2025.04-rc3 (no changes needed)
>
I am observing the following logs.

Radxa 65W power supply with a USB-C connector.
--------------------------------------------------------------------
U-Boot 2025.04-rc3-00011-g3ddae9d42a89 (Feb 27 2025 - 09:36:45 +0530)

Model: Radxa ROCK 5B
SoC:   RK3588
DRAM:  8 GiB
fusb302 usb-typec@22: TCPM: data role mismatch, initiating error recovery
fusb302 usb-typec@22: TCPM: Unrecognized ctrl message type 0x0
DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18

With Raspberry Pi 4 Type C charger
--------------------------------------------------------------------
U-Boot 2025.04-rc3-00011-g3ddae9d42a89 (Feb 27 2025 - 09:36:45 +0530)

Model: Radxa ROCK 5B
SoC:   RK3588
DRAM:  8 GiB
fusb302 usb-typec@22: Initiating hard-reset, which might result in
machine power-loss.
fusb302 usb-typec@22: TCPM: PD transmit data failed: -110
Core:  362 devices, 34 uclasses, devicetree: separate

With Raspberry Pi 5 Type C charger
--------------------------------------------------------------------
U-Boot 2025.04-rc3-00011-g3ddae9d42a89 (Feb 27 2025 - 09:36:45 +0530)

Model: Radxa ROCK 5B
SoC:   RK3588
DRAM:  8 GiB
fusb302 usb-typec@22: Initiating hard-reset, which might result in
machine power-loss.
fusb302 usb-typec@22: TCPM: PD transmit data failed: -110

Is there any issue with the power supply side
since Radxa also lists this issue with some power source

[1] https://wiki.radxa.com/Rock5/5b/power_supply

Thanks
-Anand

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Peter Robinson]

On Thu, 27 Feb 2025 at 06:01, Anand Moon <linux.amoon@gmail.com> wrote:

> Hi Sebastian,
>
> On Thu, 27 Feb 2025 at 00:15, Sebastian Reichel
> <sebastian.reichel@collabora.com> wrote:
> >
> > Hi,
> >
> > I have a couple of fixes/improvements for the TCPM code. Three are fixing
> > actual problems I noticed on the Rock 5B, which prevented booting up the
> > system. One of them simply adds an error print before potentially
> committing
> > hara-kiri by triggering a hard reset, which helps people understanding
> > why their boards reset themself in case there are more problems. I've
> > recently added the same print to the kernel TCPM code.
> >
> I have encountered issues with the Raspberry Pi Type C power supply on
> a few occasions.
> Thanks for these changes, but it dose not resolve the issue completely.
>

I don't believe the RPi Type-C power supply supports power delivery.


> Do you have plans to add a device tree node for this board?
>

For which board?


> > Changes since PATCHv1:
> >  *
> https://lore.kernel.org/u-boot/20241031175404.114773-5-sebastian.reichel@collabora.com/
> >  * rebased to v2025.04-rc3 (no changes needed)
> >
> I am observing the following logs.
>
> Radxa 65W power supply with a USB-C connector.
> --------------------------------------------------------------------
> U-Boot 2025.04-rc3-00011-g3ddae9d42a89 (Feb 27 2025 - 09:36:45 +0530)
>
> Model: Radxa ROCK 5B
> SoC:   RK3588
> DRAM:  8 GiB
> fusb302 usb-typec@22: TCPM: data role mismatch, initiating error recovery
> fusb302 usb-typec@22: TCPM: Unrecognized ctrl message type 0x0
> DDR 9fa84341ce typ 24/09/06-09:51:11,fwver: v1.18
>
> With Raspberry Pi 4 Type C charger
> --------------------------------------------------------------------
> U-Boot 2025.04-rc3-00011-g3ddae9d42a89 (Feb 27 2025 - 09:36:45 +0530)
>
> Model: Radxa ROCK 5B
> SoC:   RK3588
> DRAM:  8 GiB
> fusb302 usb-typec@22: Initiating hard-reset, which might result in
> machine power-loss.
> fusb302 usb-typec@22: TCPM: PD transmit data failed: -110
> Core:  362 devices, 34 uclasses, devicetree: separate
>
> With Raspberry Pi 5 Type C charger
> --------------------------------------------------------------------
> U-Boot 2025.04-rc3-00011-g3ddae9d42a89 (Feb 27 2025 - 09:36:45 +0530)
>
> Model: Radxa ROCK 5B
> SoC:   RK3588
> DRAM:  8 GiB
> fusb302 usb-typec@22: Initiating hard-reset, which might result in
> machine power-loss.
> fusb302 usb-typec@22: TCPM: PD transmit data failed: -110
>
> Is there any issue with the power supply side
> since Radxa also lists this issue with some power source
>
> [1] https://wiki.radxa.com/Rock5/5b/power_supply
>
> Thanks
> -Anand
>

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Anand Moon]

Hi Peter / Sebastian,

On Sat, 1 Mar 2025 at 23:41, Peter Robinson <pbrobinson@gmail.com> wrote:
>
>
>
> On Thu, 27 Feb 2025 at 06:01, Anand Moon <linux.amoon@gmail.com> wrote:
>>
>> Hi Sebastian,
>>
>> On Thu, 27 Feb 2025 at 00:15, Sebastian Reichel
>> <sebastian.reichel@collabora.com> wrote:
>> >
>> > Hi,
>> >
>> > I have a couple of fixes/improvements for the TCPM code. Three are fixing
>> > actual problems I noticed on the Rock 5B, which prevented booting up the
>> > system. One of them simply adds an error print before potentially committing
>> > hara-kiri by triggering a hard reset, which helps people understanding
>> > why their boards reset themself in case there are more problems. I've
>> > recently added the same print to the kernel TCPM code.
>> >
>> I have encountered issues with the Raspberry Pi Type C power supply on
>> a few occasions.
>> Thanks for these changes, but it dose not resolve the issue completely.
>
>
> I don't believe the RPi Type-C power supply supports power delivery.

RPi 5 Type-C power supply is generally compatible with the Rock 5B for
daily use.
I also have the Radxa 65W official Type-C power supply for the Radxa
Rock 5B board.
I was checking the connection messages with different power sources.

>
>>
>> Do you have plans to add a device tree node for this board?
>
>
> For which board?

Radxa Rock 5B and Rock 5B+ indeed have a versatile USB Type-C port that
can be used both as a display port and a power source.

During my investigation, I discovered that the Type-C port uses the
FCS, FUSB302 the
driver instead of the TCPM driver. The FUSB302 driver is specifically
designed for
USB Power Delivery (USB PD) and supports various power delivery protocols.

Here is the device node

[1] https://github.com/radxa/kernel/blob/linux-6.1-stan-rkr4.1/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts#L744-L814
[2] https://github.com/Ralim/usb-pd

As of now, I don't have a Type-C power source monitor to test the feature

Thanks
-Anand

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Sebastian Reichel]

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

Hi Anand,

On Mon, Mar 03, 2025 at 01:08:24PM +0530, Anand Moon wrote:
> On Sat, 1 Mar 2025 at 23:41, Peter Robinson <pbrobinson@gmail.com> wrote:
> > On Thu, 27 Feb 2025 at 06:01, Anand Moon <linux.amoon@gmail.com> wrote:
> >> On Thu, 27 Feb 2025 at 00:15, Sebastian Reichel
> >> <sebastian.reichel@collabora.com> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I have a couple of fixes/improvements for the TCPM code. Three are fixing
> >> > actual problems I noticed on the Rock 5B, which prevented booting up the
> >> > system. One of them simply adds an error print before potentially committing
> >> > hara-kiri by triggering a hard reset, which helps people understanding
> >> > why their boards reset themself in case there are more problems. I've
> >> > recently added the same print to the kernel TCPM code.
> >> >
> >> I have encountered issues with the Raspberry Pi Type C power
> >> supply on a few occasions. Thanks for these changes, but it
> >> dose not resolve the issue completely.

I don't promise fixing all issues with this series. USB-PD is super
complex. This series improves things and shouldn't have any
regressions. It also helps with debugging further issues by having
the extra print.

> > I don't believe the RPi Type-C power supply supports power delivery.
> 
> RPi 5 Type-C power supply is generally compatible with the Rock 5B
> for daily use. I also have the Radxa 65W official Type-C power
> supply for the Radxa Rock 5B board. I was checking the connection
> messages with different power sources.
> 
> >> Do you have plans to add a device tree node for this board?
> >
> > For which board?
> 
> Radxa Rock 5B and Rock 5B+ indeed have a versatile USB Type-C port
> that can be used both as a display port and a power source.
> 
> During my investigation, I discovered that the Type-C port uses
> the FCS,FUSB302 the driver instead of the TCPM driver. The
> FUSB302 driver is specifically designed for USB Power Delivery
> (USB PD) and supports various power delivery protocols.

The fusb302 driver uses the TCPM framework. TCPM means "Type C Port
Manager". The chip is not autonomous (like some other USB-PD chips).
Without a driver telling it, what messages should be exchanged, it
will stay quiet. TCPM implements the huge USB-PD state machine,
which knows when a specific messages is expected or needs to be
send. The remote side (i.e. the power-supply) has a similar state
machine implemented. Ending up in a bad state in the state machine
results in the system trying to do a hard reset to go back to the
start. A hard reset involves removing the supply voltage and thus
kills boards like the Rock 5B. To avoid this the state machine must
be tweaked. That's why FUSB302 is not really mentioned here - the
driver is passing the messages correctly. TCPM is the relevant bit,
as that contains the state machine.

> As of now, I don't have a Type-C power source monitor to test the
> feature

You can also get debug information from the Rock 5B itself. But
then you should make sure it has a backup power-supply (e.g. PoE
or via the GPIO header), so that it does not reset itself when a
USB-PD hard reset happens. Also this setup has some side-effects
to the communication itself, since it affects the timings if you
enable too much debug messages.

Greetings,

-- Sebastian

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

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Anand Moon]

Hi Sebastian,

On Mon, 3 Mar 2025 at 21:36, Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> Hi Anand,
>
> On Mon, Mar 03, 2025 at 01:08:24PM +0530, Anand Moon wrote:
> > On Sat, 1 Mar 2025 at 23:41, Peter Robinson <pbrobinson@gmail.com> wrote:
> > > On Thu, 27 Feb 2025 at 06:01, Anand Moon <linux.amoon@gmail.com> wrote:
> > >> On Thu, 27 Feb 2025 at 00:15, Sebastian Reichel
> > >> <sebastian.reichel@collabora.com> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > I have a couple of fixes/improvements for the TCPM code. Three are fixing
> > >> > actual problems I noticed on the Rock 5B, which prevented booting up the
> > >> > system. One of them simply adds an error print before potentially committing
> > >> > hara-kiri by triggering a hard reset, which helps people understanding
> > >> > why their boards reset themself in case there are more problems. I've
> > >> > recently added the same print to the kernel TCPM code.
> > >> >
> > >> I have encountered issues with the Raspberry Pi Type C power
> > >> supply on a few occasions. Thanks for these changes, but it
> > >> dose not resolve the issue completely.
>
> I don't promise fixing all issues with this series. USB-PD is super
> complex. This series improves things and shouldn't have any
> regressions. It also helps with debugging further issues by having
> the extra print.
>
> > > I don't believe the RPi Type-C power supply supports power delivery.
> >
> > RPi 5 Type-C power supply is generally compatible with the Rock 5B
> > for daily use. I also have the Radxa 65W official Type-C power
> > supply for the Radxa Rock 5B board. I was checking the connection
> > messages with different power sources.
> >
> > >> Do you have plans to add a device tree node for this board?
> > >
> > > For which board?
> >
> > Radxa Rock 5B and Rock 5B+ indeed have a versatile USB Type-C port
> > that can be used both as a display port and a power source.
> >
> > During my investigation, I discovered that the Type-C port uses
> > the FCS,FUSB302 the driver instead of the TCPM driver. The
> > FUSB302 driver is specifically designed for USB Power Delivery
> > (USB PD) and supports various power delivery protocols.
>
> The fusb302 driver uses the TCPM framework. TCPM means "Type C Port
> Manager". The chip is not autonomous (like some other USB-PD chips).
> Without a driver telling it, what messages should be exchanged, it
> will stay quiet. TCPM implements the huge USB-PD state machine,
> which knows when a specific messages is expected or needs to be
> send. The remote side (i.e. the power-supply) has a similar state
> machine implemented. Ending up in a bad state in the state machine
> results in the system trying to do a hard reset to go back to the
> start. A hard reset involves removing the supply voltage and thus
> kills boards like the Rock 5B. To avoid this the state machine must
> be tweaked. That's why FUSB302 is not really mentioned here - the
> driver is passing the messages correctly. TCPM is the relevant bit,
> as that contains the state machine.
>
Ok, I agree with your changes,

However, I have a question regarding the Type-C controller's
connection to the PMIC via I2C.
I didn't see a corresponding controller node in the device tree source
(dts) file
that would support this function.

I feel this might be causing issues in maintaining the power state?

[1] https://github.com/u-boot/u-boot/blob/master/drivers/usb/tcpm/fusb302.c#L1285-L1316

> > As of now, I don't have a Type-C power source monitor to test the
> > feature
>
> You can also get debug information from the Rock 5B itself. But
> then you should make sure it has a backup power-supply (e.g. PoE
> or via the GPIO header), so that it does not reset itself when a
> USB-PD hard reset happens. Also this setup has some side-effects
> to the communication itself, since it affects the timings if you
> enable too much debug messages.
Yes, you are correct. I need to have a different setup to test this.
>
> Greetings,
>
> -- Sebastian
Thanks
-Anand

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Sebastian Reichel]

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

Hi,

On Tue, Mar 04, 2025 at 10:35:03AM +0530, Anand Moon wrote:
> However, I have a question regarding the Type-C controller's
> connection to the PMIC via I2C. I didn't see a corresponding
> controller node in the device tree source (dts) file that would
> support this function.
> 
> I feel this might be causing issues in maintaining the power state?
> 
> [1] https://github.com/u-boot/u-boot/blob/master/drivers/usb/tcpm/fusb302.c#L1285-L1316

There is no direct connection between the PMIC and the fusb302. Not
in the driver, not in DT and not on the hardware. The fusb302_get_connector_node()
function you are referencing is for the USB-C connector devicetree node.
You can find it here:

https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi#L35

Greetings,

-- Sebastian

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

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Anand Moon]

Hi Sebastian,

On Tue, 4 Mar 2025 at 18:12, Sebastian Reichel
<sebastian.reichel@collabora.com> wrote:
>
> Hi,
>
> On Tue, Mar 04, 2025 at 10:35:03AM +0530, Anand Moon wrote:
> > However, I have a question regarding the Type-C controller's
> > connection to the PMIC via I2C. I didn't see a corresponding
> > controller node in the device tree source (dts) file that would
> > support this function.
> >
> > I feel this might be causing issues in maintaining the power state?
> >
> > [1] https://github.com/u-boot/u-boot/blob/master/drivers/usb/tcpm/fusb302.c#L1285-L1316
>
> There is no direct connection between the PMIC and the fusb302. Not
> in the driver, not in DT and not on the hardware. The fusb302_get_connector_node()
> function you are referencing is for the USB-C connector devicetree node.
> You can find it here:
>
> https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi#L35
>
Thanks, I completely missed this part. sorry for the noise.
I was checking the upstream dts dir.
> Greetings,
>
> -- Sebastian
Thanks
-Anand

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Anand Moon]

Hi Sebastian,

On Tue, 4 Mar 2025 at 20:20, Anand Moon <linux.amoon@gmail.com> wrote:
>
> Hi Sebastian,
>
> On Tue, 4 Mar 2025 at 18:12, Sebastian Reichel
> <sebastian.reichel@collabora.com> wrote:
> >
> > Hi,
> >
> > On Tue, Mar 04, 2025 at 10:35:03AM +0530, Anand Moon wrote:
> > > However, I have a question regarding the Type-C controller's
> > > connection to the PMIC via I2C. I didn't see a corresponding
> > > controller node in the device tree source (dts) file that would
> > > support this function.
> > >
> > > I feel this might be causing issues in maintaining the power state?
> > >
> > > [1] https://github.com/u-boot/u-boot/blob/master/drivers/usb/tcpm/fusb302.c#L1285-L1316
> >
> > There is no direct connection between the PMIC and the fusb302. Not
> > in the driver, not in DT and not on the hardware. The fusb302_get_connector_node()
> > function you are referencing is for the USB-C connector devicetree node.
> > You can find it here:
> >
> > https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi#L35
> >
> Thanks, I completely missed this part. sorry for the noise.
> I was checking the upstream dts dir.

Apologies, I had not applied the whole series of patches

Please add my
Reviewed-by: Anand Moon <linux.amoon@gmail.com>
Tested-by: Anand Moon <linux.amoon@gmail.com>

After applying enabling debug I am convinced this works on my Rock Pi 5b Board.

U-Boot 2025.04-rc3-00057-g671ac2d744b2 (Mar 06 2025 - 23:51:44 +0530)

Model: Radxa ROCK 5B
SoC:   RK3588
DRAM:  8 GiB
fusb302 usb-typec@22: probing Type-C port manager...fusb302
usb-typec@22: fusb302 device ID: 0x91
fusb302 usb-typec@22: TCPM: set voltage limit = 0 mV
fusb302 usb-typec@22: TCPM: set current limit = 0 mA
fusb302 usb-typec@22: fusb302 start drp toggling
fusb302 usb-typec@22: TCPM: init finished
fusb302 usb-typec@22: TCPM: CC connected in CC2 as UFP
fusb302 usb-typec@22: TCPM: set voltage limit = 5000 mV
fusb302 usb-typec@22: TCPM: set current limit = 3000 mA
fusb302 usb-typec@22: CC activities detected, delay handling
fusb302 usb-typec@22: CC activities detected, delay handling
fusb302 usb-typec@22: Initiating hard-reset, which might result in
machine power-loss.
fusb302 usb-typec@22: TCPM: PD transmit data failed: -110
fusb302 usb-typec@22: TCPM: set voltage limit = 5000 mV
fusb302 usb-typec@22: TCPM: set current limit = 3000 mA
fusb302 usb-typec@22: CC activities detected, delay handling
fusb302 usb-typec@22: CC activities detected, delay handling
fusb302 usb-typec@22: TCPM: PD chip enter low power mode
Core:  362 devices, 34 uclasses, devicetree: separate
MMC:   mmc@fe2c0000: 1, mmc@fe2d0000: 2, mmc@fe2e0000: 0

Thanks
-Anand

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Soeren Moch]

On 06.03.25 20:00, Anand Moon wrote:
> Apologies, I had not applied the whole series of patches
>
> Please add my
> Reviewed-by: Anand Moon<linux.amoon@gmail.com>
> Tested-by: Anand Moon<linux.amoon@gmail.com>
>
> After applying enabling debug I am convinced this works on my Rock Pi 5b Board.
>
> U-Boot 2025.04-rc3-00057-g671ac2d744b2 (Mar 06 2025 - 23:51:44 +0530)
>
> Model: Radxa ROCK 5B
> SoC:   RK3588
> DRAM:  8 GiB
> fusb302 usb-typec@22: probing Type-C port manager...fusb302
> usb-typec@22: fusb302 device ID: 0x91
> fusb302 usb-typec@22: TCPM: set voltage limit = 0 mV
> fusb302 usb-typec@22: TCPM: set current limit = 0 mA
> fusb302 usb-typec@22: fusb302 start drp toggling
> fusb302 usb-typec@22: TCPM: init finished
> fusb302 usb-typec@22: TCPM: CC connected in CC2 as UFP
> fusb302 usb-typec@22: TCPM: set voltage limit = 5000 mV
> fusb302 usb-typec@22: TCPM: set current limit = 3000 mA
> fusb302 usb-typec@22: CC activities detected, delay handling
> fusb302 usb-typec@22: CC activities detected, delay handling
> fusb302 usb-typec@22: Initiating hard-reset, which might result in
> machine power-loss.
> fusb302 usb-typec@22: TCPM: PD transmit data failed: -110
> fusb302 usb-typec@22: TCPM: set voltage limit = 5000 mV
> fusb302 usb-typec@22: TCPM: set current limit = 3000 mA
> fusb302 usb-typec@22: CC activities detected, delay handling
> fusb302 usb-typec@22: CC activities detected, delay handling
> fusb302 usb-typec@22: TCPM: PD chip enter low power mode
> Core:  362 devices, 34 uclasses, devicetree: separate
> MMC:   mmc@fe2c0000: 1, mmc@fe2d0000: 2, mmc@fe2e0000: 0
>
I also tested this series on top of v2025.04-rc3 with my working USB-PD
power supply.
Of course I cannot check the improvements for problematic power
supplies, but I
can confirm that there are no regressions from this series in my setup.

For the series:
Tested-by: Soeren Moch <smoch@web.de>


U-Boot 2025.04-rc3-00004-g27c9bc97fafe (Mar 07 2025 - 09:39:42 +0100)

Model: Radxa ROCK 5B
SoC:   RK3588
DRAM:  8 GiB
Core:  362 devices, 34 uclasses, devicetree: separate
MMC:   mmc@fe2c0000: 1, mmc@fe2d0000: 2, mmc@fe2e0000: 0
Loading Environment from nowhere... OK
In:    serial@feb50000
Out:   serial@feb50000
Err:   serial@feb50000
Model: Radxa ROCK 5B
SoC:   RK3588
Net:   No ethernet found.
Hit any key to stop autoboot:  0
=> tcpm list
| ID | Name                            | Parent name         | Parent
uclass @ seq
|  0 | usb-typec@22                    | i2c@feac0000        | i2c @ 4 |
status: 0
=> tcpm dev 0
dev: 0 @ usb-typec@22
=> tcpm info
Orientation: reverse
PD Revision: rev3
Power Role:  sink
Data Role:   device
Voltage:      5.000 V
Current:      3.000 A
=>

Thanks,
Soeren

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Nicolas Frattaroli]

On Wednesday, 26 February 2025 19:44:43 Central European Standard Time 
Sebastian Reichel wrote:
> Hi,
> 
> I have a couple of fixes/improvements for the TCPM code. Three are fixing
> actual problems I noticed on the Rock 5B, which prevented booting up the
> system. One of them simply adds an error print before potentially committing
> hara-kiri by triggering a hard reset, which helps people understanding why
> their boards reset themself in case there are more problems. I've recently
> added the same print to the kernel TCPM code.
> 
> Changes since PATCHv1:
>  *
> https://lore.kernel.org/u-boot/20241031175404.114773-5-sebastian.reichel@co
> llabora.com/ * rebased to v2025.04-rc3 (no changes needed)
> 
> Greetings,
> 
> -- Sebastian
> 
> Sebastian Reichel (4):
>   usb: tcpm: improve handling of some power-supplies
>   usb: tcpm: avoid resets for missing source capability messages
>   usb: tcpm: print error on hard reset
>   usb: tcpm: improve data role mismatch error recovery
> 
>  drivers/usb/tcpm/tcpm-internal.h |  1 +
>  drivers/usb/tcpm/tcpm.c          | 95 ++++++++++++++++++++++++++++----
>  2 files changed, 85 insertions(+), 11 deletions(-)

Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

Used this series on our 2025.04-rc2-based Sige5 tree. Resolves a problem I've 
observed with PD supplies where the board may bootloop within u-boot. Tested 
with various USB-C PD sources and cables, all of which worked.

Thanks,
Nicolas Frattaroli

Re: [PATCH v2 0/4] USB-PD TCPM improvements

[Marcel Ziswiler]

Hi folks

On Wed, 2025-02-26 at 19:44 +0100, Sebastian Reichel wrote:
> Hi,
> 
> I have a couple of fixes/improvements for the TCPM code. Three are fixing
> actual problems I noticed on the Rock 5B, which prevented booting up the
> system. One of them simply adds an error print before potentially committing
> hara-kiri by triggering a hard reset, which helps people understanding
> why their boards reset themself in case there are more problems. I've
> recently added the same print to the kernel TCPM code.

Thanks, any reason this series hasn't landed yet?

Anyway, I can confirm this tremendously improves the situation.

Whole series:

Tested-by: Marcel Ziswiler <marcel.ziswiler@codethink.co.uk> # rock5b

> Changes since PATCHv1:
>  * https://lore.kernel.org/u-boot/20241031175404.114773-5-sebastian.reichel@collabora.com/
>  * rebased to v2025.04-rc3 (no changes needed)
> 
> Greetings,
> 
> -- Sebastian
> 
> Sebastian Reichel (4):
>   usb: tcpm: improve handling of some power-supplies
>   usb: tcpm: avoid resets for missing source capability messages
>   usb: tcpm: print error on hard reset
>   usb: tcpm: improve data role mismatch error recovery
> 
>  drivers/usb/tcpm/tcpm-internal.h |  1 +
>  drivers/usb/tcpm/tcpm.c          | 95 ++++++++++++++++++++++++++++----
>  2 files changed, 85 insertions(+), 11 deletions(-)

Cheers

Marcel