Re: [PATCH v2 1/2] powerpc/perf: init pmu from core-book3s

2019-04-28 Thread Christophe Leroy
Le 29/04/2019 à 04:52, Madhavan Srinivasan a écrit : Currenty pmu driver file for each ppc64 generation processor has a __init call in itself. Refactor the code by moving the __init call to core-books.c. This also clean's up compat mode pmu driver registration. Can you explain the advantage

Re: [PATCH v2 2/2] powerpc/perf: Add generic compat mode pmu driver

2019-04-28 Thread Christophe Leroy
Le 29/04/2019 à 04:52, Madhavan Srinivasan a écrit : Most of the power processor generation performance monitoring unit (PMU) driver code is bundled in the kernel and one of those is enabled/registered based on the oprofile_cpu_type check at the boot. But things get little tricky incase of

Re: [PATCHv2] kernel/crash: make parse_crashkernel()'s return value more indicant

2019-04-28 Thread Dave Young
On 04/29/19 at 12:48pm, Pingfan Liu wrote: > On Mon, Apr 29, 2019 at 11:04 AM Pingfan Liu wrote: > > > > On Sun, Apr 28, 2019 at 4:37 PM Dave Young wrote: > > > > > > On 04/25/19 at 04:20pm, Pingfan Liu wrote: > > > > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger > > > > wrote: > > > > > >

Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-04-28 Thread Daniel Axtens
Hi, >>> I'm thinking about whether we should lock down the powerpc xmon debug >>> monitor - intuitively, I think the answer is yes if for no other reason >>> than Least Astonishment, when lockdown is enabled you probably don't >>> expect xmon to keep letting you access kernel memory. >> >> The

Re: [PATCHv2] kernel/crash: make parse_crashkernel()'s return value more indicant

2019-04-28 Thread Pingfan Liu
On Mon, Apr 29, 2019 at 11:04 AM Pingfan Liu wrote: > > On Sun, Apr 28, 2019 at 4:37 PM Dave Young wrote: > > > > On 04/25/19 at 04:20pm, Pingfan Liu wrote: > > > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger > > > wrote: > > > > > > > > > > > [...] > > > > > @@ -139,6 +141,8 @@ static int

Re: [PATCHv2] kernel/crash: make parse_crashkernel()'s return value more indicant

