linux-kernel - Re: [PATCH] usb: typec: ucsi: Skip setting orientation for UCSI version 2.0 and above

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] [day] [month] [year] [list]

Message-ID: <fetxo2ij7rstq52kxzad4yj76l25kzanzaccjrfso4bklcb5ra@mym55zc26icw>
Date: Tue, 28 Oct 2025 18:26:48 +0200
From: Abel Vesa <abel.vesa@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Heikki Krogerus <heikki.krogerus@...ux.intel.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Bjorn Andersson <andersson@...nel.org>, 
	Konrad Dybcio <konradybcio@...nel.org>, Dmitry Baryshkov <lumag@...nel.org>, 
	linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] usb: typec: ucsi: Skip setting orientation for UCSI
 version 2.0 and above

On 25-10-28 17:30:08, Dmitry Baryshkov wrote:
> On Tue, Oct 28, 2025 at 04:39:19PM +0200, Abel Vesa wrote:
> > In case of UCSI version 2.0 and above, if the orientation is set from
> > glink as well, it will trigger the consumers along the graph (PHYs,
> > repeaters and so on) to reconfigure a second time. This might break
> > the consumer drivers which aren't currently implemented to drop the
> > second request of setting the same orientation.
> 
> Might or breaks? What happens if the driver doesn't ignore the request?

So I do not have a very specific usecase in mind, but my point is more
about complex LTTPRs or repeaters which might misbehave if you trigger
multiple orientation setting.

Anyway, we currently do so on platforms where orientation is determined
by a gpio level. So I think requesting multiple same orientation settings
is definitely not a problem currently.

I still think we should stick to the UCSI payload value if available,
and ignore everything else.