[PATCH v2] usb: acpi: fix boot hang due to early incorrect 'tunneled' USB3 device links

[PATCH v2] usb: acpi: fix boot hang due to early incorrect 'tunneled' USB3 device links

[Mathias Nyman]

Fix a boot hang issue triggered when a USB3 device is incorrectly assumed
to be tunneled over USB4, thus attempting to create a device link between
the USB3 "consumer" device and the USB4 "supplier" Host Interface before
the USB4 side is properly bound to a driver.

This could happen if xhci isn't capable of detecting tunneled devices,
but ACPI tables contain all info needed to assume device is tunneled.
i.e. udev->tunnel_mode == USB_LINK_UNKNOWN.

It turns out that even for actual tunneled USB3 devices it can't be
assumed that the thunderbolt driver providing the tunnel is loaded
before the tunneled USB3 device is created.
The tunnel can be created by BIOS and remain in use by thunderbolt/USB4
host driver once it loads.

Solve this by making the device link "stateless", which doesn't create
a driver presence order dependency between the supplier and consumer
drivers.
It still guarantees correct suspend/resume and shutdown ordering.

cc: Mario Limonciello <mario.limonciello@amd.com>
Fixes: f1bfb4a6fed6 ("usb: acpi: add device link between tunneled USB3 device and USB4 Host Interface")
Tested-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
---
 v2: Use stateless device link instead of checking if driver is bound

 drivers/usb/core/usb-acpi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 21585ed89ef8..03c22114214b 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -170,11 +170,11 @@ static int usb_acpi_add_usb4_devlink(struct usb_device *udev)
 	struct fwnode_handle *nhi_fwnode __free(fwnode_handle) =
 		fwnode_find_reference(dev_fwnode(&port_dev->dev), "usb4-host-interface", 0);
 
-	if (IS_ERR(nhi_fwnode))
+	if (IS_ERR(nhi_fwnode) || !nhi_fwnode->dev)
 		return 0;
 
 	link = device_link_add(&port_dev->child->dev, nhi_fwnode->dev,
-			       DL_FLAG_AUTOREMOVE_CONSUMER |
+			       DL_FLAG_STATELESS |
 			       DL_FLAG_RPM_ACTIVE |
 			       DL_FLAG_PM_RUNTIME);
 	if (!link) {
-- 
2.25.1

Re: [PATCH v2] usb: acpi: fix boot hang due to early incorrect 'tunneled' USB3 device links

[Mario Limonciello]

On 10/24/2024 08:13, Mathias Nyman wrote:
> Fix a boot hang issue triggered when a USB3 device is incorrectly assumed
> to be tunneled over USB4, thus attempting to create a device link between
> the USB3 "consumer" device and the USB4 "supplier" Host Interface before
> the USB4 side is properly bound to a driver.
> 
> This could happen if xhci isn't capable of detecting tunneled devices,
> but ACPI tables contain all info needed to assume device is tunneled.
> i.e. udev->tunnel_mode == USB_LINK_UNKNOWN.
> 
> It turns out that even for actual tunneled USB3 devices it can't be
> assumed that the thunderbolt driver providing the tunnel is loaded
> before the tunneled USB3 device is created.
> The tunnel can be created by BIOS and remain in use by thunderbolt/USB4
> host driver once it loads.
> 
> Solve this by making the device link "stateless", which doesn't create
> a driver presence order dependency between the supplier and consumer
> drivers.
> It still guarantees correct suspend/resume and shutdown ordering.
> 
> cc: Mario Limonciello <mario.limonciello@amd.com>
> Fixes: f1bfb4a6fed6 ("usb: acpi: add device link between tunneled USB3 device and USB4 Host Interface")
> Tested-by: Harry Wentland <harry.wentland@amd.com>
Tested-by: Mario Limonciello <mario.limonciello@amd.com>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> ---
>   v2: Use stateless device link instead of checking if driver is bound
> 
>   drivers/usb/core/usb-acpi.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
> index 21585ed89ef8..03c22114214b 100644
> --- a/drivers/usb/core/usb-acpi.c
> +++ b/drivers/usb/core/usb-acpi.c
> @@ -170,11 +170,11 @@ static int usb_acpi_add_usb4_devlink(struct usb_device *udev)
>   	struct fwnode_handle *nhi_fwnode __free(fwnode_handle) =
>   		fwnode_find_reference(dev_fwnode(&port_dev->dev), "usb4-host-interface", 0);
>   
> -	if (IS_ERR(nhi_fwnode))
> +	if (IS_ERR(nhi_fwnode) || !nhi_fwnode->dev)
>   		return 0;
>   
>   	link = device_link_add(&port_dev->child->dev, nhi_fwnode->dev,
> -			       DL_FLAG_AUTOREMOVE_CONSUMER |
> +			       DL_FLAG_STATELESS |
>   			       DL_FLAG_RPM_ACTIVE |
>   			       DL_FLAG_PM_RUNTIME);
>   	if (!link) {

Re: [PATCH v2] usb: acpi: fix boot hang due to early incorrect 'tunneled' USB3 device links

[Mika Westerberg]

On Thu, Oct 24, 2024 at 04:13:55PM +0300, Mathias Nyman wrote:
> Fix a boot hang issue triggered when a USB3 device is incorrectly assumed
> to be tunneled over USB4, thus attempting to create a device link between
> the USB3 "consumer" device and the USB4 "supplier" Host Interface before
> the USB4 side is properly bound to a driver.
> 
> This could happen if xhci isn't capable of detecting tunneled devices,
> but ACPI tables contain all info needed to assume device is tunneled.
> i.e. udev->tunnel_mode == USB_LINK_UNKNOWN.
> 
> It turns out that even for actual tunneled USB3 devices it can't be
> assumed that the thunderbolt driver providing the tunnel is loaded
> before the tunneled USB3 device is created.
> The tunnel can be created by BIOS and remain in use by thunderbolt/USB4
> host driver once it loads.
> 
> Solve this by making the device link "stateless", which doesn't create
> a driver presence order dependency between the supplier and consumer
> drivers.
> It still guarantees correct suspend/resume and shutdown ordering.
> 
> cc: Mario Limonciello <mario.limonciello@amd.com>
> Fixes: f1bfb4a6fed6 ("usb: acpi: add device link between tunneled USB3 device and USB4 Host Interface")
> Tested-by: Harry Wentland <harry.wentland@amd.com>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>

Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>