From: sashiko-bot@kernel.org
To: "Christian Marangi" <ansuelsmth@gmail.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH net-next v6 12/12] net: airoha: add phylink support
Date: Wed, 10 Jun 2026 16:16:28 +0000 [thread overview]
Message-ID: <20260610161629.3B72E1F00893@smtp.kernel.org> (raw)
In-Reply-To: <20260609151212.29469-13-ansuelsmth@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Calling `phylink_destroy()` before `unregister_netdev()` causes a Use-After-Free during device teardown.
- [High] Unconditional PCS parsing in `airoha_setup_phylink()` causes probe failure for the GDM1 port.
- [Medium] The RX fragment size is incorrectly configured using the TX fragment size variable due to a copy-paste error.
- [Medium] The `phylink` instance is leaked in the `airoha_probe()` error path for successfully allocated but unregistered devices.
--
commit 7158f1ddaf486067bb751bd3d43f1a8bfc87794f
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.
These needs to be defined in the GDM port node using the pcs-handle
property.
[ ... ]
> @@ -3148,6 +3161,153 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
> return false;
> }
>
> +/* Nothing to do in MAC, everything is handled in PCS */
> +static void airoha_mac_config(struct phylink_config *config, unsigned int mode,
> + const struct phylink_link_state *state)
> +{
> +}
> +
> +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)
> +{
[ ... ]
> + if (dev->nbq == 1) {
> + mask = GDMA4_SGMII1_RX_FRAG_SIZE_MASK;
> + val = FIELD_PREP(GDMA4_SGMII1_RX_FRAG_SIZE_MASK,
> + frag_size_tx);
> + } else {
> + mask = GDMA4_SGMII0_RX_FRAG_SIZE_MASK;
> + val = FIELD_PREP(GDMA4_SGMII0_RX_FRAG_SIZE_MASK,
> + frag_size_tx);
> + }
[Severity: Medium]
Should this use frag_size_rx instead of frag_size_tx when configuring the
RX fragment size? This looks like a typo that could cause the hardware to be
configured incorrectly when the RX and TX fragment sizes differ.
> + airoha_fe_rmw(eth, REG_GDMA4_RMBI_FRAG, mask, val);
> +}
[ ... ]
> +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;
> + }
> +
> + config = &dev->phylink_config;
> +
> + config->dev = &netdev->dev;
> + config->type = PHYLINK_NETDEV;
> + config->mac_capabilities = MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_10000FD;
> + if (port->id > AIROHA_GDM1_IDX)
> + config->mac_capabilities |= MAC_10 | MAC_100 | MAC_1000 |
> + MAC_2500FD | MAC_5000FD;
> +
> + err = fwnode_phylink_pcs_parse(dev_fwnode(&netdev->dev), NULL,
> + &config->num_available_pcs);
> + if (err)
> + return err;
[Severity: High]
Does this unconditional call to fwnode_phylink_pcs_parse() cause probe to
fail for the GDM1 port?
The commit message mentions that GDM1 does not require a PCS. If its device
tree node lacks a pcs-handle property, fwnode_phylink_pcs_parse() will return
-ENODEV and abort the probe. Should this parsing logic be conditionally
skipped if port->id == AIROHA_GDM1_IDX?
> +
> + config->fill_available_pcs = airoha_fill_available_pcs;
> +
> + /*
> + * GDM1 only supports internal for Embedded Switch
> + * and doesn't require a PCS.
> + */
[ ... ]
> @@ -3435,8 +3595,10 @@ static int airoha_probe(struct platform_device *pdev)
> continue;
>
> netdev = netdev_from_priv(dev);
> - if (netdev->reg_state == NETREG_REGISTERED)
> + if (netdev->reg_state == NETREG_REGISTERED) {
> + phylink_destroy(dev->phylink);
> unregister_netdev(netdev);
> + }
[Severity: Medium]
Does this leak the phylink instance for devices that were successfully
allocated but failed to register?
In airoha_alloc_gdm_device(), the phylink structure is successfully allocated
prior to device registration. If airoha_probe() fails before or during device
registration, the NETREG_REGISTERED check here skips calling
phylink_destroy() for unregistered devices, which would leave the memory
leaked.
[Severity: High]
Is it safe to destroy the phylink instance before calling
unregister_netdev()?
If the network interface is running (IFF_UP), unregister_netdev() will
synchronously bring the device down by invoking its ndo_stop callback, which
is airoha_dev_stop().
Inside airoha_dev_stop(), the driver attempts to halt phylink:
phylink_stop(dev->phylink);
phylink_disconnect_phy(dev->phylink);
Will this result in a use-after-free since dev->phylink was already destroyed
here?
> of_node_put(netdev->dev.of_node);
> }
> airoha_metadata_dst_free(port);
[ ... ]
> @@ -3472,6 +3634,7 @@ static void airoha_remove(struct platform_device *pdev)
> continue;
>
> netdev = netdev_from_priv(dev);
> + phylink_destroy(dev->phylink);
> unregister_netdev(netdev);
[Severity: High]
Similarly to the error path in airoha_probe(), does destroying the phylink
instance before calling unregister_netdev() cause a use-after-free when
airoha_dev_stop() tries to use dev->phylink?
> of_node_put(netdev->dev.of_node);
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260609151212.29469-1-ansuelsmth@gmail.com?part=12
prev parent reply other threads:[~2026-06-10 16:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-09 15:11 [PATCH net-next v6 00/12] net: pcs: Introduce support for fwnode PCS Christian Marangi
2026-06-09 15:11 ` [PATCH net-next v6 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:11 ` [PATCH net-next v6 02/12] net: phylink: introduce internal phylink PCS handling Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:11 ` [PATCH net-next v6 03/12] net: phylink: add phylink_release_pcs() to externally release a PCS Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:12 ` [PATCH net-next v6 04/12] net: pcs: implement Firmware node support for PCS driver Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:12 ` [PATCH net-next v6 05/12] net: phylink: support late PCS provider attach Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:12 ` [PATCH net-next v6 06/12] net: Document PCS subsystem Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:12 ` [PATCH net-next v6 07/12] MAINTAINERS: add myself as PCS subsystem maintainer Christian Marangi
2026-06-09 15:12 ` [PATCH net-next v6 08/12] of: property: fw_devlink: Add support for "pcs-handle" Christian Marangi
2026-06-09 15:12 ` [PATCH net-next v6 09/12] net: phylink: add .pcs_link_down PCS OP Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:12 ` [PATCH net-next v6 10/12] dt-bindings: net: pcs: Document support for Airoha Ethernet PCS Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:12 ` [PATCH net-next v6 11/12] net: pcs: airoha: add PCS driver for Airoha AN7581 SoC Christian Marangi
2026-06-10 16:16 ` sashiko-bot
2026-06-09 15:12 ` [PATCH net-next v6 12/12] net: airoha: add phylink support Christian Marangi
2026-06-09 15:29 ` Lorenzo Bianconi
2026-06-09 23:51 ` Christian Marangi
2026-06-10 16:16 ` 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=20260610161629.3B72E1F00893@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.