>> 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 ru
Andrew Morton writes:
> On Fri, 17 Oct 2014 10:08:06 +0530 "Aneesh Kumar K.V"
> 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 hugepage directory.
>>
>> ...
>>
>> --- a/arch/
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 wi
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, accelerat
[...]
> >> +QMan Node
> >> +
> >> +PROPERTIES
> >> +
> >> +- compatible
> >> + Usage: Required
> >> + Value type:
> >> + Definition: Must include "fsl,qman"
> >> + May include "fsl,-qman"
> >> +
> >> +- reg
> >> + Usage: Required
> >> + Value type:
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 depe
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 e
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,
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
are
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
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. We could have inlines
12 matches
Mail list logo