| Message ID | 20231006145732.3419115-1-andriy.shevchenko@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3,1/2] amba: bus: balance firmware node reference counting | expand |
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!
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.
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
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 --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)
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(-)