Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Christian Marangi" <ansuelsmth@gmail.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v14 02/12] net: phylink: introduce internal phylink PCS handling
Date: Fri, 14 Aug 2026 08:36:33 +0000	[thread overview]
Message-ID: <20260814083634.41B6C1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260813083536.970196-3-ansuelsmth@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] phylink_create() unconditionally expands the MAC's supported interfaces with all PCS-supported interfaces, enabling unsupported MAC hardware modes.
- [Medium] phylink_validate_mac_and_pcs() fails to reject interfaces that require a dedicated PCS when no matching PCS is found.
--

--- Patch [2]: [PATCH v14 02/12] net: phylink: introduce internal phylink PCS handling ---
commit 6086d011ffb72e143c6102bee959c780b432bd7a
Author: Christian Marangi <ansuelsmth@gmail.com>

net: phylink: introduce internal phylink PCS handling

This commit introduces internal handling of PCS for phylink by allowing
MACs to provide a list of available PCS via phylink_config. It parses
this array and links the PCS list to the phylink instance. phylink
validation and configuration functions are updated to use this PCS list
instead of relying exclusively on .mac_select_pcs.

> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index e1e9f07f51bc6..6204e3bba16d7 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c

[ ... ]

> @@ -530,9 +550,24 @@ static int phylink_validate_mac_and_pcs(struct phylink *pl,
>  		pcs = pl->mac_ops->mac_select_pcs(pl->config, state->interface);
>  		if (IS_ERR(pcs))
>  			return PTR_ERR(pcs);
> +
> +		pcs_found = !!pcs;
> +	/*
> +	 * Find a PCS in available PCS list for the requested interface.
> +	 *
> +	 * Skip searching if the MAC doesn't require a dedicated PCS for
> +	 * the requested interface.
> +	 */
> +	} else if (test_bit(state->interface, pl->config->pcs_interfaces)) {
> +		list_for_each_entry(pcs, &pl->pcs_list, list) {
> +			if (!phylink_validate_pcs_interface(pcs, state->interface)) {
> +				pcs_found = true;
> +				break;
> +			}
> +		}
>  	}
>  
> -	if (pcs) {
> +	if (pcs_found) {

[Severity: Medium]
Should there be an explicit error return here if a dedicated PCS is
required but none is found?

If pcs_found remains false after the loop in phylink_validate_mac_and_pcs(),
the code skips the validation block without returning -EINVAL.

This allows the unsupported mode to pass MAC validation, which later fails
during phylink_major_config().

[ ... ]

> @@ -1908,16 +2028,31 @@ struct phylink *phylink_create(struct phylink_config *config,
>  	__set_bit(PHYLINK_DISABLE_STOPPED, &pl->phylink_disable_state);
>  	timer_setup(&pl->link_poll, phylink_fixed_poll, 0);
>  
> +	/* Fill the PCS list with available PCS from phylink config */
> +	ret = phylink_fill_available_pcs(pl, config);
> +	if (ret < 0)
> +		goto free_pl;
> +
> +	/* Link available PCS to phylink */
> +	list_for_each_entry(pcs, &pl->pcs_list, list)
> +		pcs->phylink = pl;
> +
>  	phy_interface_copy(pl->supported_interfaces,
>  			   pl->config->supported_interfaces);
>  
> +	/* Update supported interfaces */
> +	list_for_each_entry(pcs, &pl->pcs_list, list)
> +		phy_interface_or(pl->supported_interfaces,
> +				 pl->supported_interfaces,
> +				 pcs->supported_interfaces);
> +

[Severity: High]
Does this bitwise OR operation inadvertently expand the system's supported
interfaces beyond the MAC's physical capabilities?

By injecting all PCS-supported interfaces into pl->supported_interfaces,
generic PCS modules might expose high-speed modes that the attached MAC
does not actually support. Could this lead to the MAC driver receiving
configuration requests for unhandled interface types?

A similar capability expansion also appears to happen dynamically in
pcs_provider_notify() when a PCS provider is added:

    /* Refresh supported interfaces */
    phy_interface_copy(pl->supported_interfaces,
               pl->config->supported_interfaces);
    list_for_each_entry(pcs, &pl->pcs_list, list)
        phy_interface_or(pl->supported_interfaces,
                 pl->supported_interfaces,
                 pcs->supported_interfaces);

Is this intended?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813083536.970196-1-ansuelsmth@gmail.com?part=2

  reply	other threads:[~2026-08-14  8:36 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-13  8:35 [PATCH v14 00/12] net: pcs: Introduce support for fwnode PCS Christian Marangi
2026-08-13  8:35 ` [PATCH v14 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct Christian Marangi
2026-08-13  8:35 ` [PATCH v14 02/12] net: phylink: introduce internal phylink PCS handling Christian Marangi
2026-08-14  8:36   ` sashiko-bot [this message]
2026-08-13  8:35 ` [PATCH v14 03/12] net: pcs: implement Firmware node support for PCS driver Christian Marangi
2026-08-14  8:36   ` sashiko-bot
2026-08-13  8:35 ` [PATCH v14 04/12] net: phylink: save phylink instance fwnode on phylink_create Christian Marangi
2026-08-13  8:35 ` [PATCH v14 05/12] net: phylink: support PCS provider release Christian Marangi
2026-08-14  8:36   ` sashiko-bot
2026-08-13  8:35 ` [PATCH v14 06/12] net: phylink: support late PCS provider attach Christian Marangi
2026-08-14  8:36   ` sashiko-bot
2026-08-13  8:35 ` [PATCH v14 07/12] net: Document PCS subsystem Christian Marangi
2026-08-13  8:35 ` [PATCH v14 08/12] MAINTAINERS: add myself as PCS subsystem maintainer Christian Marangi
2026-08-13  8:35 ` [PATCH v14 09/12] net: phylink: add .pcs_link_down PCS OP Christian Marangi
2026-08-13  8:35 ` [PATCH v14 10/12] dt-bindings: net: pcs: Document support for Airoha Ethernet PCS Christian Marangi
2026-08-13  8:35 ` [PATCH v14 11/12] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC Christian Marangi
2026-08-14  8:36   ` sashiko-bot
2026-08-13  8:35 ` [PATCH v14 12/12] net: airoha: add phylink support Christian Marangi
2026-08-14  8:36   ` sashiko-bot

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=20260814083634.41B6C1F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ansuelsmth@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox