Re: [RFC PATCH] software node: Skip duplicated software_node sysfs

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel