From: sashiko-bot@kernel.org
To: "Bartosz Golaszewski" <bartosz.golaszewski@oss.qualcomm.com>
Cc: mfd@lists.linux.dev, Frank.Li@kernel.org, imx@lists.linux.dev,
lee@kernel.org
Subject: Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()
Date: Tue, 21 Jul 2026 09:26:06 +0000 [thread overview]
Message-ID: <20260721092606.B4B1D1F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-7-2dee93f42c54@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] The driver permanently leaks dynamically allocated platform devices, their resources, platform data, and fwnode references during teardown.
- [High] DMA mappings are leaked and the TX ring state becomes corrupted if descriptor mapping fails during TSO processing.
--
--- Patch [7]: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode() ---
commit d4dc0688026958e8569e1e6212a8ec7a37b4fb45
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
net: mv643xx: use platform_device_set_fwnode()
Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 9caa1e47c174c..2f2d6cce8d852 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
[ ... ]
While reviewing this patch, I noticed a couple of pre-existing regressions in
this file:
> static int txq_submit_tso(struct tx_queue *txq, struct sk_buff *skb,
> struct net_device *dev)
> {
[ ... ]
> /* clear TX_END status */
> mp->work_tx_end &= ~(1 << txq->index);
>
> /* ensure all descriptors are written before poking hardware */
> wmb();
> txq_enable(txq);
> txq->tx_desc_count += desc_count;
> return 0;
> err_release:
> /* TODO: Release all used data descriptors; header descriptors must not
> * be DMA-unmapped.
> */
> return ret;
> }
[Severity: High]
This is a pre-existing issue, but does this err_release path leak DMA memory
mappings and permanently corrupt the transmit ring state?
If txq_put_data_tso() fails (e.g., due to a dma_map_single() failure), the
code jumps to err_release and returns the error without rolling back already
configured descriptors.
Since txq->tx_desc_count is not incremented for the already processed
descriptors, the subsequent txq_reclaim() loop will never clean them up. The
txq->tx_curr_desc index has already advanced, which seems like it would cause
the ring pointers to lose synchronization.
[ ... ]
> static void mv643xx_eth_shared_of_remove(struct platform_device *pdev)
> {
> struct mv643xx_eth_platform_data *pd;
> int n;
>
> for (n = 0; n < 3; n++) {
> if (!port_platdev[n])
> continue;
> pd = dev_get_platdata(&port_platdev[n]->dev);
> if (pd)
> of_node_put(pd->phy_node);
> platform_device_del(port_platdev[n]);
> port_platdev[n] = NULL;
> }
> }
[Severity: High]
This isn't a bug introduced by this patch, but does this loop permanently leak
dynamically allocated platform devices and their resources?
The code calls platform_device_del() to remove the device from the hierarchy,
but it appears to be missing a call to platform_device_put() to drop the
initial reference count.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=7
next prev parent reply other threads:[~2026-07-21 9:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-20 9:24 [PATCH 0/8] driver core: prefer platform_device_set_fwnode() Bartosz Golaszewski
2026-07-20 9:24 ` [PATCH 1/8] powerpc/powermac: use platform_device_set_fwnode() Bartosz Golaszewski
2026-07-21 9:25 ` sashiko-bot
2026-07-20 9:24 ` [PATCH 2/8] i2c: pxa-pci: " Bartosz Golaszewski
2026-07-20 9:41 ` Wolfram Sang
2026-07-21 9:26 ` sashiko-bot
2026-07-20 9:24 ` [PATCH 3/8] iommu/fsl: " Bartosz Golaszewski
2026-07-20 12:58 ` Robin Murphy
2026-07-20 13:39 ` Bartosz Golaszewski
2026-07-20 14:34 ` Robin Murphy
2026-07-20 14:34 ` Frank Li
2026-07-21 9:26 ` sashiko-bot
2026-07-20 9:24 ` [PATCH 4/8] net: bcmgenet: " Bartosz Golaszewski
2026-07-20 14:38 ` Andrew Lunn
2026-07-20 16:57 ` Florian Fainelli
2026-07-21 9:26 ` sashiko-bot
2026-07-20 9:24 ` [PATCH 5/8] pmdomain: imx: " Bartosz Golaszewski
2026-07-20 14:34 ` Frank Li
2026-07-21 9:26 ` sashiko-bot
2026-07-20 9:24 ` [PATCH 6/8] mfd: tps6586: " Bartosz Golaszewski
2026-07-21 9:26 ` sashiko-bot
2026-07-20 9:24 ` [PATCH 7/8] net: mv643xx: " Bartosz Golaszewski
2026-07-20 14:43 ` Andrew Lunn
2026-07-20 16:01 ` Bartosz Golaszewski
2026-07-20 18:28 ` Andrew Lunn
2026-07-21 7:57 ` Bartosz Golaszewski
2026-07-21 9:26 ` sashiko-bot [this message]
2026-07-20 9:24 ` [PATCH 8/8] slimbus: qcom-ngd-ctrl: " Bartosz Golaszewski
2026-07-21 9:26 ` 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=20260721092606.B4B1D1F00A3A@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Frank.Li@kernel.org \
--cc=bartosz.golaszewski@oss.qualcomm.com \
--cc=imx@lists.linux.dev \
--cc=lee@kernel.org \
--cc=mfd@lists.linux.dev \
--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