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]

Message-ID: <f463e49d-9e69-4bff-a663-3ce7c1093202@wolfvision.net>
Date: Thu, 4 Jan 2024 17:25:27 +0100
From: Javier Carrasco <javier.carrasco@...fvision.net>
To: Jai Luthra <j-luthra@...com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
 linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org, vigneshr@...com,
 d-gole@...com, nm@...com, rogerq@...nel.org
Subject: Re: [PATCH v2 0/4] usb: typec: tipd: add patch update support for
 tps6598x

Hi Jai Luthra,
On 04.01.24 16:47, Jai Luthra wrote>> FYI, this series breaks boot for
TI SK-AM62A and SK-AM62 which use
>> TPS6598x as the USB-C PD chip.
>>
>> The platforms stopped booting since next-20240103 [1], and reverting 
>> this series [4] seems to fix the issue [2]
>>
>> Is there any change needed in the board device-tree [3] and bindings?
>>
>> We don't specify any firmware in the device-tree node, but seems like 
>> that is an assumption in this series. I tried reverting it (below 
>> change) but that did *not* help with the stuck boot.
>>Thanks a lot for your high-quality feedback. I am glad to see that you
even found a solution to the issue.

The firmware update only happens if the device is in patch mode ('PTCH'
in the Mode register - 0x03), which is the expected behavior because the
device waits in that mode until a patch arrives. That is probably the
reason why your first attempt did not work (no update was triggered).

The problem seems to be related to the reset function, as you already
noticed. That function is only called in suspend/resume, if the probe
fails and in the remove function.

Did the probe function fail and if so, could you see why? The reset
function is identical for the tps25750 and tps6598x ('GAID' with no
parameters), so I wonder why that should be the source of the problem.
> The following change seems to fix boot on SK-AM62A without reverting 
> this whole series:
> 
> ------------------
> 
> diff --git a/drivers/usb/typec/tipd/core.c b/drivers/usb/typec/tipd/core.c
> index a956eb976906a5..8ba2aa05db519b 100644
> --- a/drivers/usb/typec/tipd/core.c
> +++ b/drivers/usb/typec/tipd/core.c
> @@ -1223,11 +1223,16 @@ static int cd321x_reset(struct tps6598x *tps)
>  	return 0;
>  }
>  
> -static int tps6598x_reset(struct tps6598x *tps)
> +static int tps25750_reset(struct tps6598x *tps)
>  {
>  	return tps6598x_exec_cmd_tmo(tps, "GAID", 0, NULL, 0, NULL, 2000, 0);
>  }
>  
> +static int tps6598x_reset(struct tps6598x *tps)
> +{
> +	return 0;
> +}
> +
>  static int
>  tps25750_register_port(struct tps6598x *tps, struct fwnode_handle *fwnode)
>  {
> @@ -1545,7 +1550,7 @@ static const struct tipd_data tps25750_data = {
>  	.trace_status = trace_tps25750_status,
>  	.apply_patch = tps25750_apply_patch,
>  	.init = tps25750_init,
> -	.reset = tps6598x_reset,
> +	.reset = tps25750_reset,
>  };
>  
>  static const struct of_device_id tps6598x_of_match[] = {
> 
> ------------------
> 
> I am not an expert on this, will let you/others decide on what should be 
> the correct way to reset TPS6598x for patching without breaking this SK.
> 
> 

The driver did not support cold resets before, but that does not mean
that they should not happen like it does for the tps25750. Your fix just
removes the reset function for the tps6598x, and I would like to know
why the reset happened in the fist place.

Thanks and best regards,
Javier Carrasco