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
