On Tue, 2016-03-15 at 11:19 +1100, Michael Ellerman wrote:
> On Fri, 2016-03-11 at 21:15 -0600, Scott Wood wrote:
>
> > Highlights include 8xx optimizations, 32-bit checksum optimizations, 86xx
> > consolidation, e5500/e6500 cpu hotplug, more fman and other dt bits, and
> > minor fixes/cleanup.
>
On Tue, 2016-03-15 at 02:01 -0500, Scott Wood wrote:
> On Tue, 2016-03-15 at 11:19 +1100, Michael Ellerman wrote:
> > On Fri, 2016-03-11 at 21:15 -0600, Scott Wood wrote:
> >
> > > Highlights include 8xx optimizations, 32-bit checksum optimizations, 86xx
> > > consolidation, e5500/e6500 cpu hotplug
On Tue, 2016-03-15 at 16:15 +1100, Russell Currey wrote:
> On Tue, 2016-03-15 at 14:56 +1100, Andrew Donnellan wrote:
> > On 15/03/16 14:26, Russell Currey wrote:
> > >
> > > The HMI code knows about three types of errors: CORE, NX and UNKNOWN.
> > > If OPAL were to add a new type, it would not be
The HMI code knows about three types of errors: CORE, NX and UNKNOWN.
If OPAL were to add a new type, it would not be handled at all since
there is no fallback case. Instead of explicitly checking for UNKNOWN,
treat any checkstop type without a handler as unknown.
Signed-off-by: Russell Currey
R
Le 15/03/2016 07:25, Scott Wood a écrit :
Some versions of GCC, reportedly before 4.9, fail with
arch/powerpc/mm/8xx_mmu.c:139:2: error: memory input 1 is not directly
addressable
Use a register constraint instead of a memory constraint to avoid this.
Also change the one-element array into a si
On Wed, 9 Mar 2016, Balbir Singh wrote:
>
> The previous revision was nacked by Torsten, but compared to the alternatives
> at hand I think we should test this approach. Ideally we want all the
> complexity
> of live-patching in the live-patching code and not in the patch. The other
> option
>
Le 15/03/2016 08:01, Scott Wood a écrit :
On Tue, 2016-03-15 at 11:19 +1100, Michael Ellerman wrote:
On Fri, 2016-03-11 at 21:15 -0600, Scott Wood wrote:
Highlights include 8xx optimizations, 32-bit checksum optimizations, 86xx
consolidation, e5500/e6500 cpu hotplug, more fman and other dt b
On Thu, 10 Mar 2016, Jiri Kosina wrote:
> On Wed, 9 Mar 2016, Petr Mladek wrote:
>
> > LivePatch framework deserves some documentation, definitely.
> > This is an attempt to provide some basic info. I hope that
> > it will be useful for both LivePatch producers and also
> > potential developers o
Some versions of GCC, reportedly before 4.8, fail with
arch/powerpc/mm/8xx_mmu.c:139:2: error: memory input 1 is not directly
addressable
Change the one-element array into a simple variable to avoid this.
Signed-off-by: Christophe Leroy
Cc: Scott Wood
---
Verified with GCC 4.4.4 and GCC 4.8.3
Naples CPUs have two CAPI ports. Configure the PSL to route data to
the port corresponding to the PHB index.
Signed-off-by: Philippe Bergheaud
---
drivers/misc/cxl/pci.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl
On Tue, Mar 15, 2016 at 8:46 AM, Stephen Rothwell wrote:
> Hi Benjamin,
>
> After merging the aio tree, today's linux-next build (powerpc
> ppc44x_defconfig) failed like this:
>
> fs/built-in.o: In function `aio_thread_op_foo_at':
> aio.c:(.text+0x4dab4): undefined reference to `__get_user_bad'
>
don't use __get_user() for 64 bit values")
>
> This is due to a bug in the powerpc __get_user_check() macro (the return
> value is defined to be "unsigned long" which is only 32 bits on a 32
> bit platform).
m68k allmodconfig and all defs of m32r fails while building n
On Tuesday 15 March 2016 16:38:51 Andy Shevchenko wrote:
> On Tue, Mar 15, 2016 at 8:46 AM, Stephen Rothwell
> wrote:
> > Hi Benjamin,
> >
> > After merging the aio tree, today's linux-next build (powerpc
> > ppc44x_defconfig) failed like this:
> >
> > fs/built-in.o: In function `aio_thread_op_fo
On Tue, 2016-03-15 at 11:18 +0100, Christophe Leroy wrote:
> Le 15/03/2016 07:25, Scott Wood a écrit :
> > Some versions of GCC, reportedly before 4.9, fail with
> > arch/powerpc/mm/8xx_mmu.c:139:2: error: memory input 1 is not directly
> > addressable
> >
> > Use a register constraint instead of
On Tue, 2016-03-15 at 14:07 +0100, Christophe Leroy wrote:
> Some versions of GCC, reportedly before 4.8, fail with
> arch/powerpc/mm/8xx_mmu.c:139:2: error: memory input 1 is not directly
> addressable
"before 4.8" means "< 4.8", not "<= 4.8" -- did you mean "before 4.9"?
> Change the one-elemen
On Tue, 2016-03-15 at 20:07 +1100, Michael Ellerman wrote:
> On Tue, 2016-03-15 at 02:01 -0500, Scott Wood wrote:
> > On Tue, 2016-03-15 at 11:19 +1100, Michael Ellerman wrote:
> > > On Fri, 2016-03-11 at 21:15 -0600, Scott Wood wrote:
> > > > powerpc/mpc85xx: Add CPU hotplug support for E650
Le 15/03/2016 18:41, Scott Wood a écrit :
On Tue, 2016-03-15 at 14:07 +0100, Christophe Leroy wrote:
Some versions of GCC, reportedly before 4.8, fail with
arch/powerpc/mm/8xx_mmu.c:139:2: error: memory input 1 is not directly
addressable
"before 4.8" means "< 4.8", not "<= 4.8" -- did you me
Hi Mikey,
Le 15/03/2016 01:27, Michael Neuling a écrit :
I'm not happy with doing this unless we add something which advertises
that it's synced or not to userspace.
If we do that, I'm happy to just fail without the need of the parameter
but advertise it to userspace.
OK, so I'm guessing that
While writing some instruction tests for kvm-unit-tests for powerpc,
I've found that illegal instructions are not managed correctly with kvm-pr,
while it is fine with kvm-hv.
When an illegal instruction (like ".long 0") is processed by kvm-pr,
the kernel logs are filled with:
Couldn't emulat
1 ("aio: add support for async openat()")
> >
> > despite commit
> >
> > d2f7a973e11e ("aio: don't use __get_user() for 64 bit values")
> >
> > This is due to a bug in the powerpc __get_user_check() macro (the return
> > valu
__get_user() for 64 bit values")
> > >
> > > This is due to a bug in the powerpc __get_user_check() macro (the return
> > > value is defined to be "unsigned long" which is only 32 bits on a 32
> > > bit platform).
> >
> > m68k allmod
On Thu, 2016-03-10 at 11:22 +0100, luigi burdo wrote:
> Hi Scott,
> sorry for late reply in this last few days i become another time father .
> In any way for better explain the issue i attached my dmesg log
> probably will make understand better than my poor english
>
> Thanks for your time
> Lu
The domain/PHB field of PCI addresses has its value obtained from a
global variable, incremented each time a new domain (represented by
struct pci_controller) is added on the system. The domain addition
process happens during boot or due to PCI device hotplug.
As recent kernels are using predictab
On Tue, 2016-03-15 at 15:26 +0100, Philippe Bergheaud wrote:
> Naples CPUs have two CAPI ports.
Naples is an internal name, don't use that. Use POWER8NVL is the name
we use in the kernel.
alsi, it's a "chip" that has two CAPI ports, not the CPU.
> Configure the PSL to route data to
> the port
On Tue, Mar 15, 2016 at 07:54:41PM -0300, Guilherme G. Piccoli wrote:
>The domain/PHB field of PCI addresses has its value obtained from a
>global variable, incremented each time a new domain (represented by
>struct pci_controller) is added on the system. The domain addition
>process happens during
Commit 70fe3d9 "powerpc: Restore FPU/VEC/VSX if previously used" introduces a
call to restore_math() late in the syscall return path, after MSR_RI has been
cleared. The MSR_RI flag is used to indicate whether the kernel can take
another exception or not. A cleared MSR_RI flag indicates that the ker
On Wed, Mar 09, 2016 at 05:29:02PM +1100, Alexey Kardashevskiy wrote:
> NPU devices are quite specific, in fact they represent side DMA channel
> of a GPU device. The GPU/NPU driver never actually configures DMA
> for NPU devices, instead it relies on the platform code to propagate
> DMA setup to N
hi Scott,
the P5020 mmu is signed by the kernel no book3e found
kvm ppc64 crash if run by qemu.
in the kernel( 4.5 too)all is enabled we had a base .config by freescale/nix
where kvm options and book3e where enabled.
my suspect is this can be an generated issue by the host uboot or a missed tdb
28 matches
Mail list logo
