diff mbox series

[v3,1/2] amba: bus: balance firmware node reference counting

Message ID 20231006145732.3419115-1-andriy.shevchenko@linux.intel.com (mailing list archive)
State Handled Elsewhere, archived
Headers show
Series [v3,1/2] amba: bus: balance firmware node reference counting | expand

Commit Message

Andy Shevchenko Oct. 6, 2023, 2:57 p.m. UTC
Currently the ACPI code doesn't bump the reference count of
the firmware node, while OF counter part does. Not that it's
a problem right now, since ACPI doesn't really use the reference
counting for firmware nodes, it still makes sense to make code
robust against any changes done there. For this,
 - switch ACPI case to use device_set_node() to be unified with OF
 - move reference counting to amba_device_add()
 - switch to use firmware nodes instead of OF ones

In the result we will have reference counting done in the same module
for all callers independently on the nature of firmware node behind.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---

v3: no changes
v2: fixed compilation error (LKP), all dependencies are in v6.6-rcX (Rob)

 drivers/acpi/arm64/amba.c | 2 +-
 drivers/amba/bus.c        | 5 ++++-
 drivers/of/platform.c     | 2 +-
 3 files changed, 6 insertions(+), 3 deletions(-)

Comments

Rob Herring (Arm) Oct. 17, 2023, 6:37 p.m. UTC | #1
On Fri, 06 Oct 2023 17:57:31 +0300, Andy Shevchenko wrote:
> Currently the ACPI code doesn't bump the reference count of
> the firmware node, while OF counter part does. Not that it's
> a problem right now, since ACPI doesn't really use the reference
> counting for firmware nodes, it still makes sense to make code
> robust against any changes done there. For this,
>  - switch ACPI case to use device_set_node() to be unified with OF
>  - move reference counting to amba_device_add()
>  - switch to use firmware nodes instead of OF ones
> 
> In the result we will have reference counting done in the same module
> for all callers independently on the nature of firmware node behind.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> 
> v3: no changes
> v2: fixed compilation error (LKP), all dependencies are in v6.6-rcX (Rob)
> 
>  drivers/acpi/arm64/amba.c | 2 +-
>  drivers/amba/bus.c        | 5 ++++-
>  drivers/of/platform.c     | 2 +-
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 

Applied, thanks!
Andy Shevchenko Oct. 17, 2023, 6:42 p.m. UTC | #2
On Tue, Oct 17, 2023 at 01:37:43PM -0500, Rob Herring wrote:
> On Fri, 06 Oct 2023 17:57:31 +0300, Andy Shevchenko wrote:

...

> Applied, thanks!

Thanks, I hope w.o. patch 2 as it seems it can't be enabled on non-ARM
platforms due to some strange MM APIs.
Rob Herring (Arm) Oct. 19, 2023, 7:15 p.m. UTC | #3
On Tue, Oct 17, 2023 at 1:43 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, Oct 17, 2023 at 01:37:43PM -0500, Rob Herring wrote:
> > On Fri, 06 Oct 2023 17:57:31 +0300, Andy Shevchenko wrote:
>
> ...
>
> > Applied, thanks!
>
> Thanks, I hope w.o. patch 2 as it seems it can't be enabled on non-ARM
> platforms due to some strange MM APIs.

Yes, just patch 1. Isn't it just the driver with the error that can't
be enabled, not all ARM_AMBA. I suspect there's a more portable
variant of what was causing the error, but didn't investigate more.

Rob
Andy Shevchenko Oct. 20, 2023, 10:15 a.m. UTC | #4
On Thu, Oct 19, 2023 at 02:15:43PM -0500, Rob Herring wrote:
> On Tue, Oct 17, 2023 at 1:43 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > On Tue, Oct 17, 2023 at 01:37:43PM -0500, Rob Herring wrote:
> > > On Fri, 06 Oct 2023 17:57:31 +0300, Andy Shevchenko wrote:

...

> > > Applied, thanks!
> >
> > Thanks, I hope w.o. patch 2 as it seems it can't be enabled on non-ARM
> > platforms due to some strange MM APIs.
> 
> Yes, just patch 1. Isn't it just the driver with the error that can't
> be enabled, not all ARM_AMBA. I suspect there's a more portable
> variant of what was causing the error, but didn't investigate more.

Yeah, I think so but it's not the first time I saw such non-portable APIs in
the drivers as they were (mistakenly?) designed as ARM-only.
diff mbox series

Patch

diff --git a/drivers/acpi/arm64/amba.c b/drivers/acpi/arm64/amba.c
index 60be8ee1dbdc..171b5c2c7edd 100644
--- a/drivers/acpi/arm64/amba.c
+++ b/drivers/acpi/arm64/amba.c
@@ -101,7 +101,7 @@  static int amba_handler_attach(struct acpi_device *adev,
 	if (parent)
 		dev->dev.parent = acpi_get_first_physical_node(parent);
 
-	ACPI_COMPANION_SET(&dev->dev, adev);
+	device_set_node(&dev->dev, acpi_fwnode_handle(adev));
 
 	ret = amba_device_add(dev, &iomem_resource);
 	if (ret) {
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 09e72967b8ab..a24c152bfaac 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -18,6 +18,7 @@ 
 #include <linux/limits.h>
 #include <linux/clk/clk-conf.h>
 #include <linux/platform_device.h>
+#include <linux/property.h>
 #include <linux/reset.h>
 #include <linux/of_irq.h>
 #include <linux/of_device.h>
@@ -528,7 +529,7 @@  static void amba_device_release(struct device *dev)
 {
 	struct amba_device *d = to_amba_device(dev);
 
-	of_node_put(d->dev.of_node);
+	fwnode_handle_put(dev_fwnode(&d->dev));
 	if (d->res.parent)
 		release_resource(&d->res);
 	mutex_destroy(&d->periphid_lock);
@@ -548,6 +549,8 @@  int amba_device_add(struct amba_device *dev, struct resource *parent)
 {
 	int ret;
 
+	fwnode_handle_get(dev_fwnode(&dev->dev));
+
 	ret = request_resource(parent, &dev->res);
 	if (ret)
 		return ret;
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index f235ab55b91e..126d265aa7d8 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -273,7 +273,7 @@  static struct amba_device *of_amba_device_create(struct device_node *node,
 	dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
 
 	/* setup generic device info */
-	device_set_node(&dev->dev, of_fwnode_handle(of_node_get(node)));
+	device_set_node(&dev->dev, of_fwnode_handle(node));
 	dev->dev.parent = parent ? : &platform_bus;
 	dev->dev.platform_data = platform_data;
 	if (bus_id)