align parameter]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c |8 +++-
include/linux/pci.h |1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index
-off-by: Bjorn Helgaas bhelg...@google.com
---
arch/powerpc/include/asm/machdep.h|1 +
arch/powerpc/kernel/pci-common.c | 10 ++
arch/powerpc/platforms/powernv/pci-ioda.c | 20
3 files changed, 31 insertions(+)
diff --git a/arch/powerpc/include
internally, rename to virtfn_max_buses()
* fix typos formatting
* expand documentation
Bjorn
---
Bjorn Helgaas (2):
PCI: Print more info in sriov_enable() error message
PCI: Index IOV resources in the conventional style
Gavin Shan (1):
powerpc/pci: Refactor pci_dn
Wei Yang
instance) is populated during early fixup time.
[bhelgaas: add ifdef around add_one_dev_pci_info(), use dev_printk()]
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
arch/powerpc/include/asm/device.h |3
arch/powerpc/include/asm/pci
out.
If the pci_dev is a VF, skip the resource unset process.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
arch/powerpc/kernel/pci-common.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/pci-common.c b/arch
From: Wei Yang weiy...@linux.vnet.ibm.com
In struct pci_dn, the pcidev field is assigned but not used, so remove it.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
Acked-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm
weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
.../powerpc/pci_iov_resource_on_powernv.txt| 305
1 file changed, 305 insertions(+)
create mode 100644 Documentation/powerpc/pci_iov_resource_on_powernv.txt
diff --git a/Documentation
...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
arch/powerpc/include/asm/pci-bridge.h |2
arch/powerpc/platforms/powernv/pci-ioda.c | 197 +++--
2 files changed, 154 insertions(+), 45 deletions(-)
diff --git a/arch/powerpc/include/asm/pci-bridge.h
b/arch
for VFs of this device.
[bhelgaas: changelog, compute busnr of NumVFs, not TotalVFs, remove
kerenl-doc comment marker]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c | 31 +++
drivers/pci/pci.h
() and
pci_iov_virtfn_devfn() and export them.
[bhelgaas: changelog, make busnr int]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c | 28
include/linux/pci.h | 11 +++
2 files changed
-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 5643a1011e23..cc6fedf4a1b9 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -220,6 +220,11 @@ static void
-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index c4c33ead03bc..05f9d97e4175 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -372,6 +372,8 @@ found:
goto
If we don't have space for all the bus numbers required to enable VFs,
print the largest bus number required and the range available.
No functional change; improved error message only.
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c |7 +--
1 file changed, 5
[]
conventionally]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
arch/powerpc/include/asm/machdep.h|4 ++
arch/powerpc/include/asm/pci-bridge.h |3 ++
arch/powerpc/kernel/pci-common.c |5 +++
arch/powerpc/platforms
-by: Bjorn Helgaas bhelg...@google.com
---
arch/powerpc/platforms/powernv/eeh-powernv.c | 14 +
arch/powerpc/platforms/powernv/pci.c | 69 ++
arch/powerpc/platforms/powernv/pci.h |4 +-
3 files changed, 40 insertions(+), 47 deletions(-)
diff --git
From: Wei Yang weiy...@linux.vnet.ibm.com
Current iommu_table of a PE is a static field. This will have a problem
when iommu_free_table() is called.
Allocate iommu_table dynamically.
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
arch
On Tue, Feb 24, 2015 at 02:34:35AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
Current iommu_table of a PE is a static field. This will have a problem
when iommu_free_table() is called.
Allocate iommu_table dynamically.
I'd like a little more explanation about
On Tue, Feb 24, 2015 at 02:33:52AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
VFs are dynamically created when a driver enables them. On some platforms,
like PowerNV, special resources are necessary to enable VFs.
Add platform hooks for enabling and disabling
On Tue, Feb 24, 2015 at 02:34:06AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
When sizing and assigning resources, we divide the resources into two
lists: the requested list and the additional list. We don't consider the
alignment of additional VF(n) BAR space
On Tue, Feb 24, 2015 at 02:34:13AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
If we're going to reassign resources with flag PCI_REASSIGN_ALL_RSRC, all
resources will be cleaned out during device header fixup time and then get
reassigned by PCI core. However
On Tue, Feb 24, 2015 at 02:34:57AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
On PowerNV platform, resource position in M64 implies the PE# the resource
belongs to. In some cases, adjustment of a resource is necessary to locate
it to a correct position in M64
On Tue, Feb 24, 2015 at 02:35:04AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this
will exceed the limitation and failed to be assigned.
Introduce a different mechanism based on the IOV BAR size
...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c | 39 ---
drivers/pci/pci.h |1 +
include/linux/pci.h |3 +++
3 files changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/pci/iov.c b/drivers/pci
Most of PCI uses res = dev-resource[i], not res = dev-resource + i.
Use that style in iov.c also.
No functional change.
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
drivers/pci/iov.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/iov.c b
according to an offset.
[bhelgaas: rework loops, rework overlap check, index resource[]
conventionally, remove pci_regs.h include, squashed with next patch]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
arch/powerpc/include/asm/pci
- if IOV BAR size is bigger than 64MB, roundup power2
[bhelgaas: make dev_printk() output more consistent, use PCI_SRIOV_NUM_BARS]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
---
arch/powerpc/include/asm/pci-bridge.h |2 ++
arch/powerpc
On Tue, Feb 24, 2015 at 02:34:57AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
On PowerNV platform, resource position in M64 implies the PE# the resource
belongs to. In some cases, adjustment of a resource is necessary to locate
it to a correct position in M64
On Tue, Feb 24, 2015 at 3:00 AM, Bjorn Helgaas bhelg...@google.com wrote:
On Tue, Feb 24, 2015 at 02:34:57AM -0600, Bjorn Helgaas wrote:
From: Wei Yang weiy...@linux.vnet.ibm.com
On PowerNV platform, resource position in M64 implies the PE# the resource
belongs to. In some cases, adjustment
On Thu, Jan 15, 2015 at 10:27:58AM +0800, Wei Yang wrote:
From: Gavin Shan gws...@linux.vnet.ibm.com
pci_dn is the extension of PCI device node and it's created from
device node. Unfortunately, VFs that are enabled dynamically by
PF's driver and they don't have corresponding device nodes,
On Tue, Feb 10, 2015 at 07:14:45PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2015-02-10 at 14:25 +0800, Wei Yang wrote:
PF's resource will be assigned first, including normal BARs and IOV
BARs.
Then PF's driver will create VFs, in virtfn_add(). In this function,
VF's
resources is
On Thu, Jan 15, 2015 at 10:27:51AM +0800, Wei Yang wrote:
When implementing the SR-IOV on PowerNV platform, some resource reservation
is needed for VFs which don't exist at the bootup stage. To do the match
between resources and VFs, the code need to get the VF's BDF in advance.
In this
On Tue, Feb 10, 2015 at 12:02:31PM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2015-02-04 at 17:44 -0600, Bjorn Helgaas wrote:
diff --git a/Documentation/powerpc/pci_iov_resource_on_powernv.txt
b/Documentation/powerpc/pci_iov_resource_on_powernv.txt
new file mode 100644
index
[+cc linux-mm, linux-kernel]
For context, the start of this discussion was here:
http://lkml.kernel.org/r/1424157203-691-8-git-send-email-gws...@linux.vnet.ibm.com
where Gavin is adding a new PCI hotplug driver for PowerNV. That new
driver calls vm_unmap_aliases() the same way we do in the
On Tue, Feb 17, 2015 at 06:13:23PM +1100, Gavin Shan wrote:
The patch intends to add standalone driver to support PCI hotplug
for PowerPC PowerNV platform, which runs on top of skiboot firmware.
The firmware identified hotpluggable slots and marked their device
tree node with proper
On Thu, Feb 05, 2015 at 12:08:50AM +0800, Wei Yang wrote:
Bjorn, this is an error introduced in the patch PCI: Store individual VF BAR
size in struct pci_sriov.
This patch is based on the pci/virtualization branch. I have tried, it could
merge with the bad one cleanly.
Signed-off-by: Wei
On Thu, Jan 15, 2015 at 10:28:02AM +0800, Wei Yang wrote:
On PHB3, PF IOV BAR will be covered by M64 BAR to have better PE isolation.
Mostly the total_pe number is different from the total_VFs, which will lead
to a conflict between MMIO space and the PE number.
For example, total_VFs is 128
On Thu, Jan 15, 2015 at 10:28:03AM +0800, Wei Yang wrote:
This patch implements the pcibios_iov_resource_alignment() on powernv
platform.
On PowerNV platform, there are 3 cases for the IOV BAR:
1. initial state, the IOV BAR size is multiple times of VF BAR size
2. after expanded, the IOV
On Wed, Feb 04, 2015 at 11:34:09AM +0800, Wei Yang wrote:
On Tue, Feb 03, 2015 at 06:19:26PM -0600, Bjorn Helgaas wrote:
On Tue, Feb 03, 2015 at 03:01:43PM +0800, Wei Yang wrote:
The actual IOV BAR range is determined by the start address and the actual
size for vf_num VFs BAR. After
On Thu, Jan 15, 2015 at 10:28:06AM +0800, Wei Yang wrote:
M64 aperture size is limited on PHB3. When the IOV BAR is too big, this
will exceed the limitation and failed to be assigned.
This patch introduce a different mechanism based on the IOV BAR size:
IOV BAR size is smaller than 64M,
only one.
Bjorn
commit 6f46b79d243c24fd02c662c43aec6c829013ff64
Author: Bjorn Helgaas bhelg...@google.com
Date: Fri Jan 30 11:01:59 2015 -0600
Try to fix references to M64 window vs M64 BARs. If there really is only
one M64 window, I'm still a little confused about why there are so
On Thu, Jan 15, 2015 at 10:27:50AM +0800, Wei Yang wrote:
This patchset enables the SRIOV on POWER8.
The gerneral idea is put each VF into one individual PE and allocate required
resources like MMIO/DMA/MSI. The major difficulty comes from the MMIO
allocation and adjustment for PF's IOV BAR.
On Tue, Feb 3, 2015 at 9:34 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote:
On Tue, Feb 03, 2015 at 06:19:26PM -0600, Bjorn Helgaas wrote:
On Tue, Feb 03, 2015 at 03:01:43PM +0800, Wei Yang wrote:
+vf_num = pdn-vf_pes;
I can't actually build this, but I don't think pdn-vf_pes is defined yet
On Mon, Feb 2, 2015 at 6:25 PM, Michael Ellerman m...@ellerman.id.au wrote:
On Mon, 2015-02-02 at 09:47 -0600, Bjorn Helgaas wrote:
On Sun, Feb 1, 2015 at 8:28 PM, Michael Ellerman m...@ellerman.id.au wrote:
On Sat, 2015-01-31 at 21:47 +0800, Kevin Hao wrote:
So we can avoid the ugly #ifdef
On Tue, Feb 03, 2015 at 09:37:24AM +0800, Kevin Hao wrote:
Add a stub for pci_device_to_OF_node() so drivers don't need to
use #ifdef CONFIG_OF around calls to it.
Signed-off-by: Kevin Hao haoke...@gmail.com
Acked-by: Bjorn Helgaas bhelg...@google.com
Applied to pci/misc for v3.20, thanks
pnv_pci_vf_resource_shift() to shift the 'real' PF IOV BAR address
according to an offset.
[bhelgaas: rework loops, rework overlap check, index resource[]
conventionally, remove pci_regs.h include]
Signed-off-by: Wei Yang weiy...@linux.vnet.ibm.com
Signed-off-by: Bjorn Helgaas
Bjorn,
Do you mind putting this into your next for 3.20? Or giving us an ACK for it
if
you prefer.
I think it makes more sense to merge this along with the other 14
patches that remove the #ifdefs (at least, I assume that's what they
do; I haven't seen them).
Acked-by: Bjorn Helgaas bhelg
On Thu, Jan 15, 2015 at 10:28:04AM +0800, Wei Yang wrote:
On PowrNV platform, resource position in M64 implies the PE# the resource
belongs to. In some particular case, adjustment of a resource is necessary
to locate it to a correct position in M64.
This patch introduces a function to shift
On Fri, Jan 09, 2015 at 08:34:34PM -0600, Rob Herring wrote:
This series adds common accessor functions for PCI configuration space
accesses. This supports most PCI hosts with memory mapped configuration
space like ECAM or hosts with memory mapped address/data registers. ECAM
is not
[+cc Julia]
On Sun, Dec 21, 2014 at 10:14:34PM +0100, Wolfram Sang wrote:
This platform_driver does not need to set an owner, it will be populated by
the
driver core.
Signed-off-by: Wolfram Sang w...@the-dreams.de
I already applied the equivalent patch from Julia for v3.20, thanks!
(I
On Mon, Dec 22, 2014 at 02:05:22PM +0800, Wei Yang wrote:
Bjorn,
This patch set is tested on 3.19-rc1 and with the offset/stride update patch.
I see your comment on the MEM64 issue, so if that is reverted, this
patch set will not work. While I think we can work in parallel, I sent it here
On Thu, Dec 04, 2014 at 04:54:46PM +1100, Gavin Shan wrote:
We might not get some PCI slot information (e.g. power status)
immediately by OPAL API. Instead, opal_pci_poll() need to be called
for the required information.
The patch introduces pnv_pci_poll(), which bases on original
On Thu, Nov 20, 2014 at 03:20:57PM +0800, Wei Yang wrote:
On Wed, Nov 19, 2014 at 04:30:24PM -0700, Bjorn Helgaas wrote:
On Sun, Nov 02, 2014 at 11:41:24PM +0800, Wei Yang wrote:
From: Gavin Shan gws...@linux.vnet.ibm.com
pci_dn is the extension of PCI device node and it's created from
On Wed, Nov 19, 2014 at 05:27:40PM +0800, Wei Yang wrote:
On Tue, Nov 18, 2014 at 09:26:01PM -0700, Bjorn Helgaas wrote:
On Wed, Nov 19, 2014 at 11:21:00AM +0800, Wei Yang wrote:
On Wed, Nov 19, 2014 at 01:15:32PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2014-11-18 at 18:12 -0700, Bjorn
On Sun, Nov 02, 2014 at 11:41:24PM +0800, Wei Yang wrote:
From: Gavin Shan gws...@linux.vnet.ibm.com
pci_dn is the extension of PCI device node and it's created from
device node. Unfortunately, VFs that are enabled dynamically by
PF's driver and they don't have corresponding device nodes,
On Sun, Nov 02, 2014 at 11:41:17PM +0800, Wei Yang wrote:
When implementing the SR-IOV on PowerNV platform, some resource reservation is
needed for VFs which don't exist at the bootup stage. To do the match between
resources and VFs, the code need to get the VF's BDF in advance.
In this
On Tue, Nov 18, 2014 at 4:11 PM, Gavin Shan gws...@linux.vnet.ibm.com wrote:
On Sun, Nov 02, 2014 at 11:41:16PM +0800, Wei Yang wrote:
Hello Bjorn,
Did you have available bandwidth to review it? :-)
I'm working on it right now :)
This patchset enables the SRIOV on POWER8.
The gerneral idea
[+cc Don, Myron]
Hi Wei,
On Sun, Nov 02, 2014 at 11:41:19PM +0800, Wei Yang wrote:
When retrieving VF IOV BAR in virtfn_add(), it will divide the total PF's IOV
BAR size with the totalVF number. This is true for most cases, while may not
be correct on some specific platform.
For example on
On Wed, Nov 19, 2014 at 11:21:00AM +0800, Wei Yang wrote:
On Wed, Nov 19, 2014 at 01:15:32PM +1100, Benjamin Herrenschmidt wrote:
On Tue, 2014-11-18 at 18:12 -0700, Bjorn Helgaas wrote:
Can you help me understand this?
We have previously called sriov_init() on the PF. There, we sized
On Thu, Oct 16, 2014 at 09:55:32AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2014-10-15 at 16:19 -0600, Bjorn Helgaas wrote:
PCI/MSI: Add device flag indicating that 64-bit MSIs don't work
I'd be happy to merge it, but given what I know now, I would wait and merge
it during
On Tue, Nov 11, 2014 at 9:06 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2014-11-12 at 13:23 +1100, Michael Ellerman wrote:
On Tue, 2014-11-11 at 14:12 -0700, Bjorn Helgaas wrote:
On Thu, Oct 16, 2014 at 09:55:32AM +1100, Benjamin Herrenschmidt wrote:
On Wed, 2014-10
On Wed, Oct 15, 2014 at 11:07:12AM +0800, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
This needs slightly more detail. You're using the MSI chip framework
instead of arch MSI
On Wed, Oct 15, 2014 at 11:06:50AM +0800, Yijing Wang wrote:
Commit 0e4ccb1505a9 (PCI: Add x86_msi.msi_mask_irq() and msix_mask_irq())
introduced two __weak arch functions arch_msix_mask_irq() and
arch_msi_mask_irq() to work around a bug when running xen in x86.
These two functions made msi
On Wed, Oct 15, 2014 at 11:06:53AM +0800, Yijing Wang wrote:
Save msi chip in pci_sys_data instead of assign
msi chip to every pci bus in .add_bus().
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/pci/host/pci-tegra.c | 13 +++--
1 files changed, 3 insertions(+),
On Wed, Oct 15, 2014 at 11:06:52AM +0800, Yijing Wang wrote:
Saving msi chip in pci_sys_data can make pci bus and
devices don't need to know msi chip detail, it also
make pci enumeration code be decoupled from msi chip.
In fact, all pci devices under the same pci hostbridge
share same msi
On Wed, Oct 15, 2014 at 11:06:57AM +0800, Yijing Wang wrote:
MSI chip will be saved in pci_sys_data, now we can
clean up pcibios_add_bus() and pcibios_remove_bus()
in arm, and use pci_find_msi_chip() to get msi chip
in core MSI code.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
On Wed, Oct 15, 2014 at 11:06:58AM +0800, Yijing Wang wrote:
Now msi chip is saved in pci_sys_data in arm,
we could clean the bus-msi assignment in
pci core.
Signed-off-by: Yijing Wang wangyij...@huawei.com
CC: Thierry Reding thierry.red...@gmail.com
CC: Thomas Petazzoni
On Wed, Oct 15, 2014 at 11:06:48AM +0800, Yijing Wang wrote:
Now there are a lot of weak arch functions in MSI code.
Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm,
that's a better solution than overriding lots of existing weak arch
functionsin.
This series use
On Wed, Oct 15, 2014 at 3:00 AM, Wei Yang weiy...@linux.vnet.ibm.com wrote:
On Thu, Oct 02, 2014 at 09:59:43AM -0600, Bjorn Helgaas wrote:
...
I haven't seen any more on this series, and I'm assuming you'll post a
rebased series (maybe you're waiting for v3.18-rc1?). I'm just checking to
make
of
maintainership, how do you want to proceed ? I'm happy to merge the
whole lot via powerpc ASAP (since it's all CC'ed stable) if you guys
send me the appropriate acks, otherwise, let me know.
It all looks beautiful to me.
Acked-by: Bjorn Helgaas bhelg...@google.com
If I were merging it, I would
[+cc Victor, Oleg, David, Srikar, Ananth, Russell, linux-arm-kernel,
Ben, Paul, Michael, linuxppc-dev. arm and powerpc define some of
these functions and are at risk for this issue.]
On Wed, Oct 15, 2014 at 11:06 AM, Bjorn Helgaas bhelg...@google.com wrote:
For the following interfaces
On Mon, Oct 13, 2014 at 2:11 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2014-10-08 at 16:28 +1100, Benjamin Herrenschmidt wrote:
Further discussion with the hw teams have revealed that this is still
an issue on newer asics so I think your original patch is correct
On Thu, Oct 02, 2014 at 10:34:12AM +1000, Benjamin Herrenschmidt wrote:
Some devices have broken 64-bit MSI support which only support some
address bits (40 to 48 typically). This doesn't work on some platforms
such as POWER servers, so we need a quirk.
Currently we keep a flag in a
On Thu, Oct 02, 2014 at 10:34:22AM +1000, Benjamin Herrenschmidt wrote:
A number of radeon cards have a HW limitation causing them to be
unable to generate the full 64-bit of address bits for MSIs. This
breaks MSIs on some platforms such as POWER machines.
We used to have a powerpc
On Wed, Aug 20, 2014 at 11:35:46AM +0800, Wei Yang wrote:
On Tue, Aug 19, 2014 at 10:12:27PM -0500, Bjorn Helgaas wrote:
On Tue, Aug 19, 2014 at 9:34 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote:
On Tue, Aug 19, 2014 at 03:19:42PM -0600, Bjorn Helgaas wrote:
On Thu, Jul 24, 2014 at 02:22
On Thu, Oct 2, 2014 at 3:02 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2014-10-02 at 09:34 -0600, Bjorn Helgaas wrote:
On Thu, Oct 02, 2014 at 10:34:22AM +1000, Benjamin Herrenschmidt wrote:
A number of radeon cards have a HW limitation causing them to be
unable
On Thu, Oct 2, 2014 at 3:01 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2014-10-02 at 09:31 -0600, Bjorn Helgaas wrote:
So this moves the flag to struct pci_dev instead and adjusts the
corresponding arch/powerpc code to look for it there. At this point
On Wed, Oct 01, 2014 at 12:09:23PM +1000, Benjamin Herrenschmidt wrote:
Some devices have broken 64-bit MSI support which only support some
address bits (40 to 48 typically). This doesn't work on some platforms
such as POWER servers, so we need a quirk.
Currently we keep a flag in a
arch_msi_check_device() and is no longer needed.
[bhelgaas: changelog, split to separate patch]
Signed-off-by: Alexander Gordeev agord...@redhat.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index aff384aea639..a0b623d97ad8
On Sun, Sep 07, 2014 at 08:57:52PM +0200, Alexander Gordeev wrote:
Hello,
This is a cleanup effort to get rid of arch_msi_check_device() function.
I am sending v2 series, since kbuild for v1 reports compile errors on
ppc4xx and Armada 370. Still, I have not checked the fixes on these
On Fri, Sep 05, 2014 at 06:09:45PM +0800, Yijing Wang wrote:
This series is based Bjorn's pci-next branch + Alexander Gordeev's two patches
Remove arch_msi_check_device() link: https://lkml.org/lkml/2014/7/12/41
Currently, there are a lot of weak arch functions in MSI code.
Thierry Reding
On Wed, Aug 20, 2014 at 12:14 AM, Wei Yang weiy...@linux.vnet.ibm.com wrote:
On Tue, Aug 19, 2014 at 09:08:41PM -0600, Bjorn Helgaas wrote:
On Thu, Jul 24, 2014 at 02:22:14PM +0800, Wei Yang wrote:
At resource sizing/assigning stage, resources are divided into two lists,
requested list
On Sat, Jul 12, 2014 at 01:21:06PM +0200, Alexander Gordeev wrote:
Hello,
This is a cleanup effort to get rid of useless arch_msi_check_device().
I am not sure what were the reasons for its existence in the first place,
but at the moment it appears totally unnecessary.
Thanks!
Cc:
On Fri, Sep 5, 2014 at 3:25 PM, Bjorn Helgaas bhelg...@google.com wrote:
On Sat, Jul 12, 2014 at 01:21:06PM +0200, Alexander Gordeev wrote:
Hello,
This is a cleanup effort to get rid of useless arch_msi_check_device().
I am not sure what were the reasons for its existence in the first place
Signed-off-by: Anton Blanchard an...@samba.org
Signed-off-by: Bjorn Helgaas bhelg...@google.com
Acked-by: Milton Miller milt...@us.ibm.com
CC: sta...@vger.kernel.org
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 80c2d014283d..e73960311fb4 100644
--- a/drivers/pci/quirks.c
On Thu, Jul 24, 2014 at 02:22:10PM +0800, Wei Yang wrote:
This patch set enables the SRIOV on POWER8.
The gerneral idea is put each VF into one individual PE and allocate required
resources like DMA/MSI.
One thing special for VF PE is we use M64BT to cover the IOV BAR. M64BT is one
On Thu, Jul 24, 2014 at 02:22:11PM +0800, Wei Yang wrote:
When implementing the SR-IOV on PowerNV platform, some resource reservation is
needed for VFs which don't exist at the bootup stage. To do the match between
resources and VFs, the code need to get the VF's BDF in advance.
Ben started
On Thu, Jul 24, 2014 at 02:22:12PM +0800, Wei Yang wrote:
Current implementation calculates VF BAR size from dividing the total size of
IOV BAR by total VF number. It won't work on PowerNV platform because we're
going to expand IOV BAR size for finely alignment.
The patch enforces getting
On Thu, Jul 24, 2014 at 02:22:14PM +0800, Wei Yang wrote:
At resource sizing/assigning stage, resources are divided into two lists,
requested list and additional list, while the alignement of the additional
IOV BAR is not taken into the sizeing and assigning procedure.
This is reasonable in
On Tue, Aug 19, 2014 at 9:34 PM, Wei Yang weiy...@linux.vnet.ibm.com wrote:
On Tue, Aug 19, 2014 at 03:19:42PM -0600, Bjorn Helgaas wrote:
On Thu, Jul 24, 2014 at 02:22:10PM +0800, Wei Yang wrote:
This patch set enables the SRIOV on POWER8.
The gerneral idea is put each VF into one individual
On Sat, Jul 12, 2014 at 01:21:08PM +0200, Alexander Gordeev wrote:
There are no archs that override arch_msi_check_device()
hook. Remove it as it is completely redundant.
If an arch would need to check MSI/MSI-X possibility for a
device it should make it within arch_setup_msi_irqs() hook.
On Thu, Jul 10, 2014 at 4:11 AM, Alexander Gordeev agord...@redhat.com wrote:
On Wed, Jul 09, 2014 at 10:06:48AM -0600, Bjorn Helgaas wrote:
Out of curiosity, do you have a pointer to this? It looks like it
I.e. ICH8 chapter 12.1.30 or ICH10 chapter 14.1.27
uses one vector per port, and I'm
On Tue, Jul 8, 2014 at 6:26 AM, Alexander Gordeev agord...@redhat.com wrote:
On Mon, Jul 07, 2014 at 01:40:48PM -0600, Bjorn Helgaas wrote:
Can you quantify the benefit of this? Can't a device already use
MSI-X to request exactly the number of vectors it can use? (I know
A Intel AHCI
On Fri, Jul 4, 2014 at 2:58 AM, Alexander Gordeev agord...@redhat.com wrote:
On Thu, Jul 03, 2014 at 09:20:52AM +, David Laight wrote:
From: Bjorn Helgaas
On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
There are PCI devices that require a particular value written
On Fri, Jul 4, 2014 at 2:57 AM, Alexander Gordeev agord...@redhat.com wrote:
On Wed, Jul 02, 2014 at 02:22:01PM -0600, Bjorn Helgaas wrote:
On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
There are PCI devices that require a particular value written
to the Multiple Message
On Thu, Jun 19, 2014 at 05:22:44PM +1000, Gavin Shan wrote:
Commit d92a208d086 (powerpc/pci: Mask linkDown on resetting PCI bus)
implemented same logic (resetting PCI secondary bus by bridge's config
register PCI_BRIDGE_CTL_BUS_RESET) in PCI core and arch-dependent
code. In order to avoid the
On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
There are PCI devices that require a particular value written
to the Multiple Message Enable (MME) register while aligned on
power of 2 boundary value of actually used MSI vectors 'nvec'
is a lesser of that MME value:
On Sun, May 04, 2014 at 12:23:35PM +0800, Yijing Wang wrote:
v1-v2: Add comments for new pci_is_bridge().
This patchset rename the current pci_is_bridge() to pci_has_subordinate(),
and introduce a new pci_is_bridge() which determine pci bridge by check
dev-hdr_type. The new one is more
On Fri, Apr 25, 2014 at 3:18 AM, Yijing Wang wangyij...@huawei.com wrote:
This patchset rename the current pci_is_bridge() to pci_has_subordinate(),
and introduce a new pci_is_bridge() which determine pci bridge by check
dev-hdr_type. The new one is more accurate. PCIe Spec define the pci
On Mon, Apr 14, 2014 at 03:28:35PM +0200, Alexander Gordeev wrote:
There are no users of pci_enable_msi_block() function have
left. Obsolete it in favor of pci_enable_msi_range() and
pci_enable_msi_exact() functions.
I mistakenly assumed this would have to wait because I thought there were
On Thu, Apr 10, 2014 at 12:51 AM, Mike Qiu qiud...@linux.vnet.ibm.com wrote:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc0041d78
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c0041d78]
601 - 700 of 857 matches
Mail list logo
