Re: [PATCH v2 1/3] usb: typec: Add helper to check cable altmode support

[Andrei Kuchynski]

Hi Heikki,

On Mon, Jun 22, 2026 at 12:18 PM Heikki Krogerus
<heikki.krogerus@xxxxxxxxxxxxxxx> wrote:
>
> Hi Andrei,
>
> > +bool typec_cable_altmode_unsupported(struct typec_altmode *alt)
> > +{
> > +     return unsupported;
>
> So if typec_cable_get() doesn't return a cable, this function will now
> always return false - i.e. the cable is supported? Is that intentional?
>

Yes, this is intentional.
The UCSI GET_CABLE_PROPERTY command is optional. typec_register_cable()
function can also be called without the desc->identity field.
Failing to provide cable information shouldn't be a reason to reject the
alternate mode.
Also, the cable can be registered after the partner's altmodes. We
encounter this scenario with the cros_ec_typec driver. I'm planning to fix
it, but for now, this approach will preserve the previous behavior.

Therefore, the idea is to reject the altmode only if we know the cable
doesn't support it. That's why the function is called "unsupported".
It returns true if a limitation is detected. Otherwise, the function
returns false.

> This would probable be much more clear if you checked the cable only
> ones, right after you take the handle.
>
>         cable = typec_cable_get(typec_altmode2port(alt));
>         if (!cable)
>                 return true; /* or false? */
>         ...
>         /* Now unconditionally */
>         typec_cable_put(cable);
>

Ok, I'll redo it. Thanks

> I think this would be even more clear if the function was called
> typec_cable_altmode_supported() and you would then have a wrapper:
>
> static inline bool typec_cable_altmode_unsupported(struct typec_altmode *alt)
> {
>         return !typec_cable_altmode_supported(alt);
> }
>

I prefer exporting the 'unsupported' helper to altmode drivers. While its
naming is slightly less intuitive, it accurately reflects the logic.
What do you think about it?

Thanks,
Andrei