Thunderbolt: add initial Titan Ridge support

[ngie]

Summary

The PCI IDs were grabbed from the Linux thunderbolt driver [1]. No
additional support or logic was pulled from the Linux driver because
the other required scaffolding was already present.

Obtained from: Linux
(https://github.com/torvalds/linux/blob/eb71ab2bf72260054677e348498ba995a057c463/drivers/thunderbolt/nhi.h#L71-L75)

Test Plan

My thunderbolt(4) now attaches properly on my MacBookPro16,1.

Real world testing of hardware support pending.

[ngie]

Fix up the PCI ID for DEVICE_TR_2C_NHI (bad-copy paste on my part)

[ngie]

One thing I found interesting in this exercise is that the PCI IDs are flip flopped between FreeBSD and Linux: the NHI PCI IDs on FreeBSD are the TB PCIB PCI IDs and vice versa.

[obiwac]

I'm not entirely sure if titan ridge supports having a HCM (USB4) or if it is ICM-only (linux uses its ICM it would seem), and short of checking if the progif is USB4 (0x40) or just trying it out, I don't know how to be sure a device supports HCM. In any case, D52861 will end up removing support for non-generic USB4 NHIs.

[obiwac]

One thing I found interesting in this exercise is that the PCI IDs are flip flopped between FreeBSD and Linux: the NHI PCI IDs on FreeBSD are the TB PCIB PCI IDs and vice versa.

Some of these IDs may be wrong (can't find DEVICE_AR_2C_NHI's 0x1575 in the linux code, and I don't know which hardware @scottl was primarily testing), but which ones are flip-flopped? they mostly seem to match to me.

[ngie]

In D55635#1273085, @obiwac wrote:

One thing I found interesting in this exercise is that the PCI IDs are flip flopped between FreeBSD and Linux: the NHI PCI IDs on FreeBSD are the TB PCIB PCI IDs and vice versa.

Some of these IDs may be wrong (can't find DEVICE_AR_2C_NHI's 0x1575 in the linux code, and I don't know which hardware @scottl was primarily testing), but which ones are flip-flopped? they mostly seem to match to me.

Just a WAG, but the DEVICE_AR_2C_NHI PCI ID might have been from a pre-production version of the card/chipset.

As far as the PCI IDs were concerned, my brain was misaligning the lines, so all's good (my cognitive wires just got crossed a few days ago).

[scottl]

The AR_2C_NHI Ids probably came from https://admin.pci-ids.ucw.cz/read/PC/8086/1575. I never had pre-production hardware.

I assume that TR has an ICM, but if you've removed the ICM code from freebsd then that's moot. I would kinda recommend bringing the ICM code back and supporting TR and ICL controllers with it until you've written a comprehensive HCM. Just stay away from AR host controllers.

[ngie]

In D55635#1273148, @scottl wrote:

The AR_2C_NHI Ids probably came from https://admin.pci-ids.ucw.cz/read/PC/8086/1575. I never had pre-production hardware.

I assume that TR has an ICM, but if you've removed the ICM code from freebsd then that's moot. I would kinda recommend bringing the ICM code back and supporting TR and ICL controllers with it until you've written a comprehensive HCM. Just stay away from AR host controllers.

I haven't removed anything from thunderbolt(4) on FreeBSD. I'm trying to get the driver to work with my Intel Macs so I have less of a reason to bin the devices. Right now my only option is to go straight to GNU/Linux and deal with the annoyance of having to setup ZFS on GNU/Linux. I really don't want to deal with the clowny mess of dkms, managing a bunch of Linux kernel patches (Apple, ZFS), etc. I've already been down that road with Arch/Gentoo Linux over a decade ago..

[obiwac]

I assume that TR has an ICM, but if you've removed the ICM code from freebsd then that's moot. I would kinda recommend bringing the ICM code back and supporting TR and ICL controllers with it until you've written a comprehensive HCM. Just stay away from AR host controllers.

I mean we can bring the ICM code in, but you did say in your original email to steer clear of TB3 controllers and to remove the ICM code, and I do not have the means nor the time to test titan ridge and icelake and make sure they work. I would eventually like to work on the HCM though.

[scottl]

What I meant by "kinda recommending" is that if you're going to support TB3 PCI IDs, then bring back the ICM code until you've written an HCM to replace it. Otherwise you're relying on people to find the right option in their BIOS to disable the ICM challenge-response authorization exchange with devices.

[obiwac]

In D55635#1273245, @scottl wrote:

What I meant by "kinda recommending" is that if you're going to support TB3 PCI IDs, then bring back the ICM code until you've written an HCM to replace it. Otherwise you're relying on people to find the right option in their BIOS to disable the ICM challenge-response authorization exchange with devices.

Yeah, those should've just been removed in the initial import.

@ngie: is it alright if, for the time being, we get D52861 landed, and then we take another look at resurrecting the ICM code once you've confirmed your and @guest-seuros's hardware can't work with just a HCM?

[ngie]

In D55635#1273248, @obiwac wrote:

In D55635#1273245, @scottl wrote:

What I meant by "kinda recommending" is that if you're going to support TB3 PCI IDs, then bring back the ICM code until you've written an HCM to replace it. Otherwise you're relying on people to find the right option in their BIOS to disable the ICM challenge-response authorization exchange with devices.

Yeah, those should've just been removed in the initial import.

@ngie: is it alright if, for the time being, we get D52861 landed, and then we take another look at resurrecting the ICM code once you've confirmed your and @guest-seuros's hardware can't work with just a HCM?

As long as the TB3 support isn't deleted, sure.