On Mon, Jul 28, 2025 at 03:16:32PM -0400, Alex Deucher wrote:
> On Wed, Jul 23, 2025 at 4:28 PM Bjorn Helgaas wrote:
> >
> > From: Bjorn Helgaas
> >
> > Fix typos, most reported by "codespell drivers/gpu". Only touches
> > comments, no code ch
On Thu, Jul 17, 2025 at 03:56:58PM -0500, Bjorn Helgaas wrote:
> On Thu, Jul 17, 2025 at 12:38:03PM -0500, Mario Limonciello wrote:
> > From: Mario Limonciello
> >
> > Systems with more than one GPU userspace doesn't know which one to be
> > used to treat as pri
From: Bjorn Helgaas
Fix typos, most reported by "codespell drivers/gpu". Only touches
comments, no code changes.
Signed-off-by: Bjorn Helgaas
---
Documentation/gpu/amdgpu/driver-core.rst | 2 +-
drivers/gpu/drm/amd/amdgpu/Makefile | 2 +-
drivers/gpu/drm/
On Tue, Jul 22, 2025 at 09:45:28AM -0500, Mario Limonciello wrote:
> On 7/22/25 9:38 AM, Bjorn Helgaas wrote:
> > On Thu, Jul 17, 2025 at 12:38:11PM -0500, Mario Limonciello wrote:
> > > From: Mario Limonciello
> > >
> > > On systems with non VGA GPUs fbco
On Thu, Jul 17, 2025 at 12:38:11PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello
>
> On systems with non VGA GPUs fbcon can't find the primary GPU because
> video_is_primary_device() only checks the VGA arbiter.
>
> Add a screen info check to video_is_primary_device() so that callers
On Mon, Jul 21, 2025 at 07:28:07PM -0500, Mario Limonciello wrote:
> On 7/21/25 6:00 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 18, 2025 at 12:44:11PM -0500, Mario Limonciello wrote:
> > > On 7/18/2025 12:36 PM, Bjorn Helgaas wrote:
> > > > On Fri, Jul 18, 2025 at 12:29
On Fri, Jul 18, 2025 at 12:44:11PM -0500, Mario Limonciello wrote:
> On 7/18/2025 12:36 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 18, 2025 at 12:29:05PM -0500, Mario Limonciello wrote:
> > > On 7/18/2025 12:25 PM, Bjorn Helgaas wrote:
> > > > On Thu, Jul 17, 2
On Fri, Jul 18, 2025 at 12:29:05PM -0500, Mario Limonciello wrote:
> On 7/18/2025 12:25 PM, Bjorn Helgaas wrote:
> > On Thu, Jul 17, 2025 at 12:38:12PM -0500, Mario Limonciello wrote:
> > > From: Mario Limonciello
> > >
> > > On systems with multiple GPUs t
On Thu, Jul 17, 2025 at 12:38:12PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello
>
> On systems with multiple GPUs there can be uncertainty which GPU is the
> primary one used to drive the display at bootup. In some desktop
> environments this can lead to increased power consumption b
On Mon, Jul 07, 2025 at 03:58:30PM +0200, Lukas Wunner wrote:
> On Mon, Jul 07, 2025 at 02:53:32PM +0200, Hans de Goede wrote:
> > So I think we should move forward with Lukas' fix dor 6.16 and then
> > my patch to disable probing of unsupported devices by default can
> > be merged into linux-next
On Mon, Jun 16, 2025 at 12:50:16PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello
>
> For the suspend flow PCIe ports that have downstream devices are put into
> the appropriate D3 state when children are not in D0. For the hibernate
> flow, PCIe ports with downstream devices stay in D
On Thu, Jul 17, 2025 at 12:38:03PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello
>
> Systems with more than one GPU userspace doesn't know which one to be
> used to treat as primary. The concept of primary is important to be
> able to decide which GPU is used for display and which i
On Mon, Jul 14, 2025 at 04:21:37PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello
>
> This series started out as changes to VGA arbiter to try to handle a case
> of a system with 2 GPUs that are not VGA devices. This was discussed
> but decided not to overload the VGA arbiter for non
On Wed, Jul 02, 2025 at 11:35:17AM +0200, Michał Winiarski wrote:
> Hi,
>
> The series is now reviewed, and it looks like there's no further
> feedback.
> To limit it to PCI subsystem, I removed the last patch in the series, as
> it contained changes in drm/xe driver (it can still be found in v9 f
On Thu, Jun 26, 2025 at 06:33:15PM -0500, Mario Limonciello wrote:
> On 6/26/25 4:47 PM, Bjorn Helgaas wrote:
> > On Thu, Jun 26, 2025 at 04:12:21PM -0500, Mario Limonciello wrote:
> > > On 6/26/2025 3:45 PM, Bjorn Helgaas wrote:
> > > > On Tue, Jun 24, 2025 at 03:30
On Thu, Jun 26, 2025 at 04:12:21PM -0500, Mario Limonciello wrote:
> On 6/26/2025 3:45 PM, Bjorn Helgaas wrote:
> > On Tue, Jun 24, 2025 at 03:30:42PM -0500, Mario Limonciello wrote:
> > > From: Mario Limonciello
> > >
> > > On systems with multiple GPUs there
en_info_pci_dev(). Switch to using
> screen_info_pci_dev() instead.
>
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Mario Limonciello
Acked-by: Bjorn Helgaas
(after the kernel robot issue is fixed, of course)
> ---
> v5:
> * split from next patc
e 'boot_display' that uses the output of
> video_is_primary_device() to populate whether a PCI device was used for
> driving the display.
>
> Signed-off-by: Mario Limonciello
Acked-by: Bjorn Helgaas
Question below.
> ---
> v4:
> * new patch
> --
> Reviewed-by: Simona Vetter
> Signed-off-by: Mario Limonciello
Acked-by: Bjorn Helgaas
Not sure how this should be merged, let me know if you want me to do
something with it.
> ---
> include/linux/pci.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff -
gt;
> Replace it by actually writing the full values to the field, using the
> new HWORD_UPDATE macro, which grants us the benefit of better
> compile-time error checking.
>
> This patch was tested on RK3588 (PCIe3 x4 controller), RK3576 (PCIe2 x1
> controller) and R
s.
>
> Signed-off-by: Nicolas Frattaroli
Looks good to me. I assume you want to merge these via a non-PCI tree
since this depends on patch 01/20. PCI subject convention would
capitalize "Switch":
PCI: rockchip: Switch to HWORD_UPDATE* macros
Ac
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
On Mon, May 05, 2025 at 03:05:34PM +0200, Thomas Zimmermann wrote:
> Am 22.04.25 um 23:47 schrieb Bjorn Helgaas:
> > On Tue, Apr 22, 2025 at 09:49:57AM +0200, Thomas Zimmermann wrote:
> > > Apply bridge window offsets to screen_info framebuffers during
> > > relocation.
Petersen # SCSI
> Acked-by: Alex Deucher
> Reviewed-by: Thomas Zimmermann
> Cc: Bjorn Helgaas
> Signed-off-by: Arnd Bergmann
> ---
> v2: update changelog text
>
> Bjorn, can you take this through the PCI tree? I thought about splitting
> it up by subsystem, but it&#x
On Tue, Apr 22, 2025 at 09:49:57AM +0200, Thomas Zimmermann wrote:
> Apply bridge window offsets to screen_info framebuffers during
> relocation. Fixes invalid access to I/O memory.
>
> Resources behind a PCI bridge can be located at a certain offset
> in the kernel's I/O range. The framebuffer me
On Sun, Feb 02, 2025 at 01:02:47PM +0900, Inki Dae wrote:
> 2025년 2월 1일 (토) 오전 1:56, Bjorn Helgaas 님이 작성:
> >
> > I don't know this code at all, so this is likely just noise, but the
> > wait_event_timeout() usage in decon_wait_for_vblank() looks funny to
> > m
I don't know this code at all, so this is likely just noise, but the
wait_event_timeout() usage in decon_wait_for_vblank() looks funny to
me.
decon_wait_for_vblank() waits on wait_vsync_queue for wait_vsync_event
to be cleared.
But decon_irq_handler() only clears wait_vsync_event and wakes up
wai
On Sun, Nov 03, 2024 at 05:03:32PM +, Thomas Weißschuh wrote:
> Stop abusing the is_bin_visible() callback to calculate the attribute
> size. Instead use the new, dedicated bin_size() one.
>
> Signed-off-by: Thomas Weißschuh
Acked-by: Bjorn Helgaas
Thanks for doing this!
>
On Sun, Nov 03, 2024 at 05:03:29PM +, Thomas Weißschuh wrote:
> struct bin_attribute contains a bunch of pointer members, which when
> overwritten by accident or malice can lead to system instability and
> security problems.
> Moving the definitions of struct bin_attribute to read-only memory
>
On Sun, Nov 03, 2024 at 05:03:31PM +, Thomas Weißschuh wrote:
> Several drivers need to dynamically calculate the size of an binary
> attribute. Currently this is done by assigning attr->size from the
> is_bin_visible() callback.
s/an binary/a binary/
> This has drawbacks:
> * It is not docum
gt; throughout the tree at once.
>
> Signed-off-by: Thomas Weißschuh
Acked-by: Bjorn Helgaas# drivers/pci
> ---
> drivers/cxl/port.c | 2 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
> drivers/infiniband/hw/qib/qib_sysfs.c |
On Wed, Oct 30, 2024 at 03:20:02PM -0600, Logan Gunthorpe wrote:
> On 2024-10-30 12:46, Bjorn Helgaas wrote:
> > On Fri, Oct 25, 2024 at 06:57:37AM +, Kasireddy, Vivek wrote:
> > In the PCIe world, I don't think a TLP can "loop back" to another
> > funct
On Fri, Oct 25, 2024 at 06:57:37AM +, Kasireddy, Vivek wrote:
> > Subject: Re: [PATCH v2 1/5] PCI/P2PDMA: Don't enforce ACS check for
> > functions of same device
> >
> > On Thu, Oct 24, 2024 at 05:58:48AM +, Kasireddy, Vivek wrote:
> > > > Subject: Re: [PATCH v2 1/5] PCI/P2PDMA: Don't enf
On Wed, Oct 30, 2024 at 12:43:19PM +0100, Michał Winiarski wrote:
> On Mon, Oct 28, 2024 at 11:56:04AM -0500, Bjorn Helgaas wrote:
> > On Fri, Oct 25, 2024 at 11:50:36PM +0200, Michał Winiarski wrote:
> > > VF MMIO resource reservation, either created by system firmware and
On Fri, Oct 25, 2024 at 11:50:36PM +0200, Michał Winiarski wrote:
> VF MMIO resource reservation, either created by system firmware and
> inherited by Linux PCI subsystem or created by the subsystem itself,
> should contain enough space to fit the BAR of all SR-IOV Virtual
> Functions that can pote
On Fri, Oct 25, 2024 at 11:50:37PM +0200, Michał Winiarski wrote:
> Drivers could leverage the fact that the VF BAR MMIO reservation is
> created for total number of VFs supported by the device by resizing the
> BAR to larger size when smaller number of VFs is enabled.
>
> Add a pci_iov_vf_bar_set
On Thu, Oct 24, 2024 at 10:21:17AM -0600, Logan Gunthorpe wrote:
> On 2024-10-23 23:50, Kasireddy, Vivek wrote:
> >> I'd echo many of Bjorn's concerns. In addition, I think the name of the
> >> pci_devs_are_p2pdma_compatible() isn't quite right. Specifically this is
> >> dealing with PCI functions
On Thu, Oct 24, 2024 at 05:58:48AM +, Kasireddy, Vivek wrote:
> > Subject: Re: [PATCH v2 1/5] PCI/P2PDMA: Don't enforce ACS check for
> > functions of same device
> >
> > On Sun, Oct 20, 2024 at 10:21:29PM -0700, Vivek Kasireddy wrote:
> > > Functions of the same PCI device (such as a PF and a
ources among multiple VFs.
I don't want version history in the commit log. If the content is
useful, just incorporate it here directly (without the version info),
and put the version-to-version changelog below the "---".
> Cc: Bjorn Helgaas
> Cc: Logan Gunthorpe
> C
On Thu, Oct 10, 2024 at 12:32:01PM +0200, Michał Winiarski wrote:
> Similar to regular resizable BAR, VF BAR can also be resized.
> The structures are very similar, which means we can reuse most of the
> implementation. See PCIe r4.0, sec 9.3.7.4.
Add blank line between paragraphs.
Add "()" after
On Thu, Oct 10, 2024 at 12:31:59PM +0200, Michał Winiarski wrote:
> Similar to regular resizable BAR, VF BAR can also be resized, e.g. by
> the system firmware, or the PCI subsystem itself.
> Add the capability ID and restore it as a part of IOV state.
> See PCIe r4.0, sec 9.3.7.4.
Add blank line
On Thu, Oct 10, 2024 at 12:32:00PM +0200, Michał Winiarski wrote:
> There are multiple places where special handling is required for IOV
> resources.
> Extract it to a helper and drop a few ifdefs.
Add blank line between paragraphs.
Include name of helper in subject line and commit log, i.e.,
pci
On Thu, Oct 10, 2024 at 12:32:02PM +0200, Michał Winiarski wrote:
> VF MMIO resource reservation, either created by system firmware and
> inherited by Linux PCI subsystem or created by the subsystem itself,
> contains enough space to fit the BAR of all SR-IOV Virtual Functions
> that can potentiall
On Wed, Aug 07, 2024 at 10:30:18AM +0200, Philipp Stanner wrote:
> pcim_iomap_regions() is a complicated function that uses a bit mask to
> determine the BARs the user wishes to request and ioremap. Almost all
> users only ever set a single bit in that mask, making that mechanism
> questionable.
>
d rather take this
yourself, Dave, here's my ack for the PCI piece:
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/devres.c | 8 ++--
> include/linux/pci.h | 2 ++
> 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/devres.c b/drivers/pci/de
On Mon, Jul 29, 2024 at 11:36:24AM +0200, Philipp Stanner wrote:
> Hi everyone,
>
> Now that we've got the simplified PCI devres API available we can slowly
> start using it in drivers and step by step phase the more problematic
> API out.
>
> vboxvideo currently does not have a region request, s
On Mon, Jul 29, 2024 at 11:36:24AM +0200, Philipp Stanner wrote:
> Hi everyone,
>
> Now that we've got the simplified PCI devres API available we can slowly
> start using it in drivers and step by step phase the more problematic
> API out.
>
> vboxvideo currently does not have a region request, s
On Wed, Jul 03, 2024 at 04:52:30PM +0800, Jiaxun Yang wrote:
> 在2024年7月2日七月 下午6:03，Jiaxun Yang写道：
> > 在2024年7月2日七月 下午5:27，Christian König写道：
> >> Am 02.07.24 um 11:06 schrieb Icenowy Zheng:
> >>> [SNIP] However I don't think the definition of the AGP spec could apply
> >>> on all
> >>> PCI(e) impl
On Mon, Jun 17, 2024 at 10:21:10AM +0200, Philipp Stanner wrote:
> On Fri, 2024-06-14 at 11:14 -0500, Bjorn Helgaas wrote:
> > On Fri, Jun 14, 2024 at 10:09:46AM +0200, Philipp Stanner wrote:
> ...
> > > Apparently INTx is "old IRQ management&q
On Fri, Jun 14, 2024 at 01:38:41PM +0200, Philipp Stanner wrote:
> On Thu, 2024-06-13 at 16:57 -0500, Bjorn Helgaas wrote:
> > This is on pci/devres with some commit log rework and the following
> > diffs. I think the bar short/int thing is the only actual code
> > change
On Fri, Jun 14, 2024 at 10:09:46AM +0200, Philipp Stanner wrote:
> On Thu, 2024-06-13 at 16:06 -0500, Bjorn Helgaas wrote:
> > On Thu, Jun 13, 2024 at 01:50:23PM +0200, Philipp Stanner wrote:
> > > pci_intx() is one of the functions that have "hybrid mode" (i.e.,
> &
spelling issues (s/pci/PCI ...)
>
> Changes in v8:
> - Rebase the series on the already merged patches which were slightly
> modified by Bjorn Helgaas.
> - Reword the pci_intx() commit message so it clearly states it's about
> reworking pci_intx().
> - Move
>
> Rework the following public interfaces using the new infrastructure
> listed above:
> - pcim_iomap_release()
> - pcim_iomap()
> - pcim_iounmap()
> - pcim_iomap_regions()
> - pcim_iomap_regions_request_all()
> - pcim_iounmap_regions()
>
> Update
On Thu, Jun 13, 2024 at 07:54:38PM +0300, Ilpo Järvinen wrote:
> On Wed, 5 Jun 2024, Philipp Stanner wrote:
>
> > When the original PCI devres API was implemented, priority was given to
> > the creation of a set of "plural functions" such as
> > pcim_request_regions(). These functions have bit mas
On Thu, Jun 13, 2024 at 01:50:23PM +0200, Philipp Stanner wrote:
> pci_intx() is one of the functions that have "hybrid mode" (i.e.,
> sometimes managed, sometimes not). Providing a separate pcim_intx()
> function with its own device resource and cleanup callback allows for
> removing further large
On Thu, Jun 13, 2024 at 08:23:26PM +0300, Ilpo Järvinen wrote:
> On Wed, 5 Jun 2024, Philipp Stanner wrote:
>
> > pci_intx() is one of the functions that have "hybrid mode" (i.e.,
> > sometimes managed, sometimes not). Providing a separate pcim_intx()
> > function with its own device resource and
On Wed, Jun 12, 2024 at 10:51:40AM +0200, Philipp Stanner wrote:
> On Tue, 2024-06-11 at 16:44 -0500, Bjorn Helgaas wrote:
> > I'm trying to merge these into pci/next, but I'm having a hard time
> > writing the merge commit log. I want a one-sentence description of
>
_regions() # request & map specified BARs
pcim_iomap_regions_request_all() # request all BARs, map specified BARs
pcim_iounmap_regions()# unmap & release specified BARs
This is the kind of specific detail I'm looking for.
> Link: https://lore.ker
On Wed, Jun 05, 2024 at 10:15:52AM +0200, Philipp Stanner wrote:
> Hello Bjorn,
>
> I tried to meet your requests from the last feedback round as much as
> possible. Especially, I removed a lot of code, made almost all
> interfaces private and cut the series into smaller chunks where
> possible.
>
On Wed, Jun 05, 2024 at 10:15:59AM +0200, Philipp Stanner wrote:
> The bit describing whether the PCI device is currently enabled is stored
> in struct pci_devres. Besides this struct being subject of a cleanup
> process, struct pci_device is in general the right place to store this
> information,
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
On Wed, May 29, 2024 at 05:00:46PM +0900, Yoshinori Sato wrote:
> This is an updated version of something I wrote about 7 years ago.
> Minimum support for R2D-plus and LANDISK.
> I think R2D-1 will work if you add AX88796 to dts.
> And board-specific functions and SCI's SPI functions are not suppor
On Fri, Apr 26, 2024 at 10:07:02AM +0200, Philipp Stanner wrote:
> On Wed, 2024-04-24 at 15:12 -0500, Bjorn Helgaas wrote:
> > On Mon, Apr 08, 2024 at 10:44:12AM +0200, Philipp Stanner wrote:
> > > ...
> > > PCI's devres API suffers several weaknesses:
> > &g
On Mon, Apr 08, 2024 at 10:44:15AM +0200, Philipp Stanner wrote:
> The PCI region-request functions become managed functions when
> pcim_enable_device() has been called previously instead of
> pci_enable_device().
>
> This has already caused bugs by confusing users, who came to believe
> that all
On Mon, Apr 08, 2024 at 10:44:16AM +0200, Philipp Stanner wrote:
> Now that pure managed region request functions are available, the
> implementation of the hybrid-functions which are only sometimes managed
> can be made more consistent and readable by wrapping those
> always-managed functions.
>
On Mon, Apr 08, 2024 at 10:44:12AM +0200, Philipp Stanner wrote:
> ...
> PCI's devres API suffers several weaknesses:
>
> 1. There are functions prefixed with pcim_. Those are always managed
>counterparts to never-managed functions prefixed with pci_ – or so one
>would like to think. There
On Thu, Apr 04, 2024 at 01:59:25PM +0900, Yoshinori Sato wrote:
> This is an updated version of something I wrote about 7 years ago.
> Minimum support for R2D-plus and LANDISK.
> I think R2D-1 will work if you add AX88796 to dts.
> And board-specific functions and SCI's SPI functions are not suppor
On Fri, Mar 01, 2024 at 12:29:58PM +0100, Philipp Stanner wrote:
> When the PCI devres API was introduced to this driver, it was wrongly
> assumed that initializing the device with pcim_enable_device() instead
> of pci_enable_device() will make all PCI functions managed.
>
> This is wrong and was
On Mon, Mar 11, 2024 at 12:45:15PM +0100, Philipp Stanner wrote:
> Gentle ping because the Merge Window opened 8-)
Thanks; I'll look at this for v6.10. It's too late to add significant
changes for the v6.9 merge window since it's already open.
Bjorn
> On Fri, 2024-03-01 at 12:29 +0100, Philipp
On Thu, Feb 29, 2024 at 09:31:20AM +0100, Philipp Stanner wrote:
> @Bjorn:
> Hey Bjorn, are we good with this series? Any more wishes or
> suggestions?
Sorry, haven't had a chance to go through it yet.
FWIW, I just tried to apply these on top of pci/devres, but it failed
here:
Applying: PCI:
From: Bjorn Helgaas
The power management callbacks are never called unless .probe() has already
returned success, which means it has set drvdata to a non-NULL pointer, so
"dev" can never be NULL in the other callbacks.
Remove the unnecessary checks.
Signed-off-by: Bjorn Helgaas
--
From: Bjorn Helgaas
After 4020c2280233 ("drm/amdgpu: don't runtime suspend if there are
displays attached (v3)"), "ret" is unconditionally set later before being
used, so there's point in initializing it and the associated comment is no
longer meaningful.
Remove t
[+cc Bartosz]
On Fri, Feb 02, 2024 at 05:25:56PM -0500, Hamza Mahfooz wrote:
> Removing an amdgpu device that still has user space references allocated
> to it causes undefined behaviour. So, implement amdgpu_pci_can_remove()
> and disallow devices that still have files allocated to them from bein
On Tue, Jan 23, 2024 at 08:44:04PM +, Sakari Ailus wrote:
> On Tue, Jan 23, 2024 at 11:24:23AM -0600, Bjorn Helgaas wrote:
> ...
> > - I don't know whether it's feasible, but it would be nice if the
> > intel_pm_runtime_pm.c rework could be done in one shot
sound/
> Reviewed-by: Jacek Lawrynowicz #
> drivers/accel/ivpu/
> Acked-by: Rodrigo Vivi # drivers/gpu/drm/i915/
> Reviewed-by: Rodrigo Vivi
Acked-by: Bjorn Helgaas # drivers/pci/
- Previous PM history uses "PM: " in the subject lines (not "pm: ").
- I don
ed-by: Takashi Iwai # sound/
> Reviewed-by: Jacek Lawrynowicz #
> drivers/accel/ivpu/
> Acked-by: Rodrigo Vivi # drivers/gpu/drm/i915/
> Reviewed-by: Rodrigo Vivi
Acked-by: Bjorn Helgaas # drivers/pci/
> -EXPORT_SYMBOL_GPL(pm_runtime_get_if_active);
> +EXPORT_SYMBOL_GPL(pm_ru
On Wed, Jan 17, 2024 at 09:54:47AM +0100, Philipp Stanner wrote:
> On Tue, 2024-01-16 at 12:44 -0600, Bjorn Helgaas wrote:
> > On Mon, Jan 15, 2024 at 03:46:12PM +0100, Philipp Stanner wrote:
> > > PCI's devres API is not extensible to ranged mappings and has
> > >
On Mon, Jan 15, 2024 at 03:46:12PM +0100, Philipp Stanner wrote:
> PCI's devres API is not extensible to ranged mappings and has
> bug-provoking features. Improve that by providing better alternatives.
I guess "ranged mappings" means a mapping that doesn't cover an entire
BAR? Maybe there's a way
On Mon, Jan 15, 2024 at 03:46:18PM +0100, Philipp Stanner wrote:
> managing mwi with devres can easily be done with its own callback,
> without the necessity to store any state about it in a device-related
> struct.
s/managing/Managing/
s/mwi/MWI/ since this is an initialism. Also in subject (bu
On Mon, Jan 15, 2024 at 03:46:11PM +0100, Philipp Stanner wrote:
> ...
> pci: add new set of devres functions
> pci: deprecate iomap-table functions
> pci: warn users about complicated devres nature
> pci: devres: make devres region requests consistent
> pci: move enabled status bit to p
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 Wed, Aug 30, 2023 at 07:15:27PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The PCI code and ID assignment specification defined four types of
> display controllers for the display base class(03h), and the devices
> with 0x00h sub-class code are VGA devices. VGA devices with programmin
On Wed, Aug 30, 2023 at 07:15:28PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The PCI code and ID assignment specification defined four types of
> display controllers for the display base class(03h), and the devices
> with 0x00h sub-class code are VGA devices. VGA devices with programmin
On Thu, Oct 05, 2023 at 04:57:14PM -0500, Bjorn Helgaas wrote:
> In subject: "drm/virtio" to match previous history.
>
> On Wed, Aug 30, 2023 at 07:15:31PM +0800, Sui Jingfeng wrote:
> > From: Sui Jingfeng
> >
> > Should be no functional change, just fo
In subject: "drm/virtio" to match previous history.
On Wed, Aug 30, 2023 at 07:15:31PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Should be no functional change, just for cleanup purpose.
>
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: Gurchetan Singh
> Cc: Chia-I Wu
> Cc: Daniel Ve
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 Wed, Aug 09, 2023 at 06:34:01AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> v1:
> * Various improve.
> v2:
> * More fixes, optimizations and improvements.
>
> Sui Jingfeng (11):
> PCI/VGA: Use unsigned type for the io_state variable
> PCI: Add the pci_get_class_masked
On Fri, Aug 18, 2023 at 04:12:57PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: Ilpo Järvinen
> > Sent: Monday, July 17, 2023 8:05 AM
> > To: linux-...@vger.kernel.org; Bjorn Helgaas ; Lorenzo
> > Pieralisi ; Rob Herring ;
> > Krzy
On Fri, Aug 18, 2023 at 12:09:29PM +0800, suijingfeng wrote:
> On 2023/8/18 06:08, Bjorn Helgaas wrote:
> > On Wed, Aug 16, 2023 at 06:05:27AM +0800, Sui Jingfeng wrote:
> > > Currently, the vga_is_firmware_default() function only works on x86 and
> > > ia64, it is a no-
On Fri, Aug 18, 2023 at 09:48:46AM +0800, suijingfeng wrote:
> On 2023/8/18 06:08, Bjorn Helgaas wrote:
> > > + if (resource_type(res) != IORESOURCE_MEM)
> > > + continue;
> > > +
> > > + if (!res->start || !
On Wed, Aug 16, 2023 at 06:05:27AM +0800, Sui Jingfeng wrote:
> Currently, the vga_is_firmware_default() function only works on x86 and
> ia64, it is a no-op on ARM, ARM64, PPC, RISC-V, etc. This patch completes
> the implementation for the rest of the architectures. The added code tries
> to ident
On Tue, Aug 08, 2023 at 10:58:59PM +0800, Sui Jingfeng wrote:
> Currently, the vga_is_firmware_default() function works only on x86 and
> IA64 architectures, but it is a no-op on ARM64, PPC, RISC-V, etc. This
> patch completes the implementation by tracking the firmware framebuffer's
> address rang
On Fri, Aug 04, 2023 at 11:11:12AM +0800, suijingfeng wrote:
> On 2023/8/3 20:25, kernel test robot wrote:
> > Hi Sui,
> >
> > kernel test robot noticed the following build errors:
> >
> > [auto build test ERROR on pci/next]
> > [also build test ERROR on pci/for-linus linus/master v6.5-rc4 next-2
On Mon, Jul 24, 2023 at 09:02:14PM +0800, suijingfeng wrote:
> PING, please !
Don't worry, these are not forgotten. Your other series seems more
important, so that's what I've been paying attention to.
> On 2023/7/11 21:43, Sui Jingfeng wrote:
> > From: Sui Jingfeng
> >
> > In the vga_arbiter_
On Sat, Jul 22, 2023 at 04:11:07PM +0800, suijingfeng wrote:
> ...
> In the future, we may want to expand VGAARB to deal all PCI display class
> devices, with another patch.
>
> if (pdev->class >> 16 == PCI_BASE_CLASS_DISPLAY)
>
> // accept
>
> else
>
> // return immediately.
>
On Mon, Jul 24, 2023 at 08:47:48PM +0800, suijingfeng wrote:
> On 2023/7/20 03:32, Bjorn Helgaas wrote:
> > "drm/loongson: Add an implement for ..." also solves a problem, but it
> > lacks a commit log, so I don't know what the problem is.
>
> I have already
On Mon, Jul 24, 2023 at 08:16:18PM +0800, suijingfeng wrote:
> On 2023/7/20 03:32, Bjorn Helgaas wrote:
> > > 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)
On Mon, Jul 17, 2023 at 03:04:57PM +0300, Ilpo Järvinen wrote:
> Don't assume that only the driver would be accessing LNKCTL. ASPM
> policy changes can trigger write to LNKCTL outside of driver's control.
> And in the case of upstream bridge, the driver does not even own the
> device it's changing
On Wed, Jul 12, 2023 at 12:43:02AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> This patch adds the aperture_contain_firmware_fb() function to do the
> determination. Unfortunately, due to the fact that the apertures list
> will be freed dynamically, the location and size information of th
[+cc linux-pci; I don't apply or ack PCI patches unless they appear there]
On Wed, Jul 12, 2023 at 12:43:04AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The observation behind this is that we should avoid accessing the global
> screen_info directly. Call the aperture_contain_firmware_fb
1 - 100 of 509 matches
Mail list logo
