similar to: [PATCH v3 0/7] Improvements to pcie_bandwidth_available() for eGPUs

Fix Thunderbolt-related issues in apple-gmux and vga_switcheroo: Patch [1/5] ("Recognize Thunderbolt devices") has already been subjected to a fair amount of scrutiny over at linux-pci@, I've submitted it 5 times total since May 2016. With luck it may be in ack-able shape now. Patch [2/5] amends apple-gmux to handle combined DP/Thunderbolt ports properly on newer MacBook Pros.

On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote: > Detect on probe whether a PCI device is part of a Thunderbolt controller. > > Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234 > on such devices. Detect presence of this VSEC and cache it in a newly > added is_thunderbolt bit in struct pci_dev. Add a helper to check > whether a given PCI

Detect on probe whether a PCI device is part of a Thunderbolt controller. Intel uses a Vendor-Specific Extended Capability (VSEC) with ID 0x1234 on such devices. Detect presence of this VSEC and cache it in a newly added is_thunderbolt bit in struct pci_dev. Add a helper to check whether a given PCI device is situated on a Thunderbolt daisy chain. The necessity arises from the following: * To

> -----Original Message----- > From: Takashi Iwai <tiwai at suse.de> > Sent: Thursday, August 15, 2019 9:57 AM > To: Alex Deucher > Cc: Karol Herbst; Limonciello, Mario; nouveau; Rafael J . Wysocki; LKML; dri-devel; > Linux ACPI Mailing List; Alex Hung; Ben Skeggs; David Airlie > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to >

> > There are definitely going to be regressions on machines in the field with the > > in tree drivers by reverting this. I think we should have an answer for all of > those > > before this revert is accepted. > > > > Regarding systems with Intel+NVIDIA, we'll have to work with partners to > collect > > some information on the impact of reverting

> -----Original Message----- > From: Karol Herbst <kherbst at redhat.com> > Sent: Thursday, August 15, 2019 9:25 AM > To: Limonciello, Mario > Cc: Dave Airlie; LKML; Linux ACPI Mailing List; dri-devel; nouveau; Rafael J . > Wysocki; Alex Hung; Ben Skeggs; David Airlie > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM _OSI string to > enable dGPU

On Thu, Aug 15, 2019 at 10:15 AM Karol Herbst <kherbst at redhat.com> wrote: > > On Thu, Aug 15, 2019 at 4:13 PM Alex Deucher <alexdeucher at gmail.com> wrote: > > > > On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst <kherbst at redhat.com> wrote: > > > > > > On Thu, Aug 15, 2019 at 3:56 PM <Mario.Limonciello at dell.com> wrote: > >

On Thu, Aug 15, 2019 at 10:25 AM Karol Herbst <kherbst at redhat.com> wrote: > > On Thu, Aug 15, 2019 at 4:20 PM <Mario.Limonciello at dell.com> wrote: > > > > > > There are definitely going to be regressions on machines in the field with the > > > > in tree drivers by reverting this. I think we should have an answer for all of > > > those

On 11/15/2023 04:40, Mika Westerberg wrote: > Hi Mario, > > On Tue, Nov 14, 2023 at 02:07:53PM -0600, Mario Limonciello wrote: >> USB4 routers support a feature called "PCIe tunneling". This >> allows PCIe traffic to be transmitted over USB4 fabric. >> >> PCIe root ports that are used in this fashion can be discovered >> by device specific data

On Thu, 24 Aug 2023 08:36:45 +0100, Lee Jones wrote: > This set is part of a larger effort attempting to clean-up W=1 > kernel builds, which are currently overwhelmingly riddled with > niggly little warnings. > > Cc: Alex Deucher <alexander.deucher at amd.com> > Cc: amd-gfx at lists.freedesktop.org > Cc: Ben Skeggs <bskeggs at redhat.com> > Cc: "Christian

Hi, On Thu, Aug 24, 2023 at 10:59:54AM +0200, Maxime Ripard wrote: > On Thu, 24 Aug 2023 08:36:45 +0100, Lee Jones wrote: > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > > Cc: Alex Deucher <alexander.deucher at amd.com> > > Cc:

From: Sui Jingfeng <suijingfeng at loongson.cn> Currently, the default VGA device selection is not perfect. Potential problems are: 1) This function is a no-op on non-x86 architectures. 2) It does not take the PCI Bar may get relocated into consideration. 3) It is not effective for the PCI device without a dedicated VRAM Bar. 4) It is device-agnostic, thus it has to waste the effort to

On Fri, Feb 24, 2017 at 04:17:24PM -0600, Bjorn Helgaas wrote: > On Fri, Feb 24, 2017 at 08:19:45PM +0100, Lukas Wunner wrote: > > --- a/include/linux/pci.h > > +++ b/include/linux/pci.h > > @@ -358,6 +358,7 @@ struct pci_dev { > > unsigned int is_virtfn:1; > > unsigned int reset_fn:1; > > unsigned int is_hotplug_bridge:1; > > + unsigned int

On Thu, Aug 15, 2019 at 10:04 AM Karol Herbst <kherbst at redhat.com> wrote: > > On Thu, Aug 15, 2019 at 3:56 PM <Mario.Limonciello at dell.com> wrote: > > > > > -----Original Message----- > > > From: linux-acpi-owner at vger.kernel.org <linux-acpi-owner at vger.kernel.org> On > > > Behalf Of Dave Airlie > > > Sent: Wednesday,

> -----Original Message----- > From: linux-acpi-owner at vger.kernel.org <linux-acpi-owner at vger.kernel.org> On > Behalf Of Dave Airlie > Sent: Wednesday, August 14, 2019 5:48 PM > To: Karol Herbst > Cc: LKML; Linux ACPI; dri-devel; nouveau; Rafael J . Wysocki; Alex Hung; Ben > Skeggs; Dave Airlie > Subject: Re: [Nouveau] [PATCH 1/7] Revert "ACPI / OSI: Add OEM

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Cc: Alex Deucher <alexander.deucher at amd.com> Cc: amd-gfx at lists.freedesktop.org Cc: Ben Skeggs <bskeggs at redhat.com> Cc: "Christian K?nig" <christian.koenig at amd.com> Cc: Daniel Vetter <daniel at ffwll.ch>

On Thu, 15 Aug 2019 at 07:31, Karol Herbst <kherbst at redhat.com> wrote: > > This reverts commit 28586a51eea666d5531bcaef2f68e4abbd87242c. > > The original commit message didn't even make sense. AMD _does_ support it and > it works with Nouveau as well. > > Also what was the issue being solved here? No references to any bugs and not > even explaining any issue at