On 2014/10/23 13:18, Bjorn Helgaas wrote:
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
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 22e413c..f11108c 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -35,6 +35,9 @@ int __weak arch_setup_msi_irq(struct pci_dev *dev, struct
msi_desc *desc)
struct msi_chip *chip = dev-bus-msi;
int err;
+if
/*
* Swizzle the device pin each time we cross a bridge. If a platform does
* not provide a swizzle function, we perform the standard PCI swizzling.
@@ -478,8 +464,6 @@ static void pcibios_init_hw(struct device *parent,
struct hw_pci *hw,
sys-swizzle = hw-swizzle;
On 2014/10/23 13:41, Bjorn Helgaas wrote:
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
v1-v2:
Add a patch to make s390 MSI code build happy between patch x86/xen/MSI:
E..
and s390/MSI: Use MSI... Fix several typo problems found by Lucas.
RFC-v1:
Updated [patch 4/21] x86/xen/MSI: Eliminate..., export msi_chip instead
of #ifdef to fix MSI bug in xen running in x86.
Rename
Andrew Morton a...@linux-foundation.org writes:
On Fri, 17 Oct 2014 10:08:06 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the
On Wed, Oct 22, 2014 at 11:02:26AM +0300, Tomi Valkeinen wrote:
On 18/10/14 00:13, Jani Nikula wrote:
Documentation/kbuild/kconfig-language.txt warns to use select with care,
and in general use select only for non-visible symbols and for symbols
with no dependencies, because select will
On Wed, Oct 22, 2014 at 09:04:54PM +0100, Emil Medve wrote:
Hello Mark,
Thanks for having a look at this
On 10/22/2014 09:29 AM, Mark Rutland wrote:
On Wed, Oct 22, 2014 at 03:09:30PM +0100, Emil Medve wrote:
Portals are used by software running on processor cores, accelerators and
[...]
+QMan Node
+
+PROPERTIES
+
+- compatible
+ Usage: Required
+ Value type: stringlist
+ Definition: Must include fsl,qman
+ May include fsl,SoC-qman
+
+- reg
+ Usage: Required
+ Value type: prop-encoded-array
+
On 23/10/14 11:10, Daniel Vetter wrote:
If we want to make BACKLIGHT_CLASS_DEVICE into a library thing then I
guess we could do that, but we must then also drag it out of all the other
meta options to make sure it's always available. No need I think to ditch
BACKLIGHT_CLASS_DEVICE only
Thought I'd comment too on the interrupt question for the block-level (not
portal-level) node;
-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: October-23-14 7:26 AM
To: Medve Emilian-EMMEDVE1
[...]
You also seem to have an interrupt in the example.
Hi,
Leaping in here a little after the fact, to add a bit of background info on the
hardware in case it helps.
-Original Message-
From: Mark Rutland [mailto:mark.rutl...@arm.com]
Sent: October-23-14 7:16 AM
To: Medve Emilian-EMMEDVE1
On Wed, Oct 22, 2014 at 09:04:54PM +0100, Emil
When IOMMU bypass is enabled, a PCI device can read and write memory
that was not mapped by the driver without causing an EEH. That might
cause memory corruption, for example.
When we disable bypass, DMA reads and writes to addresses not mapped by
the IOMMU will cause an EEH, allowing us to debug
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with Johannes Weiner (CC:'d) about this we don't see how it
could be necessary.
If interrupts are disabled during the page table scan (which they
On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with Johannes Weiner (CC:'d) about this we don't see how it
could be necessary.
If
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Fri, 24 Oct 2014 10:40:35 +1100
Another option would be to make the generic code use something defined
by the arch to decide whether to use speculative get or
not. I like the idea of keeping the bulk of that code generic...
Me too.
16 matches
Mail list logo
