[PATCH 0/8] driver core: prefer platform_device_set_fwnode()

[PATCH 0/8] driver core: prefer platform_device_set_fwnode()

[Bartosz Golaszewski]

With the final platform device and software node rework changes having
been queued in the driver core tree, Danilo pointed out that
platform_device_set_fwnode() is no longer used and should be removed. I
argued that instead we should prefer it over the OF-specific
platform_device_set_of_node().

This series converts drivers using platform_device_set_of_node() to
platform_device_set_fwnode() and does not intend any functional change
as the semantics of:

  platform_device_set_of_node(pdev, np);

should be equal to those of:

  platform_device_set_fwnode(pdev, of_fwnode_handle(np));

The prerequisite changes are currently in the driver core tree so this
entire series should follow them as well with Acks from maintainers. If
it doesn't make v7.3 for some reason, then I will resend these next
cycle separately targetting individual trees.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Bartosz Golaszewski (8):
      powerpc/powermac: use platform_device_set_fwnode()
      i2c: pxa-pci: use platform_device_set_fwnode()
      iommu/fsl: use platform_device_set_fwnode()
      net: bcmgenet: use platform_device_set_fwnode()
      pmdomain: imx: use platform_device_set_fwnode()
      mfd: tps6586: use platform_device_set_fwnode()
      net: mv643xx: use platform_device_set_fwnode()
      slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode()

 arch/powerpc/platforms/powermac/low_i2c.c    | 2 +-
 drivers/i2c/busses/i2c-pxa-pci.c             | 2 +-
 drivers/iommu/fsl_pamu.c                     | 2 +-
 drivers/mfd/tps6586x.c                       | 2 +-
 drivers/net/ethernet/broadcom/genet/bcmmii.c | 3 ++-
 drivers/net/ethernet/marvell/mv643xx_eth.c   | 2 +-
 drivers/pmdomain/imx/gpc.c                   | 2 +-
 drivers/slimbus/qcom-ngd-ctrl.c              | 2 +-
 8 files changed, 9 insertions(+), 8 deletions(-)
---
base-commit: 27edebd505791748a77703e311d76f0f55a8d7ec
change-id: 20260720-pdev-set-fwnode-instead-of-of-node-e83ece371509

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

[PATCH 1/8] powerpc/powermac: use platform_device_set_fwnode()

[Bartosz Golaszewski]

Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 arch/powerpc/platforms/powermac/low_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
index a175a32a222bab4cc7400f6ab6071f5630db2cb8..eda35534cfd72e828616f27b5f8319189d68285e 100644
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -1471,7 +1471,7 @@ static int __init pmac_i2c_create_platform_devices(void)
 		if (bus->platform_dev == NULL)
 			return -ENOMEM;
 		bus->platform_dev->dev.platform_data = bus;
-		platform_device_set_of_node(bus->platform_dev, bus->busnode);
+		platform_device_set_fwnode(bus->platform_dev, of_fwnode_handle(bus->busnode));
 		platform_device_add(bus->platform_dev);
 	}
 

-- 
2.47.3

[PATCH 2/8] i2c: pxa-pci: use platform_device_set_fwnode()

[Bartosz Golaszewski]

Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/i2c/busses/i2c-pxa-pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-pxa-pci.c b/drivers/i2c/busses/i2c-pxa-pci.c
index 92a0647f08c69f841ca99caca757c1728b3f6fce..58532cf9f06d43a0f2173b962eb498c9e4bb81d0 100644
--- a/drivers/i2c/busses/i2c-pxa-pci.c
+++ b/drivers/i2c/busses/i2c-pxa-pci.c
@@ -77,7 +77,7 @@ static struct platform_device *add_i2c_device(struct pci_dev *dev, int bar)
 	}
 	pdev->dev.parent = &dev->dev;
 
-	platform_device_set_of_node(pdev, child);
+	platform_device_set_fwnode(pdev, of_fwnode_handle(child));
 
 	ret = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
 	if (ret)

-- 
2.47.3

[PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()

[Bartosz Golaszewski]

Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/iommu/fsl_pamu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index c83bbc3faad56d6ee1c89b0a7f74028af02c81e9..268a1f752fbceab4fd24013aeea5df1b6982fbb1 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -975,7 +975,7 @@ static __init int fsl_pamu_init(void)
 		goto error_device_alloc;
 	}
 
