* Re: powerpc/misc: merge reloc_offset() and add_reloc_offset()
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180417112310.BD2686C07F@po15720vm.idsi0.si.c-s.fr>
On Tue, 2018-04-17 at 11:23:10 UTC, Christophe Leroy wrote:
> reloc_offset() is the same as add_reloc_offset(0)
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/0cc377d16e565b90b43b7550cdf5b3
cheers
^ permalink raw reply
* Re: powerpc/boot: remove unused variable in mpc8xx
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180417123646.066056C09D@po15720vm.idsi0.si.c-s.fr>
On Tue, 2018-04-17 at 12:36:45 UTC, Christophe Leroy wrote:
> Variable div is set but never used. Remove it.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/169f438a7e369226a452e0ac4a54db
cheers
^ permalink raw reply
* Re: [1/5] powerpc: always enable RTC_LIB
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: arnd, y2038, linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <20180423083642.2608886-1-arnd@arndb.de>
On Mon, 2018-04-23 at 08:36:38 UTC, Arnd Bergmann wrote:
> In order to use the rtc_tm_to_time64() and rtc_time64_to_tm()
> helper functions in later patches, we have to ensure that
> CONFIG_RTC_LIB is always built-in.
>
> Note that this symbol only controls a couple of helper functions,
> not the actual RTC subsystem, which remains optional and is
> enabled with CONFIG_RTC_CLASS.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6e8cef384a41882b2d4ec6992dd0d7
cheers
^ permalink raw reply
* Re: powerpc/8xx: Remove RTC clock on 88x
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Vitaly Bordug
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180417124735.8991D6C0AC@po15720vm.idsi0.si.c-s.fr>
On Tue, 2018-04-17 at 12:47:35 UTC, Christophe Leroy wrote:
> The 885 familly processors don't have the Real Time Clock
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d04f11d2713e736a3740361f8b5bb4
cheers
^ permalink raw reply
* Re: [v2] powerpc/signal32: Use fault_in_pages_readable() to prefault user context
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: Mathieu Malaterre, linuxppc-dev, linux-kernel
In-Reply-To: <20180424160425.DB9946C5A7@po15720vm.idsi0.si.c-s.fr>
On Tue, 2018-04-24 at 16:04:25 UTC, Christophe Leroy wrote:
> Use fault_in_pages_readable() to prefault user context
> instead of open coding
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Mathieu Malaterre <malat@debian.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/56b04d568f880a48d892e840cfaf4e
cheers
^ permalink raw reply
* Re: [1/6] powerpc/64s: Add barrier_nospec
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: msuchanek, linux-kernel, npiggin
In-Reply-To: <20180424041559.32410-1-mpe@ellerman.id.au>
On Tue, 2018-04-24 at 04:15:54 UTC, Michael Ellerman wrote:
> From: Michal Suchanek <msuchanek@suse.de>
>
> A no-op form of ori (or immediate of 0 into r31 and the result stored
> in r31) has been re-tasked as a speculation barrier. The instruction
> only acts as a barrier on newer machines with appropriate firmware
> support. On older CPUs it remains a harmless no-op.
>
> Implement barrier_nospec using this instruction.
>
> mpe: The semantics of the instruction are believed to be that it
> prevents execution of subsequent instructions until preceding branches
> have been fully resolved and are no longer executing speculatively.
> There is no further documentation available at this time.
>
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/a6b3964ad71a61bb7c61d80a60bea7
cheers
^ permalink raw reply
* Re: powerpc/xics: add missing of_node_put() in error path
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: YueHaibing, benh, paulus, geoff, joe
Cc: YueHaibing, linuxppc-dev, linux-kernel
In-Reply-To: <20180425112707.16392-1-yuehaibing@huawei.com>
On Wed, 2018-04-25 at 11:27:07 UTC, YueHaibing wrote:
> The device node obtained with of_find_compatible_node() should be
> released by calling of_node_put(). But it was not released when
> of_get_property() failed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/589b1f7e4b0db4c31cef3b55f75148
cheers
^ permalink raw reply
* Re: [01/11] powerpc/64: irq_work avoid interrupt when called with hardware irqs enabled
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180504171935.25410-2-npiggin@gmail.com>
On Fri, 2018-05-04 at 17:19:25 UTC, Nicholas Piggin wrote:
> irq_work_raise should not cause a decrementer exception unless it is
> called from NMI context. Doing so often just results in an immediate
> masked decrementer interrupt:
>
> <...>-550 90d... 4us : update_curr_rt <-dequeue_task_rt
> <...>-550 90d... 5us : dbs_update_util_handler <-update_curr_rt
> <...>-550 90d... 6us : arch_irq_work_raise <-irq_work_queue
> <...>-550 90d... 7us : soft_nmi_interrupt <-soft_nmi_common
> <...>-550 90d... 7us : printk_nmi_enter <-soft_nmi_interrupt
> <...>-550 90d.Z. 8us : rcu_nmi_enter <-soft_nmi_interrupt
> <...>-550 90d.Z. 9us : rcu_nmi_exit <-soft_nmi_interrupt
> <...>-550 90d... 9us : printk_nmi_exit <-soft_nmi_interrupt
> <...>-550 90d... 10us : cpuacct_charge <-update_curr_rt
>
> The soft_nmi_interrupt here is the call into the watchdog, due to the
> decrementer interrupt firing with irqs soft-disabled. This is
> harmless, but sub-optimal.
>
> When it's not called from NMI context or with interrupts enabled, mark
> the decrementer pending in the irq_happened mask directly, rather than
> having the masked decrementer interupt handler do it. This will be
> replayed at the next local_irq_enable. See the comment for details.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ebb37cf3ffd39fdb6ec5b07111f8bb
cheers
^ permalink raw reply
* Re: [RFC, 1/4] powerpc/64: Save stack pointer when we hard disable interrupts
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: npiggin
In-Reply-To: <20180502130729.24077-1-mpe@ellerman.id.au>
On Wed, 2018-05-02 at 13:07:26 UTC, Michael Ellerman wrote:
> A CPU that gets stuck with interrupts hard disable can be difficult to
> debug, as on some platforms we have no way to interrupt the CPU to
> find out what it's doing.
>
> A stop-gap is to have the CPU save it's stack pointer (r1) in its paca
> when it hard disables interrupts. That way if we can't interrupt it,
> we can at least trace the stack based on where it last disabled
> interrupts.
>
> In some cases that will be total junk, but the stack trace code should
> handle that. In the simple case of a CPU that disable interrupts and
> then gets stuck in a loop, the stack trace should be informative.
>
> We could clear the saved stack pointer when we enable interrupts, but
> that loses information which could be useful if we have nothing else
> to go on.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/7b08729cb272b4cd5c657cd5ac0ddd
cheers
^ permalink raw reply
* Re: powerpc: cpm_gpio: Remove owner assignment from platform_driver
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Fabio Estevam; +Cc: Fabio Estevam, paulus, linuxppc-dev
In-Reply-To: <1525489285-23411-1-git-send-email-festevam@gmail.com>
On Sat, 2018-05-05 at 03:01:25 UTC, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Structure platform_driver does not need to set the owner field, as this
> will be populated by the driver core.
>
> Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c5cbde2df3951c59dc099dd2e452b5
cheers
^ permalink raw reply
* Re: [1/2] powerpc/pmu/fsl: fix is_nmi test for irq mask change
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Madhavan Srinivasan, Nicholas Piggin
In-Reply-To: <20180510010424.16854-1-npiggin@gmail.com>
On Thu, 2018-05-10 at 01:04:23 UTC, Nicholas Piggin wrote:
> When soft enabled was changed to irq disabled mask, this test missed
> being converted (although the equivalent book3s test was converted).
>
> The PMU drivers consider it an NMI when they take a PMI while general
> interrupts are disabled. This change restores that behaviour.
>
> Fixes: 01417c6cc7 ("powerpc/64: Change soft_enabled from flag to bitmask")
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/81ea11d3af3aba0bea475dd1dd2f79
cheers
^ permalink raw reply
* Re: powerpc/powernv: call OPAL_QUIESCE before OPAL_SIGNAL_SYSTEM_RESET
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180510122148.3996-1-npiggin@gmail.com>
On Thu, 2018-05-10 at 12:21:48 UTC, Nicholas Piggin wrote:
> Although it is often possible to recover a CPU that was interrupted
> from OPAL with a system reset NMI, it's undesirable to interrupt them
> for a few reasons. Firstly because dump/debug code itself needs to
> call firmware, so it could hang on a lock or possibly corrupt a
> per-cpu data structure if it or another CPU was interrupted from
> OPAL. Secondly, the kexec crash dump code will not return from
> interrupt to unwind the OPAL call.
>
> Call OPAL_QUIESCE with QUIESCE_HOLD before sending an NMI IPI to
> another CPU, which wait for it to leave firmware (or time out) to
> avoid this problem in normal conditions. Firmware bugs may still
> result in a timeout and interrupting OPAL, but that is the best
> option (stops the CPU, and possibly allows firmware to be debugged).
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ee03b9b4479d1302d01cebedda3518
cheers
^ permalink raw reply
* Re: powerpc/powernv: process all OPAL event interrupts with kopald
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Alistair Popple, Nicholas Piggin
In-Reply-To: <20180510172005.27160-1-npiggin@gmail.com>
On Thu, 2018-05-10 at 17:20:05 UTC, Nicholas Piggin wrote:
> Using irq_work for processing OPAL event interrupts is not necessary.
> irq_work is typically used to schedule work from NMI context, a
> softirq may be more appropriate. However OPAL events are not
> particularly performance or latency critical, so they can all be
> invoked by kopald.
>
> This patch removes the irq_work queueing, and instead wakes up
> kopald when there is an event to be processed. kopald processes
> interrupts individually, enabling irqs and calling cond_resched
> between each one to minimise latencies.
>
> Event handlers themselves should still use threaded handlers,
> workqueues, etc. as necessary to avoid high interrupts-off latencies
> within any single interrupt.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/56c0b48b1e443efa5d6f4d60513302
cheers
^ permalink raw reply
* Re: [v5,1/7] powerpc: Add TIDR CPU feature for POWER9
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Alastair D'Silva, linuxppc-dev
Cc: mikey, arnd, linux-doc, malat, gregkh, corbet, vaibhav, npiggin,
linux-kernel, fbarrat, aneesh.kumar, andrew.donnellan,
pombredanne, felix, sukadev, Alastair D'Silva
In-Reply-To: <20180511061303.10728-2-alastair@au1.ibm.com>
On Fri, 2018-05-11 at 06:12:57 UTC, "Alastair D'Silva" wrote:
> From: Alastair D'Silva <alastair@d-silva.org>
>
> This patch adds a CPU feature bit to show whether the CPU has
> the TIDR register available, enabling as_notify/wait in userspace.
>
> Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
> Reviewed-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/819844285ef2b5d15466f5b5062514
cheers
^ permalink raw reply
* Re: powerpc/xive: Remove (almost) unused macros
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Russell Currey, linuxppc-dev
In-Reply-To: <20180511080313.29815-1-ruscur@russell.cc>
On Fri, 2018-05-11 at 08:03:13 UTC, Russell Currey wrote:
> The GETFIELD and SETFIELD macros in xive-regs.h aren't used except for a
> single instance of GETFIELD, so replace that and remove them.
>
> These macros are also defined in vas.h, so either those should be
> eventually replaced or the macros moved into bitops.h.
>
> Signed-off-by: Russell Currey <ruscur@russell.cc>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8a792262f320245de0174e6bcb5513
cheers
^ permalink raw reply
* Re: [1/2] powerpc: Rename thread_struct.fs to addr_limit
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: thgarnie, keescook, kernel-hardening
In-Reply-To: <20180514130316.23855-1-mpe@ellerman.id.au>
On Mon, 2018-05-14 at 13:03:15 UTC, Michael Ellerman wrote:
> It's called 'fs' for historical reasons, it's named after the x86 'FS'
> register. But we don't have to use that name for the member of
> thread_struct, and in fact arch/x86 doesn't even call it 'fs' anymore.
>
> So rename it to 'addr_limit', which better reflects what it's used
> for, and is also the name used on other arches.
>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Series applied to powerpc next.
https://git.kernel.org/powerpc/c/ba0635fcbe8c1ce83523c1ec797538
cheers
^ permalink raw reply
* Re: [v2] powerpc/lib: Adjust .balign inside string functions for PPC32
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180518130116.A1A3B6F937@po14934vm.idsi0.si.c-s.fr>
On Fri, 2018-05-18 at 13:01:16 UTC, Christophe Leroy wrote:
> commit 87a156fb18fe1 ("Align hot loops of some string functions")
> degraded the performance of string functions by adding useless
> nops
>
> A simple benchmark on an 8xx calling 100000x a memchr() that
> matches the first byte runs in 41668 TB ticks before this patch
> and in 35986 TB ticks after this patch. So this gives an
> improvement of approx 10%
>
> Another benchmark doing the same with a memchr() matching the 128th
> byte runs in 1011365 TB ticks before this patch and 1005682 TB ticks
> after this patch, so regardless on the number of loops, removing
> those useless nops improves the test by 5683 TB ticks.
>
> Fixes: 87a156fb18fe1 ("Align hot loops of some string functions")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1128bb7813a896bd608fb622eee3c2
cheers
^ permalink raw reply
* Re: [v2,1/4] powerpc/perf: Rearrange memory freeing in imc init
From: Michael Ellerman @ 2018-06-04 14:11 UTC (permalink / raw)
To: Anju T Sudhakar; +Cc: maddy, linuxppc-dev, anju
In-Reply-To: <1526980357-25385-2-git-send-email-anju@linux.vnet.ibm.com>
On Tue, 2018-05-22 at 09:12:34 UTC, Anju T Sudhakar wrote:
> When any of the IMC (In-Memory Collection counter) devices fail
> to initialize, imc_common_mem_free() frees set of memory. In doing so,
> pmu_ptr pointer is also freed. But pmu_ptr pointer is used in subsequent
> function (imc_common_cpuhp_mem_free()) which is wrong. Patch here reorders
> the code to avoid such access.
>
> Also free the memory which is dynamically allocated during imc
> initialization, wherever required.
>
> Signed-off-by: Anju T Sudhakar <anju@linux.vnet.ibm.com>
> Reviewed-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cb094fa5af7c9623084aa4c3cf529b
cheers
^ permalink raw reply
* Re: [1/3] powerpc/sstep: Introduce GETTYPE macro
From: Michael Ellerman @ 2018-06-04 14:11 UTC (permalink / raw)
To: Ravi Bangoria, mikey
Cc: sandipan, Ravi Bangoria, linux-kernel, matthew.brown.dev, paulus,
anton, naveen.n.rao, linuxppc-dev, cyrilbur
In-Reply-To: <20180521042108.8318-2-ravi.bangoria@linux.ibm.com>
On Mon, 2018-05-21 at 04:21:06 UTC, Ravi Bangoria wrote:
> Replace 'op->type & INSTR_TYPE_MASK' expression with GETTYPE(op->type)
> macro.
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e6684d07e4308430b9b6497265781a
cheers
^ permalink raw reply
* Re: powerpc/32: Optimise __csum_partial()
From: Michael Ellerman @ 2018-06-04 14:11 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, segher
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <484bcfaccc1ec3d91b74aeaaa26a0ae66fe0955a.1527160868.git.christophe.leroy@c-s.fr>
On Thu, 2018-05-24 at 11:22:27 UTC, Christophe Leroy wrote:
> Improve __csum_partial by interleaving loads and adds.
>
> On a 8xx, it brings neither improvement nor degradation.
> On a 83xx, it brings a 25% improvement.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/373e098e1e788d7b89ec0f31765a6c
cheers
^ permalink raw reply
* Re: [v2, 01/13] powerpc/eeh: Add eeh_max_freezes to initial EEH log line
From: Michael Ellerman @ 2018-06-04 14:11 UTC (permalink / raw)
To: Sam Bobroff, linuxppc-dev
In-Reply-To: <ac861431c98e0c259fec18a0d220994ad6b362ae.1527217866.git.sbobroff@linux.ibm.com>
On Fri, 2018-05-25 at 03:11:28 UTC, Sam Bobroff wrote:
> The current failure message includes the number of failures that have
> occurred in the last hour (for a device) but it does not indicate
> how many failures will be tolerated before the device is permanently
> disabled.
>
> Include the limit (eeh_max_freezes) to make this less surprising when
> it happens.
>
> Also remove the embedded newline from the existing message to make it
> easier to grep for.
>
> Signed-off-by: Sam Bobroff <sbobroff@linux.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/796b9f5b317a46d1b744f661c38a62
cheers
^ permalink raw reply
* Re: [v4] powerpc: Implement csum_ipv6_magic in assembly
From: Michael Ellerman @ 2018-06-04 14:11 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras, segher
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <7a756b816161007903ca8b28aec662de27135c55.1527161282.git.christophe.leroy@c-s.fr>
On Thu, 2018-05-24 at 11:33:18 UTC, Christophe Leroy wrote:
> The generic csum_ipv6_magic() generates a pretty bad result
>
> 00000000 <csum_ipv6_magic>: (PPC32)
> 0: 81 23 00 00 lwz r9,0(r3)
> 4: 81 03 00 04 lwz r8,4(r3)
> 8: 7c e7 4a 14 add r7,r7,r9
> c: 7d 29 38 10 subfc r9,r9,r7
> 10: 7d 4a 51 10 subfe r10,r10,r10
> 14: 7d 27 42 14 add r9,r7,r8
> 18: 7d 2a 48 50 subf r9,r10,r9
> 1c: 80 e3 00 08 lwz r7,8(r3)
> 20: 7d 08 48 10 subfc r8,r8,r9
> 24: 7d 4a 51 10 subfe r10,r10,r10
> 28: 7d 29 3a 14 add r9,r9,r7
> 2c: 81 03 00 0c lwz r8,12(r3)
> 30: 7d 2a 48 50 subf r9,r10,r9
> 34: 7c e7 48 10 subfc r7,r7,r9
> 38: 7d 4a 51 10 subfe r10,r10,r10
> 3c: 7d 29 42 14 add r9,r9,r8
> 40: 7d 2a 48 50 subf r9,r10,r9
> 44: 80 e4 00 00 lwz r7,0(r4)
> 48: 7d 08 48 10 subfc r8,r8,r9
> 4c: 7d 4a 51 10 subfe r10,r10,r10
> 50: 7d 29 3a 14 add r9,r9,r7
> 54: 7d 2a 48 50 subf r9,r10,r9
> 58: 81 04 00 04 lwz r8,4(r4)
> 5c: 7c e7 48 10 subfc r7,r7,r9
> 60: 7d 4a 51 10 subfe r10,r10,r10
> 64: 7d 29 42 14 add r9,r9,r8
> 68: 7d 2a 48 50 subf r9,r10,r9
> 6c: 80 e4 00 08 lwz r7,8(r4)
> 70: 7d 08 48 10 subfc r8,r8,r9
> 74: 7d 4a 51 10 subfe r10,r10,r10
> 78: 7d 29 3a 14 add r9,r9,r7
> 7c: 7d 2a 48 50 subf r9,r10,r9
> 80: 81 04 00 0c lwz r8,12(r4)
> 84: 7c e7 48 10 subfc r7,r7,r9
> 88: 7d 4a 51 10 subfe r10,r10,r10
> 8c: 7d 29 42 14 add r9,r9,r8
> 90: 7d 2a 48 50 subf r9,r10,r9
> 94: 7d 08 48 10 subfc r8,r8,r9
> 98: 7d 4a 51 10 subfe r10,r10,r10
> 9c: 7d 29 2a 14 add r9,r9,r5
> a0: 7d 2a 48 50 subf r9,r10,r9
> a4: 7c a5 48 10 subfc r5,r5,r9
> a8: 7c 63 19 10 subfe r3,r3,r3
> ac: 7d 29 32 14 add r9,r9,r6
> b0: 7d 23 48 50 subf r9,r3,r9
> b4: 7c c6 48 10 subfc r6,r6,r9
> b8: 7c 63 19 10 subfe r3,r3,r3
> bc: 7c 63 48 50 subf r3,r3,r9
> c0: 54 6a 80 3e rotlwi r10,r3,16
> c4: 7c 63 52 14 add r3,r3,r10
> c8: 7c 63 18 f8 not r3,r3
> cc: 54 63 84 3e rlwinm r3,r3,16,16,31
> d0: 4e 80 00 20 blr
>
> 0000000000000000 <.csum_ipv6_magic>: (PPC64)
> 0: 81 23 00 00 lwz r9,0(r3)
> 4: 80 03 00 04 lwz r0,4(r3)
> 8: 81 63 00 08 lwz r11,8(r3)
> c: 7c e7 4a 14 add r7,r7,r9
> 10: 7f 89 38 40 cmplw cr7,r9,r7
> 14: 7d 47 02 14 add r10,r7,r0
> 18: 7d 30 10 26 mfocrf r9,1
> 1c: 55 29 f7 fe rlwinm r9,r9,30,31,31
> 20: 7d 4a 4a 14 add r10,r10,r9
> 24: 7f 80 50 40 cmplw cr7,r0,r10
> 28: 7d 2a 5a 14 add r9,r10,r11
> 2c: 80 03 00 0c lwz r0,12(r3)
> 30: 81 44 00 00 lwz r10,0(r4)
> 34: 7d 10 10 26 mfocrf r8,1
> 38: 55 08 f7 fe rlwinm r8,r8,30,31,31
> 3c: 7d 29 42 14 add r9,r9,r8
> 40: 81 04 00 04 lwz r8,4(r4)
> 44: 7f 8b 48 40 cmplw cr7,r11,r9
> 48: 7d 29 02 14 add r9,r9,r0
> 4c: 7d 70 10 26 mfocrf r11,1
> 50: 55 6b f7 fe rlwinm r11,r11,30,31,31
> 54: 7d 29 5a 14 add r9,r9,r11
> 58: 7f 80 48 40 cmplw cr7,r0,r9
> 5c: 7d 29 52 14 add r9,r9,r10
> 60: 7c 10 10 26 mfocrf r0,1
> 64: 54 00 f7 fe rlwinm r0,r0,30,31,31
> 68: 7d 69 02 14 add r11,r9,r0
> 6c: 7f 8a 58 40 cmplw cr7,r10,r11
> 70: 7c 0b 42 14 add r0,r11,r8
> 74: 81 44 00 08 lwz r10,8(r4)
> 78: 7c f0 10 26 mfocrf r7,1
> 7c: 54 e7 f7 fe rlwinm r7,r7,30,31,31
> 80: 7c 00 3a 14 add r0,r0,r7
> 84: 7f 88 00 40 cmplw cr7,r8,r0
> 88: 7d 20 52 14 add r9,r0,r10
> 8c: 80 04 00 0c lwz r0,12(r4)
> 90: 7d 70 10 26 mfocrf r11,1
> 94: 55 6b f7 fe rlwinm r11,r11,30,31,31
> 98: 7d 29 5a 14 add r9,r9,r11
> 9c: 7f 8a 48 40 cmplw cr7,r10,r9
> a0: 7d 29 02 14 add r9,r9,r0
> a4: 7d 70 10 26 mfocrf r11,1
> a8: 55 6b f7 fe rlwinm r11,r11,30,31,31
> ac: 7d 29 5a 14 add r9,r9,r11
> b0: 7f 80 48 40 cmplw cr7,r0,r9
> b4: 7d 29 2a 14 add r9,r9,r5
> b8: 7c 10 10 26 mfocrf r0,1
> bc: 54 00 f7 fe rlwinm r0,r0,30,31,31
> c0: 7d 29 02 14 add r9,r9,r0
> c4: 7f 85 48 40 cmplw cr7,r5,r9
> c8: 7c 09 32 14 add r0,r9,r6
> cc: 7d 50 10 26 mfocrf r10,1
> d0: 55 4a f7 fe rlwinm r10,r10,30,31,31
> d4: 7c 00 52 14 add r0,r0,r10
> d8: 7f 80 30 40 cmplw cr7,r0,r6
> dc: 7d 30 10 26 mfocrf r9,1
> e0: 55 29 ef fe rlwinm r9,r9,29,31,31
> e4: 7c 09 02 14 add r0,r9,r0
> e8: 54 03 80 3e rotlwi r3,r0,16
> ec: 7c 03 02 14 add r0,r3,r0
> f0: 7c 03 00 f8 not r3,r0
> f4: 78 63 84 22 rldicl r3,r3,48,48
> f8: 4e 80 00 20 blr
>
> This patch implements it in assembly for both PPC32 and PPC64
>
> Link: https://github.com/linuxppc/linux/issues/9
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/e9c4943a107b56696e4872cdffdba6
cheers
^ permalink raw reply
* Re: powerpc/Makefile: set -mcpu=860 flag for the 8xx
From: Michael Ellerman @ 2018-06-04 14:11 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180528060834.72DE86F377@po14934vm.idsi0.si.c-s.fr>
On Mon, 2018-05-28 at 06:08:34 UTC, Christophe Leroy wrote:
> When compiled with GCC 8.1, vmlinux is significantly bigger than
> with GCC 4.8.
>
> When looking at the generated code with objdump, we notice that
> all functions and loops when a 16 bytes alignment. This significantly
> increases the size of the kernel. It is pointless and even
> counterproductive as on the 8xx 'nop' also consumes one clock cycle.
>
> Size of vmlinux with GCC 4.8:
> text data bss dec hex filename
> 5801948 1626076 457796 7885820 7853fc vmlinux
>
> Size of vmlinux with GCC 8.1:
> text data bss dec hex filename
> 6764592 1630652 456476 8851720 871108 vmlinux
>
> Size of vmlinux with GCC 8.1 and this patch:
> text data bss dec hex filename
> 6331544 1631756 456476 8419776 8079c0 vmlinux
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/1c38976334c0efce1b285369a6037f
cheers
^ permalink raw reply
* Re: [v2] selftests/powerpc: Add perf breakpoint test
From: Michael Ellerman @ 2018-06-04 14:11 UTC (permalink / raw)
To: Michael Neuling; +Cc: mikey, linuxppc-dev
In-Reply-To: <20180528232238.22495-1-mikey@neuling.org>
On Mon, 2018-05-28 at 23:22:38 UTC, Michael Neuling wrote:
> This tests perf hardware breakpoints (ie PERF_TYPE_BREAKPOINT) on
> powerpc.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9c2d72d497a32788bf90f05610319a
cheers
^ permalink raw reply
* Re: [v2] powerpc/64: Fix build failure with GCC 8.1
From: Michael Ellerman @ 2018-06-04 14:11 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <f5f2de3e1a39613f7303bfdc0d2f2210d4c91910.1527573345.git.christophe.leroy@c-s.fr>
On Tue, 2018-05-29 at 06:03:53 UTC, Christophe Leroy wrote:
> CC arch/powerpc/kernel/nvram_64.o
> arch/powerpc/kernel/nvram_64.c: In function 'nvram_create_partition':
> arch/powerpc/kernel/nvram_64.c:1042:2: error: 'strncpy' specified bound 12 equals destination size [-Werror=stringop-truncation]
> strncpy(new_part->header.name, name, 12);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> CC arch/powerpc/kernel/trace/ftrace.o
> In function 'make_field',
> inlined from 'ps3_repository_read_boot_dat_address' at arch/powerpc/platforms/ps3/repository.c:900:9:
> arch/powerpc/platforms/ps3/repository.c:106:2: error: 'strncpy' output truncated before terminating nul copying 8 bytes from a string of the same length [-Werror=stringop-truncation]
> strncpy((char *)&n, text, 8);
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c95998811807d897ca112ea62d6671
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox