Received-SPF: pass (google.com: domain of linux-kernel+bounces-15652-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <CAM+7aWvGerEdUnsKboUg9+EoL=66k3nULHCnQgHyxsWQhUwmpw@mail.gmail.com>
 <ZZPbeUbMM3J4pH/K@kuha.fi.intel.com> <5458c2f4-b212-4e35-b870-f15fb724f41a@roeck-us.net>
In-Reply-To: <5458c2f4-b212-4e35-b870-f15fb724f41a@roeck-us.net>
From: Suniel Mahesh <sunil@amarulasolutions.com>
Date: Wed, 3 Jan 2024 20:00:25 +0530
Message-ID: <CAM+7aWvfB-TyYfwYiWiWc+RrGn9yyjr5SHagWeXqKwN44Z1H3Q@mail.gmail.com>
Subject: Re: USB PD TYPEC - FUSB302B port controller hard reset issue
To: Guenter Roeck <linux@roeck-us.net>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>, Kyle Tso <kyletso@google.com>, 
	Jagan Teki <jagan@amarulasolutions.com>, USB list <linux-usb@vger.kernel.org>, 
	linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Guenter,

On Tue, Jan 2, 2024 at 10:39=E2=80=AFPM 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-1=
1V/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=3Dy
> > > CONFIG_TYPEC_TCPM=3Dy
> > > CONFIG_TYPEC_FUSB302=3Dy
> >
> > Which kernel version?
> >
> > > 4.
> > > DT node is as follows when i use USB-C1 of wall charger:
> > >
> > >  connector {
> > >                         compatible =3D "usb-c-connector";
> > >                         label =3D "USB-C";
> > >                         data-role =3D "dual";
> > >                         power-role =3D "sink";
> > >                         try-power-role =3D "sink";
> > >                         op-sink-microwatt =3D <1000000>;
> > >                         sink-pdos =3D <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 t=
o 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