linux-kernel - Re: [PATCH v2 0/4] usb: typec: tipd: add patch update support for tps6598x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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)