Re: [PATCH] thunderbolt: Make PCIe NHI support opt-in

[Mika Westerberg]

Hi,

On Wed, Sep 16, 2026 at 06:10:59PM +0200, Konrad Dybcio wrote:
> On 9/16/26 9:59 AM, Mika Westerberg wrote:
> > Hi,
> > 
> > On Tue, Sep 15, 2026 at 07:04:10PM +0200, Konrad Dybcio wrote:
> >> From: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx>
> >>
> >> With more implementations coming in, one may desire not to enable
> >> support for the PCIe-attached NHIs. Allow it to be built as a module
> >> atop the framework.
> > 
> > Is it so that Qualcomm platform does not support PCIe tunneling at all
> > then?
> 
> 
> No, this is about letting one opt out of building in support for
> PCIe-attached NHIs - tunneling stays intact and our hw
> indeed supports it.
> 
> The PCI NHI driver (which this patch makes optional) binds host
> interfaces. TBT PCIe bridges (e.g. PCI 8086:15d3) on connected devices
> with PCIe ports are handled by the pcieport driver.

Yes okay "typically" they go hand-in-hand and that's why I wanted to check.
So you have a PCIe root complex that then exposes the tunneling root ports
as well, got it.

> [...]
> 
> >> +config USB4_PCIE
> >> +	depends on PCI
> >> +	tristate "Support for PCIe-attached USB4 and Thunderbolt controllers"
> > 
> > I think USB4_PCI and so on.
> > 
> >> +	help
> >> +	  Say Y here to add support for the USB4 and Thunderbolt host
> >> +	  routers attached over the PCIe bus, commonly found on x86 PCs.
> >> +
> >> +	  To compile this driver a module, choose M here. The module will be
> >> +	  called thunderbolt_pcie.
> > 
> > thunderbolt_pci
> 
> ack
> 
> [...]
> 
> >> --- a/drivers/thunderbolt/nhi.c
> >> +++ b/drivers/thunderbolt/nhi.c
> >> @@ -548,6 +548,7 @@ irqreturn_t ring_msix(int irq, void *data)
> >>  
> >>  	return IRQ_HANDLED;
> >>  }
> >> +EXPORT_SYMBOL_GPL(ring_msix);
> > 
> > We need to think what is going to be exported and how. For example here
> > ring_msix is pretty common name so if nothing else it needs to be properly
> > namespaced and that should be the first patch in the series.
> 
> Right, maybe EXPORT_SYMBOL_FOR_MODULES would be more fitting..

That or namespace like tb_ring_msix (this one requires probably rename
patch first but may end up looking more consistent wrt naming).

> > Secondly I think it would be good to have this whole thing as part of a
> > patch series that adds the Qualcomm controller support so we have an
> > explanation there why we are doing all this.
> 
> This change isn't really necessary and my reasoning here was to
> let the user decide if support for this specific kind of controllers
> should be built, just like CONFIG_I2C is separate from the dozens of
> implementations.

Yes but there is really no other option at the moment so it does not make
sense to provide yet another selection to the user IMHO. Once we have the
thunderbolt_platform (and thunderbolt_apple) then thunderbolt_pci makes
more sense.