Re: [PATCH v2 1/1] PCI/IOV: Fix incorrect cfg_size for VF > 0

This looks to basically be a duplicate of what Alex Williamson posted 8 days ago: https://lore.kernel.org/linux-pci/20190604143617.0a226...@x1.home/ Alex says Hao Zheng had a similar patch as well. On Wed, Jun 12, 2019 at 12:08 PM wrote: > > From: Kuppuswamy Sathyanarayanan > > Commit

[PATCH v2] net/mlx5e: Use device ID defines

. Signed-off-by: Myron Stowe <myron.st...@redhat.com> --- drivers/net/ethernet/mellanox/mlx5/core/main.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 0c123d5..8

[PATCH v2] net/mlx5e: Use device ID defines

. Signed-off-by: Myron Stowe --- drivers/net/ethernet/mellanox/mlx5/core/main.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c index 0c123d5..8a4e292 100644 --- a/drivers/net

Re: [PATCH] PCI/MSI: Export all remapped MSIs to sysfs attributes

On Thu, Oct 15, 2015 at 11:23 AM, Bjorn Helgaas wrote: > On Thu, Sep 24, 2015 at 01:31:16AM +0200, Romain Bezut wrote: >> irqbalance uses these attributes to populate its internal database, which is >> then used to bind the irq on the appropriate NUMA node. >> >> On a device

Re: [PATCH] PCI/MSI: Export all remapped MSIs to sysfs attributes

On Thu, Oct 15, 2015 at 11:23 AM, Bjorn Helgaas wrote: > On Thu, Sep 24, 2015 at 01:31:16AM +0200, Romain Bezut wrote: >> irqbalance uses these attributes to populate its internal database, which is >> then used to bind the irq on the appropriate NUMA node. >> >> On a device accepting multiple

Re: [PATCH v3] iommu/vt-d: Flush old iommu caches for kdump when the device gets context mapped

On Tue, Dec 6, 2016 at 9:03 AM, Joerg Roedel wrote: > On Mon, Dec 05, 2016 at 08:09:07PM +0800, Xunlei Pang wrote: >> drivers/iommu/intel-iommu.c | 19 +++ >> 1 file changed, 19 insertions(+) > > Applied, thanks. Joerg: This didn't seem to make the 4.10 merge

Re: [PATCH v3] iommu/vt-d: Flush old iommu caches for kdump when the device gets context mapped

On Tue, Dec 6, 2016 at 9:03 AM, Joerg Roedel wrote: > On Mon, Dec 05, 2016 at 08:09:07PM +0800, Xunlei Pang wrote: >> drivers/iommu/intel-iommu.c | 19 +++ >> 1 file changed, 19 insertions(+) > > Applied, thanks. Joerg: This didn't seem to make the 4.10 merge window. Was that

Re: [RFC 0/1] New PCI Switch Management Driver

I guess the obvious questions is: why is a driver for a PCI switch necessary? The core works with all compliant switches today and there are no specifics for a particular design or such. So I guess I'd like to hear the reasoning and justifications for why a driver for a common device that should

Re: [RFC 0/1] New PCI Switch Management Driver

I guess the obvious questions is: why is a driver for a PCI switch necessary? The core works with all compliant switches today and there are no specifics for a particular design or such. So I guess I'd like to hear the reasoning and justifications for why a driver for a common device that should

Re: [PATCH 2/2] pci: Don't set RCB bit in LNKCTL if the upstream bridge hasn't

collect the /proc/iomem contents, too. That's >> not for this bug; it's because I'm curious about the >> >> ERST: Can not request [mem 0xb928b000-0xb928cbff] for ERST >> >> problem in your dmesg log. > > Oops, I goofed and forgot to clear RCB by default. >

Re: [PATCH 2/2] pci: Don't set RCB bit in LNKCTL if the upstream bridge hasn't

128-byte RCB but doesn't actually support it. I didn't >> bother with that and set the Endpoint's RCB to 128 in all cases when >> the Root Port claims to support it. >> >> It'd be great if you could test this and comment. >> >> If you get a chance, collect the /proc/io

Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped

caching mode is 0, the fault is >> probably due to the old iotlb cache of the in-flight DMA. >> >> Thus need to flush the old iotlb after context mapping is setup for the >> device, where the device is supposed to finish reset at its driver probe >> stage and no in

Re: [PATCH] iommu/vt-d: Flush old iotlb for kdump when the device gets context mapped

e fault is >> probably due to the old iotlb cache of the in-flight DMA. >> >> Thus need to flush the old iotlb after context mapping is setup for the >> device, where the device is supposed to finish reset at its driver probe >> stage and no in-flight DMA exists hereaft

Re: [RFC] PCI: Unassigned Expansion ROM BARs

Here it is a year later and there has basically been no progress on this ongoing situation. I still often encounter bugs raised against the kernel w.r.t. unmet resource allocations - here is the most recent example, I'll attach the 'dmesg' log from the platform at

Re: [RFC] PCI: Unassigned Expansion ROM BARs

Here it is a year later and there has basically been no progress on this ongoing situation. I still often encounter bugs raised against the kernel w.r.t. unmet resource allocations - here is the most recent example, I'll attach the 'dmesg' log from the platform at

Re: [PATCH] PCI: Mark Haswell Power Control Unit as having non-compliant BARs

On Wed, Aug 31, 2016 at 11:12 AM, Prarit Bhargava <pra...@redhat.com> wrote: > On 08/31/2016 12:46 PM, Myron Stowe wrote: >> On Wed, Aug 31, 2016 at 9:50 AM, Bjorn Helgaas <bhelg...@google.com> wrote: >>> The Haswell Power Control Unit has a non-PCI register (CONFI

Re: [PATCH] PCI: Mark Haswell Power Control Unit as having non-compliant BARs

On Wed, Aug 31, 2016 at 11:12 AM, Prarit Bhargava wrote: > On 08/31/2016 12:46 PM, Myron Stowe wrote: >> On Wed, Aug 31, 2016 at 9:50 AM, Bjorn Helgaas wrote: >>> The Haswell Power Control Unit has a non-PCI register (CONFIG_TDP_NOMINAL) >>> where BAR 0 is supposed to

Re: [PATCH] PCI: Mark Haswell Power Control Unit as having non-compliant BARs

0, pci_invalid_bar); > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar); > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar); > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar); > Acked-by: Myron Stowe <myron.st...@redhat.com>

Re: [PATCH] PCI: Mark Haswell Power Control Unit as having non-compliant BARs

t; -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_bdwep_bar); > -DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_bdwep_bar); > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x2fc0, pci_invalid_bar); > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6f60, pci_invalid_bar); > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fa0, pci_invalid_bar); > +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x6fc0, pci_invalid_bar); > Acked-by: Myron Stowe

Re: [PATCH v4] pci: Limit VPD length for megaraid_sas adapter

; > >> >> This seems like a defect in the megaraid hardware or firmware. If the >> VPD ROM contains junk, there's no hope that software can read the data >> and figure out how much is safe to read. > > Yes this looks like problem with megaraid hardware. Agreed, it is a def

Re: [PATCH v4] pci: Limit VPD length for megaraid_sas adapter

r28=0x r29=0x r30=0x07feffb468d1 > r31=0x00105d94 > > > >> >> This seems like a defect in the megaraid hardware or firmware. If the >> VPD ROM contains junk, there's no hope that software can read the data >> and figure

Re: [PATCH v2] pci: Limit VPD length for megaraid_sas adapter

On Wed, Nov 11, 2015 at 8:54 AM, Babu Moger wrote: > Changes since v1 -> v2 > Removed the changes in pci_id.h. Kept all the vendor > ids in quirks.c > > Reading or Writing of PCI VPD data causes system panic. > We saw this problem by running "lspci -vvv" in the beginning. > However this can be

Re: [PATCH v2] pci: Limit VPD length for megaraid_sas adapter

On Wed, Nov 11, 2015 at 8:54 AM, Babu Moger wrote: > Changes since v1 -> v2 > Removed the changes in pci_id.h. Kept all the vendor > ids in quirks.c > > Reading or Writing of PCI VPD data causes system panic. > We saw this problem by running "lspci -vvv" in the beginning. >

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe wrote: snip > > There is a kernel boot parameter, pci=norom, that is intended to disable the > kernel's resource assignment actions for Expansion ROMs that do not already > have BIOS assigned address ranges. Note however, if I rememb

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe wrote: snip > > The kernel expects device Expansion ROM BARs to be programmed with valid > values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the > device’s expansion ROM address space is disabled). This seems to b

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe <myron.st...@gmail.com> wrote: snip > > There is a kernel boot parameter, pci=norom, that is intended to disable the > kernel's resource assignment actions for Expansion ROMs that do not already > have BIOS assigned address ranges.

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Wed, Sep 23, 2015 at 8:47 PM, Myron Stowe <myron.st...@gmail.com> wrote: snip > > The kernel expects device Expansion ROM BARs to be programmed with valid > values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the > device’s expansion ROM address space is disa

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Fri, Sep 25, 2015 at 7:31 AM, Myron Stowe wrote: > On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu wrote: >> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote: >> >>> Or do we want to keep a white list to say which device should have >>> ROM bar as mush ha

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu wrote: > On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote: > >> Or do we want to keep a white list to say which device should have >> ROM bar as mush have, and other is optional to have ? I suppose this idea is one possible outcome that could occur

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Fri, Sep 25, 2015 at 7:31 AM, Myron Stowe <myron.st...@gmail.com> wrote: > On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu <ying...@kernel.org> wrote: >> On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu <ying...@kernel.org> wrote: >> >>> Or do we want to ke

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Thu, Sep 24, 2015 at 10:35 PM, Yinghai Lu wrote: > On Thu, Sep 24, 2015 at 12:01 PM, Yinghai Lu wrote: > >> Or do we want to keep a white list to say which device should have >> ROM bar as mush have, and other is optional to have ? I suppose this idea

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Wed, Sep 23, 2015 at 9:21 PM, Yinghai Lu wrote: > On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe wrote: >> >> The kernel expects device Expansion ROM BARs to be programmed with valid >> values - even if the respective Expansion ROM's Enable bit is 0 (i.e. the >> dev

Re: [RFC] PCI: Unassigned Expansion ROM BARs

On Wed, Sep 23, 2015 at 9:21 PM, Yinghai Lu <ying...@kernel.org> wrote: > On Wed, Sep 23, 2015 at 7:47 PM, Myron Stowe <myron.st...@gmail.com> wrote: >> >> The kernel expects device Expansion ROM BARs to be programmed with valid >> values - even if the respectiv

[RFC] PCI: Unassigned Expansion ROM BARs

I've encountered numerous bugzilla reports related to platform BIOS' not programming valid values into a PCI device's Type 0 Configuration space "Expansion ROM Base Address" field (a.k.a. Expansion ROM BAR). The main observed consequence being 'dmesg' entries like the following that get customers

Re: [PATCH] PCI: Relax function 0 VPD test and relocate

0->class && > + dev->vendor == f0->vendor && dev->device == f0->device) > + dev->dev_flags |= PCI_DEV_FLAGS_VPD_REF_F0; > + > + pci_dev_put(f0); > } > DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, >

Re: [PATCH] PCI: Fix devfn for VPD access through function 0

struct pci_dev *tdev = pci_get_slot(dev->bus, PCI_SLOT(dev->devfn)); > + struct pci_dev *tdev = pci_get_slot(dev->bus, > + PCI_DEVFN(PCI_SLOT(dev->devfn), > 0)); > int ret = 0; > > if

Re: [PATCH] PCI: Relax function 0 VPD test and relocate

> + > + if (f0->vpd && dev->class == f0->class && > + dev->vendor == f0->vendor && dev->device == f0->device) > + dev->dev_flags |= PCI_DEV_FLAGS_VPD_REF_F0; > + > + pci_dev_put(f0); > } >

Re: [PATCH] PCI: Fix devfn for VPD access through function 0

t; 0)); > int ret = 0; > > if (!tdev) > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html A

[RFC] PCI: Unassigned Expansion ROM BARs

I've encountered numerous bugzilla reports related to platform BIOS' not programming valid values into a PCI device's Type 0 Configuration space "Expansion ROM Base Address" field (a.k.a. Expansion ROM BAR). The main observed consequence being 'dmesg' entries like the following that get customers

Re: [PATCH 3.4 037/176] PCI: Restore detection of read-only BARs

On Thu, 2015-04-09 at 16:44 +0800, l...@kernel.org wrote: > From: Myron Stowe > > 3.4.107-rc1 review patch. If anyone has any objections, please let me know. No objections, but I think you want 06cf35f903aa ("PCI: Handle read-only BARs on AMD CS553x devices"

Re: [PATCH 3.4 037/176] PCI: Restore detection of read-only BARs

On Thu, 2015-04-09 at 16:44 +0800, l...@kernel.org wrote: From: Myron Stowe myron.st...@redhat.com 3.4.107-rc1 review patch. If anyone has any objections, please let me know. No objections, but I think you want 06cf35f903aa (PCI: Handle read-only BARs on AMD CS553x devices) at the same time

Re: [PATCH] PCI: Expand quirk's handling of CS553x devices

erested in the resolution] > > On Tue, Feb 03, 2015 at 04:01:24PM -0700, Myron Stowe wrote: >> There seem to be a number of issues with CS553x devices and due to a >> recent patch series that detects PCI read-only BARs [1], we've encountered >> more. >> &g

Re: [PATCH] PCI: Expand quirk's handling of CS553x devices

in the resolution] On Tue, Feb 03, 2015 at 04:01:24PM -0700, Myron Stowe wrote: There seem to be a number of issues with CS553x devices and due to a recent patch series that detects PCI read-only BARs [1], we've encountered more. It appears that not only are the BAR values associated

[PATCH] PCI: Expand quirk's handling of CS553x devices

7e79c5f8cad2 PCI: Add informational printk for invalid BARs [2] https://bugzilla.kernel.org/show_bug.cgi?id=85991 (Comment #4 forward) Reference: support.amd.com/TechDocs/31506_cs5535_databook.pdf Reported-by: Nix Signed-off-by: Myron Stowe Fixes: 36e8164882ca ("PCI: Restore detection of read

Re: [3.18.3 BISECTED REGRESSION] scx200_acb / cs5535-smb / geodewdt / cs5535-clockevt torpedoed

On Tue, Feb 3, 2015 at 1:01 PM, Nix wrote: > On 3 Feb 2015, Myron Stowe uttered the following: >> As expressed above, I believe this device is non-conformant. This could be >> validated by instrumenting the kernel's sizing code in '__pci_read_base()'; >> spe

Re: [3.18.3 BISECTED REGRESSION] scx200_acb / cs5535-smb / geodewdt / cs5535-clockevt torpedoed

On Tue, Feb 3, 2015 at 9:50 AM, Bjorn Helgaas wrote: > On Mon, Feb 2, 2015 at 11:36 AM, Nix wrote: >> On 2 Feb 2015, Myron Stowe verbalised: >> >>> Nix: >>> >>> Thanks for the work you've already done with the bisection. Let's see >>> if we ca

Re: [3.18.3 BISECTED REGRESSION] scx200_acb / cs5535-smb / geodewdt / cs5535-clockevt torpedoed

On Tue, Feb 3, 2015 at 9:50 AM, Bjorn Helgaas bhelg...@google.com wrote: On Mon, Feb 2, 2015 at 11:36 AM, Nix n...@esperi.org.uk wrote: On 2 Feb 2015, Myron Stowe verbalised: Nix: Thanks for the work you've already done with the bisection. Let's see if we can get to the bottom

[PATCH] PCI: Expand quirk's handling of CS553x devices

7e79c5f8cad2 PCI: Add informational printk for invalid BARs [2] https://bugzilla.kernel.org/show_bug.cgi?id=85991 (Comment #4 forward) Reference: support.amd.com/TechDocs/31506_cs5535_databook.pdf Reported-by: Nix n...@esperi.org.uk Signed-off-by: Myron Stowe myron.st...@redhat.com Fixes: 36e8164882ca

Re: [3.18.3 BISECTED REGRESSION] scx200_acb / cs5535-smb / geodewdt / cs5535-clockevt torpedoed

On Tue, Feb 3, 2015 at 1:01 PM, Nix n...@esperi.org.uk wrote: On 3 Feb 2015, Myron Stowe uttered the following: As expressed above, I believe this device is non-conformant. This could be validated by instrumenting the kernel's sizing code in '__pci_read_base()'; specifically the initial

Re: [3.18.3 BISECTED REGRESSION] scx200_acb / cs5535-smb / geodewdt / cs5535-clockevt torpedoed

S engine enabled. > [1.504232] cs5535-mfgpt cs5535-mfgpt: registered timer 1 > [1.506634] cs5535-clockevt: Registering MFGPT timer as a clock event, > using IRQ 7 > > Bisected to: > > commit efdb9b956aa06868a052f0d4387f5f34e2321e41 > Author: Myron Stowe > Date:

Re: [3.18.3 BISECTED REGRESSION] scx200_acb / cs5535-smb / geodewdt / cs5535-clockevt torpedoed

1 [1.506634] cs5535-clockevt: Registering MFGPT timer as a clock event, using IRQ 7 Bisected to: commit efdb9b956aa06868a052f0d4387f5f34e2321e41 Author: Myron Stowe myron.st...@redhat.com Date: Thu Oct 30 11:54:37 2014 -0600 PCI: Restore detection of read-only BARs

Re: [PATCH 6/6] pci, acpi: Share ACPI PCI config space accessors.

