linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH] software node: Skip duplicated software_node sysfs
@ 2021-11-01 20:03 Qian Cai
       [not found] ` <CAHp75VcrWPdR8EVGpcsniQedT0J4X700N7thFs6+srTP1MTgwQ@mail.gmail.com>
  0 siblings, 1 reply; 18+ messages in thread
From: Qian Cai @ 2021-11-01 20:03 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andy Shevchenko, Heikki Krogerus, Greg Kroah-Hartman,
	Laurentiu Tudor, linux-acpi, linux-kernel, Qian Cai

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 <quic_qiancai@quicinc.com>
---
 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


^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
       [not found] ` <CAHp75VcrWPdR8EVGpcsniQedT0J4X700N7thFs6+srTP1MTgwQ@mail.gmail.com>
@ 2021-11-02  8:28   ` Heikki Krogerus
  2021-11-02  8:32     ` Heikki Krogerus
  2021-11-02 14:17     ` Qian Cai
  2021-11-02 19:44   ` Qian Cai
  2021-11-05 18:47   ` Qian Cai
  2 siblings, 2 replies; 18+ messages in thread
From: Heikki Krogerus @ 2021-11-02  8:28 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Qian Cai, Rafael J. Wysocki, Andy Shevchenko, Greg Kroah-Hartman,
	Laurentiu Tudor, linux-acpi, linux-kernel

On Tue, Nov 02, 2021 at 01:51:34AM +0200, Andy Shevchenko wrote:
> On Monday, November 1, 2021, Qian Cai <quic_qiancai@quicinc.com> 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 <quic_qiancai@quicinc.com>
> > ---
> >  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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-02  8:28   ` Heikki Krogerus
@ 2021-11-02  8:32     ` Heikki Krogerus
  2021-11-02 14:17     ` Qian Cai
  1 sibling, 0 replies; 18+ messages in thread
From: Heikki Krogerus @ 2021-11-02  8:32 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Qian Cai, Rafael J. Wysocki, Andy Shevchenko, Greg Kroah-Hartman,
	Laurentiu Tudor, linux-acpi, linux-kernel

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 <quic_qiancai@quicinc.com> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-02  8:28   ` Heikki Krogerus
  2021-11-02  8:32     ` Heikki Krogerus
@ 2021-11-02 14:17     ` Qian Cai
  1 sibling, 0 replies; 18+ messages in thread
From: Qian Cai @ 2021-11-02 14:17 UTC (permalink / raw)
  To: Heikki Krogerus, Andy Shevchenko
  Cc: Rafael J. Wysocki, Andy Shevchenko, Greg Kroah-Hartman,
	Laurentiu Tudor, linux-acpi, linux-kernel



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?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
       [not found] ` <CAHp75VcrWPdR8EVGpcsniQedT0J4X700N7thFs6+srTP1MTgwQ@mail.gmail.com>
  2021-11-02  8:28   ` Heikki Krogerus
@ 2021-11-02 19:44   ` Qian Cai
  2021-11-02 20:20     ` Andy Shevchenko
  2021-11-05 18:47   ` Qian Cai
  2 siblings, 1 reply; 18+ messages in thread
From: Qian Cai @ 2021-11-02 19:44 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rafael J. Wysocki, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel



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?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-02 19:44   ` Qian Cai
@ 2021-11-02 20:20     ` Andy Shevchenko
  2021-11-02 20:26       ` Andy Shevchenko
  0 siblings, 1 reply; 18+ messages in thread
From: Andy Shevchenko @ 2021-11-02 20:20 UTC (permalink / raw)
  To: Qian Cai
  Cc: Rafael J. Wysocki, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel

On Tue, Nov 2, 2021 at 9:44 PM Qian Cai <quic_qiancai@quicinc.com> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-02 20:20     ` Andy Shevchenko
@ 2021-11-02 20:26       ` Andy Shevchenko
  0 siblings, 0 replies; 18+ messages in thread
From: Andy Shevchenko @ 2021-11-02 20:26 UTC (permalink / raw)
  To: Qian Cai
  Cc: Rafael J. Wysocki, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel

On Tue, Nov 2, 2021 at 10:20 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Nov 2, 2021 at 9:44 PM Qian Cai <quic_qiancai@quicinc.com> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
       [not found] ` <CAHp75VcrWPdR8EVGpcsniQedT0J4X700N7thFs6+srTP1MTgwQ@mail.gmail.com>
  2021-11-02  8:28   ` Heikki Krogerus
  2021-11-02 19:44   ` Qian Cai
@ 2021-11-05 18:47   ` Qian Cai
  2021-11-05 19:39     ` Andy Shevchenko
  2 siblings, 1 reply; 18+ messages in thread
From: Qian Cai @ 2021-11-05 18:47 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rafael J. Wysocki, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel



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?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-05 18:47   ` Qian Cai
@ 2021-11-05 19:39     ` Andy Shevchenko
  2021-11-08 16:07       ` Qian Cai
  2021-11-16  3:54       ` Qian Cai
  0 siblings, 2 replies; 18+ messages in thread
From: Andy Shevchenko @ 2021-11-05 19:39 UTC (permalink / raw)
  To: Qian Cai
  Cc: Rafael J. Wysocki, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel

On Fri, Nov 5, 2021 at 8:47 PM Qian Cai <quic_qiancai@quicinc.com> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-05 19:39     ` Andy Shevchenko
@ 2021-11-08 16:07       ` Qian Cai
  2021-11-08 18:06         ` Andy Shevchenko
  2021-11-16  3:54       ` Qian Cai
  1 sibling, 1 reply; 18+ messages in thread
