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
[+cc linux-pci]
On Wed, Jul 12, 2023 at 12:43:01AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> 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 reloca
[+cc linux-pci (please cc in the future since the bulk of this patch
is in drivers/pci/)]
On Wed, Jul 12, 2023 at 12:43:05AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Currently, the strategy of selecting the default boot on a multiple video
> card coexistence system is not perfect. Pot
On Tue, Jul 11, 2023 at 09:43:50PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Currently, vgaarb only cares about PCI VGA-compatible class devices.
>
> While vga_arbiter_del_pci_device() gets called unbalanced when some PCI
> device is about to be removed. This happens even during the bo
On Tue, Jul 18, 2023 at 06:14:00PM -0500, Bjorn Helgaas wrote:
> On Fri, Jun 30, 2023 at 06:17:29PM +0800, Sui Jingfeng wrote:
> > From: Sui Jingfeng
> >
> > VGAARB should only care about PCI VGA class devices (pdev->class == 0x0300)
> > since only those devices
inst PCI_CLASS_DISPLAY_VGA << 8, so I
*think* this only accepts programming interface 0x00.
That might be OK, since the "PCI Code and ID Assignment" spec, r1.15,
sec 1.4, only mentions 0x0300 programming interface 0x00 as decoding
the legacy VGA addresses. But it is something t
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 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 Tue, Jun 20, 2023 at 06:06:00AM -0500, Bjorn Helgaas wrote:
> On Tue, Jun 20, 2023 at 12:04:40PM +0800, Sui Jingfeng wrote:
> > Where is the formal(unstream) PCI git branch where we could see the latest
> > patch ?
>
> Here's the "misc" branch:
> http
On Tue, Jun 20, 2023 at 12:04:40PM +0800, Sui Jingfeng wrote:
> Where is the formal(unstream) PCI git branch where we could see the latest
> patch ?
Here's the "misc" branch:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=misc
And here's the "next" branch that will be merged
On Sat, Jun 10, 2023 at 02:07:58AM +0800, Sui Jingfeng wrote:
> On 2023/6/10 01:52, Bjorn Helgaas wrote:
> > On Fri, Jun 09, 2023 at 09:37:02AM +0800, Sui Jingfeng wrote:
> > > On 2023/6/9 01:32, Bjorn Helgaas wrote:
> > > > On Wed, Jun 07, 2023 at 06:55:
On Fri, Jun 09, 2023 at 09:37:02AM +0800, Sui Jingfeng wrote:
> On 2023/6/9 01:32, Bjorn Helgaas wrote:
> > On Wed, Jun 07, 2023 at 06:55:49PM +0800, Sui Jingfeng wrote:
> > > From: Sui Jingfeng
> > >
> > > This patch adds PCI driver support on top of what we
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 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,
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
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
On Wed, Jun 07, 2023 at 06:55:49PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> This patch adds PCI driver support on top of what we already have. Take
> the GC1000 in LS7A1000/LS2K1000 as the first instance of the PCI device
> driver. There is only one GPU core for the GC1000 in the LS7A1
upport.
>
> Cc: Lucas Stach
> Cc: Christian Gmeiner
> Cc: Philipp Zabel
> Cc: Bjorn Helgaas
> Cc: Daniel Vetter
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 34 ---
> 1 file changed, 25 insertions(+), 9 d
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
On Wed, Jun 07, 2023 at 02:43:27AM +0800, Sui Jingfeng wrote:
> On 2023/6/7 00:56, Bjorn Helgaas wrote:
> > On Sat, Jun 03, 2023 at 06:59:43PM +0800, Sui Jingfeng wrote:
> > > From: Sui Jingfeng
> > >
> > > Loongson CPUs maintain cache coherency by hardware
On Sat, Jun 03, 2023 at 06:59:43PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Loongson CPUs maintain cache coherency by hardware, which means that the
> data in the CPU cache is identical to the data in main system memory. As
> for the peripheral device, most of Loongson chips chose to d
On Thu, Jun 01, 2023 at 01:44:52AM +0800, Sui Jingfeng wrote:
> Can you receive my email?
>
> I reply several email to you, but Thunderbird told me that may mail is
> returned.
>
> Maybe you could read the content at lore.
I do receive your email (at least some; obviously if there are things
I d
1 - 100 of 488 matches
Mail list logo