-	platform_device_set_of_node(pdev, np);
+	platform_device_set_fwnode(pdev, of_fwnode_handle(np));
 
 	ret = pamu_domain_init();
 	if (ret)

-- 
2.47.3

[PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()

[Bartosz Golaszewski]

Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/net/ethernet/broadcom/genet/bcmmii.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
index 0f0dbabfaabbce3469de79af91d7731b8476709f..6f471723bd53f454e4b0de1716977b4382013429 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
@@ -492,7 +492,8 @@ static int bcmgenet_mii_register(struct bcmgenet_priv *priv)
 	ppdev->dev.parent = &pdev->dev;
 
 	if (dn)
-		platform_device_set_of_node(ppdev, bcmgenet_mii_of_find_mdio(priv));
+		platform_device_set_fwnode(ppdev,
+					   of_fwnode_handle(bcmgenet_mii_of_find_mdio(priv)));
 	else
 		ppd.phy_mask = ~0;
 

-- 
2.47.3

[PATCH 5/8] pmdomain: imx: use platform_device_set_fwnode()

[Bartosz Golaszewski]

Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/pmdomain/imx/gpc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c
index abca5f449a226fbae4213926e1395c413160c950..c147eaf048ba2b79a744ec87029420981581e48e 100644
--- a/drivers/pmdomain/imx/gpc.c
+++ b/drivers/pmdomain/imx/gpc.c
@@ -487,7 +487,7 @@ static int imx_gpc_probe(struct platform_device *pdev)
 			domain->ipg_rate_mhz = ipg_rate_mhz;
 
 			pd_pdev->dev.parent = &pdev->dev;
-			platform_device_set_of_node(pd_pdev, np);
+			platform_device_set_fwnode(pd_pdev, of_fwnode_handle(np));
 
 			ret = platform_device_add(pd_pdev);
 			if (ret) {

-- 
2.47.3

[PATCH 6/8] mfd: tps6586: use platform_device_set_fwnode()

[Bartosz Golaszewski]

Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/mfd/tps6586x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index 3cfd2f02b62f3cc370e0d970ec2643b638fd0fec..fc7c4b55c385416741925904abae4fd240f55b13 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -397,7 +397,7 @@ static int tps6586x_add_subdevs(struct tps6586x *tps6586x,
 
 		pdev->dev.parent = tps6586x->dev;
 		pdev->dev.platform_data = subdev->platform_data;
-		platform_device_set_of_node(pdev, subdev->of_node);
+		platform_device_set_fwnode(pdev, of_fwnode_handle(subdev->of_node));
 
 		ret = platform_device_add(pdev);
 		if (ret) {

-- 
2.47.3

[PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()

[Bartosz Golaszewski]

Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
 		goto put_err;
 	}
 	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
-	platform_device_set_of_node(ppdev, pnp);
+	platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));
 
 	ret = platform_device_add_resources(ppdev, &res, 1);
 	if (ret)

-- 
2.47.3

[PATCH 8/8] slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode()

[Bartosz Golaszewski]

Prefer the higher-level platform_device_set_fwnode() over the
OF-specific platform_device_set_of_node() for dynamically allocated
platform devices.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
 drivers/slimbus/qcom-ngd-ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index 934c44c5bc1a92fae98f52bccd12ed849379dca8..bf077f47c9ddd484c11f98b47d2d8d4daf78dcb7 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -1538,7 +1538,7 @@ static int of_qcom_slim_ngd_register(struct device *parent,
 			kfree(ngd);
 			return ret;
 		}
-		platform_device_set_of_node(ngd->pdev, node);
+		platform_device_set_fwnode(ngd->pdev, of_fwnode_handle(node));
 		ctrl->ngd = ngd;
 
 		ret = platform_device_add(ngd->pdev);

-- 
2.47.3

Re: [PATCH 2/8] i2c: pxa-pci: use platform_device_set_fwnode()

[Wolfram Sang]

On Mon, Jul 20, 2026 at 11:24:49AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Fine with me.

Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>

Note that we still need Andi's ack.

Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()

[Robin Murphy]

On 20/07/2026 10:24 am, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.

This is very much non-portable code specific to OF-only platforms, but 
if the intention is to remove platform_device_set_of_node() again 
already, then FWIW,

Acked-by: Robin Murphy <robin.murphy@arm.com>

(Although I'm slightly puzzled by the cover letter - AFAICS in -next, 
platform_device_set_of_node() is itself very much a user of 
platform_device_set_fwnode(), however in terms of symbol exports, 
perhaps the former could now just be a static inline wrapper?)

> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>   drivers/iommu/fsl_pamu.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index c83bbc3faad56d6ee1c89b0a7f74028af02c81e9..268a1f752fbceab4fd24013aeea5df1b6982fbb1 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -975,7 +975,7 @@ static __init int fsl_pamu_init(void)
>   		goto error_device_alloc;
>   	}
>   
> -	platform_device_set_of_node(pdev, np);
> +	platform_device_set_fwnode(pdev, of_fwnode_handle(np));
>   
>   	ret = pamu_domain_init();
>   	if (ret)
> 

Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()

[Bartosz Golaszewski]

On Mon, 20 Jul 2026 14:58:27 +0200, Robin Murphy <robin.murphy@arm.com> said:
> On 20/07/2026 10:24 am, Bartosz Golaszewski wrote:
>> Prefer the higher-level platform_device_set_fwnode() over the
>> OF-specific platform_device_set_of_node() for dynamically allocated
>> platform devices.
>
> This is very much non-portable code specific to OF-only platforms, but
> if the intention is to remove platform_device_set_of_node() again
> already, then FWIW,
>

Providing platform_device_set_of_node() and using it was done to make the
transision to expanding reference counting to all firmware nodes possible.
I don't think we'll remove it just yet as it doesn't make sense to convert
the code under drivers/of/ to using the fwnode variant.

> Acked-by: Robin Murphy <robin.murphy@arm.com>
>
> (Although I'm slightly puzzled by the cover letter - AFAICS in -next,
> platform_device_set_of_node() is itself very much a user of
> platform_device_set_fwnode(), however in terms of symbol exports,
> perhaps the former could now just be a static inline wrapper?)
>

Sure that can be done independently later.

Bart

Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()

[Frank Li]

On Mon, Jul 20, 2026 at 11:24:50AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  drivers/iommu/fsl_pamu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index c83bbc3faad56d6ee1c89b0a7f74028af02c81e9..268a1f752fbceab4fd24013aeea5df1b6982fbb1 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -975,7 +975,7 @@ static __init int fsl_pamu_init(void)
>  		goto error_device_alloc;
>  	}
>
> -	platform_device_set_of_node(pdev, np);
> +	platform_device_set_fwnode(pdev, of_fwnode_handle(np));
>
>  	ret = pamu_domain_init();
>  	if (ret)
>
> --
> 2.47.3
>
>

Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()

