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 for Android: free password hash cracker in your pocket

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

Message-ID: <6e63a1f0-8ed6-41cf-b1bc-34b49099eedf@wolfvision.net>
Date: Fri, 5 Jan 2024 10:49:22 +0100
From: Javier Carrasco <javier.carrasco@...fvision.net>
To: Jai Luthra <j-luthra@...com>, rogerq@...nel.org
Cc: 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

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?

> 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