Bjorn Helgaas | 17 May 2013 21:48
Picon
Favicon

[PATCH] lspci: Fully decode ASPM support from Link Capabilities

The ASPM Support field in Link Capabilities is two bits, and all four
possible encodings are defined as of PCIe spec r3.0.  Previously, lspci
only decoded values 1, 2, and 3.  This adds 0, so lspci will show "ASPM
not supported" instead of "ASPM unknown".

Signed-off-by: Bjorn Helgaas <bhelgaas <at> google.com>
---
 ls-caps.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/ls-caps.c b/ls-caps.c
index bddb455..752a771 100644
--- a/ls-caps.c
+++ b/ls-caps.c
 <at>  <at>  -728,6 +728,8  <at>  <at>  static char *aspm_support(int code)
 {
   switch (code)
     {
+      case 0:
+        return "not supported";
       case 1:
 	return "L0s";
       case 2:

Bjorn Helgaas | 17 May 2013 19:31
Picon
Favicon

Re: enabling aspm on ati radeon

On Thu, May 16, 2013 at 4:10 PM, Phillip Susi <psusi <at> ubuntu.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/16/2013 12:42 PM, Bjorn Helgaas wrote:
>> Can you collect a complete dmesg log and complete "lspci -vv" output, please?
> ...

Thanks.  The BIOS gave us control over ASPM via _OSC, and you have
these devices where it looks like we should be enabling ASPM, because
it's supported on both ends of the link:

    00:1c.1 bridge to [bus 03] ASPM L0s L1, ASPM disabled
      03:00.0 ASPM L0s L1, ASPM disabled
    00:1c.3 bridge to [bus 05] ASPM L0s L1, ASPM Disabled
      05:00.0 ASPM L0s L1, ASPM Disabled
    00:1c.4 bridge to [bus 06] ASPM L0s L1, ASPM Disabled
      06:00.0 ASPM L0s L1, ASPM Disabled
    00:1c.7 bridge to [bus 09] ASPM L0s L1, ASPM Disabled
      09:00.0 ASPM L0s L1, ASPM Disabled

You also have this bridge where lspci says "ASPM unknown":

    00:01.0 bridge to [bus 01] ASPM unknown

Just out of curiosity, can you collect the output of "lspci -xxxs
00:01.0"?  There are only two bits in the Link Capabilities ASPM
support field, and all four encodings are defined, so I'm curious
about why lspci says "unknown".

(Continue reading)

Yijing Wang | 17 May 2013 11:55
Favicon

[PATCH -v2 0/7] Add hostbridge resource release to support root bus hotplug in IA64

v1->v2: update the patchset description in this cover letter.

Hi Bjorn,
   I update this patchset description, and add some MMIO and dmesg info in order to describe
this problem more clearly. I hope it can make you review this patch easier.

Before applied this patchset, there is a problem when we do root bus hotplug in IA64. Because
we do not release MMIO and ioport resource occupied by root bus.

1. Before hot remove pci root bus

-+-[0000:40]-+-00.0-[0000:41]--
 |           +-01.0-[0000:42]--+-00.0  Intel Corporation 82576 Gigabit Network Connection
 |           |                 \-00.1  Intel Corporation 82576 Gigabit Network Connection
 |           +-03.0-[0000:43]----00.0  LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS
 |           +-04.0-[0000:44]--
 |           +-05.0-[0000:45]--
 |           +-07.0-[0000:46]--+-00.0  Intel Corporation 82576 Gigabit Network Connection
 |           |                 \-00.1  Intel Corporation 82576 Gigabit Network Connection
 |           +-0d.0  Intel Corporation Device 343a
 |           +-0d.1  Intel Corporation Device 343b
 |           +-0d.7  Intel Corporation Device 341b
 [....snip.....]
 |           +-16.3  Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device
 |           \-16.7  Intel Corporation 5520/5500/X58 Chipset QuickData Technology Device
 \-[0000:00]-+-00.0  Intel Corporation 5520/5500/X58 I/O Hub to ESI Port
             +-01.0-[0000:01]--+-00.0  Intel Corporation 82576 Gigabit Network Connection
             |                 \-00.1  Intel Corporation 82576 Gigabit Network Connection
             +-03.0-[0000:02]----00.0  LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS
             +-04.0-[0000:03]--
(Continue reading)

Thomas Petazzoni | 16 May 2013 17:55
Favicon
Gravatar

[PATCHv10 0/9] PCIe support for the Armada 370 and Armada XP SoCs

Hello,

This series of patches introduces PCIe support for the Marvell Armada
370 and Armada XP.

I'd like this code to be merged for 3.11.

For easier testing, the code has been pushed to:

  git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v10

This PATCHv10 follows:
 * PATCHv9, sent on May, 16th 2013
 * PATCHv8, sent on April, 9th 2013
 * PATCHv7, sent on March, 27th 2013
 * PATCHv6, sent on March, 26st 2013
 * PATCHv5, sent on March, 21st 2013
 * PATCHv4, sent on March, 8th 2013
 * PATCHv3, sent on February, 12th 2013
 * PATCHv2, sent on January, 28th 2013
 * RFCv1, sent on December, 7th 2012

Changes between v9 and v10:

 * Mark mvebu_pcie_init() as __init, as reported by Ezequiel
   Garcia. platform_driver_probe() is __init_or_module, so when
   !CONFIG_MODULES is used, platform_driver_probe() belongs to the
   __init section.

 * Mark two other small functions as __init, just because they are
(Continue reading)

Jiang Liu | 16 May 2013 17:50
Picon

[RFC PATCH v2, part3 00/11] Introduce PCI bus lock and state machine

Hi all,
	About one year ago, I started to solve issues triggered by concurrent
PCI device hotplug operations, and several different solutions have been
sent to community for comments. Now we have made important changes to the
solution, so start again with a "v1".

This is the second take to resolve race conditions when hot-plugging PCI
devices/host bridges. Instead of using a globla lock to serialize all hotplug
operations as in previous version, now we introduce a state machine and lock
mechanism for PCI buses to serialize hotplug operations. For discussions
related to previous version, please refer to:
http://comments.gmane.org/gmane.linux.kernel.pci/15007

This patch-set is still in early stages, so sending it out just requesting
for comments. Any comments are welcomed, especially about whether it's the
right/suitable way to solve these race condition issues.

There are multiple methods to trigger PCI hotplug requests/operations
concurrently, such as:
1. Sysfs interfaces exported by the PCI core subsystem
	/sys/devices/pcissss:bb/ssss:bb:dd.f/.../remove
	/sys/devices/pcissss:bb/ssss:bb:dd.f/.../rescan
	/sys/devices/pcissss:bb/ssss:bb:dd.f/.../pci_bus/ssss:bb/rescan
	/sys/bus/pci/rescan
2. Sysfs interfaces exported by the PCI hotplug subsystem
	/sys/bus/pci/slots/xx/power
3. PCI hotplug events triggered by PCI Hotplug Controllers
4. ACPI hotplug events for PCI host bridges
5. Driver binding/unbinding events
	binding/unbinding pci drivers with SR-IOV support
(Continue reading)

Thomas Petazzoni | 15 May 2013 15:25
Favicon
Gravatar

[PATCHv9 0/9] PCIe support for the Armada 370 and Armada XP SoCs

Hello,

This series of patches introduces PCIe support for the Marvell Armada
370 and Armada XP. It has been rebased on top of 3.10-rc1, uses the
latest of/pci code from Andrew Murray, fixes the build failure that
was detected on powerpc64, and a regression that was introduced
between the v7 and the v8 of this patch set. See below for a detailed
changelog.

I'd like this code to be merged for 3.11.

For easier testing, the code has been pushed to:

  git://github.com/MISL-EBU-System-SW/mainline-public.git marvell-pcie-v9

This PATCHv9 follows:
 * PATCHv8, sent on April, 9th 2013
 * PATCHv7, sent on March, 27th 2013
 * PATCHv6, sent on March, 26st 2013
 * PATCHv5, sent on March, 21st 2013
 * PATCHv4, sent on March, 8th 2013
 * PATCHv3, sent on February, 12th 2013
 * PATCHv2, sent on January, 28th 2013
 * RFCv1, sent on December, 7th 2012

Changes between v8 and v9:

 * Rebased on top of 3.10-rc1. Since the PCIe Device Tree informations
   were merged in 3.10-rc1, it allowed to reduce quite significantly
   the size of this patch set.
(Continue reading)

Sarah Sharp | 15 May 2013 07:39
Picon

Re: [OPW kernel] dma_set_coherent_mask

On Wed, May 15, 2013 at 05:41:12AM +0300, Xenia Ragiadakou wrote:
> Hi Sarah, (again)
> 
> Also I noticed that  dma_set_coherent_mask() is not called somewhere,
> which according to DMA-API-HOWTO.txt, means the even if the DMA mask
> is set to 64 bits by dma_set_mask, dma_alloc_coherent and
> dma_pool_alloc wont return 64 bit addresses (32 MSbits wont be
> addressed).

Another good question for Alan, and the USB and PCI list.

(Alan, Ksenia is one of the applicants for the FOSS Outreach Program for
Women that I've been coordinating: http://kernelnewbies.org/OPWIntro)

We do allocate memory using DMA pools, and we do want 64-bit context
addresses if the xHCI host controller can handle it.

The xHCI driver calls dma_set_mask, but not dma_set_coherent_mask():

                temp = xhci_readl(xhci, &xhci->cap_regs->hcc_params);
                if (HCC_64BIT_ADDR(temp)) {
                        xhci_dbg(xhci, "Enabling 64-bit DMA addresses.\n");
                        dma_set_mask(hcd->self.controller, DMA_BIT_MASK(64));
                } else {
                        dma_set_mask(hcd->self.controller, DMA_BIT_MASK(32));
                }

Alan, should it be calling dma_set_coherent_mask()?  I think I may have
noticed the context addresses were never 64-bit addresses, but I didn't
think to look whether the host supported 64-bit addresses.  I just
(Continue reading)

Alexander Duyck | 15 May 2013 03:58
Picon

Re: [PATCH] pci: Avoid reentrant calls to work_on_cpu

On 05/14/2013 05:32 PM, Or Gerlitz wrote:
> On Tue, May 14, 2013 at 6:26 PM, Alexander Duyck
> <alexander.h.duyck <at> intel.com> wrote:
>>
>> This change is meant to fix a deadlock seen when pci_enable_sriov was
>> called from within a driver's probe routine.  The issue was that
>> work_on_cpu calls flush_work which attempts to flush a work queue for a
>> cpu that we are currently working in.  In order to avoid the reentrant
>> path we just skip the call to work_on_cpu in the case that the device
>> node matches our current node.
>>
>> Reported-by: Yinghai Lu <yinghai <at> kernel.org>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck <at> intel.com>
>> ---
>>
>> This patch is meant to address the issue pointed out in an earlier patch
>> sent by Yinghai Lu titled:
>>   [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's
>>
>>  drivers/pci/pci-driver.c |   14 +++++++++-----
>>  1 files changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>> index 79277fb..caeb1c0 100644
>> --- a/drivers/pci/pci-driver.c
>> +++ b/drivers/pci/pci-driver.c
>>  <at>  <at>  -277,12 +277,16  <at>  <at>  static int pci_call_probe(struct pci_driver *drv,
>> struct pci_dev *dev,
>>         int error, node;
>>         struct drv_dev_and_id ddi = { drv, dev, id };
(Continue reading)

Alexander Duyck | 15 May 2013 00:26
Picon
Favicon

[PATCH] pci: Avoid reentrant calls to work_on_cpu

This change is meant to fix a deadlock seen when pci_enable_sriov was
called from within a driver's probe routine.  The issue was that
work_on_cpu calls flush_work which attempts to flush a work queue for a
cpu that we are currently working in.  In order to avoid the reentrant
path we just skip the call to work_on_cpu in the case that the device
node matches our current node.

Reported-by: Yinghai Lu <yinghai <at> kernel.org>
Signed-off-by: Alexander Duyck <alexander.h.duyck <at> intel.com>
---

This patch is meant to address the issue pointed out in an earlier patch
sent by Yinghai Lu titled:
  [PATCH 6/7] PCI: Make sure VF's driver get attached after PF's

 drivers/pci/pci-driver.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 79277fb..caeb1c0 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
 <at>  <at>  -277,12 +277,16  <at>  <at>  static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev,
 	int error, node;
 	struct drv_dev_and_id ddi = { drv, dev, id };

-	/* Execute driver initialization on node where the device's
-	   bus is attached to.  This way the driver likely allocates
-	   its local memory on the right node without any need to
-	   change it. */
(Continue reading)

Jiang Liu | 14 May 2013 18:51
Picon

[RFC PATCH v2, part 2 01/18] PCI: introduce hotplug-safe PCI bus iterators

Introduce hotplug-safe PCI bus iterators as below, which hold a
reference on the returned PCI bus object.
bool pci_bus_exists(int domain, int busnr);
struct pci_bus *pci_get_bus(int domain, int busnr);
struct pci_bus *pci_get_next_bus(struct pci_bus *from);
struct pci_bus *pci_get_next_root_bus(struct pci_bus *from);
#define for_each_pci_bus(b) for (b = NULL; (b = pci_get_next_bus(b)); )
#define for_each_pci_root_bus(b)  \
		for (b = NULL; (b = pci_get_next_root_bus(b)); )

The long-term goal is to remove hotplug-unsafe pci_find_bus(),
pci_find_next_bus() and the global pci_root_buses list.

These new interfaces may be a littler slower than existing interfaces,
but it should be acceptable because they are not used on hot paths.

Signed-off-by: Jiang Liu <jiang.liu <at> huawei.com>
Cc: linux-pci <at> vger.kernel.org
Cc: linux-kernel <at> vger.kernel.org
---
 drivers/pci/pci.h    |   1 +
 drivers/pci/probe.c  |   2 +-
 drivers/pci/search.c | 159 +++++++++++++++++++++++++++++++++++++++++----------
 include/linux/pci.h  |  23 +++++++-
 4 files changed, 153 insertions(+), 32 deletions(-)

diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 68678ed..8fe15f6 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
(Continue reading)

Jimmie Mayfield | 14 May 2013 17:06
Favicon

Seeking advice: Restoring MSI-X after device reset


Hi.  I'm looking for advice on how a device driver should handle 
restoring MSI-X following a device reset.  Here's my situation: we have an 
MSI-X-capable device that for various reasons might be reset by the
device driver.  One of the features of this device is that a reset also
wipes out the MSI-X structure in MMIO address space.  

So this leads to my question:  what is the recommended way for the driver 
to restore MSI-X following such a reset?  

I suppose one (perhaps naive) way would be to do something like this:
   free all IRQs
   pci_disable_msix();
   reset device
   pci_enable_msix()
   request new IRQs

That seems unclean.  Is there a better way?

JM


Gmane