[Robin Murphy]

On 20/07/2026 2:39 pm, Bartosz Golaszewski wrote:
> On Mon, 20 Jul 2026 14:58:27 +0200, Robin Murphy <robin.murphy@arm.com> said:
>> On 20/07/2026 10:24 am, Bartosz Golaszewski wrote:
>>> Prefer the higher-level platform_device_set_fwnode() over the
>>> OF-specific platform_device_set_of_node() for dynamically allocated
>>> platform devices.
>>
>> This is very much non-portable code specific to OF-only platforms, but
>> if the intention is to remove platform_device_set_of_node() again
>> already, then FWIW,
>>
> 
> Providing platform_device_set_of_node() and using it was done to make the
> transision to expanding reference counting to all firmware nodes possible.
> I don't think we'll remove it just yet as it doesn't make sense to convert
> the code under drivers/of/ to using the fwnode variant.

OK, but in that case why convert these users either? If the OF helper 
does continue to exist then I'd imagine the static checker brigade will 
eventually end up sending patches to "simplify" these open-coded 
equivalents back to using it. And frankly, if drivers do know for sure 
they're exclusively dealing with of_nodes, rather than doing something 
conditional under an is_of_node() check, then I see little justification 
for them *not* using the dedicated helper.

If the complaint is that there are no *public* users to justify 
exporting platform_device_set_fwnode(), then as I say AFAICS that's much 
more neatly addressed with the static inline approach, such that we 
still get to unify the public APIs, actively eliminate something from 
the symbol table and save a bit of source and object code, but without 
any need to churn the truly OF-based callers at all.

Thanks,
Robin.

