linux-kernel - Re: [PATCH RFC 0/8] 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] [day] [month] [year] [list]

Message-ID: <CAMMMRMdwX8wKJz6OEvosVXFH2npr+7pd0pdq3eY9r-Pbr3tjMw@mail.gmail.com>
Date: Tue, 16 Dec 2025 15:57:40 +0100
From: Andrei Kuchynski <akuchynski@...omium.org>
To: Heikki Krogerus <heikki.krogerus@...ux.intel.com>
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>, 
	Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, "Christian A. Ehrhardt" <lk@...e.de>, 
	Abel Vesa <abel.vesa@...aro.org>, Pooja Katiyar <pooja.katiyar@...el.com>, 
	Pavan Holla <pholla@...omium.org>, Madhu M <madhu.m@...el.com>, 
	Venkat Jayaraman <venkat.jayaraman@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/8] USB Type-C alternate mode selection

On Thu, Dec 11, 2025 at 3:23 PM Heikki Krogerus
<heikki.krogerus@...ux.intel.com> wrote:
>
> Thu, Dec 11, 2025 at 03:40:24PM +0200, Heikki Krogerus kirjoitti:
> > Without going into the code review yet, I'm okay with this in general,
> > except with the artificial SID for the USB4. I still don't understand
> > why do you guys think we should use that instead of an USB4 specific
> > device type?
> >
> > I think somebody said earlier that the user space can't see the device
> > type of the alt modes? If that's really the case, then I think there
> > is some bigger issue here. Are you really sure that if you check the
> > device type of an alternate mode for example with udevadm, it does not
> > say DEVTYPE=typec_alternate_mode ?
> >
> >         % udevadm info -q property --property=DEVTYPE /sys/bus/typec/devices/port0-partner.0
> >         DEVTYPE=typec_alternate_mode
>
> Or just use grep :)
>
>         % grep DEVTYPE /sys/bus/typec/devices/port0-partner.0/uevent
>         DEVTYPE=typec_alternate_mode
>
> So, if that really does not work, then there is a bug somewhere that
> we obviously need to fix.
>
> Please note that the port altmodes are now also part of the bus.
>
> Br,
>
> --
> heikki

Thank you for the review, Heikki.

The USB4 SID is utilized for distinguishing between USB4 and alternate
modes internally and is not exposed to user-space. This represents internal
implementation detail, for example the boolean variable `is_alternate`
could serve the same purpose as the SID.
This patch series introduces no new sysfs entries; the only new attribute,
`priority`, was introduced in the mode priority series, available at
https://lore.kernel.org/all/20251124124639.1101335-1-akuchynski@chromium.org/

It is possible to use already existing `usb_capabily` and `usb_mode`
attributes to manage USB4 mode, allowing verification of USB4 support on
both the port and the partner. The activation of USB4 is accomplished
through the implementation of the `enter_usb_mode` typec operation.

I would like your opinion on whether using a USB4 device type would be a
better approach.

Please note that patches 6 and 7 are not part of the mode selection series.
They are not yet complete and are provided only to demonstrate how the
entire feature should work.

I confirm there is no issue with the DEVTYPE. Thank you.

Thanks,
Andrei