Alastair D'Silva's on March 14, 2019 12:31 pm:
> From: Alastair D'Silva
>
> When building an LTO kernel, the existing code generates warnings:
> ./arch/powerpc/include/asm/paca.h:37:30: warning: register of
> ‘local_paca’ used for multiple global register variables
> register
This adds a flag so that the DAWR can be enabled on P9 via:
echo Y > /sys/kernel/debug/powerpc/dawr_enable_dangerous
The DAWR was previously force disabled on POWER9 in:
9654153158 powerpc: Disable DAWR in the base POWER9 CPU features
Also see Documentation/powerpc/DAWR-POWER9.txt
This is a
On Tue, Mar 26, 2019 at 1:05 AM Joe Lawrence wrote:
>
> CC_FLAGS_FTRACE may contain trailing whitespace that interferes with
> findstring.
>
> For example, commit 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on
> GCC 4.9 and newer") introduced a change such that on my ppc64le box,
>
From: Wen Yang
The call to of_find_compatible_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not be affected when it is released.
Detected by
>> The call to of_find_compatible_node returns a node pointer with refcount
>> incremented thus it must be explicitly decremented after the last
>> usage.
>> irq_domain_add_linear also calls of_node_get to increase refcount,
>> so irq_domain will not be affected when it is released.
>>
>> Detected
Joel Stanley writes:
> Segher added some workarounds for GCC 4.2 and bintuils 2.18. We now set
> 4.6 and 2.20 as the minimum, so they can be dropped.
>
> This is mostly a revert of c6995fe4 ("powerpc: Fix build bug with
> binutils < 2.18 and GCC < 4.2").
>
> Signed-off-by: Joel Stanley
> ---
On Mon, 2019-03-25 at 16:35 -0700, Joe Perches wrote:
> A file pattern line in this section of the MAINTAINERS file in linux-next
> does not have a match in the linux source files.
>
> This could occur because a matching filename was never added, was deleted
> or renamed in some other commit.
>
A file pattern line in this section of the MAINTAINERS file in linux-next
does not have a match in the linux source files.
This could occur because a matching filename was never added, was deleted
or renamed in some other commit.
The commits that added and if found renamed or removed the file
On Mon, Mar 25, 2019 at 03:36:28PM -0700, Dan Williams wrote:
> On Mon, Mar 25, 2019 at 3:22 PM Ira Weiny wrote:
> [..]
> > FWIW this thread is making me think my original patch which simply
> > implemented
> > get_user_pages_fast_longterm() would be more clear. There is some evidence
> > that
On Mon, Mar 25, 2019 at 3:22 PM Ira Weiny wrote:
[..]
> FWIW this thread is making me think my original patch which simply implemented
> get_user_pages_fast_longterm() would be more clear. There is some evidence
> that the GUP API was trending that way (see get_user_pages_remote). That
> seems
On Mon, Mar 25, 2019 at 02:51:50PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2019 at 02:23:15AM -0700, Ira Weiny wrote:
> > > > Unfortunately holding the lock is required to support FOLL_LONGTERM (to
> > > > check
> > > > the VMAs) but we don't want to hold the lock to be optimal
> > > >
> -Original Message-
> From: Frederic Barrat
> Sent: Tuesday, 26 March 2019 4:34 AM
> To: Greg Kurz ; Alastair D'Silva
> Cc: alast...@d-silva.org; Arnd Bergmann ; Greg Kroah-
> Hartman ; linux-ker...@vger.kernel.org;
> Andrew Donnellan ; linuxppc-
> d...@lists.ozlabs.org
> Subject: Re:
On Mär 25 2019, Michael Ellerman wrote:
> So I'm inclined to just switch to always using SPARSEMEM on 64-bit
> Book3S, because that's what's well tested and we hardly need more code
> paths to test. Unless anyone has a strong objection, I haven't actually
> benchmarked FLATMEM vs SPARSEMEM on a
On Fri, Mar 22, 2019 at 02:24:40PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
[snip]
> > + * __gup_longterm_locked() is a wrapper for __get_uer_pages_locked which
>
> s/uer/user/
>
> > + * allows us to process the FOLL_LONGTERM flag if present.
> > + *
> > + *
On Mon, Mar 25, 2019 at 11:33:56PM +1100, Michael Ellerman wrote:
> Segher Boessenkool writes:
> > On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wrote:
> >> + clrldi r6,r4,(64-12) // r6 = r4 & 0xfff
> >
> > You can just write
> > rlwinm r6,r4,0,0x0fff
>
> > if that is clearer?
On Mon, Mar 25, 2019 at 02:23:15AM -0700, Ira Weiny wrote:
> > > Unfortunately holding the lock is required to support FOLL_LONGTERM (to
> > > check
> > > the VMAs) but we don't want to hold the lock to be optimal (specifically
> > > allow
> > > FAULT_FOLL_ALLOW_RETRY). So I'm maintaining the
Hi Arnd,
On Mon, Mar 25, 2019 at 03:47:37PM +0100, Arnd Bergmann wrote:
> Add the io_uring and pidfd_send_signal system calls to all architectures.
>
> These system calls are designed to handle both native and compat tasks,
> so all entries are the same across architectures, only arm-compat and
Le 25/03/2019 à 17:49, Greg Kurz a écrit :
Hi Alastair,
I forgot to mention it during v3 but please don't link new version
of a patchset to the previous one with --in-reply-to. This is to
ensure I can see them in my email client without having to scroll
back many days in the past (which
On Mon, Mar 25, 2019 at 01:47:13PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 25, 2019 at 01:42:26AM -0700, Ira Weiny wrote:
> > On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote:
> > > On Sun, Mar 17, 2019 at 7:36 PM wrote:
> > > >
> > > > From: Ira Weiny
> > > >
> > > > DAX pages
On Mon, 25 Mar 2019 16:34:55 +1100
"Alastair D'Silva" wrote:
> From: Alastair D'Silva
>
> Remove some unused exported symbols.
>
> Signed-off-by: Alastair D'Silva
> ---
Reviewed-by: Greg Kurz
> drivers/misc/ocxl/config.c| 4 +---
> drivers/misc/ocxl/ocxl_internal.h | 23
Hi Alastair,
I forgot to mention it during v3 but please don't link new version
of a patchset to the previous one with --in-reply-to. This is to
ensure I can see them in my email client without having to scroll
back many days in the past (which likely means a fair number of
e-mails on
On Mon, 25 Mar 2019 16:34:54 +1100
"Alastair D'Silva" wrote:
> From: Alastair D'Silva
>
> The 'extern' keyword adds no value here.
>
> Signed-off-by: Alastair D'Silva
> ---
Reviewed-by: Greg Kurz
> drivers/misc/ocxl/ocxl_internal.h | 54 +++
>
On Mon, Mar 25, 2019 at 09:45:12AM -0700, Dan Williams wrote:
> On Mon, Mar 25, 2019 at 7:21 AM Ira Weiny wrote:
> [..]
> > > > @@ -1268,10 +1246,14 @@ static long
> > > > check_and_migrate_cma_pages(unsigned long start, long nr_pages,
> > > >
On Mon, Mar 25, 2019 at 01:42:26AM -0700, Ira Weiny wrote:
> On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote:
> > On Sun, Mar 17, 2019 at 7:36 PM wrote:
> > >
> > > From: Ira Weiny
> > >
> > > DAX pages were previously unprotected from longterm pins when users
> > > called
On Mon, Mar 25, 2019 at 7:21 AM Ira Weiny wrote:
[..]
> > > @@ -1268,10 +1246,14 @@ static long check_and_migrate_cma_pages(unsigned
> > > long start, long nr_pages,
> > > putback_movable_pages(_page_list);
> > > }
> > > /*
> > > -
On Fri, Mar 22, 2019 at 03:14:26PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
> > FS DAX pages being mapped.
> >
> > Signed-off-by: Ira Weiny
> > ---
> >
On Fri, Mar 22, 2019 at 03:12:55PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > DAX pages were previously unprotected from longterm pins when users
> > called get_user_pages_fast().
> >
> > Use the new FOLL_LONGTERM flag to check for DEVMAP
On Fri, Mar 22, 2019 at 03:05:53PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > To facilitate additional options to get_user_pages_fast() change the
> > singular write parameter to be gup_flags.
> >
> > This patch does not change any
On Mon, 25 Mar 2019 12:04:38 -0400
Joe Lawrence wrote:
> CC_FLAGS_FTRACE may contain trailing whitespace that interferes with
> findstring.
>
> For example, commit 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on
> GCC 4.9 and newer") introduced a change such that on my ppc64le box,
>
On 3/25/19 3:46 AM, Christophe Leroy wrote:
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
The
On 3/25/19 3:43 AM, Christophe Leroy wrote:
Commit 0df977eafc79 ("powerpc/6xx: Don't use SPRN_SPRG2 for storing
stack pointer while in RTAS") changes the code to use a field in
thread struct to store the stack pointer while in RTAS instead of
using SPRN_SPRG2. It therefore converts all places
On 3/23/19 1:27 PM, Joe Lawrence wrote:
On 03/23/2019 12:17 PM, Steven Rostedt wrote:
On Sat, 23 Mar 2019 09:19:50 -0400
Joe Lawrence wrote:
Perhaps this is gcc version specific? I didn't see any other reports,
so maybe its specific to my config. If I run make V=1, I can see that
gcc is
CC_FLAGS_FTRACE may contain trailing whitespace that interferes with
findstring.
For example, commit 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on
GCC 4.9 and newer") introduced a change such that on my ppc64le box,
CC_FLAGS_FTRACE="-pg -mprofile-kernel ". (Note the trailing space.)
When
On 3/25/19 1:53 AM, Christophe Leroy wrote:
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my PowerBook G4
Aluminum. The bootstrap loads the initial kernel and issues the appropriate
start, but the machine hangs at that point.
Can
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
External drivers that communicate via OpenCAPI will need to make
MMIO calls to interact with the devices.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
Acked-by: Frederic Barrat
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
Event_fd is only used in the driver frontend, so it does not
need to exist in the backend code. Relocate it to the frontend
and provide an opaque mechanism for consumers instead.
Signed-off-by: Alastair D'Silva
---
Hi,
Could you share the microbenchmark you are using ?
I'd like to test the series on powerpc.
Thanks
Christophe
Le 22/03/2019 à 15:30, Waiman Long a écrit :
Modify __down_read_trylock() to optimize for an unlocked rwsem and make
it generate slightly better code.
Before this patch,
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
The use of offsets is required only in the frontend, so alter
the IRQ API to only work with IRQ IDs in the backend.
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
drivers/misc/ocxl/afu_irq.c
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
Most OpenCAPI operations require a valid context, so
exposing these functions to external drivers is necessary.
Signed-off-by: Alastair D'Silva
Reviewed-by: Greg Kurz
---
See comment on previous patch regarding
This is a huge patch, there are probably ways to split it in smaller
pieces to make the review easier. However, considering how much time
we've already invested discussing and reviewing it, it's with by me to
keep it as is.
The ref-counting and device management look good to me now. A few
Add the io_uring and pidfd_send_signal system calls to all architectures.
These system calls are designed to handle both native and compat tasks,
so all entries are the same across architectures, only arm-compat and
the generic tale still use an old format.
Signed-off-by: Arnd Bergmann
---
On Fri, Mar 22, 2019 at 02:24:40PM -0700, Dan Williams wrote:
> On Sun, Mar 17, 2019 at 7:36 PM wrote:
> >
> > From: Ira Weiny
> >
> > Rather than have a separate get_user_pages_longterm() call,
> > introduce FOLL_LONGTERM and change the longterm callers to use
> > it.
> >
> > This patch does
Segher Boessenkool writes:
> On Fri, Mar 22, 2019 at 11:37:24PM +1100, Michael Ellerman wrote:
>> .Lcmp_rest_lt8bytes:
>> -/* Here we have only less than 8 bytes to compare with. at least s1
>> - * Address is aligned with 8 bytes.
>> - * The next double words are load and shift right
I was able to activate CONFIG_SPARSEMEM in the kernel configuration. But
does the P.A. Semi Nemo board need this option?
-- Christian
On 25 March 2019 at 12:00PM, Christian Zigotzky wrote:
Hi All,
I wasn't able to compile the RC2 today because of the following error
messages:
CC
Le 25/03/2019 à 12:35, Michael Ellerman a écrit :
Ben Hutchings writes:
On Mon, 2019-03-25 at 01:03 +0100, Andreas Schwab wrote:
On Mär 24 2019, Ben Hutchings wrote:
Presumably you have CONFIG_PPC_BOOK3S_64 enabled and
CONFIG_SPARSEMEM
disabled? Was this configuration actually usable?
Ben Hutchings writes:
> On Mon, 2019-03-25 at 01:03 +0100, Andreas Schwab wrote:
>> On Mär 24 2019, Ben Hutchings wrote:
>>
>> > Presumably you have CONFIG_PPC_BOOK3S_64 enabled and
>> > CONFIG_SPARSEMEM
>> > disabled? Was this configuration actually usable?
>>
>> Why not?
>
> I assume that
Hi All,
I wasn't able to compile the RC2 today because of the following error
messages:
CC arch/powerpc/mm/slb.o
In file included from ./arch/powerpc/include/asm/book3s/64/mmu.h:39:0,
from ./arch/powerpc/include/asm/mmu.h:360,
from
Peng Hao writes:
> From: Wen Yang
>
> The call to of_find_compatible_node returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
> irq_domain_add_linear also calls of_node_get to increase refcount,
> so irq_domain will not be affected
On Mon, Mar 25, 2019 at 8:55 AM Masahiro Yamada
wrote:
>
> On Mon, Mar 25, 2019 at 4:33 PM Arnd Bergmann wrote:
> >
> > On Mon, Mar 25, 2019 at 7:11 AM Masahiro Yamada
> > wrote:
> > > I do not know why to reproduce it,
> > > but is "__init __noreturn" more sensible than
> > > "__always_inline"
On Wed, Mar 20, 2019 at 2:34 PM Arnd Bergmann wrote:
>
> On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> >
> > I've added your patch to my randconfig test setup and will let you
> > know if I see anything noticeable. I'm currently testing clang-arm32,
> > clang-arm64 and gcc-x86.
>
>
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
This data is already available in a struct
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
drivers/misc/ocxl/core.c | 38 +-
1 file changed, 21
Le 25/03/2019 à 06:44, Alastair D'Silva a écrit :
From: Alastair D'Silva
In preparation for making core code available for external drivers,
move the core code out of pci.c and into core.c
Signed-off-by: Alastair D'Silva
---
Acked-by: Frederic Barrat
drivers/misc/ocxl/Makefile
From: Wen Yang
The call to of_find_compatible_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will not be affected when it is released.
Detected by
Hi, Ben
> Presumably you have CONFIG_PPC_BOOK3S_64 enabled and CONFIG_SPARSEMEM
> disabled?
> Was this configuration actually usable?
I just noticed these build warnings too. FWIW, I've been using
CONFIG_FLATMEM on my Power Mac G5 for about three years, so I guess
the answer is "yes" (for this
Le 25/03/2019 à 18:11, Peng Hao a écrit :
From: Wen Yang
The call to of_find_compatible_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
irq_domain_add_linear also calls of_node_get to increase refcount,
so irq_domain will
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my
PowerBook G4 Aluminum. The bootstrap loads the initial kernel and issues
the appropriate start, but the machine hangs at that point.
The problem does not depend on the choice of
Commit 0df977eafc79 ("powerpc/6xx: Don't use SPRN_SPRG2 for storing
stack pointer while in RTAS") changes the code to use a field in
thread struct to store the stack pointer while in RTAS instead of
using SPRN_SPRG2. It therefore converts all places which were
manipulating SPRN_SPRG2 to use that
On Mon, Mar 25, 2019 at 4:33 PM Arnd Bergmann wrote:
>
> On Mon, Mar 25, 2019 at 7:11 AM Masahiro Yamada
> wrote:
> > On Wed, Mar 20, 2019 at 10:34 PM Arnd Bergmann wrote:
> > >
> > > On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> > > >
> > > > I've added your patch to my randconfig
On Mon, Mar 25, 2019 at 7:11 AM Masahiro Yamada
wrote:
> On Wed, Mar 20, 2019 at 10:34 PM Arnd Bergmann wrote:
> >
> > On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> > >
> > > I've added your patch to my randconfig test setup and will let you
> > > know if I see anything noticeable.
Le 25/03/2019 à 01:49, Larry Finger a écrit :
A build of kernel 5.1.0-rc2 resulted in a failure to boot on my
PowerBook G4 Aluminum. The bootstrap loads the initial kernel and issues
the appropriate start, but the machine hangs at that point.
Can you please be more explicit ? What do you
Hi Christophe,
On Sat, Mar 23, 2019 at 5:27 PM LEROY Christophe
wrote:
>
> Arnd Bergmann a écrit :
>
> > On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> >>
> >> I've added your patch to my randconfig test setup and will let you
> >> know if I see anything noticeable. I'm currently
Hi Heiko,
On Thu, Mar 21, 2019 at 5:02 PM Heiko Carstens
wrote:
>
> On Wed, Mar 20, 2019 at 03:20:27PM +0900, Masahiro Yamada wrote:
> > Commit 60a3cdd06394 ("x86: add optimized inlining") introduced
> > CONFIG_OPTIMIZE_INLINING, but it has been available only for x86.
> >
> > The idea is
On Friday, March 22, 2019 6:07:24 PM IST Michael Ellerman wrote:
> Chandan reported that fstests' generic/026 test hit a crash:
>
> BUG: Unable to handle kernel data access at 0xc0062ac4
> Faulting instruction address: 0xc0092240
> Oops: Kernel access of bad area, sig: 11
On Friday, March 22, 2019 6:07:24 PM IST Michael Ellerman wrote:
> Chandan reported that fstests' generic/026 test hit a crash:
>
> BUG: Unable to handle kernel data access at 0xc0062ac4
> Faulting instruction address: 0xc0092240
> Oops: Kernel access of bad area, sig: 11
On Mon, Mar 25, 2019 at 3:10 PM Masahiro Yamada
wrote:
>
> Hi Arnd,
>
>
>
>
> On Wed, Mar 20, 2019 at 10:34 PM Arnd Bergmann wrote:
> >
> > On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> > >
> > > I've added your patch to my randconfig test setup and will let you
> > > know if I see
Hi Arnd,
On Wed, Mar 20, 2019 at 10:34 PM Arnd Bergmann wrote:
>
> On Wed, Mar 20, 2019 at 10:41 AM Arnd Bergmann wrote:
> >
> > I've added your patch to my randconfig test setup and will let you
> > know if I see anything noticeable. I'm currently testing clang-arm32,
> > clang-arm64 and
Hi Arnd,
On Wed, Mar 20, 2019 at 10:05 PM Arnd Bergmann wrote:
>
> On Wed, Mar 20, 2019 at 11:19 AM Masahiro Yamada
> wrote:
> > On Wed, Mar 20, 2019 at 6:39 PM Arnd Bergmann wrote:
> > >
> > > On Wed, Mar 20, 2019 at 7:41 AM Masahiro Yamada
> > > wrote:
> > >
> > > > It is unclear to me
67 matches
Mail list logo
