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

From: Andrei Kuchynski

Date: Tue Dec 16 2025 - 10:10:16 EST


On Thu, Dec 11, 2025 at 3:23 PM Heikki Krogerus
<heikki.krogerus@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx/

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