From: Qian Cai @ 2021-11-08 16:07 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rafael J. Wysocki, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel



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'

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-08 16:07       ` Qian Cai
@ 2021-11-08 18:06         ` Andy Shevchenko
  2021-11-09  4:43           ` Qian Cai
  0 siblings, 1 reply; 18+ messages in thread
From: Andy Shevchenko @ 2021-11-08 18:06 UTC (permalink / raw)
  To: Qian Cai
  Cc: Rafael J. Wysocki, Heikki Krogerus, Greg Kroah-Hartman,
	Laurentiu Tudor, linux-acpi, linux-kernel

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



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-08 18:06         ` Andy Shevchenko
@ 2021-11-09  4:43           ` Qian Cai
  2021-11-09 15:23             ` Qian Cai
  0 siblings, 1 reply; 18+ messages in thread
From: Qian Cai @ 2021-11-09  4:43 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rafael J. Wysocki, Heikki Krogerus, Greg Kroah-Hartman,
	Laurentiu Tudor, linux-acpi, linux-kernel, Felipe Balbi,
	linux-usb, Lorenzo Pieralisi, linux-arm-kernel

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/20211101200346.16466-1-quic_qiancai@quicinc.com/

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-09  4:43           ` Qian Cai
@ 2021-11-09 15:23             ` Qian Cai
  0 siblings, 0 replies; 18+ messages in thread
From: Qian Cai @ 2021-11-09 15:23 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rafael J. Wysocki, Heikki Krogerus, Greg Kroah-Hartman,
	Laurentiu Tudor, linux-acpi, linux-kernel, Felipe Balbi,
	linux-usb, Lorenzo Pieralisi, linux-arm-kernel

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/e9bc1397-99b7-a57e-4860-80d146848e2c@nxp.com/

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-05 19:39     ` Andy Shevchenko
  2021-11-08 16:07       ` Qian Cai
@ 2021-11-16  3:54       ` Qian Cai
  2021-11-16 16:29         ` Rafael J. Wysocki
  1 sibling, 1 reply; 18+ messages in thread
From: Qian Cai @ 2021-11-16  3:54 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Rafael J. Wysocki, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel

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?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-16  3:54       ` Qian Cai
@ 2021-11-16 16:29         ` Rafael J. Wysocki
  2021-11-17 14:38           ` Qian Cai
  0 siblings, 1 reply; 18+ messages in thread
From: Rafael J. Wysocki @ 2021-11-16 16:29 UTC (permalink / raw)
  To: Qian Cai
  Cc: Andy Shevchenko, Rafael J. Wysocki, Andy Shevchenko,
	Heikki Krogerus, Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi,
	linux-kernel

On Tue, Nov 16, 2021 at 4:54 AM Qian Cai <quic_qiancai@quicinc.com> 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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-16 16:29         ` Rafael J. Wysocki
@ 2021-11-17 14:38           ` Qian Cai
  2021-11-17 14:45             ` Rafael J. Wysocki
  0 siblings, 1 reply; 18+ messages in thread
From: Qian Cai @ 2021-11-17 14:38 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andy Shevchenko, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel

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?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-17 14:38           ` Qian Cai
@ 2021-11-17 14:45             ` Rafael J. Wysocki
  2021-11-17 16:18               ` Qian Cai
  0 siblings, 1 reply; 18+ messages in thread
From: Rafael J. Wysocki @ 2021-11-17 14:45 UTC (permalink / raw)
  To: Qian Cai
  Cc: Rafael J. Wysocki, Andy Shevchenko, Andy Shevchenko,
	Heikki Krogerus, Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi,
	linux-kernel

On Wed, Nov 17, 2021 at 3:38 PM Qian Cai <quic_qiancai@quicinc.com> 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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [RFC PATCH] software node: Skip duplicated software_node sysfs
  2021-11-17 14:45             ` Rafael J. Wysocki
@ 2021-11-17 16:18               ` Qian Cai
  0 siblings, 0 replies; 18+ messages in thread
From: Qian Cai @ 2021-11-17 16:18 UTC (permalink / raw)
  To: Rafael J. Wysocki
  Cc: Andy Shevchenko, Andy Shevchenko, Heikki Krogerus,
	Greg Kroah-Hartman, Laurentiu Tudor, linux-acpi, linux-kernel

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.

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2021-11-17 16:18 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-01 20:03 [RFC PATCH] software node: Skip duplicated software_node sysfs Qian Cai
     [not found] ` <CAHp75VcrWPdR8EVGpcsniQedT0J4X700N7thFs6+srTP1MTgwQ@mail.gmail.com>
2021-11-02  8:28   ` Heikki Krogerus
2021-11-02  8:32     ` Heikki Krogerus
2021-11-02 14:17     ` Qian Cai
2021-11-02 19:44   ` Qian Cai
2021-11-02 20:20     ` Andy Shevchenko
2021-11-02 20:26       ` Andy Shevchenko
2021-11-05 18:47   ` Qian Cai
2021-11-05 19:39     ` Andy Shevchenko
2021-11-08 16:07       ` Qian Cai
2021-11-08 18:06         ` Andy Shevchenko
2021-11-09  4:43           ` Qian Cai
2021-11-09 15:23             ` Qian Cai
2021-11-16  3:54       ` Qian Cai
2021-11-16 16:29         ` Rafael J. Wysocki
2021-11-17 14:38           ` Qian Cai
2021-11-17 14:45             ` Rafael J. Wysocki
2021-11-17 16:18               ` Qian Cai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).