All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Christian Marangi" <ansuelsmth@gmail.com>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v9 12/12] net: airoha: add phylink support
Date: Sat, 18 Jul 2026 09:01:21 +0000	[thread overview]
Message-ID: <20260718090121.79D3A1F00A3D@smtp.kernel.org> (raw)
In-Reply-To: <20260717065448.1498335-13-ansuelsmth@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Missing phy-mode property now unconditionally causes probe failure, breaking old device trees.

Pre-existing issues:
- [High] The spinlock `port->lock` is acquired using `spin_lock()` in process contexts without disabling softirqs, creating a deadlock risk if interrupted by a softirq calling `ndo_get_stats64`.
--

--- Patch [12]: [PATCH net-next v9 12/12] net: airoha: add phylink support ---
commit bb8a7d4b36e6cc8dd02385bcf6f62f3da412aa5a
Author: Christian Marangi <ansuelsmth@gmail.com>

net: airoha: add phylink support

Add phylink support for each GDM port. For GDM1 add the internal interface
mode as the only supported mode. For GDM2/3/4 add the required
configuration of the PCS to make the external PHY or attached SFP cage
work.

> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 59001fd4b6f74..ed1ac032f3374 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
[ ... ]
> @@ -1837,7 +1838,7 @@ static void airoha_update_hw_stats(struct airoha_gdm_dev *dev)
>  	struct airoha_gdm_port *port = dev->port;
>  	int i;
>  
> -	spin_lock(&port->stats_lock);
> +	spin_lock(&port->lock);

[Severity: High]
This is a pre-existing issue, but using spin_lock() here without disabling
softirqs creates a deadlock risk.

This function is called from process context (like ethtool callbacks), but it
is also called by airoha_dev_get_stats64() which can run in softirq context.
If a softirq interrupts the process-context caller while it holds port->lock,
the softirq handler will attempt to acquire the same lock and spin forever.

Should all process-context acquisitions of this lock be updated to use
spin_lock_bh() instead?

[ ... ]
> +static void airoha_mac_link_up(struct phylink_config *config, struct phy_device *phy,
> +			       unsigned int mode, phy_interface_t interface,
> +			       int speed, int duplex, bool tx_pause, bool rx_pause)
> +{
> +	struct airoha_gdm_dev *dev = container_of(config, struct airoha_gdm_dev,
> +						  phylink_config);
> +	struct airoha_gdm_port *port = dev->port;
> +	struct airoha_eth *eth = dev->eth;
> +	u32 frag_size_tx, frag_size_rx;
> +	u32 mask, val;
> +
> +	/* TX/RX frag is configured only for GDM4 */
> +	if (port->id != AIROHA_GDM4_IDX)
> +		return;
[ ... ]
> +	spin_lock(&port->lock);
> +
> +	/* Configure TX/RX frag based on speed */

[Severity: High]
This is a pre-existing issue with the locking design, but since
airoha_mac_link_up() is a new process-context caller, using spin_lock() here
introduces a new instance of the deadlock surface mentioned above against
softirq callers like airoha_dev_get_stats64().

Should this be changed to spin_lock_bh() as well?

[ ... ]
> +static int airoha_setup_phylink(struct net_device *netdev)
> +{
> +	struct airoha_gdm_dev *dev = netdev_priv(netdev);
> +	struct device_node *np = netdev->dev.of_node;
> +	struct airoha_gdm_port *port = dev->port;
> +	struct phylink_config *config;
> +	phy_interface_t phy_mode;
> +	struct phylink *phylink;
> +	int err;
> +
> +	err = of_get_phy_mode(np, &phy_mode);
> +	if (err) {
> +		dev_err(&netdev->dev, "incorrect phy-mode\n");
> +		return err;
> +	}

[Severity: Medium]
Does this mandatory check break backwards compatibility with older device trees?

If a device tree is missing the phy-mode property, this will now unconditionally
fail the driver probe, whereas the previous driver version allowed successful
probe without it.

Is there a fallback mode we should apply here instead of returning the error?

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

      reply	other threads:[~2026-07-18  9:01 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17  6:54 [PATCH net-next v9 00/12] net: pcs: Introduce support for fwnode PCS Christian Marangi
2026-07-17  6:54 ` [PATCH net-next v9 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 02/12] net: phylink: introduce internal phylink PCS handling Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 03/12] net: phylink: add phylink_release_pcs() to externally release a PCS Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 04/12] net: pcs: implement Firmware node support for PCS driver Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 05/12] net: phylink: support late PCS provider attach Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 06/12] net: Document PCS subsystem Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 07/12] MAINTAINERS: add myself as PCS subsystem maintainer Christian Marangi
2026-07-17  6:54 ` [PATCH net-next v9 08/12] of: property: fw_devlink: Add support for "pcs-handle" Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 09/12] net: phylink: add .pcs_link_down PCS OP Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 10/12] dt-bindings: net: pcs: Document support for Airoha Ethernet PCS Christian Marangi
2026-07-17  6:54 ` [PATCH net-next v9 11/12] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC Christian Marangi
2026-07-18  9:01   ` sashiko-bot
2026-07-17  6:54 ` [PATCH net-next v9 12/12] net: airoha: add phylink support Christian Marangi
2026-07-18  9:01   ` sashiko-bot [this message]

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=20260718090121.79D3A1F00A3D@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 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.