* 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: [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: [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: [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: 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: [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/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: 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: [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: 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: [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: [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: 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: [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: [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: 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: [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/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: 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/64: optimises from64to32()
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Scott Wood
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180410063435.272F8653BC@po15720vm.idsi0.si.c-s.fr>
On Tue, 2018-04-10 at 06:34:35 UTC, Christophe Leroy wrote:
> The current implementation of from64to32() gives a poor result:
>
> 0000000000000270 <.from64to32>:
> 270: 38 00 ff ff li r0,-1
> 274: 78 69 00 22 rldicl r9,r3,32,32
> 278: 78 00 00 20 clrldi r0,r0,32
> 27c: 7c 60 00 38 and r0,r3,r0
> 280: 7c 09 02 14 add r0,r9,r0
> 284: 78 09 00 22 rldicl r9,r0,32,32
> 288: 7c 00 4a 14 add r0,r0,r9
> 28c: 78 03 00 20 clrldi r3,r0,32
> 290: 4e 80 00 20 blr
>
> This patch modifies from64to32() to operate in the same
> spirit as csum_fold()
>
> It swaps the two 32-bit halves of sum then it adds it with the
> unswapped sum. If there is a carry from adding the two 32-bit halves,
> it will carry from the lower half into the upper half, giving us the
> correct sum in the upper half.
>
> The resulting code is:
>
> 0000000000000260 <.from64to32>:
> 260: 78 60 00 02 rotldi r0,r3,32
> 264: 7c 60 1a 14 add r3,r0,r3
> 268: 78 63 00 22 rldicl r3,r3,32,32
> 26c: 4e 80 00 20 blr
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/55a0edf083022e402042255a0afb03
cheers
^ permalink raw reply
* Re: [1/5] powerpc/embedded6xx: Remove C2K board support
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Mark Greer, Benjamin Herrenschmidt, Paul Mackerras
Cc: Remi Machet, Dale Farnsworth, linuxppc-dev, linux-kernel,
Mark Greer
In-Reply-To: <20180406011720.7728-2-mgreer@animalcreek.com>
On Fri, 2018-04-06 at 01:17:16 UTC, Mark Greer wrote:
> The C2K platform appears to be orphaned so remove code supporting it.
>
> CC: Remi Machet <rmachet@nvidia.com>
> Signed-off-by: Mark Greer <mgreer@animalcreek.com>
> Acked-by: Remi Machet <remi@machet.us>
> Signed-off-by: Mark Greer <mgreer@animalcreek.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/92c8c16f345759e87c5d5b771d438f
cheers
^ permalink raw reply
* Re: hvc_opal: don't set tb_ticks_per_usec in udbg_init_opal_common()
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Stewart Smith, linuxppc-dev, benh; +Cc: Stewart Smith
In-Reply-To: <20180329060246.9970-1-stewart@linux.ibm.com>
On Thu, 2018-03-29 at 06:02:46 UTC, Stewart Smith wrote:
> time_init() will set up tb_ticks_per_usec based on reality.
> time_init() is called *after* udbg_init_opal_common() during boot.
>
> from arch/powerpc/kernel/time.c:
> unsigned long tb_ticks_per_usec = 100; /* sane default */
>
> Currently, all powernv systems have a timebase frequency of 512mhz
> (512000000/1000000 == 0x200) - although there's nothing written
> down anywhere that I can find saying that we couldn't make that
> different based on the requirements in the ISA.
>
> So, we've been (accidentally) thwacking the (currently) correct
> (for powernv at least) value for tb_ticks_per_usec earlier than
> we otherwise would have.
>
> The "sane default" seems to be adequate for our purposes between
> udbg_init_opal_common() and time_init() being called, and if it isn't,
> then we should probably be setting it somewhere that isn't hvc_opal.c!
>
> Signed-off-by: Stewart Smith <stewart@linux.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/447808bf500a7cc92173266a59f8a4
cheers
^ permalink raw reply
* Re: [1/4] powerpc/mm: constify FIRST_CONTEXT in mmu_context_nohash
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Scott Wood
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <03c175e506e88e57f48f01de9120768e1b942c6e.1521641042.git.christophe.leroy@c-s.fr>
On Wed, 2018-03-21 at 14:07:47 UTC, Christophe Leroy wrote:
> First context is now 1 for all supported platforms, so it
> can be made a constant.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8820a44738308a8a1644c6c3d04b47
cheers
^ permalink raw reply
* Re: powerpc/dma: remove unnecessary BUG()
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Scott Wood
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180228182145.AD1C76F114@po15720vm.idsi0.si.c-s.fr>
On Wed, 2018-02-28 at 18:21:45 UTC, Christophe Leroy wrote:
> Direction is already checked in all calling functions in
> include/linux/dma-mapping.h and also in called function __dma_sync()
>
> So really no need to check it once more here.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/9887334b804892f10262fa7f805998
cheers
^ permalink raw reply
* Re: SB600 for the Nemo board has non-zero devices on non-root bus
From: Michael Ellerman @ 2018-06-04 14:10 UTC (permalink / raw)
To: Christian Zigotzky, Olof Johansson, Bjorn Helgaas,
linux-pci@vger.kernel.org, Darren Stevens, Bjorn Helgaas,
linuxppc-dev
In-Reply-To: <99f78122-cd53-100f-4f58-be5bf7927d4e@xenosoft.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2311 bytes --]
On Wed, 2017-12-06 at 11:03:52 UTC, Christian Zigotzky wrote:
> On 06 December 2017 at 09:37AM, Christian Zigotzky wrote:
> > On 03 December 2017 at 10:43AM, Christian Zigotzky wrote:
> > >
> > > On 3. Dec 2017, at 00:02, Olof Johansson <olof@lixom.net> wrote:
> > >>
> > >> Typo, should be ';', not ':'. I obviously didn't even try
> compiling this. :)
> > >>
> > >>
> > >> -Olof
> > >
> > > Hi Olof,
> > >
> > > Thanks a lot for your patch! I will test it on Wednesday.
> > >
> > > Cheers,
> > > Christian
> >
> >
> > Hi Olof,
> >
> > I tested your patch today. Unfortunately the kernel 4.15-rc2 doesn't
> compile with your patch.
> >
> > Error messages:
> >
> > ^~~~~~~~~
> > arch/powerpc/platforms/pasemi/pci.c: In function ‘pas_pci_init’:
> > arch/powerpc/platforms/pasemi/pci.c:298:2: error: implicit
> declaration of function ‘pci_set_flag’
> [-Werror=implicit-function-declaration]
> > pci_set_flag(PCI_SCAN_ALL_PCIE_DEVS);
> > ^~~~~~~~~~~~
> > cc1: some warnings being treated as errors
> >
> > ---
> >
> > I figured out that we need 'pci_set_flags' instead of 'pci_set_flag'.
> I modified your patch and after that the kernel compiles. Please find
> attached the new patch.
> >
> > Cheers,
> > Christian
>
> Hi Olof,
>
> Many thanks for your patch! :-) The RC2 of kernel 4.15 boots without any
> problems on my P.A. Semi Nemo board (A-EON AmigaOne X1000). I don’t need
> the additional boot argument 'pci=pcie_scan_all' anymore.
>
> Is it possible to merge it via the powerpc tree?
>
> Thanks,
> Christian
>
> arch/powerpc/platforms/pasemi/pci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
> index 5ff6108..ea54ed2 100644
> --- a/arch/powerpc/platforms/pasemi/pci.c
> +++ b/arch/powerpc/platforms/pasemi/pci.c
> @@ -224,6 +224,8 @@ void __init pas_pci_init(void)
> return;
> }
>
> + pci_set_flags(PCI_SCAN_ALL_PCIE_DEVS);
> +
> for (np = NULL; (np = of_get_next_child(root, np)) != NULL;)
> if (np->name && !strcmp(np->name, "pxp") && !pas_add_bridge(np))
> of_node_get(np);
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/eff06ef0891d200eb0ddd156c6e96c
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