> 
>> Acked-by: Robin Murphy <robin.murphy@arm.com>
>>
>> (Although I'm slightly puzzled by the cover letter - AFAICS in -next,
>> platform_device_set_of_node() is itself very much a user of
>> platform_device_set_fwnode(), however in terms of symbol exports,
>> perhaps the former could now just be a static inline wrapper?)
>>
> 
> Sure that can be done independently later.
> 
> Bart

Re: [PATCH 5/8] pmdomain: imx: use platform_device_set_fwnode()

[Frank Li]

On Mon, Jul 20, 2026 at 11:24:52AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>  drivers/pmdomain/imx/gpc.c | 2 +-

Reviewed-by: Frank Li <Frank.Li@nxp.com>

>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c
> index abca5f449a226fbae4213926e1395c413160c950..c147eaf048ba2b79a744ec87029420981581e48e 100644
> --- a/drivers/pmdomain/imx/gpc.c
> +++ b/drivers/pmdomain/imx/gpc.c
> @@ -487,7 +487,7 @@ static int imx_gpc_probe(struct platform_device *pdev)
>  			domain->ipg_rate_mhz = ipg_rate_mhz;
>
>  			pd_pdev->dev.parent = &pdev->dev;
> -			platform_device_set_of_node(pd_pdev, np);
> +			platform_device_set_fwnode(pd_pdev, of_fwnode_handle(np));
>
>  			ret = platform_device_add(pd_pdev);
>  			if (ret) {
>
> --
> 2.47.3
>
>

Re: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()

[Andrew Lunn]

On Mon, Jul 20, 2026 at 11:24:51AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.

Why?

This driver is OF only. It does not support ACPI, and probably never
will. In general, networking and ACPI don't go together, ACPI is not
sufficiently advanced.

What is you use case here?

	Andrew

Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()

[Andrew Lunn]

On Mon, Jul 20, 2026 at 11:24:54AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
>  drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>  		goto put_err;
>  	}
>  	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> -	platform_device_set_of_node(ppdev, pnp);
> +	platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));

This is definitely an OF only driver. There are no other calls to
fwnode functions in this driver, so this is the wrong thing to do.

Sorry, NACK.

       Andrew

Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()

[Bartosz Golaszewski]

On Mon, 20 Jul 2026 16:43:40 +0200, Andrew Lunn <andrew@lunn.ch> said:
> On Mon, Jul 20, 2026 at 11:24:54AM +0200, Bartosz Golaszewski wrote:
>> Prefer the higher-level platform_device_set_fwnode() over the
>> OF-specific platform_device_set_of_node() for dynamically allocated
>> platform devices.
>>
>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> ---
>>  drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
>> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> @@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>>  		goto put_err;
>>  	}
>>  	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> -	platform_device_set_of_node(ppdev, pnp);
>> +	platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));
>
> This is definitely an OF only driver. There are no other calls to
> fwnode functions in this driver, so this is the wrong thing to do.
>
> Sorry, NACK.
>

I'm not going to die on this hill but drivers are OF-only until they're not.
For example, Qualcomm is now working on a hybrid ACPI-OF approach for
laptops[1] and we may end up needing to start converting drivers to fwnode
after all.

There's no real benefit to sticking to OF-specific APIs unless you need to
iterate over all properties of a node or use some other functionality not
available in fwnode. The overhead is minimal and it's never a hot path.

Thanks,
Bartosz

[1] https://lore.kernel.org/all/20260623145225.143218-1-johannes.goede@oss.qualcomm.com/

Re: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On 7/20/26 07:38, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 11:24:51AM +0200, Bartosz Golaszewski wrote:
>> Prefer the higher-level platform_device_set_fwnode() over the
>> OF-specific platform_device_set_of_node() for dynamically allocated
>> platform devices.
> 
> Why?
> 
> This driver is OF only. It does not support ACPI, and probably never
> will. In general, networking and ACPI don't go together, ACPI is not
> sufficiently advanced.
> 
> What is you use case here?

The driver has been, or was used on ACPI-based platforms:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99c6b06a37d4cab118c45448fef9d28df62d35d8
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5485 bytes --]

Re: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On 7/20/26 07:38, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 11:24:51AM +0200, Bartosz Golaszewski wrote:
>> Prefer the higher-level platform_device_set_fwnode() over the
>> OF-specific platform_device_set_of_node() for dynamically allocated
>> platform devices.
> 
> Why?
> 
> This driver is OF only. It does not support ACPI, and probably never
> will. In general, networking and ACPI don't go together, ACPI is not
> sufficiently advanced.
> 
> What is you use case here?

