| Message ID | 20220204182820.130339-1-mario.limonciello@amd.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Mark USB4 controllers as is_thunderbolt | expand |
[Public] > -----Original Message----- > From: Limonciello, Mario <Mario.Limonciello@amd.com> > Sent: Friday, February 4, 2022 1:28 PM > To: Bjorn Helgaas <bhelgaas@google.com>; Andreas Noever > <andreas.noever@gmail.com>; Mika Westerberg > <mika.westerberg@linux.intel.com>; open list:PCI SUBSYSTEM <linux- > pci@vger.kernel.org>; open list:THUNDERBOLT DRIVER <linux- > usb@vger.kernel.org> > Cc: Michael Jamet <michael.jamet@intel.com>; Yehezkel Bernat > <YehezkelShB@gmail.com>; Deucher, Alexander > <Alexander.Deucher@amd.com>; Limonciello, Mario > <Mario.Limonciello@amd.com> > Subject: [PATCH 0/2] Mark USB4 controllers as is_thunderbolt > > 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" Series is: Acked-by: Alex Deucher <alexander.deucher@amd.com> > > drivers/pci/probe.c | 4 ++-- > drivers/thunderbolt/nhi.h | 2 -- > include/linux/pci_ids.h | 1 + > 3 files changed, 3 insertions(+), 4 deletions(-) > > -- > 2.34.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!
[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
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". 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.
[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
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
Hi, On Mon, Feb 07, 2022 at 06:47:03PM +0100, Lukas Wunner wrote: > 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. In case of dGPU, the thing (I think) that is needed is whether there is some sort of power resource attached to the root port that allows powering it down or so. That can still be done without is_thunderbolt flag using the current ACPI functions. [ IMHO we should get rid of that flag completely, or rename it to some more generic like "removable" (following USB, perhaps moving to driver core) that allows drivers to check if the device is soldered on the motherboard or hanging off of some hotpluggable port. ]