Re: USB PD TYPEC - FUSB302B port controller hard reset issue

Re: USB PD TYPEC - FUSB302B port controller hard reset issue

[Heikki Krogerus]

Hi Suniel,

On Tue, Dec 26, 2023 at 04:14:48PM +0530, Suniel Mahesh wrote:
> Hi Guenter Roeck / Heikki Krogerus and all,
> 
> 1.
> I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which has a
> FUSB302B TYPEC port controller.
> 
> 2.
> My source is a wall charger which is based on Gallium Nitride (GaN II)
> technology and has four ports as follows:
> 
> USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
> USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
> USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
> USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
> 
> 3.
> i am using latest linux-next and enabled all the relevant configs,
> especially:
> CONFIG_TYPEC=y
> CONFIG_TYPEC_TCPM=y
> CONFIG_TYPEC_FUSB302=y

Which kernel version?

> 4.
> DT node is as follows when i use USB-C1 of wall charger:
> 
>  connector {
>                         compatible = "usb-c-connector";
>                         label = "USB-C";
>                         data-role = "dual";
>                         power-role = "sink";
>                         try-power-role = "sink";
>                         op-sink-microwatt = <1000000>;
>                         sink-pdos = <PDO_FIXED(5000, 3000,
> PDO_FIXED_USB_COMM)
>                                     PDO_FIXED(12000, 3000,
> PDO_FIXED_USB_COMM)>;
>                 };

What do you mean by "when i use USB-C1..."? Why is the above valid
only then and not with the other PD contracts?

> Issue:
> The board power well most of the time, but may be in 1 out of 5 cold boots,
> FUSB302B is getting a hard reset, as
> FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
> 
> After some digging, found out that the above behaviour is accounted to when
> something is wrong with the CRC of
> the received packet (SOP - Start of Packet)

How did you determine that the problem is a bad CRC?

> This behaviour is seen i.e. FUSB302B getting a hard reset more on the
> USB-C3 port.
> 
> Any pointers on how to solve this issue.

Guenter, do you have time to take a look at this?

thanks,

-- 
heikki

Re: USB PD TYPEC - FUSB302B port controller hard reset issue

[Guenter Roeck]

On Tue, Jan 02, 2024 at 11:46:34AM +0200, Heikki Krogerus wrote:
> Hi Suniel,
> 
> On Tue, Dec 26, 2023 at 04:14:48PM +0530, Suniel Mahesh wrote:
> > Hi Guenter Roeck / Heikki Krogerus and all,
> > 
> > 1.
> > I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which has a
> > FUSB302B TYPEC port controller.
> > 
> > 2.
> > My source is a wall charger which is based on Gallium Nitride (GaN II)
> > technology and has four ports as follows:
> > 
> > USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
> > USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
> > USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
> > USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
> > 
> > 3.
> > i am using latest linux-next and enabled all the relevant configs,
> > especially:
> > CONFIG_TYPEC=y
> > CONFIG_TYPEC_TCPM=y
> > CONFIG_TYPEC_FUSB302=y
> 
> Which kernel version?
> 
> > 4.
> > DT node is as follows when i use USB-C1 of wall charger:
> > 
> >  connector {
> >                         compatible = "usb-c-connector";
> >                         label = "USB-C";
> >                         data-role = "dual";
> >                         power-role = "sink";
> >                         try-power-role = "sink";
> >                         op-sink-microwatt = <1000000>;
> >                         sink-pdos = <PDO_FIXED(5000, 3000,
> > PDO_FIXED_USB_COMM)
> >                                     PDO_FIXED(12000, 3000,
> > PDO_FIXED_USB_COMM)>;
> >                 };
> 
> What do you mean by "when i use USB-C1..."? Why is the above valid
> only then and not with the other PD contracts?
> 
> > Issue:
> > The board power well most of the time, but may be in 1 out of 5 cold boots,
> > FUSB302B is getting a hard reset, as
> > FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
> > 
> > After some digging, found out that the above behaviour is accounted to when
> > something is wrong with the CRC of
> > the received packet (SOP - Start of Packet)
> 
> How did you determine that the problem is a bad CRC?
> 
> > This behaviour is seen i.e. FUSB302B getting a hard reset more on the
> > USB-C3 port.
> > 
> > Any pointers on how to solve this issue.
> 
> Guenter, do you have time to take a look at this?
> 

