[PATCH 5/5] powerpc/zImage: Also check for stdout-path

The /chosen/linux,stdout-path is "deprecated" in favour of /chosen/stdout-path so we should be checking for both. Signed-off-by: Oliver O'Halloran --- arch/powerpc/boot/serial.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/boot/serial.c

[PATCH 2/5] powerpc/zImage: Don't build zlib object files

The required source files are directly #include`ed into decompress.c when using gzip compression. Building the separate .o files for the zlib sources isn't required and can cause linker errors due to the symbols being defined in decompress.o and the zlib .o files. Signed-off-by: Oliver O'Halloran

[PATCH 4/5] powerpc/zImage: Rework serial driver probing

Rather than checking the compatible string in serial_driver_init() we call into the driver's init function and wait for a driver to inidicate it bound to the device by returning zero. The pointers to each driver probe functions are stored in the ".serialdrv" section of the zImage, similar to how

[PATCH 3/5] powerpc/zImage: Check compatible at driver init

Have each driver's init function check the compatible string of the node given by the stdout path. This gives the drivers a more traditional probe-also-inits structure. Signed-off-by: Oliver O'Halloran --- arch/powerpc/boot/cpm-serial.c | 2 ++ arch/powerpc/boot/mpc52xx-psc.c

[PATCH 1/5] powerpc/zImage: Remove #ifdef in opal.c

This file is only ever compiled if CONFIG_PPC64_BOOT_WRAPPER is set so this check is unnecessary. Signed-off-by: Oliver O'Halloran --- arch/powerpc/boot/opal.c | 8 1 file changed, 8 deletions(-) diff --git a/arch/powerpc/boot/opal.c b/arch/powerpc/boot/opal.c index

Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

On Sun, Mar 18, 2018 at 06:18:48PM +, Al Viro wrote: > I'd done some digging in that area, will find the notes and post. OK, found: We have two ABIs in the game - syscall and normal C. The latter (for all targets we support) can be described in the following terms: * there is a

[PATCH v2 9/9] powerpc/eeh: Add eeh_state_active() helper

Checking for a "fully active" device state requires testing two flag bits, which is open coded in several places, so add a function to do it. Signed-off-by: Sam Bobroff --- arch/powerpc/include/asm/eeh.h | 6 ++ arch/powerpc/kernel/eeh.c

[PATCH v2 8/9] powerpc/eeh: Factor out common code eeh_reset_device()

The caller will always pass NULL for 'rmv_data' when 'eeh_aware_driver' is true, so the first two calls to eeh_pe_dev_traverse() can be combined without changing behaviour as can the two arms of the final 'if' block. This should not change behaviour. Signed-off-by: Sam Bobroff

[PATCH v2 7/9] powerpc/eeh: Remove always-true tests in eeh_reset_device()

eeh_reset_device() tests the value of 'bus' more than once but the only caller, eeh_handle_normal_device() does this test itself and will never pass NULL. So, remove the dead tests. This should not change behaviour. Signed-off-by: Sam Bobroff ---

[PATCH v2 6/9] powerpc/eeh: Clarify arguments to eeh_reset_device()

It is currently difficult to understand the behaviour of eeh_reset_device() due to the way it's parameters are used. In particular, when 'bus' is NULL, it's value is still necessary so the same value is looked up again locally under a different name ('frozen_bus') but behaviour is changed. To

[PATCH v2 5/9] powerpc/eeh: Rename frozen_bus to bus in eeh_handle_normal_event()

The name "frozen_bus" is misleading: it's not necessarily frozen, it's just the PE's PCI bus. Signed-off-by: Sam Bobroff --- arch/powerpc/kernel/eeh_driver.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kernel/eeh_driver.c

[PATCH v2 4/9] powerpc/eeh: Remove misleading test in eeh_handle_normal_event()

Remove a test that checks if "frozen_bus" is NULL, because it cannot have changed since it was tested at the start of the function and so must be true here. Signed-off-by: Sam Bobroff --- arch/powerpc/kernel/eeh_driver.c | 24 +++- 1 file changed, 11

[PATCH v2 3/9] powerpc/eeh: Fix misleading comment in __eeh_addr_cache_get_device()

Commit "0ba17b05 powerpc/eeh: Remove reference to PCI device" removed a call to pci_dev_get() from __eeh_addr_cache_get_device() but did not update the comment to match. Signed-off-by: Sam Bobroff --- arch/powerpc/kernel/eeh_cache.c | 3 +-- 1 file changed, 1

