mbox series

[0/2] Mark USB4 controllers as is_thunderbolt

Message ID 20220204182820.130339-1-mario.limonciello@amd.com
Headers show
Series Mark USB4 controllers as is_thunderbolt | expand

Message

Mario Limonciello Feb. 4, 2022, 6:28 p.m. UTC
Various drivers in the kernel use `pci_is_thunderbolt_attached` to
designate behaving differently from a device that is internally in
the machine. This function relies upon the `is_thunderbolt` designation
which checks for a specific capability only set on Intel controllers.

Non-Intel USB4 designs should also match this designation so that they
can be treated the same regardless of the host they're connected to.

Mario Limonciello (2):
  thunderbolt: move definition of PCI_CLASS_SERIAL_USB_USB4
  pci: mark USB4 devices as "is_thunderbolt"

 drivers/pci/probe.c       | 4 ++--
 drivers/thunderbolt/nhi.h | 2 --
 include/linux/pci_ids.h   | 1 +
 3 files changed, 3 insertions(+), 4 deletions(-)

Comments

Mika Westerberg Feb. 7, 2022, 6:41 a.m. UTC | #1
Hi Mario,

On Fri, Feb 04, 2022 at 12:28:18PM -0600, Mario Limonciello wrote:
> Various drivers in the kernel use `pci_is_thunderbolt_attached` to
> designate behaving differently from a device that is internally in
> the machine. This function relies upon the `is_thunderbolt` designation
> which checks for a specific capability only set on Intel controllers.
> 
> Non-Intel USB4 designs should also match this designation so that they
> can be treated the same regardless of the host they're connected to.

Not objecting this if really needed but since USB4 is supposed to be
transparent to the native (tunneled) protocol, I would rather try to
figure out if there is really need to change driver behaviour whether it
is connected over USB4 or plugged natively on the PCIe slot.

Can you elaborate a bit what kind of functionality needs this? Perhaps
we can figure a better alternative?

Thanks!
Deucher, Alexander Feb. 7, 2022, 3 p.m. UTC | #2
[Public]

> -----Original Message-----
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> Sent: Monday, February 7, 2022 1:42 AM
> To: Limonciello, Mario <Mario.Limonciello@amd.com>
> Cc: Bjorn Helgaas <bhelgaas@google.com>; Andreas Noever
> <andreas.noever@gmail.com>; open list:PCI SUBSYSTEM <linux-
> pci@vger.kernel.org>; open list:THUNDERBOLT DRIVER <linux-
> usb@vger.kernel.org>; Michael Jamet <michael.jamet@intel.com>; Yehezkel
> Bernat <YehezkelShB@gmail.com>; Deucher, Alexander
> <Alexander.Deucher@amd.com>
> Subject: Re: [PATCH 0/2] Mark USB4 controllers as is_thunderbolt
> 
> Hi Mario,
> 
> On Fri, Feb 04, 2022 at 12:28:18PM -0600, Mario Limonciello wrote:
> > Various drivers in the kernel use `pci_is_thunderbolt_attached` to
> > designate behaving differently from a device that is internally in the
> > machine. This function relies upon the `is_thunderbolt` designation
> > which checks for a specific capability only set on Intel controllers.
> >
> > Non-Intel USB4 designs should also match this designation so that they
> > can be treated the same regardless of the host they're connected to.
> 
> Not objecting this if really needed but since USB4 is supposed to be
> transparent to the native (tunneled) protocol, I would rather try to figure out
> if there is really need to change driver behaviour whether it is connected
> over USB4 or plugged natively on the PCIe slot.
> 
> Can you elaborate a bit what kind of functionality needs this? Perhaps we can
> figure a better alternative?

In the AMD GPU driver we use it to determine which dGPU is built into a platform vs. externally connected since the internal one uses ACPI for certain things and the external one does not.  There are probably other ways to determine this, but it's not in place at the moment.

Alex
Deucher, Alexander Feb. 7, 2022, 3:52 p.m. UTC | #3
[Public]

