Hi Guenter, On Tue, Jan 2, 2024 at 10:39 PM Guenter Roeck <linux@xxxxxxxxxxxx> 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