As far as I can see, the bit means that a hard reset request has been
received from the charger. What else can the code do but to execute
that hard reset ? On a higher level, if there is a communication problem
due to bad CRC (i.e., a bad communication link) between the wall charger
and the development system, I am not sure if there is anything we can do
in software to remedy the problem.

Secondary question: Is this a regression ? The original e-mail states
that it was seen with the "latest linux-next". If it is a regression, it
should be possible to bisect it. However, the only recent commit which
might affect reset behavior is a6fe37f428c1 ("usb: typec: tcpm: Skip hard
reset when in error recovery"). If anything I would assume that this
commit would improve the situation, not make it worse.

Thanks,
Guenter

Re: USB PD TYPEC - FUSB302B port controller hard reset issue

[Suniel Mahesh]

Hi Guenter,

On Tue, Jan 2, 2024 at 10:39 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On Tue, Jan 02, 2024 at 11:46:34AM +0200, Heikki Krogerus wrote:
> > Hi Suniel,
> >
> > On Tue, Dec 26, 2023 at 04:14:48PM +0530, Suniel Mahesh wrote:
> > > Hi Guenter Roeck / Heikki Krogerus and all,
> > >
> > > 1.
> > > I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which has a
> > > FUSB302B TYPEC port controller.
> > >
> > > 2.
> > > My source is a wall charger which is based on Gallium Nitride (GaN II)
> > > technology and has four ports as follows:
> > >
> > > USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
> > > USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
> > > USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
> > > USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
> > >
> > > 3.
> > > i am using latest linux-next and enabled all the relevant configs,
> > > especially:
> > > CONFIG_TYPEC=y
> > > CONFIG_TYPEC_TCPM=y
> > > CONFIG_TYPEC_FUSB302=y
> >
> > Which kernel version?
> >
> > > 4.
> > > DT node is as follows when i use USB-C1 of wall charger:
> > >
> > >  connector {
> > >                         compatible = "usb-c-connector";
> > >                         label = "USB-C";
> > >                         data-role = "dual";
> > >                         power-role = "sink";
> > >                         try-power-role = "sink";
> > >                         op-sink-microwatt = <1000000>;
> > >                         sink-pdos = <PDO_FIXED(5000, 3000,
> > > PDO_FIXED_USB_COMM)
> > >                                     PDO_FIXED(12000, 3000,
> > > PDO_FIXED_USB_COMM)>;
> > >                 };
> >
> > What do you mean by "when i use USB-C1..."? Why is the above valid
> > only then and not with the other PD contracts?
> >
> > > Issue:
> > > The board power well most of the time, but may be in 1 out of 5 cold boots,
> > > FUSB302B is getting a hard reset, as
> > > FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
> > >
> > > After some digging, found out that the above behaviour is accounted to when
> > > something is wrong with the CRC of
> > > the received packet (SOP - Start of Packet)
> >
> > How did you determine that the problem is a bad CRC?
> >
> > > This behaviour is seen i.e. FUSB302B getting a hard reset more on the
> > > USB-C3 port.
> > >
> > > Any pointers on how to solve this issue.
> >
> > Guenter, do you have time to take a look at this?
> >
>
> As far as I can see, the bit means that a hard reset request has been
> received from the charger. What else can the code do but to execute
> that hard reset ? On a higher level, if there is a communication problem
> due to bad CRC (i.e., a bad communication link) between the wall charger
> and the development system, I am not sure if there is anything we can do
> in software to remedy the problem.
>
> Secondary question: Is this a regression ? The original e-mail states
> that it was seen with the "latest linux-next". If it is a regression, it
> should be possible to bisect it. However, the only recent commit which
> might affect reset behavior is a6fe37f428c1 ("usb: typec: tcpm: Skip hard
> reset when in error recovery"). If anything I would assume that this
> commit would improve the situation, not make it worse.

I have tested linux-next, linux-lts (v6.1) and linux-stable branches.

linux-next atleast reboots after it(FUSB302B) gets a hard reset
some branches in LTS, development board power is cutoff during
negotiation and board never boots.

>
> Thanks,
> Guenter

Thanks,
Suniel

Re: USB PD TYPEC - FUSB302B port controller hard reset issue

[Suniel Mahesh]

Hi Heikki,

On Tue, Jan 2, 2024 at 3:16 PM Heikki Krogerus
<heikki.krogerus@linux.intel.com> wrote:
>
> Hi Suniel,
>
> On Tue, Dec 26, 2023 at 04:14:48PM +0530, Suniel Mahesh wrote:
> > Hi Guenter Roeck / Heikki Krogerus and all,
> >
> > 1.
> > I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which has a
> > FUSB302B TYPEC port controller.
> >
> > 2.
> > My source is a wall charger which is based on Gallium Nitride (GaN II)
> > technology and has four ports as follows:
> >
> > USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
> > USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
> > USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
> > USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A
> >
> > 3.
> > i am using latest linux-next and enabled all the relevant configs,
> > especially:
> > CONFIG_TYPEC=y
> > CONFIG_TYPEC_TCPM=y
> > CONFIG_TYPEC_FUSB302=y
>
> Which kernel version?

The kernel version is linux-next which is 6.7.0-rc8

>
> > 4.
> > DT node is as follows when i use USB-C1 of wall charger:
> >
> >  connector {
> >                         compatible = "usb-c-connector";
> >                         label = "USB-C";
> >                         data-role = "dual";
> >                         power-role = "sink";
> >                         try-power-role = "sink";
> >                         op-sink-microwatt = <1000000>;
> >                         sink-pdos = <PDO_FIXED(5000, 3000,
> > PDO_FIXED_USB_COMM)
> >                                     PDO_FIXED(12000, 3000,
> > PDO_FIXED_USB_COMM)>;
> >                 };
>
> What do you mean by "when i use USB-C1..."? Why is the above valid
> only then and not with the other PD contracts?

USB-C1, USB-C2 and USB-C3 are the receptacles/connectors on the PD Wall charger
USB-C1 and USB-C2 are idenical rated as: 100W PD3.0, 5V/3A, 9V/3A,
12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
USB-C3 is rated as: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A

now when i say "when i use USB-C1", i mean that I am using receptacle
USB-C1 on the wall charger to power
my target/development system which has a FUSB302B receptacle/connector.

irrespective of the PDO's requested, like:
PDO_FIXED(9000, 3000, PDO_FIXED_USB_COMM);
or
PDO_FIXED(12000, 3000, PDO_FIXED_USB_COMM);
or
PDO_FIXED(15000, 3000, PDO_FIXED_USB_COMM);
or
PDO_FIXED(20000, 5000, PDO_FIXED_USB_COMM);

the target/development board FUSB302B is getting a hard reset like i
mentioned in
1 out of 5 cold boots.

>
> > Issue:
> > The board power well most of the time, but may be in 1 out of 5 cold boots,
> > FUSB302B is getting a hard reset, as
> > FUSB302B INTERRUPTA register bit I_HARDRST is getting set.
> >
> > After some digging, found out that the above behaviour is accounted to when
> > something is wrong with the CRC of
> > the received packet (SOP - Start of Packet)
>
> How did you determine that the problem is a bad CRC?

The power contract negotiation as per my understanding is:
cable detect => source sends Accept => Sink responds with good CRC =>
source sends capabilities =>
=> sink replied with goodCRC and sink requests for a particular PDO =>
=> source sends accept => sink replied with goodCRC =>
=> source sends PS_RDY to sink => sink replied with goodCRC and gets
bound to desired contract from source.

However in some scenarios, based on below log, i guessed it as bad
CRC: (RX, header is 0x0)
[    1.599074] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[    1.602877] FUSB302: IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83
[    1.605978] TCPM: tcpm_pd_event_handler:
[    1.606575] TCPM: tcpm_pd_event_handler: in TCPM_CC_EVENT
[    1.967732] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[    2.132493] FUSB302: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93
[    2.133057] FUSB302: IRQ: PD tx success
[    2.135446] TCPM: PD TX complete, status: 0
[    2.138529] FUSB302: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0xd1
[    2.141351] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[    2.141968] FUSB302: IRQ: PD sent good CRC
[    2.144321] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
[    2.144912] TCPM: PD RX, header: 0x1a3 [1]
[    2.145479] TCPM: tcpm_pd_ctrl_request: type:0x3
[    2.145873] TCPM: tcpm_pd_ctrl_request: case PD_CTRL_ACCEPT
[    2.146309] TCPM: tcpm_pd_ctrl_request: case SOFT_RESET_SEND
[    2.146706] TCPM: tcpm_pd_rx_handler: done
[    2.154971] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[    2.155374] FUSB302: IRQ: PD sent good CRC
[    2.158067] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
[    2.158496] TCPM: PD RX, header: 0x0 [1]
[    2.159030] TCPM: tcpm_pd_rx_handler: done
[    2.176842] FUSB302: IRQ: 0x41, a: 0x01, b: 0x00, status0: 0x83
[    2.177298] FUSB302: IRQ: PD received hardreset: interrupta: 1
[    2.177850] FUSB302: fusb302_pd_reset:
[    2.179471] TCPM: tcpm_pd_event_handler:
[    2.179919] TCPM: tcpm_pd_event_handler: TCPM_RESET_EVENT
[    2.180449] TCPM: _tcpm_pd_hard_reset: Received hard reset
[    2.181099] TCPM4: _tcpm_pd_hard_reset:

board(FUSB302B hard reset) reboots

when i use a USB-C3 receptacle on wall charger with rating: 20W PD3.0,
5V/3A, 9V/2.22A, 12V/1.67A
and device tree node as:
connector {
                        compatible = "usb-c-connector";
                        label = "USB-C";
                        data-role = "dual";
                        power-role = "sink";
                        try-power-role = "sink";
                        op-sink-microwatt = <1000000>;
                        sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
                                    PDO_FIXED(12000, 1670, PDO_FIXED_USB_COMM)>;
                };
log when FUSB302B gets a hard reset: (here it might or might not be a bad CRC ?)

[   1.602441] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[    1.606642] FUSB302: IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83
[    1.609672] TCPM: tcpm_pd_event_handler:
[    1.610240] TCPM: tcpm_pd_event_handler: in TCPM_CC_EVENT
[    1.976170] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[    2.136304] FUSB302: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93
[    2.136916] FUSB302: IRQ: PD tx success
[    2.139148] TCPM: PD TX complete, status: 0
[    2.141867] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[    2.142325] FUSB302: IRQ: PD sent good CRC
[    2.144775] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
[    2.145313] TCPM: PD RX, header: 0x1a3 [1]
[    2.145886] TCPM: tcpm_pd_ctrl_request: type:0x3
[    2.146281] TCPM: tcpm_pd_ctrl_request: case PD_CTRL_ACCEPT
[    2.146716] TCPM:tcpm_pd_ctrl_request: case SOFT_RESET_SEND
[    2.147113] TCPM: tcpm_pd_rx_handler: done
[    2.167042] FUSB302: IRQ: 0x41, a: 0x01, b: 0x00, status0: 0x83
[    2.167495] FUSB302: IRQ: PD received hardreset: interrupta: 1
[    2.168047] FUSB302: fusb302_pd_reset:
[    2.169988] TCPM: tcpm_pd_event_handler:
[    2.170395] TCPM: tcpm_pd_event_handler: TCPM_RESET_EVENT
[    2.170785] TCPM: _tcpm_pd_hard_reset: Received hard reset
[    2.171290] TCPM4: _tcpm_pd_hard_reset:

 when FUSB302B negotiates for a contract on USB-C3 receptacle, the
FUSB302B gets hard reset more
 number of times compared to USB-C1/C2.

>
> > This behaviour is seen i.e. FUSB302B getting a hard reset more on the
> > USB-C3 port.
> >
> > Any pointers on how to solve this issue.
>
> Guenter, do you have time to take a look at this?
>
> thanks,
>
> --
> heikki

Thanks,
Suniel

USB PD TYPEC - FUSB302B port controller hard reset issue

[Suniel Mahesh]

Hi Guenter/Heikki/Greg and all,

This email is a narrowed version of the earlier discussion at:
https://lore.kernel.org/all/CAM+7aWt7hJSmJQ78Fes0jMcrF9E8yhN=sDgYuU-hBxO0+1Uj0g@mail.gmail.com/T/

Please guide/suggest on why the FUSB302B port controller on a target board
is getting reset(hard reset) on reception of a 0x0 packet from source(PD Wall
charger 100W - 20V@5A).

log when reset:

[    1.599049] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[    1.602836] FUSB302: IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83
[    1.606210] TCPM: tcpm_pd_event_handler: in TCPM_CC_EVENT
[    1.968179] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
[    2.133140] FUSB302: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93
[    2.133704] FUSB302: IRQ: PD tx success
[    2.136046] FUSB302: PD message header: 161
[    2.136392] FUSB302: PD message len: 0
[    2.136845] TCPM: PD TX complete, status: 0
[    2.139382] FUSB302: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x93
[    2.142192] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[    2.142804] FUSB302: IRQ: PD sent good CRC
[    2.145274] FUSB302: PD message header: 1a3
[    2.145674] FUSB302: PD message len: 0
[    2.146072] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
[    2.146478] TCPM: PD RX, header: 0x1a3 [1]
[    2.147042] TCPM: tcpm_pd_ctrl_request: type:0x3
[    2.147435] TCPM: tcpm_pd_ctrl_request: case PD_CTRL_ACCEPT
[    2.146309] TCPM: tcpm_pd_ctrl_request: case SOFT_RESET_SEND
[    2.148266] TCPM: tcpm_pd_rx_handler: done
[    2.158196] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
[    2.158600] FUSB302: IRQ: PD sent good CRC
[    2.161283] FUSB302: PD message header: 0
[    2.161710] FUSB302: PD message len: 0
[    2.162092] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
[    2.162608] TCPM: PD RX, header: 0x0 [1]
[    2.163181] TCPM: tcpm_pd_rx_handler: done
[    2.179843] FUSB302: IRQ: 0x41, a: 0x01, b: 0x00, status0: 0x83
[    2.180314] FUSB302: IRQ: PD received hardreset: interrupta: 1
[    2.181125] FUSB302: fusb302_pd_reset:
[    2.182597] TCPM: tcpm_pd_event_handler:
[    2.182937] TCPM: tcpm_pd_event_handler: TCPM_RESET_EVENT
[    2.183292] TCPM: _tcpm_pd_hard_reset: Received hard reset
[    2.183770] TCPM: _tcpm_pd_hard_reset:

Let me know if you need anymore details.

Thanks and Regards
-- 
Suniel Mahesh
Embedded Linux and Kernel Engineer
Amarula Solutions India

Re: USB PD TYPEC - FUSB302B port controller hard reset issue

[Gábor Stefanik]

Unfortunately this seems to just be the behavior of many wall
chargers, triggered by either an excessive delay between first drawing
power and beginning PD communication, or by an incorrect sequence
number. From what I've heard, this is a workaround for a bug in the
earliest USB-C MacBooks, but it unfortunately makes those chargers
unusable for powering anything that doesn't have an internal battery.

Suniel Mahesh <sunil@amarulasolutions.com> ezt írta (időpont: 2024.
jan. 9., K, 8:17):
>
> Hi Guenter/Heikki/Greg and all,
>
> This email is a narrowed version of the earlier discussion at:
> https://lore.kernel.org/all/CAM+7aWt7hJSmJQ78Fes0jMcrF9E8yhN=sDgYuU-hBxO0+1Uj0g@mail.gmail.com/T/
>
> Please guide/suggest on why the FUSB302B port controller on a target board
> is getting reset(hard reset) on reception of a 0x0 packet from source(PD Wall
> charger 100W - 20V@5A).
>
> log when reset:
>
> [    1.599049] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
> [    1.602836] FUSB302: IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83
> [    1.606210] TCPM: tcpm_pd_event_handler: in TCPM_CC_EVENT
> [    1.968179] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
> [    2.133140] FUSB302: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93
> [    2.133704] FUSB302: IRQ: PD tx success
> [    2.136046] FUSB302: PD message header: 161
> [    2.136392] FUSB302: PD message len: 0
> [    2.136845] TCPM: PD TX complete, status: 0
> [    2.139382] FUSB302: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x93
> [    2.142192] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
> [    2.142804] FUSB302: IRQ: PD sent good CRC
> [    2.145274] FUSB302: PD message header: 1a3
> [    2.145674] FUSB302: PD message len: 0
> [    2.146072] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
> [    2.146478] TCPM: PD RX, header: 0x1a3 [1]
> [    2.147042] TCPM: tcpm_pd_ctrl_request: type:0x3
> [    2.147435] TCPM: tcpm_pd_ctrl_request: case PD_CTRL_ACCEPT
> [    2.146309] TCPM: tcpm_pd_ctrl_request: case SOFT_RESET_SEND
> [    2.148266] TCPM: tcpm_pd_rx_handler: done
> [    2.158196] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
> [    2.158600] FUSB302: IRQ: PD sent good CRC
> [    2.161283] FUSB302: PD message header: 0
> [    2.161710] FUSB302: PD message len: 0
> [    2.162092] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
> [    2.162608] TCPM: PD RX, header: 0x0 [1]
> [    2.163181] TCPM: tcpm_pd_rx_handler: done
> [    2.179843] FUSB302: IRQ: 0x41, a: 0x01, b: 0x00, status0: 0x83
> [    2.180314] FUSB302: IRQ: PD received hardreset: interrupta: 1
> [    2.181125] FUSB302: fusb302_pd_reset:
> [    2.182597] TCPM: tcpm_pd_event_handler:
> [    2.182937] TCPM: tcpm_pd_event_handler: TCPM_RESET_EVENT
> [    2.183292] TCPM: _tcpm_pd_hard_reset: Received hard reset
> [    2.183770] TCPM: _tcpm_pd_hard_reset:
>
> Let me know if you need anymore details.
>
> Thanks and Regards
> --
> Suniel Mahesh
> Embedded Linux and Kernel Engineer
> Amarula Solutions India
>

Re: USB PD TYPEC - FUSB302B port controller hard reset issue

[Guenter Roeck]

On 1/8/24 23:17, Suniel Mahesh wrote:
> Hi Guenter/Heikki/Greg and all,
> 
> This email is a narrowed version of the earlier discussion at:
> https://lore.kernel.org/all/CAM+7aWt7hJSmJQ78Fes0jMcrF9E8yhN=sDgYuU-hBxO0+1Uj0g@mail.gmail.com/T/
> 
> Please guide/suggest on why the FUSB302B port controller on a target board
> is getting reset(hard reset) on reception of a 0x0 packet from source(PD Wall
> charger 100W - 20V@5A).
> 
> log when reset:
> 
> [    1.599049] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
> [    1.602836] FUSB302: IRQ: 0x00, a: 0x40, b: 0x00, status0: 0x83
> [    1.606210] TCPM: tcpm_pd_event_handler: in TCPM_CC_EVENT
> [    1.968179] FUSB302: IRQ: 0x80, a: 0x00, b: 0x00, status0: 0x83
> [    2.133140] FUSB302: IRQ: 0x41, a: 0x04, b: 0x00, status0: 0x93
> [    2.133704] FUSB302: IRQ: PD tx success
> [    2.136046] FUSB302: PD message header: 161
> [    2.136392] FUSB302: PD message len: 0
> [    2.136845] TCPM: PD TX complete, status: 0
> [    2.139382] FUSB302: IRQ: 0x51, a: 0x00, b: 0x00, status0: 0x93
> [    2.142192] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
> [    2.142804] FUSB302: IRQ: PD sent good CRC
> [    2.145274] FUSB302: PD message header: 1a3
> [    2.145674] FUSB302: PD message len: 0
> [    2.146072] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
> [    2.146478] TCPM: PD RX, header: 0x1a3 [1]
> [    2.147042] TCPM: tcpm_pd_ctrl_request: type:0x3
> [    2.147435] TCPM: tcpm_pd_ctrl_request: case PD_CTRL_ACCEPT
> [    2.146309] TCPM: tcpm_pd_ctrl_request: case SOFT_RESET_SEND
> [    2.148266] TCPM: tcpm_pd_rx_handler: done
> [    2.158196] FUSB302: IRQ: 0x51, a: 0x00, b: 0x01, status0: 0x93
> [    2.158600] FUSB302: IRQ: PD sent good CRC
> [    2.161283] FUSB302: PD message header: 0
> [    2.161710] FUSB302: PD message len: 0
> [    2.162092] FUSB302: fusb302_pd_read_message: to tcpm_pd_receive
> [    2.162608] TCPM: PD RX, header: 0x0 [1]
> [    2.163181] TCPM: tcpm_pd_rx_handler: done
> [    2.179843] FUSB302: IRQ: 0x41, a: 0x01, b: 0x00, status0: 0x83
> [    2.180314] FUSB302: IRQ: PD received hardreset: interrupta: 1
> [    2.181125] FUSB302: fusb302_pd_reset:
> [    2.182597] TCPM: tcpm_pd_event_handler:
> [    2.182937] TCPM: tcpm_pd_event_handler: TCPM_RESET_EVENT
> [    2.183292] TCPM: _tcpm_pd_hard_reset: Received hard reset
> [    2.183770] TCPM: _tcpm_pd_hard_reset:
> 
> Let me know if you need anymore details.
> 

AFAICS the wall charger sends a hard reset request, which is honored.
This seems to work as intended to me. What is interesting though is that
I don't see a "Unrecognized extended message type" in the log,
suggesting that the message id is 0 and matches the previous
message ID. This would cause the message to be ignored.

I don't really know what do do with this. All I can say is that
the charger should not send a message with header==0x0. It looks like
there is no response sent to this message, which is possibly the
reason why the charger sends the hard reset request. But that doesn't
give us a hint what we should or even could do in this situation.

Guenter

USB PD TYPEC - FUSB302B port controller hard reset issue

[Suniel Mahesh]

Hi Guenter Roeck / Heikki Krogerus and all,

1.
I am testing USB TYPEC PD on a Rockchip Rk3399 SOC based target which
has a FUSB302B TYPEC port controller.

2.
My source is a wall charger which is based on Gallium Nitride (GaN II)
technology and has four ports as follows:

USB-C1: 100W PD3.0, 5V/3A, 9V/3A, 12V/3A, 15V/3A. 20V/5A. PPS: 3.3V-11V/4A
USB-C2: 100W PD3.0. 5V/3A. 9V/3A. 12V/3A, 15V/3A. 20V/5A PPS:3.3-11V/4A
USB-C3: 20W PD3.0, 5V/3A, 9V/2.22A, 12V/1.67A
USB-A: 18W QC3.0. 5V/3A, 9V/2A, 12V/1.5A

3.
i am using latest linux-next and enabled all the relevant configs, especially:
CONFIG_TYPEC=y
CONFIG_TYPEC_TCPM=y
CONFIG_TYPEC_FUSB302=y

4.
DT node is as follows when i use USB-C1 of wall charger:

 connector {
                        compatible = "usb-c-connector";
                        label = "USB-C";
                        data-role = "dual";
                        power-role = "sink";
                        try-power-role = "sink";
                        op-sink-microwatt = <1000000>;
                        sink-pdos = <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)
                                    PDO_FIXED(12000, 3000, PDO_FIXED_USB_COMM)>;
                };

Issue:
The board power well most of the time, but may be in 1 out of 5 cold
boots, FUSB302B is getting a hard reset, as
FUSB302B INTERRUPTA register bit I_HARDRST is getting set.

After some digging, found out that the above behaviour is accounted to
when something is wrong with the CRC of
the received packet (SOP - Start of Packet)

This behaviour is seen i.e. FUSB302B getting a hard reset more on the
USB-C3 port.

Any pointers on how to solve this issue.

Thanks and Regards
-- 
Suniel Mahesh
Embedded Linux and Kernel Engineer
Amarula Solutions India