Thank you Lukas and Mika!
This is very useful and helpful!
I am setting up two alternative builds with both of your suggested
approaches and will test on devices once I get back into the office,
hopefully around next week.
> + /*
> + * Any integrated Thunderbolt 3/4 PCIe root ports from Intel
> + * before Alder Lake do not have the above device property so we
> + * use their PCI IDs instead. All these are tunneled. This list
> + * is not expected to grow.
> + */
> + if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> + switch (pdev->device) {
> + /* Ice Lake Thunderbolt 3 PCIe Root Ports */
> + case 0x8a1d:
> + case 0x8a1f:
> + case 0x8a21:
> + case 0x8a23:
> + /* Tiger Lake-LP Thunderbolt 4 PCIe Root Ports */
> + case 0x9a23:
> + case 0x9a25:
> + case 0x9a27:
> + case 0x9a29:
> + /* Tiger Lake-H Thunderbolt 4 PCIe Root Ports */
> + case 0x9a2b:
> + case 0x9a2d:
> + case 0x9a2f:
> + case 0x9a31:
> + return true;
> + }
> + }
> +
Something I noticed is that the list of root ports you have there does
not include [8086:02b4] or [8086:9db4], the Comet Lake and
Whiskey/Cannon Point root ports that I saw on the laptops I tested on.
Those laptops do not have the usb4-host-interface property. This makes
me think that the patch won't work as is.
Then I queried for up all the root ports on all of our devices that
are confirmed to be affected by this bug. Here they are as a
reference:
Cannon Point (6 devices in our lab with different combos of these root ports)
9db8 #1
9dbc #5
9dbe: #7
9dbf #8
9db0 #9
9db4 #13
Comet Lake (7 devices in our lab with different combos of these root ports)
02b8 #1
02bc #5
02b0 #9
06b0 #9 (one device had this variation of #9)
02b4 #13
Tiger Lake (1 device in our lab)
a0bf #8 (the root port's device id is different from all the ones on your list)
After first trying your fix as-is, I can vary the list to add all
these root port devices to see if that has an effect. It seems like
this list might have to be longer than it currently is though.