[PATCH v2 2/9] powerpc/eeh: Manage EEH_PE_RECOVERING inside eeh_handle_normal_event()

Currently the EEH_PE_RECOVERING flag for a PE is managed by both the caller and callee of eeh_handle_normal_event() (among other places not considered here). This is complicated by the fact that the PE may or may not have been invalidated by the call. So move the callee's handling into

[PATCH v2 1/9] powerpc/eeh: Remove eeh_handle_event()

The function eeh_handle_event(pe) does nothing other than switching between calling eeh_handle_normal_event(pe) and eeh_handle_special_event(). However it is only called in two places, one where pe can't be NULL and the other where it must be NULL (see eeh_event_handler()) so it does nothing but

[PATCH v2 0/9] EEH refactoring 1

Hello everyone, Here is a set of some small, mostly idempotent, changes to improve maintainability in some of the EEH code, primarily in eeh_driver.c. I've kept them all small to aid review but perhaps they should be squashed down before being applied. Cheers, Sam. Patch set changelog follows:

Re: [PATCH v3 18/18] infiniband: cxgb4: Eliminate duplicate barriers on weakly-ordered archs

On Sat, Mar 17, 2018 at 02:30:10PM -0400, Sinan Kaya wrote: > Somebody also has to take a task and work very hard to get rid of > __raw_writeX() > APIs in drivers/net directory. It looked like a very common practice though > it clearly violates multiarch portability concerns Jason and Deve

Re: [RFC PATCH 2/2] powerpc: Only support DYNAMIC_FTRACE not static

Steven Rostedt writes: > On Sat, 17 Mar 2018 00:46:33 +1100 > Michael Ellerman wrote: > >> We've had dynamic ftrace support for over 9 years since Steve first >> wrote it, all the distros use dynamic, and static is basically >> untested these days, so

Re: [RFC PATCH 1/2] ftrace: Allow arches to opt-out of static ftrace

Steven Rostedt writes: > On Sat, 17 Mar 2018 00:46:32 +1100 > Michael Ellerman wrote: > >> There is a small but non-zero amount of code required by arches to >> suppory non-dynamic (static) ftrace, and more importantly there is the >> added work of

Re: [PATCH 1/5] mtd: Initialize ->fail_addr early in mtd_erase()

On Mon, 12 Feb 2018 22:03:07 +0100 Boris Brezillon wrote: > mtd_erase() can return an error before ->fail_addr is initialized to > MTD_FAIL_ADDR_UNKNOWN. Move this initialization at the very beginning > of the function. Applied the patchset after addressing Miquel's

Re: [RFC PATCH 2/6] fs: provide a generic compat_sys_truncate64() implementation

On Sun, Mar 18, 2018 at 9:10 AM, Dominik Brodowski wrote: > +#ifdef __ARCH_WANT_COMPAT_SYS_TRUNCATE64 > +#if defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \ > + defined(__ARCH_WANT_LE_COMPAT_SYS) > +COMPAT_SYSCALL_DEFINE4(truncate64, const char __user *,

Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

On Sun, Mar 18, 2018 at 11:06:42AM -0700, Linus Torvalds wrote: > and then we can do > > COMPAT_SYSCALL_DEFINE5(readahead, int, fd, > COMPAT_ARG_64BIT_ODD(off), compat_size_t, count) > { > return do_readahead(fd, off_lo + ((u64)off_hi << 64), count); > } > > which at least looks

Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

On Sun, Mar 18, 2018 at 05:10:54PM +0100, Dominik Brodowski wrote: > +#ifdef __ARCH_WANT_COMPAT_SYS_READAHEAD > +#if defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \ > + defined(__ARCH_WANT_LE_COMPAT_SYS) > +COMPAT_SYSCALL_DEFINE5(readahead, int, fd, unsigned int, padding, > +