2019-04-28 Thread Pingfan Liu
On Sun, Apr 28, 2019 at 4:37 PM Dave Young wrote: > > On 04/25/19 at 04:20pm, Pingfan Liu wrote: > > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote: > > > > > > > > [...] > > > > @@ -139,6 +141,8 @@ static int __init parse_crashkernel_simple(char > > > > *cmdline, > > > >

[PATCH v2 2/2] powerpc/perf: Add generic compat mode pmu driver

2019-04-28 Thread Madhavan Srinivasan
Most of the power processor generation performance monitoring unit (PMU) driver code is bundled in the kernel and one of those is enabled/registered based on the oprofile_cpu_type check at the boot. But things get little tricky incase of "compat" mode boot. IBM POWER System Server based

[PATCH v2 1/2] powerpc/perf: init pmu from core-book3s

2019-04-28 Thread Madhavan Srinivasan
Currenty pmu driver file for each ppc64 generation processor has a __init call in itself. Refactor the code by moving the __init call to core-books.c. This also clean's up compat mode pmu driver registration. Suggested-by: Michael Ellerman Signed-off-by: Madhavan Srinivasan --- Changelog v1: -

Re: [PATCH v8 05/20] KVM: PPC: Book3S HV: Remove pmd_is_leaf()

2019-04-28 Thread Paul Mackerras
On Wed, Apr 03, 2019 at 03:16:12PM +0100, Steven Price wrote: > Since pmd_large() is now always available, pmd_is_leaf() is redundant. > Replace all uses with calls to pmd_large(). NAK. I don't want to do this, because pmd_is_leaf() is purely about the guest page tables (the "partition-scoped"

Re: [PATCH V32 01/27] Add the ability to lock down access to the running kernel image

2019-04-28 Thread Daniel Axtens
Matthew Garrett writes: > On Tue, Apr 16, 2019 at 1:40 AM Andrew Donnellan > wrote: >> I'm thinking about whether we should lock down the powerpc xmon debug >> monitor - intuitively, I think the answer is yes if for no other reason >> than Least Astonishment, when lockdown is enabled you

Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.1-6 tag

2019-04-28 Thread pr-tracker-bot
The pull request you sent on Sun, 28 Apr 2019 16:55:57 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-5.1-6 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0d82044e1b7e5497c2177abd39b31e9ba27be8b7 Thank you! --

Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range

2019-04-28 Thread Andy Shevchenko
On Sat, Apr 27, 2019 at 02:52:21PM +0200, Enrico Weigelt, metux IT consult wrote: > Introduce a little helpers for settings the mmio range from an > struct resource or start/len parameters with less code. > (also setting iotype to UPIO_MEM) > > Also converting drivers to use these new helpers as

Re: [PATCH 37/41] drivers: tty: serial: 8250: simplify io resource size computation

2019-04-28 Thread Andy Shevchenko
On Sat, Apr 27, 2019 at 02:52:18PM +0200, Enrico Weigelt, metux IT consult wrote: > Simpily io resource size computation by setting mapsize field. > > Some of the special cases handled by serial8250_port_size() can be > simplified by putting this data to corresponding platform data > or probe

Re: [PATCH 36/41] drivers: tty: serial: 8250: store mmio resource size in port struct

2019-04-28 Thread Andy Shevchenko
On Sat, Apr 27, 2019 at 02:52:17PM +0200, Enrico Weigelt, metux IT consult wrote: > The io resource size is currently recomputed when it's needed but this > actually needs to be done once (or drivers could specify fixed values) io -> IO > > Simplify that by doing this computation only once and

[PATCH v10 1/2] powerpc/64s: reimplement book3s idle code in C

2019-04-28 Thread Nicholas Piggin
Reimplement Book3S idle code in C, moving POWER7/8/9 implementation speific HV idle code to the powernv platform code. Book3S assembly stubs are kept in common code and used only to save the stack frame and non-volatile GPRs before executing architected idle instructions, and restoring the stack

[PATCH v10 2/2] powerpc/64s: KVM update for reimplement book3s idle code in C

2019-04-28 Thread Nicholas Piggin
This is the KVM update to the new idle code. A few improvements: - Idle sleepers now always return to caller rather than branch out to KVM first. - This allows optimisations like very fast return to caller when no state has been lost. - KVM no longer requires nap_state_lost because it

[PATCH v10 0/2] powerpc/64s: reimplement book3s idle code in C

2019-04-28 Thread Nicholas Piggin
The KVM code is in better shape now, survives various testing I came up with, so should be ready for more review. I won't post it again with the KVM part split out unless significant changes are required there. As explained in the comments for patch 1, the split results in some intermediate KVM

Re: [PATCHv2] kernel/crash: make parse_crashkernel()'s return value more indicant

2019-04-28 Thread Dave Young
On 04/25/19 at 04:20pm, Pingfan Liu wrote: > On Wed, Apr 24, 2019 at 4:31 PM Matthias Brugger wrote: > > > > > [...] > > > @@ -139,6 +141,8 @@ static int __init parse_crashkernel_simple(char > > > *cmdline, > > > pr_warn("crashkernel: unrecognized char: %c\n", *cur); > > >

[GIT PULL] Please pull powerpc/linux.git powerpc-5.1-6 tag

2019-04-28 Thread Michael Ellerman
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Linus, Please pull some more powerpc fixes for 5.1. I was 50/50 on whether these were worthy of sending at rc6, but decided I would send them as they're in obscure areas of the code and they do fix user-visible bugs. cheers The following

Re: [PATCH stable v4.4 00/52] powerpc spectre backports for 4.4

2019-04-28 Thread Michael Ellerman
Diana Madalina Craciun writes: > Hi Michael, > > There are some missing NXP Spectre v2 patches. I can send them > separately if the series will be accepted. I have merged them, but I did > not test them, I was sick today and incapable of doing that. No worries, there's no rush :) Sorry I missed

Re: [PATCH stable v4.4 00/52] powerpc spectre backports for 4.4

2019-04-28 Thread Michael Ellerman
Greg KH writes: > On Mon, Apr 22, 2019 at 12:19:45AM +1000, Michael Ellerman wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi Greg/Sasha, >> >> Please queue up these powerpc patches for 4.4 if you have no objections. > > why? Do you, or someone else, really care about