Re: [PATCH RFC 0/8] USB Type-C alternate mode selection

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

Wed, Jan 07, 2026 at 10:02:45AM +0100, Andrei Kuchynski kirjoitti:
> On Tue, Dec 23, 2025 at 12:17 PM Heikki Krogerus
> <heikki.krogerus@linux.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@linux.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.

No objections :)


-- 
heikki