This preserves the ability to build using older binutils (reportedly <=
2.22).
Signed-off-by: Scott Wood
Cc: chenhui.z...@freescale.com
---
arch/powerpc/kernel/head_64.S | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kern
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'
aio.c:(.text+0x4daec): undefined reference to `__get_user_bad'
Caused b
On Fri, Mar 11, 2016 at 01:15:20PM +1100, Alexey Kardashevskiy wrote:
> On 03/10/2016 04:18 PM, David Gibson wrote:
> >On Wed, Mar 09, 2016 at 07:46:47PM +1100, Alexey Kardashevskiy wrote:
> >>On 03/08/2016 10:08 PM, David Gibson wrote:
> >>>On Mon, Mar 07, 2016 at 02:41:16PM +1100, Alexey Kardashe
On Fri, Mar 11, 2016 at 10:09:50AM +1100, Alexey Kardashevskiy wrote:
> On 03/10/2016 04:21 PM, David Gibson wrote:
> >On Wed, Mar 09, 2016 at 08:20:12PM +1100, Alexey Kardashevskiy wrote:
> >>On 03/09/2016 04:45 PM, David Gibson wrote:
> >>>On Mon, Mar 07, 2016 at 02:41:17PM +1100, Alexey Kardashe
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 simple variable.
Signed-off-by: Scott Wood
Cc
On Tue, 2016-03-15 at 16:36 +1100, Andrew Donnellan wrote:
> On 15/03/16 16:15, Russell Currey wrote:
> >
> > >
> > > Would it be useful to print xstop_type in the unknown case?
> > I don't think so - if there's a new checkstop type, specific handling
> > for
> > it should be implemented in the k
On 15/03/16 16:15, Russell Currey wrote:
Would it be useful to print xstop_type in the unknown case?
I don't think so - if there's a new checkstop type, specific handling for
it should be implemented in the kernel, and if you're getting unknown
checkstops that are bringing down your machine you
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 handled at all since
> > there is no fallback case. Instead of ex
Hi Mikey,
Michael Neuling writes:
> 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.
>
> The parameter is a bit of a PITA too
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 handled at all since
there is no fallback case. Instead of explicitly checking for UNKNOWN,
treat any checkstop type without a handler as
On Tue, 2016-03-15 at 11:27 +1100, Michael Neuling wrote:
> On Mon, 2016-03-14 at 20:29 +0100, Frederic Barrat wrote:
> > CXL driver synchronizes the PSL timebase with the CAPP during
> > initialization. If it can't synchronize, then the driver currently
> > fails and the cxl adapter is not usabl
Russell Currey writes:
> 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.
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
-
Michael Bringmann writes:
> Summary: The following properties: ibm,drc-indexes, ibm,drc-names,
> ibm,drc-types and ibm,drc-power-domains will be combined and condensed
> into the single property, ibm,drc-info.
>
> The ibm,dynamic-memory property will be condensed into a new version,
> ibm,dynam
On Mon, 14 Mar 2016, Michael Ellerman wrote:
> > Move the logic to work out the kernel toc pointer into a header. This is
> > a good cleanup, and also means we can use it elsewhere in future.
> >
> > Reviewed-by: Kamalesh Babulal
> > Reviewed-by: Torsten Duwe
> > Signed-off-by: Michael Ellerman
On Mon, 2016-03-14 at 20:29 +0100, Frederic Barrat wrote:
> CXL driver synchronizes the PSL timebase with the CAPP during
> initialization. If it can't synchronize, then the driver currently
> fails and the cxl adapter is not usable. That behavior is a bit
> extreme for the time being, as some adap
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.
Hi Scott,
This one's giving me a few troubles.
> chenhui zhao (6):
>
On Fri, 11 Mar 2016 08:31:55 +0530 Anshuman Khandual
wrote:
> On 03/09/2016 05:40 PM, Anshuman Khandual wrote:
> > Currently both the ARCH_WANT_GENERAL_HUGETLB functions 'huge_pte_alloc'
> > and 'huge_pte_offset' dont take into account huge page implementation
> > at the PGD level. With addition
CXL driver synchronizes the PSL timebase with the CAPP during
initialization. If it can't synchronize, then the driver currently
fails and the cxl adapter is not usable. That behavior is a bit
extreme for the time being, as some adapters are known to have
troubles syncing their PSL timebase and the
On 03/14/2016 02:29 AM, Yangbo Lu wrote:
>> -Original Message-
>> From: Arnd Bergmann [mailto:a...@arndb.de]
>> Sent: Monday, March 14, 2016 6:26 AM
>> To: linuxppc-dev@lists.ozlabs.org
>> Cc: Yangbo Lu; devicet...@vger.kernel.org; linux-arm-
>> ker...@lists.infradead.org; linux-ker...@vger
CXL driver synchronizes the PSL timebase with the CAPP during
initialization. If it can't synchronize, then the driver currently
fails and the cxl adapter is not usable. That behavior is a bit
extreme for the time being, as some adapters are known to have
troubles syncing their PSL timebase and the
On 13/03/2016 04:10, Lan Tianyu wrote:
> This series is to clear up kvm mmu memory barriers.
> 1) Remove redundant barrier (PATCH 1)
> 2) Replace origin barrier functions with preferrable ones (PATCH 2, 3, 5)
> 3) Fix unpaired barriers (PATCH 4)
> 4) Update or add barrier related comments (PATCH
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Monday, March 14, 2016 6:26 AM
> To: linuxppc-dev@lists.ozlabs.org
> Cc: Yangbo Lu; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-ker...@vger.kernel.org; linux-
> c...@vger.kernel.org; lin
On Thu, 2016-03-03 at 04:26:53 UTC, Michael Ellerman wrote:
> Move the logic to work out the kernel toc pointer into a header. This is
> a good cleanup, and also means we can use it elsewhere in future.
>
> Reviewed-by: Kamalesh Babulal
> Reviewed-by: Torsten Duwe
> Signed-off-by: Michael Ellerm
24 matches
Mail list logo
