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
