headers
Ram Pai | 1 Feb 07:21
Picon
Favicon

Re: [BUGFIX][PATCH] pci: check for 4k resource_size alignment in sriov_init

On Tue, Jan 31, 2012 at 11:14:02PM +0530, Vaidyanathan Srinivasan wrote:
> * Ram Pai <linuxram <at> us.ibm.com> [2012-01-30 11:18:45]:
> 
> > On Sat, Jan 28, 2012 at 12:40:32AM +0530, Vaidyanathan Srinivasan wrote:
> > > Hi Ram and Jesse,
> > > 
> > > I found a trivial issue with page size alignment check on IBM POWER
> > > box with 64k base page size.  In sriov_init(), changing the check from
> > > PAGE_SIZE (arch and config dependent) to HW_PAGE_SIZE (always 4k) was
> > > required to use one of the sriov adapter as PF since the
> > > resource_size() comes up as 0x8000 and PAGE_SIZE would be 0x10000 for
> > > pseries boxes.
> > > 
> > > I think resource_size() could be less than SystemPageSize, but I would
> > > like your comments/ack/nack on any consequences of checking for only
> > > 4k alignment here in a system with larger base page size.
> > 
> > As per the SRIOV specs, the  resource has to be System page size aligned.
> > 
> > PFs are required to support 4-KB, 8-KB, 64-KB, 256-KB, 1-MB, and 4-MB
> > page sizes. In your case if your adapter's PF is not supporting 64K page size
> > then I think it is not conforming to the PCI SRIOV spec.
> 
> Hi Ram,
> 
> Thanks for the pointer.  I did some more experiments and found that
> the card does support 64k page size, but the PCI_SRIOV_SYS_PGSIZE was
> set to default 4k when we do the query and check resource_size().
> 
> You were correct, the resource_size() has to come up with 64k on 64k
(Continue reading)

Permalink | Reply | 3 comments |
headers
Vaidyanathan Srinivasan | 1 Feb 14:02
Picon

Re: [BUGFIX][PATCH] pci: check for 4k resource_size alignment in sriov_init

* Ram Pai <linuxram <at> us.ibm.com> [2012-02-01 14:21:45]:

> On Tue, Jan 31, 2012 at 11:14:02PM +0530, Vaidyanathan Srinivasan wrote:
> > * Ram Pai <linuxram <at> us.ibm.com> [2012-01-30 11:18:45]:
> > 
> > > On Sat, Jan 28, 2012 at 12:40:32AM +0530, Vaidyanathan Srinivasan wrote:
> > > > Hi Ram and Jesse,
> > > > 
> > > > I found a trivial issue with page size alignment check on IBM POWER
> > > > box with 64k base page size.  In sriov_init(), changing the check from
> > > > PAGE_SIZE (arch and config dependent) to HW_PAGE_SIZE (always 4k) was
> > > > required to use one of the sriov adapter as PF since the
> > > > resource_size() comes up as 0x8000 and PAGE_SIZE would be 0x10000 for
> > > > pseries boxes.
> > > > 
> > > > I think resource_size() could be less than SystemPageSize, but I would
> > > > like your comments/ack/nack on any consequences of checking for only
> > > > 4k alignment here in a system with larger base page size.
> > > 
> > > As per the SRIOV specs, the  resource has to be System page size aligned.
> > > 
> > > PFs are required to support 4-KB, 8-KB, 64-KB, 256-KB, 1-MB, and 4-MB
> > > page sizes. In your case if your adapter's PF is not supporting 64K page size
> > > then I think it is not conforming to the PCI SRIOV spec.
> > 
> > Hi Ram,
> > 
> > Thanks for the pointer.  I did some more experiments and found that
> > the card does support 64k page size, but the PCI_SRIOV_SYS_PGSIZE was
> > set to default 4k when we do the query and check resource_size().
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jiri Kosina | 1 Feb 14:15
Picon

Re: [PATCH 2/5] Dynamic ID addition doesn't need get_driver()

On Tue, 24 Jan 2012, Alan Stern wrote:

> As part of the removal of get_driver()/put_driver(), this patch
> (as1511) changes all the places that add dynamic IDs for drivers.
> Since these additions are done by writing to the drivers' sysfs
> attribute files, and the attributes are removed when the drivers are
> unregistered, there is no reason to take an extra reference to the
> drivers.
> 
> The one exception is the pci-stub driver, which calls pci_add_dynid()
> as part of its registration.  But again, there's no reason to take an
> extra reference here, because the driver can't be unloaded while it is
> being registered.
> 
> Signed-off-by: Alan Stern <stern <at> rowland.harvard.edu>
> CC: Dmitry Torokhov <dmitry.torokhov <at> gmail.com>
> CC: Jiri Kosina <jkosina <at> suse.cz>
> CC: Jesse Barnes <jbarnes <at> virtuousgeek.org>
> CC: Dominik Brodowski <linux <at> dominikbrodowski.net>

