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

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

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 */
        };

> 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.

Got it.

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

Okay, good. So there are no bugs at least :)

Br,

-- 
heikki