A recent commit allowed device_create_managed_software_node() to call
software_node_notify() which could generate duplicated "software_node"
sysfs files. For example,
"/devices/platform/808622B7:01/xhci-hcd.3.auto/software_node"
Since it was created earlier from another path,
sysfs_create_link
software_node_notify
device_add
platform_device_add
dwc3_host_init
dwc3_probe
platform_probe
really_probe.part.0
really_probe
__driver_probe_device
driver_probe_device
__driver_attach
bus_for_each_dev
driver_attach
bus_add_driver
driver_register
__platform_driver_register
dwc3_driver_init at drivers/usb/dwc3/core.c:2072
do_one_initcall
Fixed it by using sysfs_create_link_nowarn() in software_node_notify() to
avoid those bad messages during booting,
sysfs: cannot create duplicate filename '/devices/platform/808622B7:01/xhci-hcd.3.auto/software_node'
Call trace:
dump_backtrace
show_stack
dump_stack_lvl
dump_stack
sysfs_warn_dup
sysfs_do_create_link_sd.isra.0
sysfs_create_link
software_node_notify
device_create_managed_software_node
iort_named_component_init
iort_iommu_configure_id
acpi_dma_configure_id
platform_dma_configure
really_probe.part.0
really_probe
__driver_probe_device
driver_probe_device
__driver_attach
bus_for_each_dev
driver_attach
bus_add_driver
driver_register
__platform_driver_register
xhci_plat_init
do_one_initcall
kernel_init_freeable
kernel_init
ret_from_fork
Fixes: 5aeb05b27f81 ("software node: balance refcount for managed software nodes")
Signed-off-by: Qian Cai <[email protected]>
---
drivers/base/swnode.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
index 4debcea4fb12..0a266c312aa3 100644
--- a/drivers/base/swnode.c
+++ b/drivers/base/swnode.c
@@ -1126,17 +1126,15 @@ void software_node_notify(struct device *dev)
if (!swnode)
return;
- ret = sysfs_create_link(&dev->kobj, &swnode->kobj, "software_node");
- if (ret)
+ ret = sysfs_create_link_nowarn(&dev->kobj, &swnode->kobj,
+ "software_node");
+ if (ret && ret != -EEXIST)
return;
- ret = sysfs_create_link(&swnode->kobj, &dev->kobj, dev_name(dev));
- if (ret) {
+ if (!sysfs_create_link(&swnode->kobj, &dev->kobj, dev_name(dev)))
+ kobject_get(&swnode->kobj);
+ else if (!ret)
sysfs_remove_link(&dev->kobj, "software_node");
- return;
- }
-
- kobject_get(&swnode->kobj);
}
void software_node_notify_remove(struct device *dev)
--
2.30.2
On Tue, Nov 02, 2021 at 01:51:34AM +0200, Andy Shevchenko wrote:
> On Monday, November 1, 2021, Qian Cai <[email protected]> wrote:
>
> > A recent commit allowed device_create_managed_software_node() to call
> > software_node_notify() which could generate duplicated "software_node"
> > sysfs files. For example,
> >
> > "/devices/platform/808622B7:01/xhci-hcd.3.auto/software_node"
> >
> > Since it was created earlier from another path,
> >
> > sysfs_create_link
> > software_node_notify
> > device_add
> > platform_device_add
> > dwc3_host_init
> > dwc3_probe
> > platform_probe
> > really_probe.part.0
> > really_probe
> > __driver_probe_device
> > driver_probe_device
> > __driver_attach
> > bus_for_each_dev
> > driver_attach
> > bus_add_driver
> > driver_register
> > __platform_driver_register
> > dwc3_driver_init at drivers/usb/dwc3/core.c:2072
> > do_one_initcall
> >
> > Fixed it by using sysfs_create_link_nowarn() in software_node_notify() to
> > avoid those bad messages during booting,
>
>
> No, it’s not so easy. What you are doing is a papering over the real issue
> which is the limitation of the firmware nodes to two. What we need is to
> drop the link from struct fwnode_handle, move it to upper layer and modify
> all fwnode ops to be used over the list of fwnode:s.
>
> XHCI driver and DWC3 are sharing the primary fwnode, but at the same time
> they wanted to have _different_ secondary ones when role is switched. This
> can’t be done in the current design. And here is the symptom what you got.
I'm actually not sure what is going on in this case, because this is
the ACPI enumerated BSW board, at least based on the ACPI ID?
That board should not have the initial secondary fwnode assigned by
the time the dwc3 host driver is called.
> sysfs: cannot create duplicatefilename '/devices/platform/808622B7:
> > 01/xhci-hcd.3.auto/software_node'
> > Call trace:
> > dump_backtrace
> > show_stack
> > dump_stack_lvl
> > dump_stack
> > sysfs_warn_dup
> > sysfs_do_create_link_sd.isra.0
> > sysfs_create_link
> > software_node_notify
> > device_create_managed_software_node
> > iort_named_component_init
> > iort_iommu_configure_id
> > acpi_dma_configure_id
> > platform_dma_configure
> > really_probe.part.0
> > really_probe
> > __driver_probe_device
> > driver_probe_device
> > __driver_attach
> > bus_for_each_dev
> > driver_attach
> > bus_add_driver
> > driver_register
> > __platform_driver_register
> > xhci_plat_init
> > do_one_initcall
> > kernel_init_freeable
> > kernel_init
> > ret_from_fork
> >
> > Fixes: 5aeb05b27f81 ("software node: balance refcount for managed software
> > nodes")
> > Signed-off-by: Qian Cai <[email protected]>
> > ---
> > drivers/base/swnode.c | 14 ++++++--------
> > 1 file changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> > index 4debcea4fb12..0a266c312aa3 100644
> > --- a/drivers/base/swnode.c
> > +++ b/drivers/base/swnode.c
> > @@ -1126,17 +1126,15 @@ void software_node_notify(struct device *dev)
> > if (!swnode)
> > return;
> >
> > - ret = sysfs_create_link(&dev->kobj, &swnode->kobj,
> > "software_node");
> > - if (ret)
> > + ret = sysfs_create_link_nowarn(&dev->kobj, &swnode->kobj,
> > + "software_node");
> > + if (ret && ret != -EEXIST)
> > return;
> >
> > - ret = sysfs_create_link(&swnode->kobj, &dev->kobj, dev_name(dev));
> > - if (ret) {
> > + if (!sysfs_create_link(&swnode->kobj, &dev->kobj, dev_name(dev)))
> > + kobject_get(&swnode->kobj);
> > + else if (!ret)
> > sysfs_remove_link(&dev->kobj, "software_node");
> > - return;
> > - }
> > -
> > - kobject_get(&swnode->kobj);
> > }
> >
> > void software_node_notify_remove(struct device *dev)
thanks,
--
heikki
On Tue, Nov 02, 2021 at 10:28:45AM +0200, Heikki Krogerus wrote:
> On Tue, Nov 02, 2021 at 01:51:34AM +0200, Andy Shevchenko wrote:
> > On Monday, November 1, 2021, Qian Cai <[email protected]> wrote:
> >
> > > A recent commit allowed device_create_managed_software_node() to call
> > > software_node_notify() which could generate duplicated "software_node"
> > > sysfs files. For example,
> > >
> > > "/devices/platform/808622B7:01/xhci-hcd.3.auto/software_node"
> > >
> > > Since it was created earlier from another path,
> > >
> > > sysfs_create_link
> > > software_node_notify
> > > device_add
> > > platform_device_add
> > > dwc3_host_init
> > > dwc3_probe
> > > platform_probe
> > > really_probe.part.0
> > > really_probe
> > > __driver_probe_device
> > > driver_probe_device
> > > __driver_attach
> > > bus_for_each_dev
> > > driver_attach
> > > bus_add_driver
> > > driver_register
> > > __platform_driver_register
> > > dwc3_driver_init at drivers/usb/dwc3/core.c:2072
> > > do_one_initcall
> > >
> > > Fixed it by using sysfs_create_link_nowarn() in software_node_notify() to
> > > avoid those bad messages during booting,
> >
> >
> > No, it’s not so easy. What you are doing is a papering over the real issue
> > which is the limitation of the firmware nodes to two. What we need is to
> > drop the link from struct fwnode_handle, move it to upper layer and modify
> > all fwnode ops to be used over the list of fwnode:s.
> >
> > XHCI driver and DWC3 are sharing the primary fwnode, but at the same time
> > they wanted to have _different_ secondary ones when role is switched. This
> > can’t be done in the current design. And here is the symptom what you got.
>
> I'm actually not sure what is going on in this case, because this is
> the ACPI enumerated BSW board, at least based on the ACPI ID?
>
> That board should not have the initial secondary fwnode assigned by
> the time the dwc3 host driver is called.
But what Andy said is still true. You are only hiding the core problem
with this. So this patch is not the way to go.
thanks,
--
heikki
On 11/2/21 4:28 AM, Heikki Krogerus wrote:
> I'm actually not sure what is going on in this case, because this is
> the ACPI enumerated BSW board, at least based on the ACPI ID?
Yes, this is an ACPI-based server.
> That board should not have the initial secondary fwnode assigned by
> the time the dwc3 host driver is called.
Heikki, what information would be helpful to figure it out? Is the full
demsg useful here?
On 11/1/21 7:51 PM, Andy Shevchenko wrote:
> No, it’s not so easy. What you are doing is a papering over the real issue
> which is the limitation of the firmware nodes to two. What we need is to
> drop the link from struct fwnode_handle, move it to upper layer and modify
> all fwnode ops to be used over the list of fwnode:s.
Andy, this is my first time touching fwnode/swnode. After reading the
source code for a few hours, I still don't understand the hint here.
Specifically, what does the "the link" refer to?
On Tue, Nov 2, 2021 at 9:44 PM Qian Cai <[email protected]> wrote:
> On 11/1/21 7:51 PM, Andy Shevchenko wrote:
> > No, it’s not so easy. What you are doing is a papering over the real issue
> > which is the limitation of the firmware nodes to two. What we need is to
> > drop the link from struct fwnode_handle, move it to upper layer and modify
> > all fwnode ops to be used over the list of fwnode:s.
>
> Andy, this is my first time touching fwnode/swnode. After reading the
> source code for a few hours, I still don't understand the hint here.
> Specifically, what does the "the link" refer to?
https://elixir.bootlin.com/linux/latest/source/include/linux/fwnode.h#L36
(Property related) fwnode (as of today) is the single linked list with
only two possible entries. Comments against set_primary_fwnode()
followed by set_secondary_fwnode() may shed a bit of light here
https://elixir.bootlin.com/linux/latest/source/drivers/base/core.c#L4724
--
With Best Regards,
Andy Shevchenko
On Tue, Nov 2, 2021 at 10:20 PM Andy Shevchenko
<[email protected]> wrote:
> On Tue, Nov 2, 2021 at 9:44 PM Qian Cai <[email protected]> wrote:
> > On 11/1/21 7:51 PM, Andy Shevchenko wrote:
> > > No, it’s not so easy. What you are doing is a papering over the real issue
> > > which is the limitation of the firmware nodes to two. What we need is to
> > > drop the link from struct fwnode_handle, move it to upper layer and modify
> > > all fwnode ops to be used over the list of fwnode:s.
> >
> > Andy, this is my first time touching fwnode/swnode. After reading the
> > source code for a few hours, I still don't understand the hint here.
> > Specifically, what does the "the link" refer to?
>
> https://elixir.bootlin.com/linux/latest/source/include/linux/fwnode.h#L36
>
> (Property related) fwnode (as of today) is the single linked list with
> only two possible entries. Comments against set_primary_fwnode()
> followed by set_secondary_fwnode() may shed a bit of light here
> https://elixir.bootlin.com/linux/latest/source/drivers/base/core.c#L4724
What you can start with, btw, is adding the trace events / points to
these two functions. (Currently only devres is enabled:
https://elixir.bootlin.com/linux/latest/source/drivers/base/trace.h)
When you do this, you may actually see what's going on and how the
swnode tries to recreate the same file.
--
With Best Regards,
Andy Shevchenko
On 11/1/21 7:51 PM, Andy Shevchenko wrote:
> No, it’s not so easy. What you are doing is a papering over the real issue
> which is the limitation of the firmware nodes to two. What we need is to
> drop the link from struct fwnode_handle, move it to upper layer and modify
> all fwnode ops to be used over the list of fwnode:s.
>
> XHCI driver and DWC3 are sharing the primary fwnode, but at the same time
> they wanted to have _different_ secondary ones when role is switched. This
> can’t be done in the current design. And here is the symptom what you got.
Andy, thanks for the pointers so far. I was able to trace
set_primary_fwnode() and set_secondary_fwnode().
Anyway, what's the "upper layer"? Is that "struct device" or "struct
swnode"? I suppose you meant:
- Remove "secondary" field from "struct fwnode_handle".
- Replace "fwnode" from "upper layer" with
"struct list_head fwnode_head;".
- Modify all functions in "software_node_ops" to use "fwnode_head".
Is that correct?
On Fri, Nov 5, 2021 at 8:47 PM Qian Cai <[email protected]> wrote:
> On 11/1/21 7:51 PM, Andy Shevchenko wrote:
> > No, it’s not so easy. What you are doing is a papering over the real issue
> > which is the limitation of the firmware nodes to two. What we need is to
> > drop the link from struct fwnode_handle, move it to upper layer and modify
> > all fwnode ops to be used over the list of fwnode:s.
> >
> > XHCI driver and DWC3 are sharing the primary fwnode, but at the same time
> > they wanted to have _different_ secondary ones when role is switched. This
> > can’t be done in the current design. And here is the symptom what you got.
>
> Andy, thanks for the pointers so far. I was able to trace
> set_primary_fwnode() and set_secondary_fwnode().
Can you share the trace you have got?
> Anyway, what's the "upper layer"? Is that "struct device" or "struct
> swnode"? I suppose you meant:
struct device here.
> - Remove "secondary" field from "struct fwnode_handle".
> - Replace "fwnode" from "upper layer" with
> "struct list_head fwnode_head;".
> - Modify all functions in "software_node_ops" to use "fwnode_head".
>
> Is that correct?
Yes.
It might be a bit complicated taking into account how much fwnode is
spreaded in the kernel... Basically, you need to fix all direct
accesses to the dev->fwnode first.
Besides that you need to check that fwnode, which is used out of the
device scope, like in IRQ domains, doesn't use secondary pointer(s).
This nevertheless adds a lot of flexibility and we may add whatever
type of fwnodes and mix them together.
--
With Best Regards,
Andy Shevchenko
On 11/5/21 3:39 PM, Andy Shevchenko wrote:
>> Andy, thanks for the pointers so far. I was able to trace
>> set_primary_fwnode() and set_secondary_fwnode().
>
> Can you share the trace you have got?
I used a simple debugging patch below:
diff --git a/drivers/base/core.c b/drivers/base/core.c
index fd034d742447..d8ae96289acf 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -4742,6 +4742,11 @@ void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode)
struct device *parent = dev->parent;
struct fwnode_handle *fn = dev->fwnode;
+ printk("KK set_primary_fwnode dev name = %s, fwnode = %px\n", dev_name(dev), fwnode);
+ if (parent)
+ printk("KK parent = %s\n", dev_name(dev->parent));
+ if (fwnode && fwnode->dev)
+ printk("KK fwnode->dev = %s\n", dev_name(fwnode->dev));
if (fwnode) {
if (fwnode_is_primary(fn))
fn = fn->secondary;
@@ -4761,6 +4766,8 @@ void set_primary_fwnode(struct device *dev, struct fwnode_handle *fwnode)
dev->fwnode = NULL;
}
}
+ if (fwnode)
+ printk("KK secondary = %px\n", dev->fwnode->secondary);
}
EXPORT_SYMBOL_GPL(set_primary_fwnode);
@@ -4775,13 +4782,20 @@ EXPORT_SYMBOL_GPL(set_primary_fwnode);
*/
void set_secondary_fwnode(struct device *dev, struct fwnode_handle *fwnode)
{
+ printk("KK set_secondary_fwnode dev name = %s, fwnode = %px\n", dev_name(dev), fwnode);
+ if (dev->parent)
+ printk("KK parent = %s\n", dev_name(dev->parent));
+ if (fwnode && fwnode->dev)
+ printk("KK fwnode->dev = %s\n", dev_name(fwnode->dev));
if (fwnode)
fwnode->secondary = ERR_PTR(-ENODEV);
- if (fwnode_is_primary(dev->fwnode))
+ if (fwnode_is_primary(dev->fwnode)) {
dev->fwnode->secondary = fwnode;
- else
+ printk("KK primary = %px\n", dev->fwnode);
+ } else {
dev->fwnode = fwnode;
+ }
}
EXPORT_SYMBOL_GPL(set_secondary_fwnode);
Then, here are the relevant outputs indicating that
"808622B7:01" and "xhci-hcd.3.auto" have the same
primary but different secondaries.
[ 11.233280] KK set_secondary_fwnode dev name = 808622B7:01, fwnode = ffff000838618840
[ 11.241846] KK parent = platform
[ 11.245790] KK primary = ffff0008064b9010
[ 11.259838] KK set_primary_fwnode dev name = (null), fwnode = ffff0008064b9010
[ 11.267795] KK parent = 808622B7:01
[ 11.272000] KK fwnode->dev = 808622B7:01
[ 11.276636] KK secondary = ffff000838618840
[ 11.680489] KK set_secondary_fwnode dev name = xhci-hcd.3.auto, fwnode = ffff000838325040
[ 11.689406] KK parent = 808622B7:01
[ 11.693916] KK primary = ffff0008064b9010
[ 11.698763] sysfs: cannot create duplicate filename '/devices/platform/808622B7:01/xhci-hcd.3.auto/software_node'
On Mon, Nov 08, 2021 at 11:07:53AM -0500, Qian Cai wrote:
> On 11/5/21 3:39 PM, Andy Shevchenko wrote:
> >> Andy, thanks for the pointers so far. I was able to trace
> >> set_primary_fwnode() and set_secondary_fwnode().
> >
> > Can you share the trace you have got?
...
> Then, here are the relevant outputs indicating that
> "808622B7:01" and "xhci-hcd.3.auto" have the same
> primary but different secondaries.
So, it confirms my theory if I'm not mistaken.
Btw, what you can do in this case is to switch to use fwnode_create_software
node and switch them in drd.c. It will be much much easier to achieve then
full kernel refactoring.
> [ 11.233280] KK set_secondary_fwnode dev name = 808622B7:01, fwnode = ffff000838618840
> [ 11.241846] KK parent = platform
> [ 11.245790] KK primary = ffff0008064b9010
> [ 11.259838] KK set_primary_fwnode dev name = (null), fwnode = ffff0008064b9010
> [ 11.267795] KK parent = 808622B7:01
> [ 11.272000] KK fwnode->dev = 808622B7:01
> [ 11.276636] KK secondary = ffff000838618840
> [ 11.680489] KK set_secondary_fwnode dev name = xhci-hcd.3.auto, fwnode = ffff000838325040
> [ 11.689406] KK parent = 808622B7:01
> [ 11.693916] KK primary = ffff0008064b9010
> [ 11.698763] sysfs: cannot create duplicate filename '/devices/platform/808622B7:01/xhci-hcd.3.auto/software_node'
--
With Best Regards,
Andy Shevchenko
On Mon, Nov 08, 2021 at 08:06:26PM +0200, Andy Shevchenko wrote:
> Btw, what you can do in this case is to switch to use fwnode_create_software
> node and switch them in drd.c. It will be much much easier to achieve then
> full kernel refactoring.
(Adding arm64 and dwc3 people since that iort_iommu_configure_id()
path below to create a duplicated sysfs is arm64-specific. The
original thread is here):
https://lore.kernel.org/lkml/[email protected]/
Andy, did you mean host.c? I saw that the first time
"/devices/platform/808622B7:01/xhci-hcd.3.auto/software_node" was
created by dwc3_host_init(). Call trace:
sysfs_do_create_link_sd.isra.0
sysfs_create_link
software_node_notify
device_add
platform_device_add
dwc3_host_init
dwc3_probe
platform_probe
really_probe.part.0
really_probe
__driver_probe_device
driver_probe_device
__driver_attach
bus_for_each_dev
driver_attach
bus_add_driver
driver_register
__platform_driver_register
dwc3_driver_init
dwc3_driver_init at drivers/usb/dwc3/core.c:2072
do_one_initcall
kernel_init_freeable
kernel_init
ret_from_fork
Then, which functions do you suggest to replace with
fwnode_create_software_node()? In dwc3_host_init(),
int dwc3_host_init(struct dwc3 *dwc)
{
...
xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
...
ret = platform_device_add(xhci);
I am wondering if that we could solve the problem by avoiding
"xhci-hcd" string here which would unfortunately clash with
xhci_plat_init() as mentioned before:
sysfs_create_link
software_node_notify
device_create_managed_software_node
iort_named_component_init
iort_iommu_configure_id
acpi_dma_configure_id
platform_dma_configure
really_probe.part.0
really_probe
__driver_probe_device
driver_probe_device
__driver_attach
bus_for_each_dev
driver_attach
bus_add_driver
driver_register
__platform_driver_register
xhci_plat_init
do_one_initcall
kernel_init_freeable
kernel_init
ret_from_fork
since the driver would also use "xhci-hcd".
static struct platform_driver usb_xhci_driver = {
...
.driver = {
.name = "xhci-hcd",
static int __init xhci_plat_init(void)
{
...
return platform_driver_register(&usb_xhci_driver);
BTW, "/sys/devices/platform/808622B7:01/software_node" was also
created from the path:
sysfs_create_link
software_node_notify
device_create_managed_software_node
iort_named_component_init
iort_iommu_configure_id
acpi_dma_configure_id
platform_dma_configure
really_probe.part.0
really_probe
__driver_probe_device
driver_probe_device
__driver_attach
bus_for_each_dev
driver_attach
bus_add_driver
driver_register
__platform_driver_register
dwc3_driver_init
do_one_initcall
kernel_init_freeable
kernel_init
ret_from_fork
# ls -l /sys//devices/platform/808622B7:01/xhci-hcd.3.auto/software_node
lrwxrwxrwx 1 root root 0 Nov 9 03:18 /sys//devices/platform/808622B7:01/xhci-hcd.3.auto/software_node -> ../../../../kernel/software_nodes/node4
# ls -l /sys//devices/platform/808622B7:01/software_node
lrwxrwxrwx 1 root root 0 Nov 9 03:18 /sys//devices/platform/808622B7:01/software_node -> ../../../kernel/software_nodes/node4
On Mon, Nov 08, 2021 at 11:43:54PM -0500, Qian Cai wrote:
> Then, which functions do you suggest to replace with
> fwnode_create_software_node()? In dwc3_host_init(),
>
> int dwc3_host_init(struct dwc3 *dwc)
> {
> ...
> xhci = platform_device_alloc("xhci-hcd", PLATFORM_DEVID_AUTO);
> ...
> ret = platform_device_add(xhci);
>
> I am wondering if that we could solve the problem by avoiding
> "xhci-hcd" string here which would unfortunately clash with
> xhci_plat_init() as mentioned before:
Okay, I suppose that name has to be "xhci-hcd" to match the dirver
name. Otherwise, the below path did not run to create "xhci-hcd"
either. I noticed that the regression was discussed a few months ago
and leave it as is.
https://lore.kernel.org/lkml/[email protected]/
Alternatively, we might revert the commit 434b73e61cc6
("iommu/arm-smmu-v3: Use device properties for pasid-num-bits")
started to use device_add_properties() in iort_named_component_init()
which probably does not look pretty either. I can't think of any other
ways to avoid refactoring at the moment.
>
> sysfs_create_link
> software_node_notify
> device_create_managed_software_node
> iort_named_component_init
> iort_iommu_configure_id
> acpi_dma_configure_id
> platform_dma_configure
> really_probe.part.0
> really_probe
> __driver_probe_device
> driver_probe_device
> __driver_attach
> bus_for_each_dev
> driver_attach
> bus_add_driver
> driver_register
> __platform_driver_register
> xhci_plat_init
> do_one_initcall
> kernel_init_freeable
> kernel_init
> ret_from_fork
On Fri, Nov 05, 2021 at 09:39:42PM +0200, Andy Shevchenko wrote:
> > Anyway, what's the "upper layer"? Is that "struct device" or "struct
> > swnode"? I suppose you meant:
>
> struct device here.
>
> > - Remove "secondary" field from "struct fwnode_handle".
> > - Replace "fwnode" from "upper layer" with
> > "struct list_head fwnode_head;".
> > - Modify all functions in "software_node_ops" to use "fwnode_head".
> >
> > Is that correct?
>
> Yes.
>
> It might be a bit complicated taking into account how much fwnode is
> spreaded in the kernel... Basically, you need to fix all direct
> accesses to the dev->fwnode first.
> Besides that you need to check that fwnode, which is used out of the
> device scope, like in IRQ domains, doesn't use secondary pointer(s).
>
> This nevertheless adds a lot of flexibility and we may add whatever
> type of fwnodes and mix them together.
Okay, here is my plan until someone still has an idea to avoid a
redesign.
Frist, fixes all dev->fwnode / dev.fwnode to use dev_fwnode(). This
could be a standalone tree-wide patchset going out to avoid
heavy-lifting later.
Then, we can create another patchset on top. I have audited
"irq_domain" but not seen any "secondary" leakage. Struct
"cht_int33fe_data" does have some need to fix.
Rename set_secondary_fwnode() to insert_secondary_fwnode(). Fix things
in drivers/base/core.c, swnode.c etc to use the new fwnode_head and
anything I can't think of right now.
Since we will have multiple "software_node" (secondary fwnode:s) for a
single "device". What would be the usual way to deal with a
linked-list in the sysfs? I can think of just let "software_node"
become a directory to host a list of symlinks named from
swnode->id. Thoughts?
On Tue, Nov 16, 2021 at 4:54 AM Qian Cai <[email protected]> wrote:
>
> On Fri, Nov 05, 2021 at 09:39:42PM +0200, Andy Shevchenko wrote:
> > > Anyway, what's the "upper layer"? Is that "struct device" or "struct
> > > swnode"? I suppose you meant:
> >
> > struct device here.
> >
> > > - Remove "secondary" field from "struct fwnode_handle".
> > > - Replace "fwnode" from "upper layer" with
> > > "struct list_head fwnode_head;".
> > > - Modify all functions in "software_node_ops" to use "fwnode_head".
> > >
> > > Is that correct?
> >
> > Yes.
> >
> > It might be a bit complicated taking into account how much fwnode is
> > spreaded in the kernel... Basically, you need to fix all direct
> > accesses to the dev->fwnode first.
> > Besides that you need to check that fwnode, which is used out of the
> > device scope, like in IRQ domains, doesn't use secondary pointer(s).
> >
> > This nevertheless adds a lot of flexibility and we may add whatever
> > type of fwnodes and mix them together.
>
> Okay, here is my plan until someone still has an idea to avoid a
> redesign.
>
> Frist, fixes all dev->fwnode / dev.fwnode to use dev_fwnode(). This
> could be a standalone tree-wide patchset going out to avoid
> heavy-lifting later.
>
> Then, we can create another patchset on top. I have audited
> "irq_domain" but not seen any "secondary" leakage. Struct
> "cht_int33fe_data" does have some need to fix.
>
> Rename set_secondary_fwnode() to insert_secondary_fwnode(). Fix things
> in drivers/base/core.c, swnode.c etc to use the new fwnode_head and
> anything I can't think of right now.
>
> Since we will have multiple "software_node" (secondary fwnode:s) for a
> single "device". What would be the usual way to deal with a
> linked-list in the sysfs? I can think of just let "software_node"
> become a directory to host a list of symlinks named from
> swnode->id. Thoughts?
Note that one pointer dereference in ACPI_COMPANION() is enough.
On Tue, Nov 16, 2021 at 05:29:56PM +0100, Rafael J. Wysocki wrote:
> > Frist, fixes all dev->fwnode / dev.fwnode to use dev_fwnode(). This
> > could be a standalone tree-wide patchset going out to avoid
> > heavy-lifting later.
> >
> > Then, we can create another patchset on top. I have audited
> > "irq_domain" but not seen any "secondary" leakage. Struct
> > "cht_int33fe_data" does have some need to fix.
> >
> > Rename set_secondary_fwnode() to insert_secondary_fwnode(). Fix things
> > in drivers/base/core.c, swnode.c etc to use the new fwnode_head and
> > anything I can't think of right now.
> >
> > Since we will have multiple "software_node" (secondary fwnode:s) for a
> > single "device". What would be the usual way to deal with a
> > linked-list in the sysfs? I can think of just let "software_node"
> > become a directory to host a list of symlinks named from
> > swnode->id. Thoughts?
>
> Note that one pointer dereference in ACPI_COMPANION() is enough.
Rafael, we suppose to convert ACPI_COMPANION() to:
to_acpi_device_node(dev_fwnode())
since we will no longer has a dev->fwnode pointer anymore. Do you
suggest to keep that pointer but convert the "secondary" to a linked
list instead?
On Wed, Nov 17, 2021 at 3:38 PM Qian Cai <[email protected]> wrote:
>
> On Tue, Nov 16, 2021 at 05:29:56PM +0100, Rafael J. Wysocki wrote:
> > > Frist, fixes all dev->fwnode / dev.fwnode to use dev_fwnode(). This
> > > could be a standalone tree-wide patchset going out to avoid
> > > heavy-lifting later.
> > >
> > > Then, we can create another patchset on top. I have audited
> > > "irq_domain" but not seen any "secondary" leakage. Struct
> > > "cht_int33fe_data" does have some need to fix.
> > >
> > > Rename set_secondary_fwnode() to insert_secondary_fwnode(). Fix things
> > > in drivers/base/core.c, swnode.c etc to use the new fwnode_head and
> > > anything I can't think of right now.
> > >
> > > Since we will have multiple "software_node" (secondary fwnode:s) for a
> > > single "device". What would be the usual way to deal with a
> > > linked-list in the sysfs? I can think of just let "software_node"
> > > become a directory to host a list of symlinks named from
> > > swnode->id. Thoughts?
> >
> > Note that one pointer dereference in ACPI_COMPANION() is enough.
>
> Rafael, we suppose to convert ACPI_COMPANION() to:
>
> to_acpi_device_node(dev_fwnode())
>
> since we will no longer has a dev->fwnode pointer anymore. Do you
> suggest to keep that pointer but convert the "secondary" to a linked
> list instead?
Yes, please.
On Wed, Nov 17, 2021 at 03:45:34PM +0100, Rafael J. Wysocki wrote:
> > since we will no longer has a dev->fwnode pointer anymore. Do you
> > suggest to keep that pointer but convert the "secondary" to a linked
> > list instead?
>
> Yes, please.
Sounds good. I think that would simplify the changes of the existing
interfaces even though only to mantain one fwnode_head would be a bit
cleaner. Though, that cleanup could always be on top later if needed.