[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4erwnvyyammnsdihwpvqcmm4v4fcyxozltocklsbnbfdhacoye@le7x2giuxrwv>
Date: Fri, 5 Jan 2024 15:40:54 +0530
From: Jai Luthra <j-luthra@...com>
To: Javier Carrasco <javier.carrasco@...fvision.net>,
Abdel Alkuor
<abdelalkuor@...tab.com>
CC: <rogerq@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<vigneshr@...com>, <d-gole@...com>, <nm@...com>
Subject: Re: [PATCH v2 0/4] usb: typec: tipd: add patch update support for
tps6598x
Hi Javier, Abdel,
On Jan 05, 2024 at 10:49:22 +0100, Javier Carrasco wrote:
> On 05.01.24 09:12, Jai Luthra wrote:
> > I added some prints and can see that the probe fails once at
> > fwnode_usb_role_switch_get() because the other endpoint (of USB device)
> > is not yet probed. It then re-probes later where it passes.
> >
> > The GAID reset being done unconditionally in your series seems to cause
> > the board to get stuck in the boot process when it hits the above error
> > due to probe-order between USB subsystem and this IC. My guess would be
> > SoC stops getting power because we reset the PD chip?
> >
> > Anyway, I will send below change as a separate "Fixes:" patch for now,
> > to keep how things as they were before your series.
> >
>
> My biggest concern is that we are sending GAID for the tps25750 under
> the same circumstances. Could we not have the same problem with that
> device? We would be resetting the PD controller and the SoC would stop
> getting power as well, right? Or is there anything device-specific that
> would avoid that?
>
Yes I would guess same problem can happen depending on probe order of
the remote-endpoint node, but I don't see any upstream platform using
ti,tps25750 compatible, so I have no way to confirm.
Maybe Abdel can comment on how it works, as he added the GAID reset for
tps25750.
> > If you have a better architecture in mind that can reset only when PTCH
> > has been applied and not for other probe defers, feel free to send it on
> > top of it.
> >
>
> I added the cold reset to have the same behavior upon probe failures for
> both devices, given that they use the same command. But if that can
> cause problems, let's leave the reset alone...
>
> Best regards,
> Javier Carrasco
--
Thanks,
Jai
GPG Fingerprint: 4DE0 D818 E5D5 75E8 D45A AFC5 43DE 91F9 249A 7145
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists