ACK/Cmnt: [PATCH 0/4][SRU][Jammy/Unstable/OEM-5.17] Bolt doesn't work with native USB4 hosts

[Tim Gardner]

Acked-by: Tim Gardner <tim.gardner at canonical.com>

Patches 1-3 are merged upstream. Patch 4 is still linux-next.

On 4/7/22 11:17, You-Sheng Yang wrote:
> BugLink: https://bugs.launchpad.net/bugs/1962349
> 
> [Impact]
> 
>   * AMD Yellow Carp provides integrated USB4 host controllers
>   * When plugging in a Thunderbolt3 or USB4 device, users are unable to authorize
>     it using the GUI due to an error message: "parent not authorized, deferring"
> 
> [Test Plan]
> 
> AMD Yellow Carp Host (issue this bug is about)
> ----------------------------------------------
>   * Plug in USB4 device or TBT3 to AMD Yellow Carp host
>   * Ensure that PCI topology has populated
>   * Observe that /sys/bus/thunderbolt/devices/DEVICE/authorized is "0"
>   * Try to run `boltctl enroll $UUID`
> 
> Alpine Ridge / Titan Ridge host (discrete controller)
> ------------------------------------------------------
> Start out on a host with discrete controller (Alpine Ridge or Titan Ridge)
> 1. sudo boltctl forget -a
> 2. Plug in dock
> 3. Make sure 'boltctl list' enumerates dock.
> 4. Check /sys/bus/thunderbolt/devices/domain0/iommu_dma_protection (value
>     dependent upon host)
>     - If 0; try to manually enroll using 'boltctl enroll $UUID'
>     - If 1; ensure that device automatically enrolled with bolt.
> 
> GUI Check
> ---------
> Ensure that devices show up in the Settings GUI and are now able to authorize.
> Note: for AMD platforms enumerating PCIe devices is a separate problem from BOLT
> handled by kernel tasks. GUI check is only about "authorization".
> 
> [Where problems could occur]
> 
>   * Intel USB4 or TBT3 hosts also use bolt. They could have a problem with the
>     new version of bolt.
>   * This is very unlikely however since there is a through test suite, and up
>     until now the entire industry has been using bolt on Intel controllers for a
>     long time.
>   * There haven't been any significant bugs reported upstream or in Ubuntu since
>     0.9.1 release.
> 
> [Other Info]
>   * This bug also occurs on Intel controllers from ICL, TGL or ALD, but in many
>     cases they are automatically authorized to an iommu DMA policy.
>   * It is fixed in bolt 0.9.1 or later release.
>   * To solve the SRU, will backport 0.9.1 release from Impish.
>   * I did look into backporting just the commit(s) for fixing this, but it's not
>     a trivial backport. Quoting the changelog
>     (https://gitlab.freedesktop.org/bolt/bolt/-/blob/master/CHANGELOG.md):
>     "Additionally the unique_id of said host controller changes with every boot,
>     which breaks one of the fundamental assumptions in boltd".
> 
> Mario Limonciello (4):
>    thunderbolt: Retry DROM reads for more failure scenarios
>    thunderbolt: Do not resume routers if UID is not set
>    thunderbolt: Do not make DROM read success compulsory
>    PCI/ACPI: Allow D3 only if Root Port can signal and wake from D3
> 
>   drivers/pci/pci-acpi.c       | 41 ++++++++++++++++++++++++++----------
>   drivers/thunderbolt/eeprom.c | 17 +++++++++------
>   drivers/thunderbolt/switch.c | 10 +++++----
>   3 files changed, 46 insertions(+), 22 deletions(-)
> 

-- 
-----------
Tim Gardner
Canonical, Inc