removal of the pci_msi_ignore_mask
> bodge devices behind a VMD bridge do work fine when use from a Linux Xen
> hardware domain. That's the whole point of the series.
>
> Signed-off-by: Roger Pau Monné
> Reviewed-by: Thomas Gleixner
> Acked-by: Juergen Gross
Acked-by:
> devices behind the VMD bridge.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Bjorn Helgaas
> ---
> Changes since v2:
> - Adjust patch subject.
> - Adjust code comment.
>
> Changes since v1:
> - Add xen header.
> - Expand comment.
> ---
> drivers/pci/con
On Tue, Feb 25, 2025 at 02:03:53PM +, Frediano Ziglio wrote:
> On XenServer on Windows machine a platform device with ID 2 instead of
> 1 is used.
> This device is mainly identical to device 1 but due to some Windows
> update behaviour it was decided to use a device with a different ID.
> This
The subject line convention for this file is:
PCI: vmd: Disable MSI remapping ...
On Tue, Jan 14, 2025 at 11:33:12AM +0100, Roger Pau Monne wrote:
> MSI remapping bypass (directly configuring MSI entries for devices on the
> VMD bus) won't work under Xen, as Xen is not aware of devices in such
It looks like the convention for this file is to capitalize the
subject, e.g.,
xen/pci: Do not register ...
On Tue, Jan 14, 2025 at 11:33:11AM +0100, Roger Pau Monne wrote:
> The current hypercall interface for doing PCI device operations always uses
> a segment field that has a 16 bit width.
[+to Juergen, Nirmal, +cc Jonathan]
On Tue, Jan 14, 2025 at 11:33:10AM +0100, Roger Pau Monne wrote:
> Hello,
>
> The following series should fix the usage of devices behind a VMD bridge
> when running Linux as a Xen PV hardware domain (dom0). I've only been
> able to test PV. I think PVH should
On Wed, Feb 12, 2025 at 01:35:16PM -0600, Bjorn Helgaas wrote:
> From: Bjorn Helgaas
>
> The Mediatek MT7922 WiFi device advertises FLR support, but it apparently
> does not work, and all subsequent config reads return ~0:
>
> pci :01:00.0: [14c3:0616] type 00 class 0x02
From: Bjorn Helgaas
The Mediatek MT7922 WiFi device advertises FLR support, but it apparently
does not work, and all subsequent config reads return ~0:
pci :01:00.0: [14c3:0616] type 00 class 0x028000 PCIe Endpoint
pciback :01:00.0: not ready 65535ms after FLR; giving up
After an
[+cc Alex, Mediatek folks, thread at
https://lore.kernel.org/r/Z4pHll_6GX7OUBzQ@mail-itl]
On Wed, Feb 05, 2025 at 11:14:17PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 30, 2025 at 03:31:23PM -0600, Bjorn Helgaas wrote:
> > On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beul
On Wed, Feb 05, 2025 at 11:14:17PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Jan 30, 2025 at 03:31:23PM -0600, Bjorn Helgaas wrote:
> > On Thu, Jan 30, 2025 at 10:30:33AM +0100, Jan Beulich wrote:
> > > On 30.01.2025 05:55, Marek Marczykowski-Górecki wrote:
> > &
On Thu, Feb 06, 2025 at 09:33:26AM +0100, Roger Pau Monné wrote:
> On Wed, Feb 05, 2025 at 09:17:31AM -0600, Bjorn Helgaas wrote:
> > Please run git log --oneline and match the subject line capitalization
> > style, i.e.,
> >
> > PCI/MSI: Remove ...
> >
Please run git log --oneline and match the subject line capitalization
style, i.e.,
PCI/MSI: Remove ...
But it doesn't look like this actually *removes* the functionality, it
just implements it differently so it can be applied more selectively.
So maybe the subject should say something like "c
ring config space via pci_restore_state(), where
we restore some PCIe registers and the header (first 64 bytes). My
*guess* is the device isn't ready (or at least not responding) since
all the reads return ~0.
> > [1] https://gist.github.com/marmarek/b4391c71801145e52590e877c559c5e0
On Wed, Jan 29, 2025 at 03:10:49AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 07:15:26PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-Górecki wrote:
> > > After updating PV dom0 to Linux 6.12, The Medi
On Wed, Jan 29, 2025 at 02:52:33PM +0100, Jan Beulich wrote:
> On 29.01.2025 14:32, Bjorn Helgaas wrote:
> > On Wed, Jan 29, 2025 at 04:47:28AM +0100, Marek Marczykowski-Górecki wrote:
> >> On Tue, Jan 28, 2025 at 09:40:18PM -0600, Bjorn Helgaas wrote:
> >>> I guess
On Wed, Jan 29, 2025 at 10:17:20AM +0100, Jan Beulich wrote:
> On 29.01.2025 04:22, Marek Marczykowski-Górecki wrote:
> > On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
> >> The report claims the problem only happens with Xen. I'm not a Xen
> >>
On Wed, Jan 29, 2025 at 04:47:28AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 09:40:18PM -0600, Bjorn Helgaas wrote:
> > I guess the code at [2] is running in user mode and uses Linux
> > syscalls for config access? Is it straceable?
>
> Nope
On Wed, Jan 29, 2025 at 04:22:43AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 29, 2025 at 03:10:49AM +0100, Marek Marczykowski-Górecki wrote:
> > > On Tue, Jan 28, 2025 at 07:15:26PM -0600, B
[+cc linux-pci]
On Wed, Jan 29, 2025 at 03:10:49AM +0100, Marek Marczykowski-Górecki wrote:
> On Tue, Jan 28, 2025 at 07:15:26PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 17, 2025 at 01:05:30PM +0100, Marek Marczykowski-Górecki wrote:
> > > After updating PV dom0 to Linux
ff ff
>
> The same operation done on Linux 6.12 running without Xen works fine.
>
> git bisect points at:
>
> commit d591f6804e7e1310881c9224d72247a2b65039af
> Author: Bjorn Helgaas
> Date: Tue Aug 27 18:48:46 2024 -0500
>
> PCI: Wait for device read
On Mon, Jan 13, 2025 at 11:18:57AM +0100, Roger Pau Monné wrote:
> On Fri, Jan 10, 2025 at 04:21:29PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 10, 2025 at 03:01:48PM +0100, Roger Pau Monne wrote:
> > > The PCI segment value is limited to 16 bits, however there are bus
On Mon, Jan 13, 2025 at 11:25:58AM +0100, Roger Pau Monné wrote:
> On Fri, Jan 10, 2025 at 04:30:57PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 10, 2025 at 03:01:50PM +0100, Roger Pau Monne wrote:
> > > Setting pci_msi_ignore_mask inhibits the toggling of the mask bit f
Match subject line style again.
On Fri, Jan 10, 2025 at 03:01:50PM +0100, Roger Pau Monne wrote:
> Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both MSI
> and MSI-X entries globally, regardless of the IRQ chip they are using. Only
> Xen sets the pci_msi_ignore_mask when r
On Fri, Jan 10, 2025 at 03:01:48PM +0100, Roger Pau Monne wrote:
> The PCI segment value is limited to 16 bits, however there are buses like VMD
> that fake being part of the PCI topology by adding segment with a number
> outside the scope of the PCI firmware specification range (>= 0x1). The
>
Match historical subject line style for prefix and capitalization:
PCI: vmd: Set devices to D0 before enabling PM L1 Substates
PCI: vmd: Add DID 8086:B06F and 8086:B60B for Intel client SKUs
PCI: vmd: Fix indentation issue in vmd_shutdown()
On Fri, Jan 10, 2025 at 03:01:49PM +0100, Roger Pa
[+cc personal address for Igor]
On Fri, Dec 13, 2024 at 12:30:42PM +0200, Kalle Valo wrote:
> Bjorn Helgaas writes:
>
> > [cc->to: Igor]
> >
> > On Mon, Dec 09, 2024 at 02:06:31PM +0100, Philipp Stanner wrote:
> >> pci_intx() is a hybrid function wh
[cc->to: Arnd, Greg, Alex]
On Mon, Dec 09, 2024 at 02:06:27PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-manage
[cc->to: Igor]
On Mon, Dec 09, 2024 at 02:06:31PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
>
[cc->to: Sudarsana, Manish, Rasesh]
On Mon, Dec 09, 2024 at 02:06:25PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a nev
[cc->to: Alex W]
On Mon, Dec 09, 2024 at 02:06:28PM +0100, Philipp Stanner wrote:
> pci_intx() is a hybrid function which can sometimes be managed through
> devres. To remove this hybrid nature from pci_intx(), it is necessary to
> port users to either an always-managed or a never-managed version.
On Mon, Dec 09, 2024 at 02:06:22PM +0100, Philipp Stanner wrote:
> @Driver-Maintainers: Your driver might be touched by patch "Remove
> devres from pci_intx()". You might want to take a look.
>
> Changes in v3:
> - Add Thomas' RB.
>
> Changes in v2:
> - Drop pci_intx() deprecation patch.
>
On Tue, Oct 15, 2024 at 08:51:10PM +0200, Philipp Stanner wrote:
> @Driver-Maintainers: Your driver might be touched by patch "Remove
> devres from pci_intx()". You might want to take a look.
>
> Changes since the RFC [1]:
> - Add a patch deprecating pci{m}_intx(). (Heiner, Andy, Me)
> - Add A
On Wed, Oct 16, 2024 at 10:53:16AM +0200, Philipp Stanner wrote:
> On Wed, 2024-10-16 at 10:43 +0200, Heiner Kallweit wrote:
> > On 16.10.2024 08:57, Philipp Stanner wrote:
> > > On Tue, 2024-10-15 at 13:53 -0600, Alex Williamson wrote:
> > > > On Tue, 15 Oct 2024 20:51:23 +0200
> > > > Philipp Sta
[+to Rafael]
On Mon, Apr 08, 2024 at 06:42:31AM +, Chen, Jiqian wrote:
> Hi Bjorn,
> It has been almost two months since we received your reply last time.
> This series are blocking on this patch, since there are patches on Xen and
> Qemu side depending on it.
> Do you still have any confusio
On Mon, Feb 12, 2024 at 10:13:28AM +0100, Roger Pau Monné wrote:
> On Fri, Feb 09, 2024 at 03:05:49PM -0600, Bjorn Helgaas wrote:
> > On Thu, Feb 01, 2024 at 09:39:49AM +0100, Roger Pau Monné wrote:
> > > On Wed, Jan 31, 2024 at 01:00:14PM -0600, Bjorn Helgaas wrote:
> >
On Thu, Feb 01, 2024 at 09:39:49AM +0100, Roger Pau Monné wrote:
> On Wed, Jan 31, 2024 at 01:00:14PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 31, 2024 at 09:58:19AM +0100, Roger Pau Monné wrote:
> > > On Tue, Jan 30, 2024 at 02:44:03PM -0600, Bjorn Helgaas wrote:
> >
On Wed, Jan 31, 2024 at 09:58:19AM +0100, Roger Pau Monné wrote:
> On Tue, Jan 30, 2024 at 02:44:03PM -0600, Bjorn Helgaas wrote:
> > On Tue, Jan 30, 2024 at 10:07:36AM +0100, Roger Pau Monné wrote:
> > > On Mon, Jan 29, 2024 at 04:01:13PM -0600, Bjorn Helgaas wrote:
> >
On Tue, Jan 30, 2024 at 10:07:36AM +0100, Roger Pau Monné wrote:
> On Mon, Jan 29, 2024 at 04:01:13PM -0600, Bjorn Helgaas wrote:
> > On Thu, Jan 25, 2024 at 07:17:24AM +, Chen, Jiqian wrote:
> > > On 2024/1/24 00:02, Bjorn Helgaas wrote:
> > > > On Tue, Jan 23,
On Thu, Jan 25, 2024 at 07:17:24AM +, Chen, Jiqian wrote:
> On 2024/1/24 00:02, Bjorn Helgaas wrote:
> > On Tue, Jan 23, 2024 at 10:13:52AM +, Chen, Jiqian wrote:
> >> On 2024/1/23 07:37, Bjorn Helgaas wrote:
> >>> On Fri, Jan 05, 2024 at 02:22:17PM +0800, J
On Tue, Jan 23, 2024 at 10:13:52AM +, Chen, Jiqian wrote:
> On 2024/1/23 07:37, Bjorn Helgaas wrote:
> > On Fri, Jan 05, 2024 at 02:22:17PM +0800, Jiqian Chen wrote:
> >> There is a need for some scenarios to use gsi sysfs.
> >> For example, when xen passthroug
On Fri, Jan 05, 2024 at 02:22:17PM +0800, Jiqian Chen wrote:
> There is a need for some scenarios to use gsi sysfs.
> For example, when xen passthrough a device to dumU, it will
> use gsi to map pirq, but currently userspace can't get gsi
> number.
> So, add gsi sysfs for that and for other potenti
On Wed, May 31, 2023 at 08:48:35PM +0200, Jonas Gorski wrote:
> ...
> Looking at the code I understand where coverity is coming from:
>
> #define __pci_dev_for_each_res0(dev, res, ...) \
>for (unsigned int __b = 0; \
>
On Fri, May 12, 2023 at 02:48:51PM -0500, Bjorn Helgaas wrote:
> On Fri, May 12, 2023 at 01:56:29PM +0300, Andy Shevchenko wrote:
> > On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> > > On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > >
On Fri, May 12, 2023 at 01:56:29PM +0300, Andy Shevchenko wrote:
> On Tue, May 09, 2023 at 01:21:22PM -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > &g
On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > Provide two new helper macros to iterate over PCI device resources and
> > convert users.
> Applied 2-7 to pci/resource for v6.4, thanks, I reall
On Wed, Apr 05, 2023 at 11:28:27AM +0300, Andy Shevchenko wrote:
> On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> > > Provide two new helper macros to iterate over PCI device resources and
&
On Wed, Apr 05, 2023 at 02:50:47PM +0300, Andy Shevchenko wrote:
> On Thu, Mar 30, 2023 at 07:24:32PM +0300, Andy Shevchenko wrote:
> > Refactor pci_bus_for_each_resource() in the same way as it's done in
> > pci_dev_for_each_resource() case. This will allow to hide iterator
> > inside the loop, wh
On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
> Provide two new helper macros to iterate over PCI device resources and
> convert users.
>
> Looking at it, refactor existing pci_bus_for_each_resource() and convert
> users accordingly.
>
> Note, the amount of lines grew due to th
On Thu, Mar 23, 2023 at 04:30:01PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 22, 2023 at 02:28:04PM -0500, Bjorn Helgaas wrote:
> > On Mon, Mar 20, 2023 at 03:16:30PM +0200, Andy Shevchenko wrote:
> ...
>
> > > + pci_dev_for_each_resource_p(dev, r) {
> > >
On Mon, Mar 20, 2023 at 03:16:31PM +0200, Andy Shevchenko wrote:
> ...
> -#define pci_bus_for_each_resource(bus, res, i)
> \
> - for (i = 0; \
> - (res = pci_bus_resource_n(bus, i)) || i < PCI_BRIDGE_RES
Hi Andy and Mika,
I really like the improvements here. They make the code read much
better.
On Mon, Mar 20, 2023 at 03:16:30PM +0200, Andy Shevchenko wrote:
> From: Mika Westerberg
> ...
> static void fixup_winbond_82c105(struct pci_dev* dev)
> {
> - int i;
> + struct resource *r;
>
The conventional style for subject (from "git log --oneline") is:
xen/pcifront: Handle ...
On Mon, Aug 29, 2022 at 11:15:36AM -0400, Jason Andryuk wrote:
> An HVM guest with linux stubdom and 2 PCI devices failed to start as
"stubdom" might be handy shorthand in the Xen world, but I think
it w
On Mon, Feb 14, 2022 at 11:07:47AM +0100, Josef Johansson wrote:
> From: Josef Johansson
>
> PCI/MSI: Correct use of can_mask in msi_add_msi_desc()
>
> Commit 71020a3c0dff4 ("PCI/MSI: Use msi_add_msi_desc()") modifies
> the logic of checking msi_attrib.can_mask, without any reason.
>
>
On Fri, Aug 05, 2022 at 09:10:41AM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 05, 2022 at 12:03:15PM +0200, Josef Johansson wrote:
> > On 2/14/22 11:07, Josef Johansson wrote:
> > > From: Josef Johansson
> > >
> > > PCI/MSI: Correct use of can_mask in msi_add_msi_desc()
> > > Commit 71020a3c0dff
On Fri, Feb 11, 2022 at 01:10:22AM +0100, Josef Johansson wrote:
> On 2/11/22 00:55, Bjorn Helgaas wrote:
> > On Sat, Jan 22, 2022 at 02:10:01AM +0100, Josef Johansson wrote:
> >> From: Josef Johansson
> >>
> >> PCI/MSI: msix_setup_msi_descs: Restore logic for
[+cc Jason, since you reviewed the original commit]
On Sat, Jan 22, 2022 at 02:10:01AM +0100, Josef Johansson wrote:
> From: Josef Johansson
>
> PCI/MSI: msix_setup_msi_descs: Restore logic for msi_attrib.can_mask
Please match the form and style of previous subject lines (in
particular, omit "m
On Mon, Dec 06, 2021 at 11:51:33PM +0100, Thomas Gleixner wrote:
> Replace the about to vanish iterators and make use of the filtering. Take
> the descriptor lock around the iterators.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/contr
On Mon, Dec 06, 2021 at 11:51:18PM +0100, Thomas Gleixner wrote:
> Use the new iterator functions which pave the way for dynamically extending
> MSI-X vectors.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |4 ++--
xner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |3 ++-
> drivers/pci/msi/legacy.c|1 +
> drivers/pci/msi/msi.c | 14 --
> 3 files changed, 3 insertions(+), 15 deletions(-)
>
> --- a/drivers/pci/msi/irqdomain.c
> +++ b/drivers
xner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/msi.c | 122
> --
> 1 file changed, 59 insertions(+), 63 deletions(-)
>
> --- a/drivers/pci/msi/msi.c
> +++ b/drivers/pci/msi/msi.c
> @@ -340,45 +340,51 @@ v
: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> Documentation/driver-api/pci/pci.rst |2
> drivers/pci/Makefile |3
> drivers/pci/msi.c| 1532
> ---
> drivers/pci/msi/Makefile
On Mon, Dec 06, 2021 at 11:27:49PM +0100, Thomas Gleixner wrote:
> These functions are required even when CONFIG_PCI_MSI is not set. Move them
> to their own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked
reverse lock ordering vs. CPU hotplug lock as some callers of the PCI/MSI
> allocation interfaces already hold it.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |4 -
> drivers/pci/msi/msi.c | 120
>
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas# PCI
> ---
> drivers/pci/msi/irqdomain.c | 13 -
> include/linux/msi.h |5 +
> kernel/irq/msi.c| 29 +
> 3 files changed, 26 insertions(+), 21 de
On Mon, Dec 06, 2021 at 11:39:41PM +0100, Thomas Gleixner wrote:
> Use msi_get_vector() and handle the return value to be compatible.
>
> No functional change intended.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: Handle the INTx case directly
-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c | 16 ++--
> include/linux/msi.h |2 ++
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> --- a
On Mon, Dec 06, 2021 at 11:39:26PM +0100, Thomas Gleixner wrote:
> Store the properties which are interesting for various places so the MSI
> descriptor fiddling can be removed.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: Use the setter function
&g
specific storage for no value.
>
> Signed-off-by: Thomas Gleixner
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> arch/powerpc/platforms/pseries/msi.c |4 ++--
> arch/x86/pci/xen.c |2 +-
>
y: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |2 +-
> drivers/pci/msi/legacy.c|6 +-
> drivers/pci/msi/msi.c | 23 ---
> include/linux/pci.h |1 -
> 4 files changed, 6 insertions(+), 26 del
nthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/msi.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> --- a/drivers/pci/msi/msi.c
> +++ b/drivers/pci/msi/msi.c
> @@ -889,10 +889,12 @@ static int __pci_enable_msi_range(struc
On Mon, Dec 06, 2021 at 11:28:00PM +0100, Thomas Gleixner wrote:
> The irqdomain code already returns the information. Move the loop to the
> legacy code.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
On Mon, Dec 06, 2021 at 11:27:57PM +0100, Thomas Gleixner wrote:
> No users outside of that file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/irqdomain.c |5 +++--
&
On Mon, Dec 06, 2021 at 11:27:56PM +0100, Thomas Gleixner wrote:
> It's only required for PCI/MSI. So no point in having it in every struct
> device.
>
> Signed-off-by: Thomas Gleixner
Acked-by: Bjorn Helgaas
> ---
> V2: New patch
> ---
> drivers/base/core.c
esciptors/descriptors/
> Store the mapping in struct pci_dev and free it after freeing the MSI-X
> descriptors.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi/msi.c | 18
On Mon, Dec 06, 2021 at 11:27:52PM +0100, Thomas Gleixner wrote:
> Move the irqdomain specific code into it's own file.
s/it's/its/
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> driver
On Mon, Dec 06, 2021 at 11:27:51PM +0100, Thomas Gleixner wrote:
> Split out the non irqdomain code into its own file.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> V2: Add proper includes
nthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -642,8 +642,8 @@ static void msix_update_entries(struct p
> {
> struct msi_de
On Mon, Dec 06, 2021 at 11:27:44PM +0100, Thomas Gleixner wrote:
> Get rid of the pile of unneeded includes which accumulated over time.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
Nice, thanks!
>
-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
> Cc: x...@kernel.org
> Cc: xen-devel@lists.xenproject.org
> Cc: Christian Borntraeger
> Cc: Heiko Carstens
Acked-by: Bjorn Helgaas# PCI
> ---
> arch/s390/pci/pci_irq.c |4 +-
> arch/x86/include/a
On Mon, Dec 06, 2021 at 11:27:36PM +0100, Thomas Gleixner wrote:
> instead of fiddling with msi descriptors.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
s/msi/MSI/ above if you have a chance. Nice
On Mon, Dec 06, 2021 at 11:27:34PM +0100, Thomas Gleixner wrote:
> Last user is gone long ago.
>
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi.c |8
> in
nthorpe
Acked-by: Bjorn Helgaas# PCI
> ---
> drivers/irqchip/irq-gic-v2m.c|1 -
> drivers/irqchip/irq-gic-v3-its-pci-msi.c |1 -
> drivers/irqchip/irq-gic-v3-mbi.c |1 -
> drivers/pci/msi.c|2 +-
> include/linux/msi.
s: aff171641d18 ("PCI: Provide sensible IRQ vector alloc/free routines")
> Signed-off-by: Thomas Gleixner
> Tested-by: Juergen Gross
> Reviewed-by: Jason Gunthorpe
Acked-by: Bjorn Helgaas
> ---
> V2: Fix typo in subject - Jason
> ---
> drivers/pci/msi.c | 26
On Tue, Oct 19, 2021 at 10:15:05PM +0200, Josef Johansson wrote:
> On 10/19/21 21:57, Bjorn Helgaas wrote:
> > On Mon, Oct 18, 2021 at 08:22:32AM +0200, Josef Johansson wrote:
> I'll make an effort to do a better commit log. Thanks for reviewing the
> entry!
>
> What i
[+cc Marc]
On Mon, Oct 18, 2021 at 08:22:32AM +0200, Josef Johansson wrote:
> From: Josef Johansson
>
>
> PCI/MSI: Re-add checks for skip masking MSI-X on Xen PV
>
> 'commit fcacdfbef5a1 ("PCI/MSI: Provide a new set of mask and unmask
> functions")' introduced functions pci_msi_update_mask
On Wed, Oct 13, 2021 at 04:23:09PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 13, 2021 at 06:33:56AM -0500, Bjorn Helgaas wrote:
> > On Wed, Oct 13, 2021 at 12:26:42PM +0300, Andy Shevchenko wrote:
> > > On Wed, Oct 13, 2021 at 2:33 AM Bjorn Helgaas wrote:
> > > >
On Wed, Oct 13, 2021 at 12:26:42PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 13, 2021 at 2:33 AM Bjorn Helgaas wrote:
> > On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
>
> > I split some of the bigger patches apart so they only touched one
> > drive
On Wed, Oct 13, 2021 at 10:51:31AM +0200, Uwe Kleine-König wrote:
> On Tue, Oct 12, 2021 at 06:32:12PM -0500, Bjorn Helgaas wrote:
> > On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
> > > Hello,
> > >
> > > this is v6 of the quest to drop the
On Mon, Oct 04, 2021 at 02:59:24PM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this is v6 of the quest to drop the "driver" member from struct pci_dev
> which tracks the same data (apart from a constant offset) as dev.driver.
I like this a lot and applied it to pci/driver for v5.16, thanks!
I sp
ency: At present,
> XEN_PV con only be set when X86 is also enabled. In general an
> architecture supporting Xen PV (and PCI) would want to have this driver
> built.
s/con only/can only/
> Signed-off-by: Jan Beulich
> Reviewed-by: Stefano Stabellini
Acked-by: Bjorn Helgaas
&g
On Tue, Sep 07, 2021 at 06:14:16PM +0200, Jan Beulich wrote:
> On 07.09.2021 17:30, Bjorn Helgaas wrote:
> > Update subject to follow conventions (use "git log --oneline
> > drivers/pci/Kconfig"). Should say what this patch does.
>
> I can change that; I don&#x
Update subject to follow conventions (use "git log --oneline
drivers/pci/Kconfig"). Should say what this patch does.
Commit log below should also say what this patch does. Currently it's
part of the rationale for the change, but doesn't say what the patch
does.
On Tue, Sep 07, 2021 at 02:10:41P
On Mon, Aug 30, 2021 at 10:14:26PM +0200, Sergio Miguéns Iglesias wrote:
> Thanks again for you answers!
> I am lerning a lot from your replys and I really appreciate it. Should I
> make a v3 patch and split that one into 2 different patches or would it
> be confusing?
>
> I don't want to take mor
On Mon, Aug 30, 2021 at 07:53:05PM +0200, Sergio Miguéns Iglesias wrote:
> An unnecessary "__ref" annotation was removed from the
> "drivers/pci/xen_pcifront.c" file. The function where the annotation
> was used was "pcifront_backend_changed()", which does not call any
> functions annotated as "__*
000e]
> local_pci_probe+0x42/0x80
> (...)
>
> There is pci_msi_ignore_mask variable for bypassing MSI(-X) masking on Xen
> PV, but msix_mask_all() missed checking it. Add the check there too.
>
> Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries"
On Thu, Aug 26, 2021 at 06:36:49PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Aug 26, 2021 at 09:55:32AM -0500, Bjorn Helgaas wrote:
> > If/when you repost this, please run "git log --oneline
> > drivers/pci/msi.c" and follow the convention of capitali
If/when you repost this, please run "git log --oneline
drivers/pci/msi.c" and follow the convention of capitalizing the
subject line.
Also, I think this patch refers specifically to MSI-X, not MSI, so
please update the subject line and the "masking MSI" below to reflect
that.
On Thu, Aug 26, 2021
On Thu, Aug 05, 2021 at 12:28:32AM +0200, Sergio Miguéns Iglesias wrote:
> The code style for most files was fixed. This means that blank lines
> were added when needed (normally after variable declarations), spaces
> before tabs were removed, some code alignment issues were solved, block
> comment
On Sat, Aug 07, 2021 at 11:26:45AM +0200, Uwe Kleine-König wrote:
> On Fri, Aug 06, 2021 at 04:24:52PM -0500, Bjorn Helgaas wrote:
> > On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> > > On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> >
On Fri, Aug 06, 2021 at 08:46:23AM +0200, Uwe Kleine-König wrote:
> On Thu, Aug 05, 2021 at 06:42:34PM -0500, Bjorn Helgaas wrote:
> > I looked at all the bus_type.probe() methods, it looks like pci_dev is
> > not the only offender here. At least the following also have a driver
1 - 100 of 129 matches
Mail list logo
