Re: git: 2ed9833791f2 - main - thunderbolt: Import USB4 code

On Sat, 27 Sep 2025, Aymeric Wibo wrote:

> The branch main has been updated by obiwac:
>
> URL: https://cgit.FreeBSD.org/src/commit/?id=2ed9833791f28e14843ac813f90cb030e45948dc
>
> commit 2ed9833791f28e14843ac813f90cb030e45948dc
> Author:     Aymeric Wibo <obiwac@FreeBSD.org>
> AuthorDate: 2025-09-27 11:50:43 +0000
> Commit:     Aymeric Wibo <obiwac@FreeBSD.org>
> CommitDate: 2025-09-27 17:13:13 +0000
>
>    thunderbolt: Import USB4 code
>
>    Add initial USB4 code written by Scott Long and originally passed on to
>    HPS (source: https://github.com/hselasky/usb4), minus the ICM code and
>    with some small fixes.
>
>    For context, older TB chips implemented the connection manager in
>    firmware (ICM) instead of in the OS (HCM), but maintaining the ICM code
>    would be a huge burden for not many chips.

I cannot find a better reference currently to reply to.

This seems to be one of the ICM cases given the warning?

[44.426631] nhi0: <Thunderbolt 3 NHI (Alpine Ridge LP 2C)> mem 0xda000000-0xda03ffff,0xda040000-0xda040fff at device 0.0 on pci5
[44.426653] nhi0: Cannot find Upstream Facing Port
[44.426668] nhi0: attempting to allocate 16 MSI-X vectors (16 supported)
[44.426677] msi: routing MSI-X IRQ 146 to local APIC 0 vector 56
[44.426685] msi: routing MSI-X IRQ 147 to local APIC 2 vector 54
[44.426693] msi: routing MSI-X IRQ 148 to local APIC 4 vector 54
[44.426700] msi: routing MSI-X IRQ 149 to local APIC 6 vector 56
[44.426708] msi: routing MSI-X IRQ 150 to local APIC 0 vector 57
[44.426716] msi: routing MSI-X IRQ 151 to local APIC 2 vector 55
[44.426724] msi: routing MSI-X IRQ 152 to local APIC 4 vector 55
[44.426731] msi: routing MSI-X IRQ 153 to local APIC 6 vector 57
[44.426739] msi: routing MSI-X IRQ 154 to local APIC 0 vector 58
[44.426747] msi: routing MSI-X IRQ 155 to local APIC 2 vector 56
[44.426755] msi: routing MSI-X IRQ 156 to local APIC 4 vector 56
[44.426762] msi: routing MSI-X IRQ 157 to local APIC 6 vector 58
[44.426770] msi: routing MSI-X IRQ 158 to local APIC 0 vector 59
[44.426778] msi: routing MSI-X IRQ 159 to local APIC 2 vector 57
[44.426786] msi: routing MSI-X IRQ 160 to local APIC 4 vector 57
[44.426793] msi: routing MSI-X IRQ 161 to local APIC 6 vector 59
[44.426798] nhi0: using IRQs 146-161 for MSI-X
[44.426976] nhi0: WARN: device uses an internal connection manager
[46.426984] nhi0: tb_router_attach_root()  error.  The driver should be loaded at boot
[46.427115] device_attach: nhi0 attach returned 60
..
[46.431111] acpi_wmi0: <ACPI-WMI mapping> on acpi0
[46.431148] nhi_wmi0: <Thunderbolt WMI Endpoint> on acpi_wmi0


Rather than going through all the resource allocations, can we (if detected to be not supported) just barf and exit or remove the device IDs and not probe at all to avoid all the delay on boot?

That said, the check in nhi_attach can never work as nothing seems to ever set NHI_CAP_ICM?

So the warning presumably comes from nhi_init() which happens at the end of nhi_attach() but it doesn't actually do anything about it and lets it run into follow-up problems?

Maybe the warning should say something about "ICM device. Will never be supported on FreeBSD" or the like?


Another thing that I found non-intuitive for an "nhi" driver was the check:
 	if (resource_disabled("tb", 0))


I understand it's not your code, but I hope we can improve this case a bit given the decision?

/bz

-- 
Bjoern A. Zeeb                                                     r15:7