Ok, looking at the history of bolt, I see we did accept new upstream
version bumps for our LTS series as per the HWE exception policy (e.g.
in bionic). I don't see us having any concrete written down arguments
for that. I'm generally fine with this in this particular case, although
I think we would need a bit more exploratory testing done as part of
verification than just checking for the USB4 issues being resolved.
Could you propose some tests that could be ran to check for regressions?
Another thing I'm a bit worried about is the move of the boltd daemon.
For SRUs we generally dislike binaries changing places. Not sure how
this could affect existing users, I assume usr/lib/bolt/boltd was only
used internally by bolt - but is it possible that someone could rely on
the boltd binary externally? Do you think that's a valid concern? Since
normally I'd feel a bit more calm if this particular change got reverted
in comparison to Debian.
** Changed in: bolt (Ubuntu Focal)
Status: In Progress => Incomplete
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-oem-5.14 in Ubuntu.
https://bugs.launchpad.net/bugs/1962349
Title:
Bolt doesn't work with native USB4 hosts
Status in OEM Priority Project:
New
Status in bolt package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
In Progress
Status in linux-oem-5.14 package in Ubuntu:
Invalid
Status in linux-oem-5.17 package in Ubuntu:
In Progress
Status in bolt source package in Focal:
Incomplete
Status in linux source package in Focal:
Won't Fix
Status in linux-oem-5.14 source package in Focal:
In Progress
Status in linux-oem-5.17 source package in Focal:
Invalid
Status in bolt source package in Impish:
Fix Released
Status in linux source package in Impish:
Won't Fix
Status in linux-oem-5.14 source package in Impish:
Invalid
Status in linux-oem-5.17 source package in Impish:
Invalid
Status in bolt source package in Jammy:
Fix Released
Status in linux source package in Jammy:
In Progress
Status in linux-oem-5.14 source package in Jammy:
Invalid
Status in linux-oem-5.17 source package in Jammy:
In Progress
Bug description:
[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]
* 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`
[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".
To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1962349/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
