linux-kernel - Re: [PATCH RFC 0/5] USB Type-C alternate mode selection

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: <aMliLCWFKy5Esl0-@kuha.fi.intel.com>
Date: Tue, 16 Sep 2025 16:12:12 +0300
From: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To: Andrei Kuchynski <akuchynski@...omium.org>
Cc: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>,
	Benson Leung <bleung@...omium.org>,
	Jameson Thies <jthies@...gle.com>,
	Tzung-Bi Shih <tzungbi@...nel.org>, linux-usb@...r.kernel.org,
	chrome-platform@...ts.linux.dev,
	Guenter Roeck <groeck@...omium.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/5] USB Type-C alternate mode selection

On Tue, Sep 09, 2025 at 12:30:23PM +0000, Andrei Kuchynski wrote:
> This patch series introduces a flexible mechanism for USB Type-C mode
> selection, enabling into USB4 mode, Thunderbolt alternate mode, or
> DisplayPort alternate mode.
> 
> New sysfs `mode_selection` attribute is exposed to provide user control
> over mode selection. It triggers an alternate mode negotiation.
> The mode selection logic attempts to enter prioritized modes sequentially.
> A mode is considered successfully negotiated only when its alternate mode
> driver explicitly reports a positive status. Alternate mode drivers are
> required to report their mode entry status (either successful or failed).
> If the driver does not report its status within a defined timeout period,
> the system automatically proceeds to attempt entry into the next preferred
> mode.

I'm still struggling to understand what is the benefit from this - why
would you want the user space to explicitly start the entry process
like this? Instead why would you not just take full control over the
alt modes in user space by enabling the them one by one in what ever
order you want?

I don't believe you can make this approach scale much if and when in
the future the use cases change. Right now I don't feel comfortable
with this at all.

thanks,

> This series was tested on an Android OS device with kernel 6.16.
> This series depends on the 'USB Type-C alternate mode priorities' series:
> https://lore.kernel.org/all/20250905142206.4105351-1-akuchynski@chromium.org/ 
> 
> Andrei Kuchynski (5):
>   usb: typec: Implement mode selection
>   usb: typec: Expose mode_selection attribute via sysfs
>   usb: typec: Report altmode entry status via callback
>   usb: typec: ucsi: displayport: Propagate DP altmode entry result
>   platform/chrome: cros_ec_typec: Propagate altmode entry result
> 
>  Documentation/ABI/testing/sysfs-class-typec  |  11 +
>  drivers/platform/chrome/cros_ec_typec.c      |   9 +
>  drivers/platform/chrome/cros_typec_altmode.c |  32 +-
>  drivers/platform/chrome/cros_typec_altmode.h |   6 +
>  drivers/usb/typec/altmodes/displayport.c     |  19 +-
>  drivers/usb/typec/altmodes/thunderbolt.c     |  10 +
>  drivers/usb/typec/class.c                    |  37 ++
>  drivers/usb/typec/class.h                    |   4 +
>  drivers/usb/typec/mode_selection.c           | 345 +++++++++++++++++++
>  drivers/usb/typec/mode_selection.h           |  25 ++
>  drivers/usb/typec/ucsi/displayport.c         |  10 +-
>  include/linux/usb/typec_altmode.h            |  11 +
>  include/linux/usb/typec_dp.h                 |   2 +
>  include/linux/usb/typec_tbt.h                |   3 +
>  14 files changed, 516 insertions(+), 8 deletions(-)
> 
> -- 
> 2.51.0.384.g4c02a37b29-goog

-- 
heikki