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

Message-ID: <CAMMMRMfk1Rv7P4NMkYnG+2RFqVm-7Effb_xiBQU3NXhPJeeg_g@mail.gmail.com>
Date: Wed, 7 Jan 2026 10:02:45 +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 Tue, Dec 23, 2025 at 12:17 PM Heikki Krogerus
<heikki.krogerus@...ux.intel.com> wrote:
>
> Hi,
>
> Tue, Dec 16, 2025 at 03:57:40PM +0100, Andrei Kuchynski kirjoitti:
> > 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.
>
> The device for the USB4 mode will need to have its own device type in
> any case, but I'm indeed mainly concerned about how we expose the USB4
> mode device to the user space.
>
> As a kernel internal implementation detail the custom SID is probable
> fine for now, although I was actually hoping that we could improve the
> API a bit. So something like typec_register_mode() type of API. You
> probable could introduce something like this for that API:
>
>         struct typec_mode {
>                 /* enum typec_accessory         accessory; */
>                 enum usb_mode                   usb;      /* or just USB4 flag */
>                 struct typec_altmode_desc       *altmode; /* NULL with USB4 */
>         };

Got it.
If you don’t have objections regarding the mode selection, I will proceed
with sending the current patch series, omitting the USB4 support.
The support for USB4 mode will be in a subsequent series.

Thanks,
Andrei