On Thu, Nov 20, 2014 at 3:26 PM, Bjorn Helgaas wrote: > On Wed, Nov 19, 2014 at 05:19:20PM +0100, Arnd Bergmann wrote: >> On Wednesday 19 November 2014 17:04:51 Tomasz Nowicki wrote: >> > +/* >> > + * raw_pci_read/write - ACPI PCI config space accessors. >> > + * >> > + * ACPI spec defines MMCFG

Re: [PATCH 6/6] pci, acpi: Share ACPI PCI config space accessors.

On Thu, Nov 20, 2014 at 3:26 PM, Bjorn Helgaas bhelg...@google.com wrote: On Wed, Nov 19, 2014 at 05:19:20PM +0100, Arnd Bergmann wrote: On Wednesday 19 November 2014 17:04:51 Tomasz Nowicki wrote: +/* + * raw_pci_read/write - ACPI PCI config space accessors. + * + * ACPI spec defines

[PATCH v2] PCI: Remove fixed parameter in pci_iov_resource_bar()

pci_iov_resource_bar() always sets its 'pci_bar_type' parameter to 'pci_bar_unknown'. Drop the parameter and just use 'pci_bar_unknown' directly in the callers. No functional change intended. Signed-off-by: Myron Stowe Cc: Chris Wright Cc: Yu Zhao --- drivers/pci/iov.c | 11

[PATCH v2] PCI: Remove fixed parameter in pci_iov_resource_bar()

pci_iov_resource_bar() always sets its 'pci_bar_type' parameter to 'pci_bar_unknown'. Drop the parameter and just use 'pci_bar_unknown' directly in the callers. No functional change intended. Signed-off-by: Myron Stowe myron.st...@redhat.com Cc: Chris Wright chr...@sous-sol.org Cc: Yu Zhao yuz

[PATCH] PCI: Remove fixed parameter in pci_iov_resource_bar()

pci_iov_resource_bar() always sets its 'pci_bar_type' parameter to 'pci_bar_unknown'. Drop the parameter and just use 'pci_bar_unknown' directly in the callers. No functional change intended. Signed-off-by: Myron Stowe Cc: Chris Wright Cc: Yu Zhao --- drivers/pci/iov.c | 11

[PATCH 0/3] PCI: Fix detection of read-only BARs

illa.kernel.org/show_bug.cgi?id=43331 [4] https://bugzilla.kernel.org/show_bug.cgi?id=85991 Myron Stowe (3): PCI: Restore detection of read-only BARs PCI: Re-factor __pci_read_base PCI: Add a informational printk for invalid BARs drivers/pci/probe.c | 75 +

[PATCH 3/3] PCI: Add a informational printk for invalid BARs

-by: Myron Stowe Cc: Matthew Wilcox --- drivers/pci/probe.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 5c13279..2953c1d 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -271,8 +271,11 @@ int __pci_read_base(struct

[PATCH 2/3] PCI: Re-factor __pci_read_base

bit BARs, consolidating both cases. No functional change intended. Reported-by: William Unruh Reported-by: Martin Lucina Signed-off-by: Myron Stowe Cc: Matthew Wilcox --- drivers/pci/probe.c | 77 +-- 1 file changed, 32 insertions(+), 45

[PATCH 1/3] PCI: Restore detection of read-only BARs

_bug.cgi?id=85991 Reported-by: William Unruh Reported-by: Martin Lucina Signed-off-by: Myron Stowe Cc: Matthew Wilcox --- drivers/pci/probe.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 5ed9930..19dc247 100644 --- a/drivers/pci/prob

[PATCH 1/3] PCI: Restore detection of read-only BARs

...@physics.ubc.ca Reported-by: Martin Lucina mar...@lucina.net Signed-off-by: Myron Stowe myron.st...@redhat.com Cc: Matthew Wilcox wi...@linux.intel.com --- drivers/pci/probe.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 5ed9930

[PATCH 2/3] PCI: Re-factor __pci_read_base

bit BARs, consolidating both cases. No functional change intended. Reported-by: William Unruh un...@physics.ubc.ca Reported-by: Martin Lucina mar...@lucina.net Signed-off-by: Myron Stowe myron.st...@redhat.com Cc: Matthew Wilcox wi...@linux.intel.com --- drivers/pci/probe.c | 77

[PATCH 3/3] PCI: Add a informational printk for invalid BARs

mar...@lucina.net Signed-off-by: Myron Stowe myron.st...@redhat.com Cc: Matthew Wilcox wi...@linux.intel.com --- drivers/pci/probe.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 5c13279..2953c1d 100644 --- a/drivers/pci

[PATCH 0/3] PCI: Fix detection of read-only BARs

=1307ef6621991f1c4bc3cec1b5a4ebd6fd3d66b9 pre-git commit 1307ef662199 PCI: probing read-only Bars [2] Pre-git commit 182d090b9dfe Undo due to weird behaviour on various boxes [3] https://bugzilla.kernel.org/show_bug.cgi?id=43331 [4] https://bugzilla.kernel.org/show_bug.cgi?id=85991 Myron

[PATCH] PCI: Remove fixed parameter in pci_iov_resource_bar()

pci_iov_resource_bar() always sets its 'pci_bar_type' parameter to 'pci_bar_unknown'. Drop the parameter and just use 'pci_bar_unknown' directly in the callers. No functional change intended. Signed-off-by: Myron Stowe myron.st...@redhat.com Cc: Chris Wright chr...@sous-sol.org Cc: Yu Zhao yuz

Re: [PATCH] pci, add sysfs numa_node write function

On Thu, 2014-10-16 at 08:32 -0400, Prarit Bhargava wrote: > > On 10/15/2014 05:20 PM, Bjorn Helgaas wrote: > > On Wed, Oct 15, 2014 at 1:47 PM, Prarit Bhargava wrote: > >> On 10/15/2014 03:23 PM, Bjorn Helgaas wrote: > >>> Hi Prarit, > >>> > >>> On Wed, Oct 15, 2014 at 1:05 PM, Prarit Bhargava

Re: [PATCH] pci, add sysfs numa_node write function

On Thu, 2014-10-16 at 08:32 -0400, Prarit Bhargava wrote: On 10/15/2014 05:20 PM, Bjorn Helgaas wrote: On Wed, Oct 15, 2014 at 1:47 PM, Prarit Bhargava pra...@redhat.com wrote: On 10/15/2014 03:23 PM, Bjorn Helgaas wrote: Hi Prarit, On Wed, Oct 15, 2014 at 1:05 PM, Prarit Bhargava

Re: [PATCH] PCI: pciehp: Include the Data Link Layer State Changed bit when clearing the Slot Status register's event bits

On Tue, Jul 1, 2014 at 1:29 PM, Bjorn Helgaas wrote: > On Mon, Jun 30, 2014 at 10:49 AM, Myron Stowe wrote: >> On Tue, Jun 17, 2014 at 3:07 PM, Bjorn Helgaas wrote: >>> On Tue, Jun 17, 2014 at 1:27 PM, Myron Stowe wrote: >>>> During PCIe hot-plug initialization -

Re: [PATCH] PCI: pciehp: Include the Data Link Layer State Changed bit when clearing the Slot Status register's event bits

On Tue, Jul 1, 2014 at 1:29 PM, Bjorn Helgaas bhelg...@google.com wrote: On Mon, Jun 30, 2014 at 10:49 AM, Myron Stowe myron.st...@gmail.com wrote: On Tue, Jun 17, 2014 at 3:07 PM, Bjorn Helgaas bhelg...@google.com wrote: On Tue, Jun 17, 2014 at 1:27 PM, Myron Stowe myron.st...@redhat.com wrote

Re: [PATCH] PCI: pciehp: Include the Data Link Layer State Changed bit when clearing the Slot Status register's event bits

On Tue, Jun 17, 2014 at 3:07 PM, Bjorn Helgaas wrote: > On Tue, Jun 17, 2014 at 1:27 PM, Myron Stowe wrote: >> During PCIe hot-plug initialization - pciehp_probe - data structures >> related to slot capabilities are set up. As part of this set up, ISRs are >> put in place

Re: [PATCH] PCI: pciehp: Include the Data Link Layer State Changed bit when clearing the Slot Status register's event bits

On Tue, Jun 17, 2014 at 3:07 PM, Bjorn Helgaas bhelg...@google.com wrote: On Tue, Jun 17, 2014 at 1:27 PM, Myron Stowe myron.st...@redhat.com wrote: During PCIe hot-plug initialization - pciehp_probe - data structures related to slot capabilities are set up. As part of this set up, ISRs

[PATCH] PCI: pciehp: Include the Data Link Layer State Changed bit when clearing the Slot Status register's event bits

Status bit to the event bits that are cleared out during initialization. Reference: PCI-SIG. PCI Express Base Specification Revision 4.0 Version 0.3 (PCI-SIG, 2014): 7.8.11. Slot Status Register (Offset 1Ah). Signed-off-by: Myron Stowe --- drivers/pci/hotplug/pciehp_hpc.c |2 +- 1 files

[PATCH] PCI: pciehp: Include the Data Link Layer State Changed bit when clearing the Slot Status register's event bits

Status bit to the event bits that are cleared out during initialization. Reference: PCI-SIG. PCI Express Base Specification Revision 4.0 Version 0.3 (PCI-SIG, 2014): 7.8.11. Slot Status Register (Offset 1Ah). Signed-off-by: Myron Stowe myron.st...@redhat.com --- drivers/pci/hotplug/pciehp_hpc.c

Re: [PATCH V3 1/3] x86/PCI: Fix PCI root numa_node info on AMD family15h

On Thu, May 8, 2014 at 9:37 AM, Robert Richter wrote: > On 08.05.14 10:21:07, Suravee Suthikulanit wrote: >> The reason I put it all these comments here is because it took us a while to >> discuss what to do with this file going forward. There were some confusions. >> Therefore, I just want to

Re: [PATCH V3 1/3] x86/PCI: Fix PCI root numa_node info on AMD family15h

On Thu, May 8, 2014 at 9:37 AM, Robert Richter r...@kernel.org wrote: On 08.05.14 10:21:07, Suravee Suthikulanit wrote: The reason I put it all these comments here is because it took us a while to discuss what to do with this file going forward. There were some confusions. Therefore, I just

Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

On Wed, Apr 30, 2014 at 1:00 AM, Robert Richter wrote: > On 29.04.14 15:40:28, Myron Stowe wrote: >> On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov wrote: >> > So sounds to me like we want to get rid of the whole IO ECS deal >> > altogether then. >> > >&

Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

On Wed, Apr 30, 2014 at 1:00 AM, Robert Richter r...@kernel.org wrote: On 29.04.14 15:40:28, Myron Stowe wrote: On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov b...@alien8.de wrote: So sounds to me like we want to get rid of the whole IO ECS deal altogether then. Now, I'm wondering

Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov wrote: > On Tue, Apr 29, 2014 at 10:16:57AM -0500, Suravee Suthikulanit wrote: >> In the new code, the IO ECS was needed to retrieve the >> AMD_NB_F1_MMIO_BASE_LIMIT_HI_REG (offset 0x180) during the early >> initialization as part of (2) logic.

Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

On Tue, Apr 29, 2014 at 1:14 PM, Borislav Petkov b...@alien8.de wrote: On Tue, Apr 29, 2014 at 10:16:57AM -0500, Suravee Suthikulanit wrote: In the new code, the IO ECS was needed to retrieve the AMD_NB_F1_MMIO_BASE_LIMIT_HI_REG (offset 0x180) during the early initialization as part of (2)

Re: [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node'

On Sun, Apr 20, 2014 at 4:54 AM, Borislav Petkov wrote: > On Fri, Apr 18, 2014 at 08:53:46PM -0600, Myron Stowe wrote: >> With the amd_bus.c updates to support additional AMD processors (11h, 12h, >> 14h 15h and 16h) 'quirk_amd_nb_node' seems to be redundant. This p

Re: [PATCH v2 4/5] ACPI/PCI: Warn if we have to "guess" host bridge node information

On Sun, Apr 20, 2014 at 4:21 AM, Borislav Petkov wrote: > On Fri, Apr 18, 2014 at 08:53:39PM -0600, Myron Stowe wrote: >> The vast majority of platforms are not supplying ACPI _PXM (proximity) >> information corresponding to host bridge (PNP0A03/PNP0A08) devices >> resultin

Re: [PATCH v2 3/5] x86/PCI: Miscellaneous code clean up for early_fillup_mp_bus_info

On Sun, Apr 20, 2014 at 2:02 AM, Borislav Petkov wrote: > On Fri, Apr 18, 2014 at 08:53:31PM -0600, Myron Stowe wrote: >> From: Suravee Suthikulpanit >> >> * Refactoring of the early_fill_mp_bus_info function into multiple helper >> functions since it is getting lo

Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

On Sat, Apr 19, 2014 at 7:52 AM, Borislav Petkov wrote: > On Fri, Apr 18, 2014 at 08:53:23PM -0600, Myron Stowe wrote: >> From: Suravee Suthikulpanit >> >> This patch adds supports for additional MMIO ranges (16 ranges). Also, >> each MMIO base/limit can now support

Re: [PATCH v2 1/5] x86/PCI: Add support for generic AMD hostbridges

On Sat, Apr 19, 2014 at 5:31 AM, Borislav Petkov wrote: > On Fri, Apr 18, 2014 at 08:53:16PM -0600, Myron Stowe wrote: >> From: Suravee Suthikulpanit >> >> AMD hostbridges gnenerally show up as PCI device 0:18.0. This patch adds >> logic to automatically probe

Re: [PATCH v2 1/5] x86/PCI: Add support for generic AMD hostbridges

On Sat, Apr 19, 2014 at 5:31 AM, Borislav Petkov b...@suse.de wrote: On Fri, Apr 18, 2014 at 08:53:16PM -0600, Myron Stowe wrote: From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com AMD hostbridges gnenerally show up as PCI device 0:18.0. This patch adds logic to automatically probe

Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

On Sat, Apr 19, 2014 at 7:52 AM, Borislav Petkov b...@alien8.de wrote: On Fri, Apr 18, 2014 at 08:53:23PM -0600, Myron Stowe wrote: From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com This patch adds supports for additional MMIO ranges (16 ranges). Also, each MMIO base/limit can now

Re: [PATCH v2 3/5] x86/PCI: Miscellaneous code clean up for early_fillup_mp_bus_info

On Sun, Apr 20, 2014 at 2:02 AM, Borislav Petkov b...@suse.de wrote: On Fri, Apr 18, 2014 at 08:53:31PM -0600, Myron Stowe wrote: From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com * Refactoring of the early_fill_mp_bus_info function into multiple helper functions since it is getting

Re: [PATCH v2 4/5] ACPI/PCI: Warn if we have to guess host bridge node information

On Sun, Apr 20, 2014 at 4:21 AM, Borislav Petkov b...@suse.de wrote: On Fri, Apr 18, 2014 at 08:53:39PM -0600, Myron Stowe wrote: The vast majority of platforms are not supplying ACPI _PXM (proximity) information corresponding to host bridge (PNP0A03/PNP0A08) devices resulting in sysfs

Re: [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node'

On Sun, Apr 20, 2014 at 4:54 AM, Borislav Petkov b...@suse.de wrote: On Fri, Apr 18, 2014 at 08:53:46PM -0600, Myron Stowe wrote: With the amd_bus.c updates to support additional AMD processors (11h, 12h, 14h 15h and 16h) 'quirk_amd_nb_node' seems to be redundant. This patch removes

Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

On Sun, Apr 20, 2014 at 1:59 AM, Borislav Petkov wrote: > Drop Andreas' old email address from CC as it keeps bouncing. > > On Sat, Apr 19, 2014 at 03:52:20PM +0200, Borislav Petkov wrote: >> > -static void __init pci_enable_pci_io_ecs(void) >> > +static void __init pci_enable_pci_io_ecs(u8 bus,

Re: [PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

On Sun, Apr 20, 2014 at 1:59 AM, Borislav Petkov b...@suse.de wrote: Drop Andreas' old email address from CC as it keeps bouncing. On Sat, Apr 19, 2014 at 03:52:20PM +0200, Borislav Petkov wrote: -static void __init pci_enable_pci_io_ecs(void) +static void __init pci_enable_pci_io_ecs(u8

Re: [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node'

On Sun, Apr 20, 2014 at 4:54 AM, Borislav Petkov wrote: > On Fri, Apr 18, 2014 at 08:53:46PM -0600, Myron Stowe wrote: >> With the amd_bus.c updates to support additional AMD processors (11h, 12h, >> 14h 15h and 16h) 'quirk_amd_nb_node' seems to be redundant. This p

Re: [PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node'

On Sun, Apr 20, 2014 at 4:54 AM, Borislav Petkov b...@suse.de wrote: On Fri, Apr 18, 2014 at 08:53:46PM -0600, Myron Stowe wrote: With the amd_bus.c updates to support additional AMD processors (11h, 12h, 14h 15h and 16h) 'quirk_amd_nb_node' seems to be redundant. This patch removes

[PATCH v2 1/5] x86/PCI: Add support for generic AMD hostbridges

8F1x[EC:E0] Configuration Map, 42301 Rev 3.12 - October 11, 2012. Signed-off-by: Suravee Suthikulpanit Signed-off-by: Myron Stowe Tested-by: Aravind Gopalakrishnan --- arch/x86/pci/amd_bus.c | 71 1 files changed, 47 insertions(+), 24 deletion

[PATCH v2 5/5] PCI: Remove redundant 'quirk_amd_nb_node'

With the amd_bus.c updates to support additional AMD processors (11h, 12h, 14h 15h and 16h) 'quirk_amd_nb_node' seems to be redundant. This patch removes it. Signed-off-by: Myron Stowe --- arch/x86/kernel/quirks.c | 58 -- 1 files changed, 0

[PATCH v2 4/5] ACPI/PCI: Warn if we have to "guess" host bridge node information

m amd_bus.c, there's no reason to believe they will be compatible. This patch warns when this situation occurs: pci_root PNP0A08:00: [Firmware Bug]: No _PXM; guessing node number 0 [1] https://bugzilla.kernel.org/show_bug.cgi?id=72051 Signed-off-by: Myron Stowe --- arch/x86/pci/acpi.c |

[PATCH v2 3/5] x86/PCI: Miscellaneous code clean up for early_fillup_mp_bus_info

unctional changes. Signed-off-by: Suravee Suthikulpanit Signed-off-by: Myron Stowe Tested-by: Aravind Gopalakrishnan --- arch/x86/pci/amd_bus.c | 284 ++-- 1 files changed, 152 insertions(+), 132 deletions(-) diff --git a/arch/x86/pci/amd_bus.c b/arch/x

[PATCH v2 2/5] x86/PCI: Support additional MMIO range capabilities

8F1x[DC,D4,CC,C4] IO-Space Limit, 42301 Rev 3.12 - October 11, 2012. Signed-off-by: Suravee Suthikulpanit Signed-off-by: Myron Stowe Tested-by: Aravind Gopalakrishnan --- arch/x86/pci/amd_bus.c | 126 +++- 1 files changed, 103 insertions(+), 23

[PATCH v2 0/5] x86/PCI: Add AMD hostbridge support for newer AMD systems

we "guess" a hostbridge's node value (patch 4), o I believe with the additional Family support that 'quirk_amd_nb_node' is now redundant so I added patch 5 which removes it. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=72051 Myron Stowe (2): P

[PATCH v2 0/5] x86/PCI: Add AMD hostbridge support for newer AMD systems

a hostbridge's node value (patch 4), o I believe with the additional Family support that 'quirk_amd_nb_node' is now redundant so I added patch 5 which removes it. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=72051 Myron Stowe (2): PCI: Remove redundant

  1   2   3   >