[PATCH v2] macintosh: rack-meter: make of_device_ids const.

of_device_ids are not supposed to change at runtime. All functions working with of_device_ids provided by work with const of_device_ids. So mark the non-const structs as const. File size before: textdata bss dec hex filename 407 576 0 983 3d7

[PATCH] macintosh: rack-meter: make of_device_ids const.

of_device_ids are not supposed to change at runtime. All functions working with of_device_ids provided by work with const of_device_ids. So mark the non-const structs as const. File size before: textdata bss dec hex filename 407 576 0 983 3d7

Re: [PATCH 4/9] powerpc/64s: SLB miss handler avoid r3 save/restore

Nicholas Piggin writes: > diff --git a/arch/powerpc/kernel/exceptions-64s.S > b/arch/powerpc/kernel/exceptions-64s.S > index 486e205cc762..6ba4c4c6ae69 100644 > --- a/arch/powerpc/kernel/exceptions-64s.S > +++ b/arch/powerpc/kernel/exceptions-64s.S > @@ -625,6 +625,9 @@

[PATCH] powerpc/perf: Fix POWER9 branch event

From: Anton Blanchard The POWER9 branch event is wrong, and we always get a count of zero: ... 0 branches 3844 branch-misses #0.00% of all branches Replace it with the correct event. Fixes: d89f473ff6f8 ("powerpc/perf:

Re: [PATCH V5 2/2] powerpc/numa: Update CPU topology when VPHN enabled

Hi Michael, [auto build test ERROR on powerpc/next] [also build test ERROR on v4.12-rc5 next-20170616] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH] powerpc/perf: Add POWER9 alternate PM_RUN_CYC and PM_RUN_INST_CMPL events

From: Anton Blanchard Similar to POWER8, POWER9 can count run cycles and run instructions completed on more than one PMU. Signed-off-by: Anton Blanchard --- arch/powerpc/perf/power9-events-list.h | 4 arch/powerpc/perf/power9-pmu.c | 2 ++ 2

[PATCH V5 2/2] powerpc/numa: Update CPU topology when VPHN enabled

powerpc/numa: Correct the currently broken capability to set the topology for shared CPUs in LPARs. At boot time for shared CPU lpars, the topology for each shared CPU is set to node zero, however, this is now updated correctly using the Virtual Processor Home Node (VPHN) capabilities

[PATCH 1/2] powerpc/hotplug: Ensure enough nodes avail for operations

powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be defined and initialized at boot. In order

[PATCH V5 0/2] powerpc/dlpar: Correct display of hot-add/hot-remove CPUs and memory

On Power systems with shared configurations of CPUs and memory, there are some issues with association of additional CPUs and memory to nodes when hot-adding resources. These patches address some of those problems. powerpc/hotplug: On systems like PowerPC which allow 'hot-add' of CPU or memory

Re: [PATCH] of: update ePAPR references to point to Devicetree Specification

On Tue, Jun 13, 2017 at 07:49:04PM -0700, frowand.l...@gmail.com wrote: > From: Frank Rowand > > The Devicetree Specification has superseded the ePAPR as the > base specification for bindings. Update files in Documentation > to reference the new document. > > Some files

Re: [PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

On Sun, 2017-06-18 at 00:13 -0700, Christoph Hellwig wrote: > On Sun, Jun 18, 2017 at 06:50:27AM +1000, Benjamin Herrenschmidt wrote: > > What is your rationale here ? (I have missed patch 0 it seems). > > Less code duplication, more modular dma_map_ops insteance. > > > dma_supported() was

Re: [PATCH] powerpc64/hw_breakpoints: Handle data breakpoints in radix mode

On 2017/06/16 03:16PM, Michael Ellerman wrote: > "Naveen N. Rao" writes: > > > diff --git a/arch/powerpc/kernel/exceptions-64s.S > > b/arch/powerpc/kernel/exceptions-64s.S > > index ae418b85c17c..17ee701b8336 100644 > > --- a/arch/powerpc/kernel/exceptions-64s.S

Re: [PATCH 42/44] powerpc/cell: use the dma_supported method for ops switching

On Sun, Jun 18, 2017 at 06:50:27AM +1000, Benjamin Herrenschmidt wrote: > What is your rationale here ? (I have missed patch 0 it seems). Less code duplication, more modular dma_map_ops insteance. > dma_supported() was supposed to be pretty much a "const" function > simply informing whether a

Re: [PATCH 03/44] dmaengine: ioat: don't use DMA_ERROR_CODE

On Fri, Jun 16, 2017 at 01:40:24PM -0700, Alexander Duyck wrote: > dma_unmap_page on dest_dma if "op == IOAT_OP_XOR"? Odds are it is what > the compiler is already generating and will save a few lines of code > so what you end up with is something like: Honestly wanted to touch the code as little