All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Andrei Kuchynski <akuchynski@chromium.org>
Cc: Benson Leung <bleung@chromium.org>,
	Jameson Thies <jthies@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/3] usb: typec: Add helper to check cable altmode support
Date: Mon, 22 Jun 2026 13:18:51 +0300	[thread overview]
Message-ID: <ajkMCz52lkq9hz3s@kuha> (raw)
In-Reply-To: <20260622093910.1210089-2-akuchynski@chromium.org>

Hi Andrei,

> +bool typec_cable_altmode_unsupported(struct typec_altmode *alt)
> +{
> +	struct typec_altmode *plug;
> +	struct typec_cable *cable;
> +	bool unsupported = false;
> +
> +	/*
> +	 * Check if the cable has an e-marker, supports modal operation, and the
> +	 * SOP' altmode nodes are created. If yes, then altmode is supported.
> +	 */
> +	plug = typec_altmode_get_plug(alt, TYPEC_PLUG_SOP_P);
> +	if (plug) {
> +		typec_altmode_put_plug(plug);
> +		return false;
> +	}
> +
> +	/*
> +	 * Check if the cable is registered and its identity is specified.
> +	 * If not, the cable altmode restriction cannot be checked.
> +	 */
> +	cable = typec_cable_get(typec_altmode2port(alt));
> +	if (cable && cable->identity) {
> +		const u32 id_header = cable->identity->id_header;
> +		const u32 speed = VDO_TYPEC_CABLE_SPEED(cable->identity->vdo[0]);
> +
> +		/*
> +		 * A cable lacking an ID Header indicates a non-e-marked cable,
> +		 * can only be guaranteed to have a USB 2.0 data path (D+ and D-).
> +		 */
> +		if (!id_header) {
> +			unsupported = true;
> +		} else {
> +			switch (PD_IDH_PTYPE(id_header)) {
> +			/*
> +			 * If the speed field explicitly declares it is a
> +			 * USB 2.0-only cable, altmode is unsupported.
> +			 */
> +			case IDH_PTYPE_PCABLE:
> +				unsupported = (speed == CABLE_USB2_ONLY);
> +				break;
> +			/*
> +			 * Active cables must establish an SOP' communication
> +			 * node. Since that check failed at the beginning of
> +			 * this function, this active cable does not support
> +			 * this specific altmode.
> +			 */
> +			case IDH_PTYPE_ACABLE:
> +				unsupported = true;
> +				break;
> +			}
> +		}
> +	}
> +	if (cable)
> +		typec_cable_put(cable);
> +
> +	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?

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);

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);
}

Thanks,

-- 
heikki

  reply	other threads:[~2026-06-22 10:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-22  9:39 [PATCH v2 0/3] Restrict alternate modes based on cable capabilities Andrei Kuchynski
2026-06-22  9:39 ` [PATCH v2 1/3] usb: typec: Add helper to check cable altmode support Andrei Kuchynski
2026-06-22 10:18   ` Heikki Krogerus [this message]
2026-06-22 12:03     ` Andrei Kuchynski
2026-06-23  8:30       ` Heikki Krogerus
2026-06-23 15:34         ` Andrei Kuchynski
2026-06-22  9:39 ` [PATCH v2 2/3] usb: typec: thunderbolt: Check " Andrei Kuchynski
2026-06-22  9:39 ` [PATCH v2 3/3] usb: typec: displayport: " Andrei Kuchynski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ajkMCz52lkq9hz3s@kuha \
    --to=heikki.krogerus@linux.intel.com \
    --cc=akuchynski@chromium.org \
    --cc=bleung@chromium.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jthies@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.