> -----Original Message-----
> From: Mika Westerberg <mika.westerberg@linux.intel.com>
> Sent: Monday, February 7, 2022 10:45 AM
> To: Deucher, Alexander <Alexander.Deucher@amd.com>
> Cc: Limonciello, Mario <Mario.Limonciello@amd.com>; Bjorn Helgaas
> <bhelgaas@google.com>; Andreas Noever <andreas.noever@gmail.com>;
> open list:PCI SUBSYSTEM <linux-pci@vger.kernel.org>; open
> list:THUNDERBOLT DRIVER <linux-usb@vger.kernel.org>; Michael Jamet
> <michael.jamet@intel.com>; Yehezkel Bernat <YehezkelShB@gmail.com>
> Subject: Re: [PATCH 0/2] Mark USB4 controllers as is_thunderbolt
> 
> Hi,
> 
> On Mon, Feb 07, 2022 at 03:00:19PM +0000, Deucher, Alexander wrote:
> > [Public]
> >
> > > -----Original Message-----
> > > From: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > Sent: Monday, February 7, 2022 1:42 AM
> > > To: Limonciello, Mario <Mario.Limonciello@amd.com>
> > > Cc: Bjorn Helgaas <bhelgaas@google.com>; Andreas Noever
> > > <andreas.noever@gmail.com>; open list:PCI SUBSYSTEM <linux-
> > > pci@vger.kernel.org>; open list:THUNDERBOLT DRIVER <linux-
> > > usb@vger.kernel.org>; Michael Jamet <michael.jamet@intel.com>;
> > > Yehezkel Bernat <YehezkelShB@gmail.com>; Deucher, Alexander
> > > <Alexander.Deucher@amd.com>
> > > Subject: Re: [PATCH 0/2] Mark USB4 controllers as is_thunderbolt
> > >
> > > Hi Mario,
> > >
> > > On Fri, Feb 04, 2022 at 12:28:18PM -0600, Mario Limonciello wrote:
> > > > Various drivers in the kernel use `pci_is_thunderbolt_attached` to
> > > > designate behaving differently from a device that is internally in
> > > > the machine. This function relies upon the `is_thunderbolt`
> > > > designation which checks for a specific capability only set on Intel
> controllers.
> > > >
> > > > Non-Intel USB4 designs should also match this designation so that
> > > > they can be treated the same regardless of the host they're connected
> to.
> > >
> > > Not objecting this if really needed but since USB4 is supposed to be
> > > transparent to the native (tunneled) protocol, I would rather try to
> > > figure out if there is really need to change driver behaviour
> > > whether it is connected over USB4 or plugged natively on the PCIe slot.
> > >
> > > Can you elaborate a bit what kind of functionality needs this?
> > > Perhaps we can figure a better alternative?
> >
> > In the AMD GPU driver we use it to determine which dGPU is built into
> > a platform vs. externally connected since the internal one uses ACPI
> > for certain things and the external one does not.  There are probably
> > other ways to determine this, but it's not in place at the moment.
> 
> Can't you check if the device is behind a hotplug bridge? Then for certain it is
> "removable".

Unfortunately, most (all?) of the root ports on modern platforms are hotplug capable even if the hardware is soldered to the board.

> 
> The other option is to look for ACPI companion (ACPI_COMPANION()) of the
> device. AFAICT dGPUs don't have one (as the BIOS does not know in advance
> what will be connected to the hotplug ports) whereas internal does typically
> have one.

Yeah, this is probably the right way to do this.

Alex
Lukas Wunner Feb. 7, 2022, 5:47 p.m. UTC | #4
On Mon, Feb 07, 2022 at 03:52:13PM +0000, Deucher, Alexander wrote:
> > From: Mika Westerberg <mika.westerberg@linux.intel.com>
> > The other option is to look for ACPI companion (ACPI_COMPANION()) of the
> > device. AFAICT dGPUs don't have one (as the BIOS does not know in advance
> > what will be connected to the hotplug ports) whereas internal does typically
> > have one.
> 
> Yeah, this is probably the right way to do this.

No, that doesn't work.  At least Apple represents the first few devices
in the Thunderbolt daisy-chain in the ACPI namespace, so IIUC you'd find
an ACPI companion for those but not for the remainder of the daisy-chain.
This is from a 2019/2020 MacBookPro16,1:

$ grep 'Device ' acpidump/mbp161/ssdt6.dsl
            Device (UPSB)
                Device (DSB0)
                    Device (NHI0)
                Device (DSB1)
                    Device (UPS0)
                        Device (DSB0)
                            Device (DEV0)
                        Device (DSB3)
                            Device (UPS0)
                                Device (DSB0)
                                    Device (DEV0)
                                Device (DSB3)
                                    Device (DEV0)
            ...

There's a *reason* why I introduced the is_thunderbolt flag,
there is no other reliable way to detect externally attached devices.

Thanks,

Lukas