* [PATCH] of/platform: Initialise dev->fwnode appropriately
@ 2016-09-15 13:36 ` Rob Herring
0 siblings, 0 replies; 11+ messages in thread
From: Rob Herring @ 2016-09-15 13:36 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote:
> Whilst we're some of the way towards a universal firmware property
> interface, drivers which deal with both OF and ACPI probing end up
> having to do things like this:
>
> dev->of_node ? &dev->of_node->fwnode : dev->fwnode
>
> This seems unnecessary, when the OF code could instead simply fill in
> the device's fwnode when binding the of_node, and let the drivers use
> dev->fwnode either way. Let's give it a go and see what falls out.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/of/platform.c | 2 ++
> 1 file changed, 2 insertions(+)
I've applied this, but what about non-platform devices such as i2c?
Rob
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] of/platform: Initialise dev->fwnode appropriately
@ 2016-09-15 13:36 ` Rob Herring
0 siblings, 0 replies; 11+ messages in thread
From: Rob Herring @ 2016-09-15 13:36 UTC (permalink / raw)
To: Robin Murphy
Cc: frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
lorenzo.pieralisi-5wv7dgnIgG8, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA
On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote:
> Whilst we're some of the way towards a universal firmware property
> interface, drivers which deal with both OF and ACPI probing end up
> having to do things like this:
>
> dev->of_node ? &dev->of_node->fwnode : dev->fwnode
>
> This seems unnecessary, when the OF code could instead simply fill in
> the device's fwnode when binding the of_node, and let the drivers use
> dev->fwnode either way. Let's give it a go and see what falls out.
>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
> drivers/of/platform.c | 2 ++
> 1 file changed, 2 insertions(+)
I've applied this, but what about non-platform devices such as i2c?
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] of/platform: Initialise dev->fwnode appropriately
2016-09-15 13:36 ` Rob Herring
(?)
@ 2016-09-16 11:12 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 11+ messages in thread
From: Lorenzo Pieralisi @ 2016-09-16 11:12 UTC (permalink / raw)
To: Rob Herring
Cc: Robin Murphy, frowand.list, devicetree, linux-arm-kernel,
linux-kernel, okaya, yisen.zhuang, salil.mehta
On Thu, Sep 15, 2016 at 08:36:57AM -0500, Rob Herring wrote:
> On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote:
> > Whilst we're some of the way towards a universal firmware property
> > interface, drivers which deal with both OF and ACPI probing end up
> > having to do things like this:
> >
> > dev->of_node ? &dev->of_node->fwnode : dev->fwnode
> >
> > This seems unnecessary, when the OF code could instead simply fill in
> > the device's fwnode when binding the of_node, and let the drivers use
> > dev->fwnode either way. Let's give it a go and see what falls out.
> >
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > ---
> > drivers/of/platform.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> I've applied this, but what about non-platform devices such as i2c?
Thanks ! Patch below should do for mfd and i2c (to be confirmed) but
I am pretty certain it is still missing some devices, are we going
to convert them on a case-by-case policy (ie when/if needed) ?
Lorenzo
-- >8 --
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index da3a02e..667a393 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1574,6 +1574,7 @@ static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
info.addr = addr;
info.of_node = of_node_get(node);
+ info.fwnode = &node->fwnode;
info.archdata = &dev_ad;
if (of_get_property(node, "wakeup-source", NULL))
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 3ac486a..c264bf5 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -179,6 +179,7 @@ static int mfd_add_device(struct device *parent, int id,
for_each_child_of_node(parent->of_node, np) {
if (of_device_is_compatible(np, cell->of_compatible)) {
pdev->dev.of_node = np;
+ pdev->dev.fwnode = &np->fwnode;
break;
}
}
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH] of/platform: Initialise dev->fwnode appropriately
@ 2016-09-16 11:12 ` Lorenzo Pieralisi
0 siblings, 0 replies; 11+ messages in thread
From: Lorenzo Pieralisi @ 2016-09-16 11:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Sep 15, 2016 at 08:36:57AM -0500, Rob Herring wrote:
> On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote:
> > Whilst we're some of the way towards a universal firmware property
> > interface, drivers which deal with both OF and ACPI probing end up
> > having to do things like this:
> >
> > dev->of_node ? &dev->of_node->fwnode : dev->fwnode
> >
> > This seems unnecessary, when the OF code could instead simply fill in
> > the device's fwnode when binding the of_node, and let the drivers use
> > dev->fwnode either way. Let's give it a go and see what falls out.
> >
> > Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> > ---
> > drivers/of/platform.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> I've applied this, but what about non-platform devices such as i2c?
Thanks ! Patch below should do for mfd and i2c (to be confirmed) but
I am pretty certain it is still missing some devices, are we going
to convert them on a case-by-case policy (ie when/if needed) ?
Lorenzo
-- >8 --
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index da3a02e..667a393 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1574,6 +1574,7 @@ static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
info.addr = addr;
info.of_node = of_node_get(node);
+ info.fwnode = &node->fwnode;
info.archdata = &dev_ad;
if (of_get_property(node, "wakeup-source", NULL))
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 3ac486a..c264bf5 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -179,6 +179,7 @@ static int mfd_add_device(struct device *parent, int id,
for_each_child_of_node(parent->of_node, np) {
if (of_device_is_compatible(np, cell->of_compatible)) {
pdev->dev.of_node = np;
+ pdev->dev.fwnode = &np->fwnode;
break;
}
}
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] of/platform: Initialise dev->fwnode appropriately
@ 2016-09-16 11:12 ` Lorenzo Pieralisi
0 siblings, 0 replies; 11+ messages in thread
From: Lorenzo Pieralisi @ 2016-09-16 11:12 UTC (permalink / raw)
To: Rob Herring
Cc: Robin Murphy, frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
okaya-sgV2jX0FEOL9JmXXK+q4OQ,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA
On Thu, Sep 15, 2016 at 08:36:57AM -0500, Rob Herring wrote:
> On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote:
> > Whilst we're some of the way towards a universal firmware property
> > interface, drivers which deal with both OF and ACPI probing end up
> > having to do things like this:
> >
> > dev->of_node ? &dev->of_node->fwnode : dev->fwnode
> >
> > This seems unnecessary, when the OF code could instead simply fill in
> > the device's fwnode when binding the of_node, and let the drivers use
> > dev->fwnode either way. Let's give it a go and see what falls out.
> >
> > Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> > ---
> > drivers/of/platform.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> I've applied this, but what about non-platform devices such as i2c?
Thanks ! Patch below should do for mfd and i2c (to be confirmed) but
I am pretty certain it is still missing some devices, are we going
to convert them on a case-by-case policy (ie when/if needed) ?
Lorenzo
-- >8 --
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index da3a02e..667a393 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1574,6 +1574,7 @@ static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
info.addr = addr;
info.of_node = of_node_get(node);
+ info.fwnode = &node->fwnode;
info.archdata = &dev_ad;
if (of_get_property(node, "wakeup-source", NULL))
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index 3ac486a..c264bf5 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -179,6 +179,7 @@ static int mfd_add_device(struct device *parent, int id,
for_each_child_of_node(parent->of_node, np) {
if (of_device_is_compatible(np, cell->of_compatible)) {
pdev->dev.of_node = np;
+ pdev->dev.fwnode = &np->fwnode;
break;
}
}
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH] of/platform: Initialise dev->fwnode appropriately
2016-09-15 13:36 ` Rob Herring
(?)
@ 2016-09-16 12:07 ` Robin Murphy
-1 siblings, 0 replies; 11+ messages in thread
From: Robin Murphy @ 2016-09-16 12:07 UTC (permalink / raw)
To: Rob Herring
Cc: frowand.list, devicetree, linux-arm-kernel, linux-kernel,
lorenzo.pieralisi, okaya, yisen.zhuang, salil.mehta
On 15/09/16 14:36, Rob Herring wrote:
> On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote:
>> Whilst we're some of the way towards a universal firmware property
>> interface, drivers which deal with both OF and ACPI probing end up
>> having to do things like this:
>>
>> dev->of_node ? &dev->of_node->fwnode : dev->fwnode
>>
>> This seems unnecessary, when the OF code could instead simply fill in
>> the device's fwnode when binding the of_node, and let the drivers use
>> dev->fwnode either way. Let's give it a go and see what falls out.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/of/platform.c | 2 ++
>> 1 file changed, 2 insertions(+)
>
> I've applied this, but what about non-platform devices such as i2c?
I was indeed wondering that, coming from the perspective of DMA/IOMMU
configuration which doesn't really apply beyond the PCI and platform
buses. More generally, at this point it's largely for the benefit of
subsystems which need to chuck around firmware data for other devices
that don't exist yet (or at all), which maybe is just the DMA and IRQ
layers.
I guess beyond that it comes down to auditing the intersection between
callers of the property API and OF-probed buses, then killing the
dev_fwnode() helper in property.c and making sure nothing else breaks.
The possible alternative would be pushing this right down into
device_initialize(), but that seems a bit wrong.
Thanks,
Robin.
>
> Rob
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH] of/platform: Initialise dev->fwnode appropriately
@ 2016-09-16 12:07 ` Robin Murphy
0 siblings, 0 replies; 11+ messages in thread
From: Robin Murphy @ 2016-09-16 12:07 UTC (permalink / raw)
To: linux-arm-kernel
On 15/09/16 14:36, Rob Herring wrote:
> On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote:
>> Whilst we're some of the way towards a universal firmware property
>> interface, drivers which deal with both OF and ACPI probing end up
>> having to do things like this:
>>
>> dev->of_node ? &dev->of_node->fwnode : dev->fwnode
>>
>> This seems unnecessary, when the OF code could instead simply fill in
>> the device's fwnode when binding the of_node, and let the drivers use
>> dev->fwnode either way. Let's give it a go and see what falls out.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/of/platform.c | 2 ++
>> 1 file changed, 2 insertions(+)
>
> I've applied this, but what about non-platform devices such as i2c?
I was indeed wondering that, coming from the perspective of DMA/IOMMU
configuration which doesn't really apply beyond the PCI and platform
buses. More generally, at this point it's largely for the benefit of
subsystems which need to chuck around firmware data for other devices
that don't exist yet (or at all), which maybe is just the DMA and IRQ
layers.
I guess beyond that it comes down to auditing the intersection between
callers of the property API and OF-probed buses, then killing the
dev_fwnode() helper in property.c and making sure nothing else breaks.
The possible alternative would be pushing this right down into
device_initialize(), but that seems a bit wrong.
Thanks,
Robin.
>
> Rob
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH] of/platform: Initialise dev->fwnode appropriately
@ 2016-09-16 12:07 ` Robin Murphy
0 siblings, 0 replies; 11+ messages in thread
From: Robin Murphy @ 2016-09-16 12:07 UTC (permalink / raw)
To: Rob Herring
Cc: frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
lorenzo.pieralisi-5wv7dgnIgG8, okaya-sgV2jX0FEOL9JmXXK+q4OQ,
yisen.zhuang-hv44wF8Li93QT0dZR+AlfA,
salil.mehta-hv44wF8Li93QT0dZR+AlfA
On 15/09/16 14:36, Rob Herring wrote:
> On Wed, Sep 14, 2016 at 04:01:24PM +0100, Robin Murphy wrote:
>> Whilst we're some of the way towards a universal firmware property
>> interface, drivers which deal with both OF and ACPI probing end up
>> having to do things like this:
>>
>> dev->of_node ? &dev->of_node->fwnode : dev->fwnode
>>
>> This seems unnecessary, when the OF code could instead simply fill in
>> the device's fwnode when binding the of_node, and let the drivers use
>> dev->fwnode either way. Let's give it a go and see what falls out.
>>
>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>> ---
>> drivers/of/platform.c | 2 ++
>> 1 file changed, 2 insertions(+)
>
> I've applied this, but what about non-platform devices such as i2c?
I was indeed wondering that, coming from the perspective of DMA/IOMMU
configuration which doesn't really apply beyond the PCI and platform
buses. More generally, at this point it's largely for the benefit of
subsystems which need to chuck around firmware data for other devices
that don't exist yet (or at all), which maybe is just the DMA and IRQ
layers.
I guess beyond that it comes down to auditing the intersection between
callers of the property API and OF-probed buses, then killing the
dev_fwnode() helper in property.c and making sure nothing else breaks.
The possible alternative would be pushing this right down into
device_initialize(), but that seems a bit wrong.
Thanks,
Robin.
>
> Rob
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 11+ messages in thread