Acked-by: Jiri Kosina <jkosina <at> suse.cz>

for the drivers/hid part. Thanks,

--

-- 
Jiri Kosina
SUSE Labs
Permalink | Reply | 0 comments |
headers
Yinghai Lu | 1 Feb 23:42
Favicon

[PATCH 7/7] PCI: only enable pci realloc when SRIOV bar is not assigned

If bios does not assign those BAR or wrong address, then kernel will
try to do pci realloc.

in that case, user still can use pci=realloc=off to override it.

Signed-off-by: Yinghai Lu <yinghai <at> kernel.org>
---
 drivers/pci/setup-bus.c |   28 ++++++++++++++++++++++++++++
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 9526038..520f256 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1293,6 +1293,31 @@ static bool __init pci_realloc_enabled(void)
 	return pci_realloc_enable >= enable_yes_user;
 }

+static void __init pci_realloc_detect(void)
+{
+	struct pci_dev *dev = NULL;
+
+	if (pci_realloc_enable != enable_not_set)
+		return;
+
+#ifdef CONFIG_PCI_IOV
+	for_each_pci_dev(dev) {
+		int i;
+
+		for (i = PCI_IOV_RESOURCES; i <= PCI_IOV_RESOURCE_END; i++) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yinghai Lu | 1 Feb 23:42
Favicon

[PATCH 3/7] PCI: Skip reset cardbus assigned resource during pci bus rescan

otherwise when rescan is used for cardbus, assigned resource will get
cleared.

Signed-off-by: Yinghai Lu <yinghai <at> kernel.org>
---
 drivers/pci/setup-bus.c |   14 ++++++++++++++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 3b3932a..2991a89 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -901,6 +901,8 @@ static void pci_bus_size_cardbus(struct pci_bus *bus,
 	resource_size_t b_res_3_size = pci_cardbus_mem_size * 2;
 	u16 ctrl;

+	if (b_res[0].parent)
+		goto handle_b_res_1;
 	/*
 	 * Reserve some resources for CardBus.  We reserve
 	 * a fixed amount of bus space for CardBus bridges.
@@ -914,6 +916,9 @@ static void pci_bus_size_cardbus(struct pci_bus *bus,
 				pci_cardbus_io_size);
 	}

+handle_b_res_1:
+	if (b_res[1].parent)
+		goto handle_b_res_2;
 	b_res[1].start = pci_cardbus_io_size;
 	b_res[1].end = b_res[1].start + pci_cardbus_io_size - 1;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yinghai Lu | 1 Feb 23:43
Favicon

[PATCH 09/15] PCI: Add pci_bus_extend/shrink_top()

extend or shrink bus and parent buses top (subordinate)

extended range is verified safe range, and stop at recorded parent_res.

Signed-off-by: Yinghai Lu <yinghai <at> kernel.org>
---
 drivers/pci/probe.c |   46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 46 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 79de0dd..91fdaec 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -624,6 +624,52 @@ static void pci_fixup_parent_subordinate_busnr(struct pci_bus *child, int max)
 	}
 }

+static void __devinit pci_bus_extend_top(struct pci_bus *parent,
+		 resource_size_t size, struct resource *parent_res)
+{
+	struct resource *res;
+
+	if (!size)
+		return;
+
+	while (parent) {
+		res = &parent->busn_res;
+		if (res == parent_res)
+			break;
+		res->end += size;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kenji Kaneshige | 2 Feb 11:00
Favicon

Re: [PATCH -v2 0/7] PCI: pcie hotplug related patch

Yinghai, Jesse,

I tested pciehp with your set of patches. I have some comments below.

(1) I got a following warning message on compiling the patch [5/7].

     drivers/pci/hotplug/pciehp_hpc.c:281: warning: 'pcie_wait_link_not_active' defined but not used

(2) I got following warning messages on compiling the patch [6/7]

     drivers/pci/hotplug/pciehp_hpc.c:381: warning: 'pciehp_link_enable' defined but not used
     drivers/pci/hotplug/pciehp_hpc.c:386: warning: 'pciehp_link_disable' defined but not used

(3) I've asked Naoki Yanagimoto, who reported that configuration read
     on some hot-added PCIe device returns invalid value, to test the
     patch. Unfortunately, the problem happens with your patch. But
     after some discussion and testing, it turned out that problem doesn't
     happen when the same card with updated bios is used. So it seems the
     problem is in PCIe card side.

As a result, problems I found are (1) and (2). Please fix those.
Other than that, pciehp seems to work well.

Tested-by: Kenji Kaneshige <kaneshige.kenji <at> jp.fujitsu.com>

Regards,
Kenji Kaneshige

(2012/01/28 3:55), Yinghai Lu wrote:
> 75e4615: pciehp: Disable/enable link during slot power off/on
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michal Simek | 2 Feb 11:50
Picon

Re: [RFC PATCH v1 10/18] microblaze/PCI: get rid of device resource fixups

Hi,

Bjorn Helgaas wrote:
> Tell the PCI core about host bridge address translation so it can take
> care of bus-to-resource conversion for us.
> 
> N.B. We might need to tweak the I/O range and offset to account for the
> 32-bit mask previously used in pcibios_resource_to_bus().  I don't
> know the details of this mapping.  If anybody can help me test and
> fix this, please let me know.
> 
> CC: Michal Simek <monstr <at> monstr.eu>
> ---
>  arch/microblaze/include/asm/pci.h |    8 +---
>  arch/microblaze/pci/pci-common.c  |   69 ++-----------------------------------
>  2 files changed, 4 insertions(+), 73 deletions(-)
> 
> diff --git a/arch/microblaze/include/asm/pci.h b/arch/microblaze/include/asm/pci.h
> index 0331376..8db01f7 100644
> --- a/arch/microblaze/include/asm/pci.h
> +++ b/arch/microblaze/include/asm/pci.h
> @@ -94,13 +94,7 @@ extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
>   */
>  #define PCI_DMA_BUS_IS_PHYS     (1)
>  
> -extern void pcibios_resource_to_bus(struct pci_dev *dev,
> -			struct pci_bus_region *region,
> -			struct resource *res);
> -
> -extern void pcibios_bus_to_resource(struct pci_dev *dev,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fischer, Anna | 2 Feb 12:05
Picon
Favicon

PCI MSI-X vectors in /proc/interrupts

I'm developing a kernel device driver which is using 2 PCI MSI-X vectors. 

When the device comes up and I call pci_enable_msix() the kernel prints 

"[snip] irq 45 for MSI/MSI-X"
"[snip] irq 46 for MSI/MSI-X"

So it seems as if IRQs 45 and 46 are allocated for my device. However, when I look into /proc/interrupts, it
lists my device under IRQ 42 and 43. Is it expected that those IRQ numbers match, e.g. something is broken in
my device driver or kernel code? I use Linux 3.2.0-rc7.

Thanks for your help.

Anna
Permalink | Reply | 0 comments |
headers
MUNEDA Takahiro | 2 Feb 17:09
Favicon

[PATCH v5] Add pcie_hp=nomsi to disable MSI/MSI-X for pciehp driver

Not to use MSI/MSI-X for pciehp, add a kernel parameter, pcie_hp=nomsi.

In my environment, while shutting down, following stack trace is shown
sometimes.

  irq 16: nobody cared (try booting with the "irqpoll" option)
  Pid: 1081, comm: reboot Not tainted 3.2.0 #1
  Call Trace:
   <IRQ>  [<ffffffff810cec1d>] __report_bad_irq+0x3d/0xe0
   [<ffffffff810cee1c>] note_interrupt+0x15c/0x210
   [<ffffffff810cc485>] handle_irq_event_percpu+0xb5/0x210
   [<ffffffff810cc621>] handle_irq_event+0x41/0x70
   [<ffffffff810cf675>] handle_fasteoi_irq+0x55/0xc0
   [<ffffffff81015356>] handle_irq+0x46/0xb0
   [<ffffffff814fbe9d>] do_IRQ+0x5d/0xe0
   [<ffffffff814f146e>] common_interrupt+0x6e/0x6e
   [<ffffffff8106b040>] ? __do_softirq+0x60/0x210
   [<ffffffff8108aeb1>] ? hrtimer_interrupt+0x151/0x240
   [<ffffffff814fb5ec>] call_softirq+0x1c/0x30
   [<ffffffff810152d5>] do_softirq+0x65/0xa0
   [<ffffffff8106ae9d>] irq_exit+0xbd/0xe0
   [<ffffffff814fbf8e>] smp_apic_timer_interrupt+0x6e/0x99
   [<ffffffff814f9e5e>] apic_timer_interrupt+0x6e/0x80
   <EOI>  [<ffffffff814f0fb1>] ? _raw_spin_unlock_irqrestore+0x11/0x20
   [<ffffffff812629fc>] pci_bus_write_config_word+0x6c/0x80
   [<ffffffff81266fc2>] pci_intx+0x52/0xa0
   [<ffffffff8127de3d>] pci_intx_for_msi+0x1d/0x30
  [<ffffffff8127e4fb>] pci_msi_shutdown+0x7b/0x110
   [<ffffffff81269d34>] pci_device_shutdown+0x34/0x50
   [<ffffffff81326c4f>] device_shutdown+0x2f/0x140
(Continue reading)

Permalink | Reply | 5 comments |

Gmane