The driver has been, or was used on ACPI-based platforms:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99c6b06a37d4cab118c45448fef9d28df62d35d8
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5485 bytes --]

Re: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On 7/20/26 07:38, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 11:24:51AM +0200, Bartosz Golaszewski wrote:
>> Prefer the higher-level platform_device_set_fwnode() over the
>> OF-specific platform_device_set_of_node() for dynamically allocated
>> platform devices.
> 
> Why?
> 
> This driver is OF only. It does not support ACPI, and probably never
> will. In general, networking and ACPI don't go together, ACPI is not
> sufficiently advanced.
> 
> What is you use case here?

The driver has been, or was used on ACPI-based platforms:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99c6b06a37d4cab118c45448fef9d28df62d35d8
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5485 bytes --]

Re: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On 7/20/26 07:38, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 11:24:51AM +0200, Bartosz Golaszewski wrote:
>> Prefer the higher-level platform_device_set_fwnode() over the
>> OF-specific platform_device_set_of_node() for dynamically allocated
>> platform devices.
> 
> Why?
> 
> This driver is OF only. It does not support ACPI, and probably never
> will. In general, networking and ACPI don't go together, ACPI is not
> sufficiently advanced.
> 
> What is you use case here?

The driver has been, or was used on ACPI-based platforms:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99c6b06a37d4cab118c45448fef9d28df62d35d8
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5485 bytes --]

Re: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()

[Florian Fainelli]

[-- Attachment #1: Type: text/plain, Size: 668 bytes --]

On 7/20/26 07:38, Andrew Lunn wrote:
> On Mon, Jul 20, 2026 at 11:24:51AM +0200, Bartosz Golaszewski wrote:
>> Prefer the higher-level platform_device_set_fwnode() over the
>> OF-specific platform_device_set_of_node() for dynamically allocated
>> platform devices.
> 
> Why?
> 
> This driver is OF only. It does not support ACPI, and probably never
> will. In general, networking and ACPI don't go together, ACPI is not
> sufficiently advanced.
> 
> What is you use case here?

The driver has been, or was used on ACPI-based platforms:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=99c6b06a37d4cab118c45448fef9d28df62d35d8
-- 
Florian

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5485 bytes --]

Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()

[Andrew Lunn]

On Mon, Jul 20, 2026 at 06:01:37PM +0200, Bartosz Golaszewski wrote:
> On Mon, 20 Jul 2026 16:43:40 +0200, Andrew Lunn <andrew@lunn.ch> said:
> > On Mon, Jul 20, 2026 at 11:24:54AM +0200, Bartosz Golaszewski wrote:
> >> Prefer the higher-level platform_device_set_fwnode() over the
> >> OF-specific platform_device_set_of_node() for dynamically allocated
> >> platform devices.
> >>
> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> >> ---
> >>  drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> >> index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
> >> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> >> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> >> @@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
> >>  		goto put_err;
> >>  	}
> >>  	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> >> -	platform_device_set_of_node(ppdev, pnp);
> >> +	platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));
> >
> > This is definitely an OF only driver. There are no other calls to
> > fwnode functions in this driver, so this is the wrong thing to do.
> >
> > Sorry, NACK.
> >
> 
> I'm not going to die on this hill but drivers are OF-only until they're not.
> For example, Qualcomm is now working on a hybrid ACPI-OF approach for
> laptops[1] and we may end up needing to start converting drivers to fwnode
> after all.
> 
> There's no real benefit to sticking to OF-specific APIs unless you need to
> iterate over all properties of a node or use some other functionality not
> available in fwnode. The overhead is minimal and it's never a hot path.

There is a lot of benefit to sticking to OF specific APIs, because
within the kernel OF is well maintained, has active maintainers, there
are tools to validate bindings, etc. ACPI is a Wild West, each driver
is a snow flake, there is no review, no binding documentation, no
validation tools etc.

I hope you allow plenty of time to convert any networking drivers,
where Linux is driving the hardware, to ACPI. Your first stop will be
the UEFI forum making a proposal for MDIO busses, because that
currently is not part of ACPI. You will then need to spend time
understanding the DT bindings, and figuring out which properties are
deprecated so need to stay OF only, and which can be converted to dual
OF/ACPI. I've seen too many naive attempts which blindly convert
everything, copying all the past errors in the DT binding into the
brand new ACPI binding. That will get NACKed.

