[+cc Sasha -- stable kernel regression]
[+cc Patrick, Kai-Heng, LKML]
On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> On Tue, Jul 7, 2020 at 9:30 PM Karol Herbst wrote:
> >
> > Hi everybody,
> >
> > with the mentioned commit Nouveau isn't able to load firmware onto the
> > GPU on
On Fri, Jul 17, 2020 at 10:43:18AM -0400, Sasha Levin wrote:
> On Fri, Jul 17, 2020 at 02:43:52AM +0200, Karol Herbst wrote:
> > On Fri, Jul 17, 2020 at 1:54 AM Bjorn Helgaas wrote:
> > > On Fri, Jul 17, 2020 at 12:10:39AM +0200, Karol Herbst wrote:
> > > > On Tue
On Fri, Jul 24, 2020 at 12:57:51PM +0300, Mika Westerberg wrote:
> On Thu, Jul 23, 2020 at 10:30:58PM +0200, Karol Herbst wrote:
> > On Wed, Jul 22, 2020 at 11:25 AM Mika Westerberg
> > wrote:
> > >
> > > On Tue, Jul 21, 2020 at 01:37:12PM -0500, Patrick Volkerding wrote:
> > > > On 7/21/20 10:27
Is there any chance the nouveau mailing list
(https://lists.freedesktop.org/archives/nouveau/) could be added to
lore?
Threads like this conversation:
https://lore.kernel.org/r/20200908002935.gd20...@merlins.org get
harder to browse when mailing lists that *are* on lore get removed
from cc.
Thank
Hi Marc, I appreciate your persistence on this. I am frankly
surprised that you've put up with this so long.
On Sat, Dec 26, 2020 at 03:12:09AM -0800, Marc MERLIN wrote:
> This started with 5.5 and hasn't gotten better since then, despite
> some reports I tried to send.
>
> As per my previous me
On Wed, Jan 27, 2021 at 03:33:02PM -0600, Bjorn Helgaas wrote:
> On Sat, Dec 26, 2020 at 03:12:09AM -0800, Marc MERLIN wrote:
> > This started with 5.5 and hasn't gotten better since then, despite
> > some reports I tried to send.
> >
> > As per my previous message
On Thu, Jan 28, 2021 at 04:56:26PM -0800, Marc MERLIN wrote:
> On Wed, Jan 27, 2021 at 03:33:00PM -0600, Bjorn Helgaas wrote:
> > Hi Marc, I appreciate your persistence on this. I am frankly
> > surprised that you've put up with this so long.
>
> Well, been using li
[+cc Ben]
Hi Marc,
Thanks for paying attention to these things. I added Ben (who
probably would see this via nouveau@lists.freedesktop.org anyway).
I don't see a PCI issue here, but the nouveau timeout, which I know
nothing about, does look like it could be interesting.
On Wed, May 05, 2021 at
> Acked-by: Alex Deucher
> Acked-by: Mika Westerberg
> Signed-off-by: Mario Limonciello
I would change the subject to:
PCI: Add USB4 class definition
because this seems like more of a PCI thing than a Thunderbolt thing,
but either way:
Acked-by: Bjorn Helgaas
> ---
&g
Update subject to something like:
PCI: pciehp: Quirk broken Command Completed support on Intel Thunderbolt
controllers
On Fri, Feb 11, 2022 at 01:32:40PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` check is currently used to indicate the lack of
> command completed support for a num
On Fri, Feb 11, 2022 at 01:32:41PM -0600, Mario Limonciello wrote:
> `pci_bridge_d3_possible` currently checks explicitly for a Thunderbolt
> controller to indicate that D3 is possible. As this is used solely
> for older Apple systems, move it into a quirk that enumerates across
> all Intel TBT co
On Fri, Feb 11, 2022 at 01:32:43PM -0600, Mario Limonciello wrote:
> The root port used for PCIe tunneling should be marked as removable to
> ensure that the entire chain is marked removable.
>
> This can be done by looking for the device property specified in
> the ACPI tables `usb4-host-interfac
On Fri, Feb 11, 2022 at 01:32:44PM -0600, Mario Limonciello wrote:
> USB4 class devices are also removable like Intel Thunderbolt devices.
Spec reference, please.
> Drivers of downstream devices use this information to declare functional
> differences in how the drivers perform by knowing that th
Make the subject specific, not just "appropriately." I think you're
marking something *removable*, so include that.
On Fri, Feb 11, 2022 at 01:32:45PM -0600, Mario Limonciello wrote:
> Discrete USB4 controllers won't have ACPI nodes specifying which
> PCIe or XHCI port they are linked with.
>
>
On Mon, Feb 14, 2022 at 12:56:58PM +0200, Mika Westerberg wrote:
> On Mon, Feb 14, 2022 at 09:52:02AM +0100, Lukas Wunner wrote:
> > On Mon, Feb 14, 2022 at 09:34:26AM +0200, Mika Westerberg wrote:
> > > On Fri, Feb 11, 2022 at 03:45:46PM -0600, Bjorn Helgaas wrote:
> > &g
On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute originally had a well defined list of
> quirks that it existed for, but it has been overloaded with more
> meaning.
>
> Instead use the driver core removable attribute to indicate the
> detail a dev
On Thu, Feb 24, 2022 at 07:23:49PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> > The `is_thunderbolt` attribute originally had a well defined list of
> > quirks that it existed for, but it has been overloaded with m
On Thu, Feb 24, 2022 at 03:51:12PM -0600, Mario Limonciello wrote:
> The `is_thunderbolt` attribute originally had a well defined list of
> quirks that it existed for, but it has been overloaded with more
> meaning.
>
> Instead use the driver core removable attribute to indicate the
> detail a dev
On Mon, Feb 28, 2022 at 03:33:13PM +, Limonciello, Mario wrote:
> [AMD Official Use Only]
>
> >
> > On Fri, Feb 25, 2022 at 11:42:24AM -0600, Bjorn Helgaas wrote:
> > > That would just leave the "PCI_VSEC_ID_INTEL_TBT implies external-
> > facing&
h_string(ecrc_policy_str, ARRAY_SIZE(ecrc_policy_str), str);
> + i = match_string(ecrc_policy_str, str);
> if (i < 0)
> return;
>
Acked-by: Bjorn Helgaas# drivers/pci/
> +++ b/mm/vmpressure.c
> @@ -388,7 +388,7 @@ int vmpressure_register_event(str
[+cc Rafael]
On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote:
> On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote:
> > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote:
> > > On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote:
> > > >
On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote:
> On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul wrote:
> > On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote:
> > > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote:
> > > > On Tue, Fe
From: Bjorn Helgaas
Commit 3a6536c51d5d ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE")
added a definition of ACPI_VIDEO_NOTIFY_PROBE because didn't
supply one. Later, commit eff4a751cce5 ("ACPI / video: Move
ACPI_VIDEO_NOTIFY_* defines to acpi/video.h") moved AC
[+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime)
resume")]
On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote:
> > On Wed, Mar 13, 2019 at 06:25:02PM -0400, Lyude Paul
On Wed, Apr 24, 2019 at 01:31:09PM -0400, Lyude Paul wrote:
> Any update on this? This has been waiting for a while now
Oh, sorry, I guess we were both waiting for the other. Let me respond to
the email with context.
> On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote:
> &g
On Mon, Apr 15, 2019 at 02:07:18PM -0400, Lyude Paul wrote:
> On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote:
> > [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime)
> > resume")]
> >
> > On Fri, Mar 22, 2019 at 06:30:15AM -05
On Wed, Apr 24, 2019 at 03:16:37PM -0400, Lyude Paul wrote:
> On Wed, 2019-04-24 at 13:59 -0500, Bjorn Helgaas wrote:
> > Not being a scheduled work expert, I was unsure if this experiment was
> > equivalent to what I proposed.
> >
> > I'm always suspicious of sing
On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote:
> On a very specific subset of ThinkPad P50 SKUs, particularly ones that
> come with a Quadro M1000M chip instead of the M2000M variant, the BIOS
> seems to have a very nasty habit of not always resetting the secondary
> Nvidia GPU between
On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote:
> Apperantly things go south if we suspend the device with a different PCIE
> link speed set than it got booted with. Fixes runtime suspend on my gp107.
>
> This all looks like some bug inside the pci subsystem and I would prefer a
> fi
On Tue, May 07, 2019 at 10:12:43PM +0200, Karol Herbst wrote:
> Signed-off-by: Karol Herbst
> Reviewed-by: Lyude Paul
> ---
> drm/nouveau/nvkm/subdev/pci/gk104.c | 8
> drm/nouveau/nvkm/subdev/pci/gp100.c | 10 ++
> drm/nouveau/nvkm/subdev/pci/priv.h | 5 +
> 3 files chan
On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote:
> On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote:
> > On Tue, May 07, 2019 at 10:12:45PM +0200, Karol Herbst wrote:
> > > Apperantly things go south if we suspend the device with a different PCIE
> > >
On Tue, May 21, 2019 at 03:28:48PM +0200, Karol Herbst wrote:
> On Tue, May 21, 2019 at 3:11 PM Bjorn Helgaas wrote:
> > On Tue, May 21, 2019 at 12:30:38AM +0200, Karol Herbst wrote:
> > > On Mon, May 20, 2019 at 11:20 PM Bjorn Helgaas wrote:
> > > > On Tue, Ma
00 00 00 00 00 00 00 00 00 00
> > > 70: 00 00 00 00 00 00 00 00 00 62 17 00 00 00 00 0a
> > > 80: 01 90 03 c8 08 00 00 00 0d 80 00 00 28 10 be 07
> > > 90: 05 a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > a0: 10 00 42 01 01 80 00 00 20 00 00 00 03 ad 61 02
&
[+cc Rafael, Martin, zigarrre]
On Thu, Jun 13, 2019 at 02:35:14PM +0800, Daniel Drake wrote:
> From: Lukas Wunner
>
> The integrated HDA controller on Nvidia GPUs can be hidden with a bit in
> the GPU's config space. Information about this scheme was provided by
> NVIDIA on their forums.
>
> Ma
y Daniel Drake.
Link: https://lore.kernel.org/r/20190708051744.24039-1-dr...@endlessm.com
Link: https://devtalk.nvidia.com/default/topic/1024022
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75985
Signed-off-by: Lukas Wunner
Signed-off-by: Daniel Drake
[bhelgaas:
ci_reset_bus() instead which properly
> resets the GPU bus and all device functions under it, including both the
> GPU and the HDA controller.
>
> Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers")
> Cc: Lukas Wunner
> Cc: Daniel Drake
> Cc: Bjorn Helgaas
> Cc
s for sharing it :) I could learn a lot of useful
python by studying it.
> Signed-off-by: Karol Herbst
> Cc: Bjorn Helgaas
> Cc: Lyude Paul
> Cc: linux-...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> ---
> drivers/pci/pci.c |
On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:
> On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
> wrote:
> >
> > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> > > still happens with your patch applied. The machine simply gets shut down.
> > >
> > > dmesg can be fo
On Tue, Oct 01, 2019 at 06:21:28PM +0200, Karol Herbst wrote:
> On Tue, Oct 1, 2019 at 3:27 PM Bjorn Helgaas wrote:
> > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:
> > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
> > > wrote:
> > > >
t only for certain combinations of intel and nvidia hardware
>
> Signed-off-by: Karol Herbst
> Cc: Bjorn Helgaas
> Cc: Lyude Paul
> Cc: Rafael J. Wysocki
> Cc: Mika Westerberg
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: dri-de...@lists.freede
el should weigh in on. I don't know
why we set the device to D3hot with PCI_PM_CTRL before using the ACPI
methods, and I don't know what the effect of skipping that is. It
seems a little messy to slice out this tiny piece from the middle, but
maybe it makes sense.
> On Wed, Oct 16, 201
On Wed, Oct 16, 2019 at 11:48:22PM +0200, Karol Herbst wrote:
> On Wed, Oct 16, 2019 at 11:37 PM Bjorn Helgaas wrote:
> > On Wed, Oct 16, 2019 at 09:18:32PM +0200, Karol Herbst wrote:
> > > but setting the PCI_DEV_FLAGS_NO_D3 flag does prevent using the
> > > platform
uff below straightened out.
> Signed-off-by: Karol Herbst
> Cc: Bjorn Helgaas
> Cc: Lyude Paul
> Cc: Rafael J. Wysocki
> Cc: Mika Westerberg
> Cc: linux-...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lis
[+cc Daniel, Vidya, Thierry; thread starts at
https://lore.kernel.org/r/20191017121901.13699-1-kher...@redhat.com]
On Tue, Nov 19, 2019 at 11:26:45PM +0100, Karol Herbst wrote:
> On Tue, Nov 19, 2019 at 10:50 PM Bjorn Helgaas wrote:
> > On Thu, Oct 17, 2019 at 02:19:01PM +0200, Kar
On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote:
> Fixes the infamous 'runtime PM' bug many users are facing on Laptops with
> Nvidia Pascal GPUs by skipping said PCI power state changes on the GPU.
>
> Depending on the used kernel there might be messages like those in demsg:
>
> "no
On Sat, Mar 21, 2020 at 02:02:22AM +0100, Karol Herbst wrote:
> On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas wrote:
> >
> > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote:
> > > Fixes the infamous 'runtime PM' bug many users are facing on Laptop
On Tue, Mar 24, 2020 at 06:31:08PM +0100, Karol Herbst wrote:
> On Sat, Mar 21, 2020 at 2:02 AM Karol Herbst wrote:
> >
> > On Fri, Mar 20, 2020 at 11:19 PM Bjorn Helgaas wrote:
> > >
> > > On Tue, Mar 10, 2020 at 08:26:27PM +0100, Karol Herbst wrote:
> >
) previously directly accessed an __iomem
> pointer. Avoid this by calling memcpy_fromio() instead of kmemdup().
>
> pci_platform_rom() now has no remaining callers, so remove it.
>
> Signed-off-by: Mikel Rychliski
I applied this to pci/resource for v5.7. I would feel better if some
of
On Mon, Mar 30, 2020 at 01:54:33PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Bjorn Helgaas
> > Sent: Saturday, March 28, 2020 4:19 PM
> > To: Mikel Rychliski
> > Cc: amd-...@lists.freedesktop.org; linux-...@vger.kernel.org;
>
vv" of the HDA before and after the suspend may show
different things, which seems counter-intuitive.
I wouldn't think of a full-blown restore as "inflating the code"; I
would think of it as "having fewer special cases", i.e., we always use
the same res
t; on ->remove a runtime PM ref was only acquired under the first of those
> conditions. Thus, binding and unbinding the driver twice on a
> vga_switcheroo capable system caused the runtime PM refcount to drop
> below zero. The issue is resolved because the AZX_DCAPS_PM_RUNTIME flag
lk the hierarchy again and wake all devices, causing them to
> be put into D0active and then letting them autosuspend as they see fit.
>
> To this end make pci_wakeup_bus() & pci_bus_set_current_state() public
> so PCI drivers don't have to reinvent the wheel.
>
> Cc: B
[+cc George]
On Fri, Feb 23, 2018 at 10:51:47AM +0100, Lukas Wunner wrote:
> On Tue, Feb 20, 2018 at 04:20:59PM -0600, Bjorn Helgaas wrote:
> > On Sun, Feb 18, 2018 at 09:38:32AM +0100, Lukas Wunner wrote:
> > > The device link is added in a PCI quirk rather than in hda_in
s BARs will be
> uninitialized when a driver later probes it.
>
> Fix by saving and restoring config space over a runtime suspend cycle
> even if the device is not bound.
>
> Cc: Bjorn Helgaas
> Signed-off-by: Rafael J. Wysocki
> [lukas: add commit message, bikeshed code c
On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote:
> On Tue, Mar 06, 2018 at 11:29:40AM +0100, Daniel Vetter wrote:
> > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > > Modernize vga_switcheroo by using a device link to enforce a runtime PM
> > > dependency from an HDA
[+cc Intel folks]
On Fri, Aug 31, 2018 at 03:30:57PM +0800, Daniel Drake wrote:
> On over 40 Intel-based Asus products, the nvidia GPU becomes unusable
> after S3 suspend/resume. The affected products include multiple
> generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs
> many e
[+cc LKML]
On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
> On 38+ Intel-based Asus products, the nvidia GPU becomes unusable
> after S3 suspend/resume. The affected products include multiple
> generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs
> many errors such
[+cc LKML, Dave, Luming]
On Fri, Sep 07, 2018 at 05:05:15PM +0200, Peter Wu wrote:
> On Fri, Sep 07, 2018 at 01:36:14PM +0800, Daniel Drake wrote:
> <..>
> > Thomas Martitz reports that this workaround also solves an issue where
> > the AMD Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unrespons
On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote:
> On 38+ Intel-based Asus products, the nvidia GPU becomes unusable
> after S3 suspend/resume. The affected products include multiple
> generations of nvidia GPUs and Intel SoCs. After resume, nouveau logs
> many errors such as:
>
>
[+cc LKML]
On Tue, Sep 18, 2018 at 04:32:44PM -0500, Bjorn Helgaas wrote:
> On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote:
> > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable
> > after S3 suspend/resume. The affected products include multiple
>
Hi Thomas,
On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote:
> Am 01.10.18 um 06:57 schrieb Daniel Drake:
> > On Sun, Sep 30, 2018 at 5:07 AM Thomas Martitz wrote:
> > > The latest iteration does not work on my HP system. The GPU fails to
> > > power up just like the unpatched kerne
On Tue, Oct 2, 2018 at 4:27 PM Thomas Martitz wrote:
>
> Am 02.10.18 um 22:03 schrieb Bjorn Helgaas:
> > Hi Thomas,
> >
> > On Mon, Oct 01, 2018 at 04:25:06PM +0200, Thomas Martitz wrote:
> >> Am 01.10.18 um 06:57 schrieb Daniel Drake:
> >>> On Sun,
Hi Lyude,
On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote:
> On a very specific subset of ThinkPad P50 SKUs, particularly ones that
> come with a Quadro M1000M chip instead of the M2000M variant, the BIOS
> seems to have a very nasty habit of not always resetting the secondary
> Nvidia
On Mon, Feb 18, 2019 at 3:14 PM Sasha Levin wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v4.20.8, v4.19.21
On Thu, Jul 3, 2014 at 10:32 PM, Ilia Mirkin wrote:
> So let me get this straight -- you're suggesting I add a quirk for
> every PCI chipset that doesn't support MSI? There are probably
> hundreds of these... anything made before 1999 or so, and probably a
> bunch since then too. There _has_ to be
On Fri, Feb 24, 2017 at 1:19 PM, Lukas Wunner wrote:
> An external Thunderbolt GPU can neither drive the laptop's panel nor be
> powered off by the platform, so there's no point in registering it with
> vga_switcheroo.
> In fact, when the external GPU is runtime suspended,
> vga_switcheroo will c
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_t
On Sat, Feb 25, 2017 at 08:40:03AM +0100, Lukas Wunner wrote:
> 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
> > >
in
> Cc: Jarkko Sakkinen
> Cc: Jani Nikula
> Cc: Ben Skeggs
> Cc: Benjamin Tissoires
> Cc: Joerg Roedel
> Cc: Adrian Hunter
> Cc: Yisen Zhuang
> Cc: Bjorn Helgaas
> Cc: Zhang Rui
> Cc: Felipe Balbi
> Cc: Mathias Nyman
> Cc: Heikki Krogerus
> Cc
this should be a pci_info_once() sort of thing? I think there's
some value in knowing that we're changing the BIOS configuration
outside the purview of a driver, since I assume BIOS had some reason
for hiding the HDA controller.
> Cc: Bjorn Helgaas
> Cc: Lukas Wunner
Match the subject line style:
$ git log --oneline drivers/pci/vgaarb.c
f321c35feaee PCI/VGA: Replace full MIT license text with SPDX identifier
d5109fe4d1ec PCI/VGA: Use unsigned format string to print lock counts
4e6c91847a7f PCI/VGA: Log bridge control messages when adding devices
dc59
Capitalize subject to match ("Tidy ...")
On Thu, Jun 08, 2023 at 07:43:19PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> This patch replaces the leading space with a tab and removes the double
> blank line, no functional change.
Can you move this to the end of the series? The functional
Start with verb and capitalize to match ("Deal only with ...")
On Thu, Jun 08, 2023 at 07:43:21PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> vgaarb only deal with the VGA devcie(pdev->class == 0x0300), so replace the
> pci_get_subsys() function with pci_get_class(). Filter the non pci d
On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The vga_is_firmware_default() function is arch-dependent, which doesn't
> sound right. At least, it also works on the Mips and LoongArch platforms.
> Tested with the drm/amdgpu and drm/radeon drivers. However,
On Fri, Jun 09, 2023 at 10:27:39AM +0800, Sui Jingfeng wrote:
> On 2023/6/9 03:19, Bjorn Helgaas wrote:
> > On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:
> > > From: Sui Jingfeng
> > >
> > > The vga_is_firmware_default() function is arch-depend
On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> A nouveau developer(Lyude) from redhat send me a R-B,
>
> Thanks for the developers of nouveau project.
>
>
> Please allow me add a link[1] here.
>
>
> [1]
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff2585
On Fri, Jun 30, 2023 at 10:14:11AM +0800, suijingfeng wrote:
> On 2023/6/30 01:44, Limonciello, Mario wrote:
> > > On 2023/6/29 23:54, Bjorn Helgaas wrote:
> > > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> > > > 4) Right now we're i
On Fri, Aug 25, 2023 at 02:27:09PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> There is no function that can be used to get all PCI(e) devices in a
> system by matching against its the PCI base class code only, while keep
> the sub-class code and the programming interface ignored. Therefo
On Fri, Nov 03, 2023 at 02:07:49PM -0500, Mario Limonciello wrote:
> Downstream drivers are getting the wrong values from
> pcie_bandwidth_available() which is causing problems for performance
> of eGPUs.
>
> This series overhauls Thunderbolt related device detection and uses
> the changes to chan
On Thu, May 08, 2025 at 10:15:15PM -0500, Andrew Ballance wrote:
> From: Fiona Behrens
>
> Replace the Io struct with a new MMIo struct that uses the different
> traits (`IoAccess`, `IoAccess64`, `IoAccessRelaxed` and
> `IoAccess64Relaxed).
> This allows to later implement PortIo and a generic Io
80 matches
Mail list logo