Re: [RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

On Sun, Mar 18, 2018 at 10:40 AM, Al Viro wrote: > > *UGH* > > static inline compat_to_u64(u32 w0, u32 w1) > { > #ifdef __BIG_ENDIAN > return ((u64)w0 << 32) | w1; > #else > return ((u64)w1 << 32) | w0; > #endif > } > > in compat.h, then this turns into >

Re: [RFC PATCH 3/6] fs: provide generic compat_sys_p{read, write}64() implementations

On Sun, Mar 18, 2018 at 05:10:53PM +0100, Dominik Brodowski wrote: > +#ifdef __ARCH_WANT_COMPAT_SYS_PREADWRITE64 > +#if defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \ > + defined(__ARCH_WANT_LE_COMPAT_SYS) > +COMPAT_SYSCALL_DEFINE6(pread64, unsigned int, fd, char __user *, ubuf, > +

Re: [RFC PATCH 2/6] fs: provide a generic compat_sys_truncate64() implementation

On Sun, Mar 18, 2018 at 05:10:52PM +0100, Dominik Brodowski wrote: > +#ifdef __ARCH_WANT_COMPAT_SYS_TRUNCATE64 > +#if defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \ > + defined(__ARCH_WANT_LE_COMPAT_SYS) > +COMPAT_SYSCALL_DEFINE4(truncate64, const char __user *, filename, u32 > padding, >

Re: [RFC PATCH 3/6] fs: provide generic compat_sys_p{read, write}64() implementations

Honestly, I think the patches like this are disgusting: On Sun, Mar 18, 2018 at 9:10 AM, Dominik Brodowski wrote: > +#ifdef __ARCH_WANT_COMPAT_SYS_PREADWRITE64 > +#if defined(__ARCH_WANT_COMPAT_SYS_WITH_PADDING) && \ > + defined(__ARCH_WANT_LE_COMPAT_SYS) >

[RFC PATCH 1/6] fs: provide a generic compat_sys_fallocate() implementation

The compat_sys_fallocate() implementations in mips, powerpc, s390, sparc and x86 only differed based on the endianness of the u64 being passed as parameters (3, 4) and (5, 6). In addition, do not call sys_fallocate() from compat_sys_fallocate(), but use a common do_fallocate() helper instead.

[RFC PATCH 3/6] fs: provide generic compat_sys_p{read, write}64() implementations

The compat_sys_{read,write}64() implementations in mips, powerpc, s390, sparc and x86 only differed based on whether the u64 parameter needed padding and on their endianness. Oh, and some defined the parameters as u64 or "unsigned long" which expanded to u64, though it only expected u32 in these

[RFC PATCH 2/6] fs: provide a generic compat_sys_truncate64() implementation

The compat_sys_truncate64() implementations in mips, powerpc, s390, sparc and x86 only differed based on whether the u64 parameter needed padding and on its endianness. Oh, and some defined the parameters as "unsigned long" which expanded to u64, though it only expected u32 in these parameters.

[RFC PATCH 4/6] mm: provide generic compat_sys_readahead() implementation

The compat_sys_readahead() implementations in mips, powerpc, s390, sparc and x86 only differed based on whether the u64 parameter needed padding and on their endianness. Oh, and some defined the parameters as u64 or "unsigned long" which expanded to u64, though it only expected u32 in these

Re: [PATCH v12 00/11] Application Data Integrity feature introduced by SPARC M7

From: Khalid Aziz Date: Wed, 21 Feb 2018 10:15:42 -0700 > V12 changes: > This series is same as v10 and v11 and was simply rebased on 4.16-rc2 > kernel and patch 11 was added to update signal delivery code to use the > new helper functions added by Eric Biederman. Can mm

[PATCH V5 4/4] powerpc/mm/hash: Don't memset pgd table if not needed

We need to zero-out pgd table only if we share the slab cache with pud/pmd level caches. With the support of 4PB, we don't share the slab cache anymore. Instead of removing the code completely hide it within an #ifdef. We don't need to do this with any other page table level, because they all

[PATCH V5 3/4] powerpc/mm/hash64: Increase the VA range

This patch increase the max virtual address value to 4PB. With 4K page size config we continue to limit ourself to 64TB. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/include/asm/book3s/64/hash-64k.h | 2 +- arch/powerpc/include/asm/processor.h | 9

[PATCH V5 2/4] powerpc/mm: Add support for handling > 512TB address in SLB miss

For address above 512TB we allocate additional mmu context. To make it all easy, address above 512TB is handled with IR/DR=1 and with stack frame setup. The mmu_context_t is also updated to track the new extended_ids. To support upto 4PB we need a total 8 contexts. Signed-off-by: Aneesh Kumar

[PATCH V5 1/4] powerpc/mm/slice: Consolidate the return path for the function.

In the follow up patch, on finding a free area we will need to do allocated extra contexts as needed. Consolidating the return path for slice_get_unmapped_area makes it easy. Split into a separate patch to make review easy. Signed-off-by: Aneesh Kumar K.V ---

[PATCH V5 0/4] Add support for 4PB virtual address space on hash

This patch series extended the max virtual address space value from 512TB to 4PB with 64K page size. We do that by allocating one vsid context for each 512TB range. More details of that is explained in patch 3. Changes from V4: * Move context allocation to mmap time instead of SLB miss time *