OF != ACPI

	Andrew

Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()

[Bartosz Golaszewski]

On Mon, 20 Jul 2026 20:28:39 +0200, Andrew Lunn <andrew@lunn.ch> said:
> On Mon, Jul 20, 2026 at 06:01:37PM +0200, Bartosz Golaszewski wrote:
>> On Mon, 20 Jul 2026 16:43:40 +0200, Andrew Lunn <andrew@lunn.ch> said:
>> > On Mon, Jul 20, 2026 at 11:24:54AM +0200, Bartosz Golaszewski wrote:
>> >> Prefer the higher-level platform_device_set_fwnode() over the
>> >> OF-specific platform_device_set_of_node() for dynamically allocated
>> >> platform devices.
>> >>
>> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> >> ---
>> >>  drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
>> >> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
>> >> @@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
>> >>  		goto put_err;
>> >>  	}
>> >>  	ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> >> -	platform_device_set_of_node(ppdev, pnp);
>> >> +	platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));
>> >
>> > This is definitely an OF only driver. There are no other calls to
>> > fwnode functions in this driver, so this is the wrong thing to do.
>> >
>> > Sorry, NACK.
>> >
>>
>> I'm not going to die on this hill but drivers are OF-only until they're not.
>> For example, Qualcomm is now working on a hybrid ACPI-OF approach for
>> laptops[1] and we may end up needing to start converting drivers to fwnode
>> after all.
>>
>> There's no real benefit to sticking to OF-specific APIs unless you need to
>> iterate over all properties of a node or use some other functionality not
>> available in fwnode. The overhead is minimal and it's never a hot path.
>
> There is a lot of benefit to sticking to OF specific APIs, because
> within the kernel OF is well maintained, has active maintainers, there
> are tools to validate bindings, etc. ACPI is a Wild West, each driver
> is a snow flake, there is no review, no binding documentation, no
> validation tools etc.
>
> I hope you allow plenty of time to convert any networking drivers,
> where Linux is driving the hardware, to ACPI. Your first stop will be
> the UEFI forum making a proposal for MDIO busses, because that
> currently is not part of ACPI. You will then need to spend time
> understanding the DT bindings, and figuring out which properties are
> deprecated so need to stay OF only, and which can be converted to dual
> OF/ACPI. I've seen too many naive attempts which blindly convert
> everything, copying all the past errors in the DT binding into the
> brand new ACPI binding. That will get NACKed.
>
> OF != ACPI
>

I've never said that and ACPI is actually irrelevant to this discussion. Fwnode
is the abstraction layer and OF happens to implement it. Unless you need
fine-grained control (only exposed by the lower-level abstraction) or
performance - neither of which is the case here - you should use the top-level
API. As I said: there's no good reason to stick to OF-specific interfaces for
drivers that don't really require it - and even then, we should strive to fill
the gaps in the fwnode API instead.

Bart

Re: [PATCH 1/8] powerpc/powermac: use platform_device_set_fwnode()

[sashiko-bot]

> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=1

Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()

[sashiko-bot]

> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=3

Re: [PATCH 2/8] i2c: pxa-pci: use platform_device_set_fwnode()

[sashiko-bot]

> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
> 
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=2

Re: [PATCH 6/8] mfd: tps6586: use platform_device_set_fwnode()

[sashiko-bot]

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

New issues:
- [Low] The commit message uses non-standard capitalization for the description, violating MFD subsystem prefix rules.

Pre-existing issues:
- [High] Manual assignment of `pdev->dev.platform_data` bypasses `platform_device_add_data()`, causing a bad free and kernel panic during device release.
--

--- Patch [6]: [PATCH 6/8] mfd: tps6586: use platform_device_set_fwnode() ---
commit 0c67148d3505d89af495783abc48f5f8ff3075d3
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

mfd: tps6586: use platform_device_set_fwnode()

This commit updates the tps6586 driver to prefer the higher-level
platform_device_set_fwnode() over the OF-specific
platform_device_set_of_node() for dynamically allocated platform devices.

> mfd: tps6586: use platform_device_set_fwnode()

[Severity: Low]
This isn't a bug, but should the description after the subsystem prefix
be capitalized?

