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@xxxxxxx/ 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