The MFD subsystem guidelines dictate always capitalizing the description
after the subsystem prefix for MFD, LED, and Backlight subsystems.

> diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
> --- a/drivers/mfd/tps6586x.c
> +++ b/drivers/mfd/tps6586x.c

[ ... ]

> @@ -397,7 +397,7 @@ static int tps6586x_add_subdevs(struct tps6586x *tps6586x,
>  
>  		pdev->dev.parent = tps6586x->dev;
>  		pdev->dev.platform_data = subdev->platform_data;

[Severity: High]
This is a pre-existing issue, but does assigning the platform_data pointer
directly like this cause a bad free and kernel panic during device release?

When platform_device_release() is called, either due to a failure in
platform_device_add() or when the device is unregistered later, it
unconditionally calls kfree() on the platform_data pointer.

Since subdev->platform_data is typically statically allocated by board files
rather than dynamically allocated by the platform bus, bypassing the proper
duplication handled by platform_device_add_data() can lead to a crash.

> -		platform_device_set_of_node(pdev, subdev->of_node);
> +		platform_device_set_fwnode(pdev, of_fwnode_handle(subdev->of_node));
>  
>  		ret = platform_device_add(pdev);
>  		if (ret) {

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=6

Re: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The static function `bcmgenet_mii_of_find_mdio()` becomes completely unreferenced and triggers a compiler warning (`-Wunused-function`) when `CONFIG_OF` is disabled.
--

--- Patch [4]: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode() ---
commit 91caf438269ceae68bf14d692c72b6702b3b3004
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

net: bcmgenet: use platform_device_set_fwnode()

This patch changes dynamically allocated platform devices to use the
higher-level platform_device_set_fwnode() rather than the OF-specific
platform_device_set_of_node().

> diff --git a/drivers/net/ethernet/broadcom/genet/bcmmii.c b/drivers/net/ethernet/broadcom/genet/bcmmii.c
> index 0f0dbabfaabbc..6f471723bd53f 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmmii.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmmii.c
[ ... ]
> @@ -492,7 +492,8 @@ static int bcmgenet_mii_register(struct bcmgenet_priv *priv)
>  	ppdev->dev.parent = &pdev->dev;
>  
>  	if (dn)
> -		platform_device_set_of_node(ppdev, bcmgenet_mii_of_find_mdio(priv));
> +		platform_device_set_fwnode(ppdev,
> +					   of_fwnode_handle(bcmgenet_mii_of_find_mdio(priv)));

[Severity: Low]
Will this cause a -Wunused-function warning for bcmgenet_mii_of_find_mdio()
when CONFIG_OF is disabled?

When CONFIG_OF is not set, include/linux/of.h defines of_fwnode_handle(node)
as just NULL. Because the macro discards its argument during preprocessing,
the call to bcmgenet_mii_of_find_mdio() is completely dropped, leaving the
static function unreferenced in this configuration.

Should bcmgenet_mii_of_find_mdio() be marked with __maybe_unused to prevent
build failures on setups using -Werror?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=4

Re: [PATCH 5/8] pmdomain: imx: use platform_device_set_fwnode()

[sashiko-bot]

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

Pre-existing issues:
- [High] Pre-existing leak of dynamically added child `platform_device`s on probe error or unbind, leading to use-after-free of parent's devm-managed resources.
--

--- Patch [5]: [PATCH 5/8] pmdomain: imx: use platform_device_set_fwnode() ---
commit 4ab43e8055c75d8cfe06f1c383c67f571e59d263
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

pmdomain: imx: use platform_device_set_fwnode()

This commit updates the driver to 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/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c
> --- a/drivers/pmdomain/imx/gpc.c
> +++ b/drivers/pmdomain/imx/gpc.c
> @@ -487,7 +487,7 @@ static int imx_gpc_probe(struct platform_device *pdev)
>  			domain->ipg_rate_mhz = ipg_rate_mhz;
>  
>  			pd_pdev->dev.parent = &pdev->dev;
> -			platform_device_set_of_node(pd_pdev, np);
> +			platform_device_set_fwnode(pd_pdev, of_fwnode_handle(np));
>  
>  			ret = platform_device_add(pd_pdev);
>  			if (ret) {
>  				platform_device_put(pd_pdev);
>  				return ret;
>  			}

[Severity: High]
This isn't a bug introduced by this patch, but does this error path leave
previously added child platform devices registered?

In imx_gpc_probe(), the child imx-pgc-power-domain platform devices are
added in a loop. If a subsequent iteration fails and returns here, it
triggers devres cleanup for the parent device, freeing resources like
the devm-managed regmap.

Because the previously added child devices are not unregistered on this
error path, will they remain bound with a dangling domain->regmap pointer?

Additionally, looking at imx_gpc_remove(), it entirely omits child
unregistration when the new DT binding is used, leaving the child
devices registered while parent devm resources are torn down:

drivers/pmdomain/imx/gpc.c:imx_gpc_remove() {
    ...
		}
	}

	of_node_put(pgc_node);
}

Could this also lead to a similar use-after-free of the regmap struct
on an explicit sysfs unbind?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=5

Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()

[sashiko-bot]

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

Re: [PATCH 8/8] slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode()

[sashiko-bot]

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

Pre-existing issues:
- [High] Missing NULL check on `of_match_node()` result leads to NULL pointer dereference.
- [High] Premature freeing of parent controller's data in child driver's remove callback causes NULL pointer dereference.
- [High] Use-After-Free due to uncancelled work on the system workqueue.
--

--- Patch [8]: [PATCH 8/8] slimbus: qcom-ngd-ctrl: use platform_device_set_fwnode() ---
commit 1bfb7c41dded376cdac1bca23cdc026328648166
Author: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

slimbus: qcom-ngd-ctrl: 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/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
> index 934c44c5bc1a9..bf077f47c9ddd 100644
> --- a/drivers/slimbus/qcom-ngd-ctrl.c
> +++ b/drivers/slimbus/qcom-ngd-ctrl.c
> @@ -1538,7 +1538,7 @@ static int of_qcom_slim_ngd_register(struct device *parent,
>  			kfree(ngd);
>  			return ret;
>  		}
> -		platform_device_set_of_node(ngd->pdev, node);
> +		platform_device_set_fwnode(ngd->pdev, of_fwnode_handle(node));
>  		ctrl->ngd = ngd;
>  
>  		ret = platform_device_add(ngd->pdev);

[Severity: High]
This isn't a bug introduced by this patch, but while looking at
of_qcom_slim_ngd_register(), I noticed that of_match_node() doesn't
have a NULL check:

drivers/slimbus/qcom-ngd-ctrl.c:of_qcom_slim_ngd_register() {
	...
	match = of_match_node(qcom_slim_ngd_dt_match, parent->of_node);
	data = match->data;
	...
}

Can this lead to a NULL pointer dereference if a user with root privileges
binds the driver via sysfs to a platform device that lacks an appropriate
of_node?

[Severity: High]
This is a pre-existing issue, but I noticed the parent controller's data
could be prematurely freed in the child driver's remove callback:

drivers/slimbus/qcom-ngd-ctrl.c:qcom_slim_ngd_remove() {
	...
	kfree(ctrl->ngd);
	ctrl->ngd = NULL;
	...
}

If the child driver is unbound via sysfs, this frees ctrl->ngd. If the
parent driver is subsequently unbound, won't qcom_slim_ngd_unregister()
dereference the NULL ctrl->ngd pointer to delete the platform device?

drivers/slimbus/qcom-ngd-ctrl.c:qcom_slim_ngd_unregister() {
	struct qcom_slim_ngd *ngd = ctrl->ngd;

	platform_device_del(ngd->pdev);
}

[Severity: High]
This is also a pre-existing issue, but could there be a use-after-free
if work is scheduled on the system workqueue during driver removal?

In qcom_slim_ngd_ctrl_remove(), the private workqueue is destroyed, but
cancel_work_sync(&ctrl->ngd_up_work) is omitted for the system workqueue:

drivers/slimbus/qcom-ngd-ctrl.c:qcom_slim_ngd_ctrl_remove() {
	...
	destroy_workqueue(ctrl->mwq);
	...
}

If the scheduled work executes after devres frees the ctrl structure, won't
the worker dereference the freed memory?

drivers/slimbus/qcom-ngd-ctrl.c:qcom_slim_ngd_up_worker() {
	...
	ctrl = container_of(work, struct qcom_slim_ngd_ctrl, ngd_up_work);
	...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-pdev-set-fwnode-instead-of-of-node-v1-0-2dee93f42c54@oss.qualcomm.com?part=8