* Re: [PATCH v10 4/6] powerpc/papr_scm: Improve error logging and handling papr_scm_ndctl()
From: Vaibhav Jain @ 2020-06-06 11:21 UTC (permalink / raw)
To: Dan Williams, Ira Weiny
Cc: Santosh Sivaraj, linux-nvdimm, Aneesh Kumar K . V,
Linux Kernel Mailing List, Steven Rostedt, Oliver O'Halloran,
linuxppc-dev
In-Reply-To: <CAPcyv4g2x7LV3ARRj-RBS1K84WNayr9oDcupzPQ1gtK1A_e+aQ@mail.gmail.com>
Hi Ira and Dan,
Thanks for reviewing this patch. Have updated the patch based on your
feedback to upadate cmd_rc only when the nd_cmd was handled and return
'0' in that case.
Other errors in case the nd_cmd was unrecognized or invalid result in
error returned from this functions as you suggested.
~ Vaibhav
Dan Williams <dan.j.williams@intel.com> writes:
> On Fri, Jun 5, 2020 at 10:13 AM Ira Weiny <ira.weiny@intel.com> wrote:
>>
>> On Fri, Jun 05, 2020 at 05:11:34AM +0530, Vaibhav Jain wrote:
>> > Since papr_scm_ndctl() can be called from outside papr_scm, its
>> > exposed to the possibility of receiving NULL as value of 'cmd_rc'
>> > argument. This patch updates papr_scm_ndctl() to protect against such
>> > possibility by assigning it pointer to a local variable in case cmd_rc
>> > == NULL.
>> >
>> > Finally the patch also updates the 'default' clause of the switch-case
>> > block removing a 'return' statement thereby ensuring that value of
>> > 'cmd_rc' is always logged when papr_scm_ndctl() returns.
>> >
>> > Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
>> > Cc: Dan Williams <dan.j.williams@intel.com>
>> > Cc: Michael Ellerman <mpe@ellerman.id.au>
>> > Cc: Ira Weiny <ira.weiny@intel.com>
>> > Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
>> > ---
>> > Changelog:
>> >
>> > v9..v10
>> > * New patch in the series
>>
>> Thanks for making this a separate patch it is easier to see what is going on
>> here.
>>
>> > ---
>> > arch/powerpc/platforms/pseries/papr_scm.c | 10 ++++++++--
>> > 1 file changed, 8 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
>> > index 0c091622b15e..6512fe6a2874 100644
>> > --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> > +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> > @@ -355,11 +355,16 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
>> > {
>> > struct nd_cmd_get_config_size *get_size_hdr;
>> > struct papr_scm_priv *p;
>> > + int rc;
>> >
>> > /* Only dimm-specific calls are supported atm */
>> > if (!nvdimm)
>> > return -EINVAL;
>> >
>> > + /* Use a local variable in case cmd_rc pointer is NULL */
>> > + if (!cmd_rc)
>> > + cmd_rc = &rc;
>> > +
>>
>> This protects you from the NULL. However...
>>
>> > p = nvdimm_provider_data(nvdimm);
>> >
>> > switch (cmd) {
>> > @@ -381,12 +386,13 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
>> > break;
>> >
>> > default:
>> > - return -EINVAL;
>> > + dev_dbg(&p->pdev->dev, "Unknown command = %d\n", cmd);
>> > + *cmd_rc = -EINVAL;
>>
>> ... I think you are conflating rc and cmd_rc...
>>
>> > }
>> >
>> > dev_dbg(&p->pdev->dev, "returned with cmd_rc = %d\n", *cmd_rc);
>> >
>> > - return 0;
>> > + return *cmd_rc;
>>
>> ... this changes the behavior of the current commands. Now if the underlying
>> papr_scm_meta_[get|set]() fails you return that failure as rc rather than 0.
>>
>> Is that ok?
>
> The expectation is that rc is "did the command get sent to the device,
> or did it fail for 'transport' reasons". The role of cmd_rc is to
> translate the specific status response of the command into a common
> error code. The expectations are:
>
> rc < 0: Error code, Linux terminated the ioctl before talking to hardware
>
> rc == 0: Linux successfully submitted the command to hardware, cmd_rc
> is valid for command specific response
>
> rc > 0: Linux successfully submitted the command, but detected that
> only a subset of the data was accepted for "write"-style commands, or
> that only subset of data was returned for "read"-style commands. I.e.
> short-write / short-read semantics. cmd_rc is valid in this case and
> its up to userspace to determine if a short transfer is an error or
> not.
>
>> Also 'logging cmd_rc' in the invalid cmd case does not seem quite right unless
>> you really want rc to be cmd_rc.
>>
>> The architecture is designed to separate errors which occur in the kernel vs
>> errors in the firmware/dimm. Are they always the same? The current code
>> differentiates them.
>
> Yeah, they're distinct, transport vs end-point / command-specific
> status returns.
--
Cheers
~ Vaibhav
^ permalink raw reply
* [PATCH] tty: serial: cpm_uart: Fix behaviour for non existing GPIOs
From: Christophe Leroy @ 2020-06-06 7:30 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Linus Walleij
Cc: linuxppc-dev, linux-kernel, linux-serial
devm_gpiod_get_index() doesn't return NULL but -ENOENT when the
requested GPIO doesn't exist, leading to the following messages:
[ 2.742468] gpiod_direction_input: invalid GPIO (errorpointer)
[ 2.748147] can't set direction for gpio #2: -2
[ 2.753081] gpiod_direction_input: invalid GPIO (errorpointer)
[ 2.758724] can't set direction for gpio #3: -2
[ 2.763666] gpiod_direction_output: invalid GPIO (errorpointer)
[ 2.769394] can't set direction for gpio #4: -2
[ 2.774341] gpiod_direction_input: invalid GPIO (errorpointer)
[ 2.779981] can't set direction for gpio #5: -2
[ 2.784545] ff000a20.serial: ttyCPM1 at MMIO 0xfff00a20 (irq = 39, base_baud = 8250000) is a CPM UART
Use IS_ERR_OR_NULL() to properly check gpiod validity.
Fixes: 97cbaf2c829b ("tty: serial: cpm_uart: Convert to use GPIO descriptors")
Cc: stable@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index a04f74d2e854..3cbe24802296 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1217,7 +1217,7 @@ static int cpm_uart_init_port(struct device_node *np,
gpiod = devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
- if (gpiod) {
+ if (!IS_ERR_OR_NULL(gpiod)) {
if (i == GPIO_RTS || i == GPIO_DTR)
ret = gpiod_direction_output(gpiod, 0);
else
--
2.25.0
^ permalink raw reply related
* [PATCH] powerpc/fadump: update kernel logs before fadump crash begins
From: Sourabh Jain @ 2020-06-06 4:45 UTC (permalink / raw)
To: mpe; +Cc: mahesh, linux-kernel, hbathini, linuxppc-dev
When we hit the fadump crash via the panic path the pstore update is
missing. This is observed when commit 8341f2f222d7 ("sysrq: Use panic()
to force a crash") changed the sysrq-trigger to take panic path instead
of die path.
The PPC panic event handler addresses the system panic in two different
ways based on the system configuration. It first allows the FADump (if
configured) to handle the kernel panic else forwards the call to platform
specific panic function. Now pstore update is missing only if FADump
handles the kernel panic, the platform-specific panic function do update
the pstore by calling panic_flush_kmsg_end function.
The simplest approach to handle this issue is to add pstore update in PPC
panic handler before FADump handles the panic. But this leads to multiple
pstore updates in case FADump is not configured and platform-specific
panic function serves the kernel panic.
Hence the function panic_flush_kmsg_end (used by the platform-specific
panic function to update the kernel logs) is split into two functions, one
will update the pstore (called in ppc panic event handler) and others will
flush the kmsg on the console (called in platform specific panic function).
Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
---
arch/powerpc/include/asm/bug.h | 2 ++
arch/powerpc/kernel/setup-common.c | 1 +
arch/powerpc/kernel/traps.c | 12 +++++++++++-
arch/powerpc/platforms/ps3/setup.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 2 +-
5 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/bug.h b/arch/powerpc/include/asm/bug.h
index 338f36cd9934..9268551a69bc 100644
--- a/arch/powerpc/include/asm/bug.h
+++ b/arch/powerpc/include/asm/bug.h
@@ -118,6 +118,8 @@ extern void _exception_pkey(struct pt_regs *, unsigned long, int);
extern void die(const char *, struct pt_regs *, long);
extern bool die_will_crash(void);
extern void panic_flush_kmsg_start(void);
+extern void panic_flush_kmsg_dump(void);
+extern void panic_flush_kmsg_console(void);
extern void panic_flush_kmsg_end(void);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 7f8c890360fe..2d546a9e8bb1 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -699,6 +699,7 @@ static int ppc_panic_event(struct notifier_block *this,
* want interrupts to be hard disabled.
*/
hard_irq_disable();
+ panic_flush_kmsg_dump();
/*
* If firmware-assisted dump has been registered then trigger
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 82a3438300fd..bb6bc19992b3 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -169,15 +169,25 @@ extern void panic_flush_kmsg_start(void)
bust_spinlocks(1);
}
-extern void panic_flush_kmsg_end(void)
+extern void panic_flush_kmsg_dump(void)
{
printk_safe_flush_on_panic();
kmsg_dump(KMSG_DUMP_PANIC);
+}
+
+extern void panic_flush_kmsg_console(void)
+{
bust_spinlocks(0);
debug_locks_off();
console_flush_on_panic(CONSOLE_FLUSH_PENDING);
}
+extern void panic_flush_kmsg_end(void)
+{
+ panic_flush_kmsg_dump();
+ panic_flush_kmsg_console();
+}
+
static unsigned long oops_begin(struct pt_regs *regs)
{
int cpu;
diff --git a/arch/powerpc/platforms/ps3/setup.c b/arch/powerpc/platforms/ps3/setup.c
index b29368931c56..f96ba34284a1 100644
--- a/arch/powerpc/platforms/ps3/setup.c
+++ b/arch/powerpc/platforms/ps3/setup.c
@@ -101,7 +101,7 @@ static void ps3_panic(char *str)
printk(" System does not reboot automatically.\n");
printk(" Please press POWER button.\n");
printk("\n");
- panic_flush_kmsg_end();
+ panic_flush_kmsg_console();
while(1)
lv1_pause(1);
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0c8421dd01ab..66ecb88c4b8e 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -788,7 +788,7 @@ static void __init pSeries_setup_arch(void)
static void pseries_panic(char *str)
{
- panic_flush_kmsg_end();
+ panic_flush_kmsg_console();
rtas_os_term(str);
}
--
2.25.4
^ permalink raw reply related
* [powerpc:merge] BUILD SUCCESS ec7b8eb9bc7a519047485c95f7292b48f5b73fe6
From: kernel test robot @ 2020-06-06 3:48 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: ec7b8eb9bc7a519047485c95f7292b48f5b73fe6 module: break nested ARCH_HAS_STRICT_MODULE_RWX and STRICT_MODULE_RWX #ifdefs
elapsed time: 747m
configs tested: 134
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
powerpc allyesconfig
m68k m5475evb_defconfig
nios2 10m50_defconfig
mips malta_kvm_defconfig
m68k mvme147_defconfig
arm imote2_defconfig
arm lpc18xx_defconfig
sh kfr2r09-romimage_defconfig
arm spitz_defconfig
c6x alldefconfig
arm orion5x_defconfig
powerpc mpc5200_defconfig
arc vdk_hs38_defconfig
sh se7724_defconfig
powerpc mpc512x_defconfig
sh sh7785lcr_32bit_defconfig
mips ip28_defconfig
arm s5pv210_defconfig
mips ip32_defconfig
mips tb0287_defconfig
ia64 generic_defconfig
arc nps_defconfig
s390 alldefconfig
h8300 defconfig
i386 allnoconfig
powerpc mgcoge_defconfig
mips bmips_stb_defconfig
arm alldefconfig
powerpc pasemi_defconfig
arc vdk_hs38_smp_defconfig
s390 allnoconfig
arm lpc32xx_defconfig
riscv allnoconfig
mips ath79_defconfig
mips loongson1c_defconfig
arm magician_defconfig
arm pxa910_defconfig
arc nsimosci_hs_defconfig
alpha alldefconfig
arm mvebu_v5_defconfig
mips qi_lb60_defconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
m68k allyesconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
xtensa defconfig
h8300 allmodconfig
h8300 allyesconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200605
i386 randconfig-a006-20200605
i386 randconfig-a002-20200605
i386 randconfig-a005-20200605
i386 randconfig-a004-20200605
i386 randconfig-a003-20200605
x86_64 randconfig-a002-20200605
x86_64 randconfig-a001-20200605
x86_64 randconfig-a003-20200605
x86_64 randconfig-a004-20200605
x86_64 randconfig-a005-20200605
i386 randconfig-a014-20200605
i386 randconfig-a015-20200605
i386 randconfig-a011-20200605
i386 randconfig-a016-20200605
i386 randconfig-a012-20200605
i386 randconfig-a013-20200605
x86_64 randconfig-a006-20200605
riscv allyesconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allmodconfig
s390 defconfig
sparc allyesconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
From: Daniel Kolesa @ 2020-06-06 2:13 UTC (permalink / raw)
To: Segher Boessenkool, musl
Cc: Rich Felker, libc-alpha, eery, Will Springer,
Palmer Dabbelt via binutils, via libc-dev, Michal Suchánek,
linuxppc-dev, Joseph Myers
In-Reply-To: <20200606001210.GV31009@gate.crashing.org>
On Sat, Jun 6, 2020, at 02:12, Segher Boessenkool wrote:
> On Fri, Jun 05, 2020 at 11:59:32PM +0200, Daniel Kolesa wrote:
> > On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote:
> > > > Third party precompiled stuff doesn't really need to concern us, since none really exists.
> > >
> > > ... Yet. And if you claim you support ELFv2, not mentioning the ways
> > > your implementation deviates from it, users will be unhappy.
> >
> > Will they?
>
> Yes; not only *your* users, but also users of the "actual" ELFv2 (for
> BE), if anything starts using that: the ABI is defined, and at least at
> some point it worked, it is not unreasonable to think someone might
> want to start using it).
I guess you mean like, if third party software starts shipping builds using ELFv2 and people suddenly find these things don't work because $reasons. The ABI itself wouldn't cause issues here as at binary interface level we're still compatible, but problems may actually arise in case glibc has a modern HW targeting ELFv2 port with IEEE quad float at some point. (not to mention that would be 100% incompatible at binary level because symvers, so i want to resolve this until then either way)
>
> Just don't pretend X and Y are the same if they are not, people do not
> like to be misled. Just be clear upfront what the differences are, and
> everyone will be happy. Confusing people and wasting their time won't
> make you very popular though ;-)
>
> > The system explicitly mentions that the minimum target in the binary packages is 970. Users can't be expecting features that the hardware we support doesn't support :)
>
> But you are not the only user of ELFv2.
Sure, the point was more like "ELFv2 + 970 minimum", both of which are explicitly mentioned, cannot really mean anything else than what it already does.
>
> > Also, we're not the only ones that do this - there's musl of course, but there's also the BSDs. FreeBSD 13 uses ELFv2, and supports all the old hardware including processors without VMX, let alone VSX. OpenBSD is likely to take the same path. But I'm not opposed to making this explicit, if that's what it takes to make other people happy with it.
>
> Yeah, please do :-)
>
> > > > It's also still an upgrade over ELFv1 regardless (I mean, the same things apply there).
> > >
> > > Yeah, in mostly minor ways, but it all adds up for sure.
> >
> > It's made my life simpler on numerous occasions,
>
> Great to hear that!
>
> > and allowed us to bring in software that'd otherwise take significant patching (no software is complete until it has its own assembly implementation of coroutines or something like that :P),
>
> .. but does it have a mail client?
Probably some ad-hoc, informally specified, bug-ridden implementations of half of Common Lisp as well...
>
> > > That depends on what you call the average case. Code that is control
> > > and memory-bound will not benefit much from *anything* :-)
> >
> > Average case is, quite literally, an average case - i.e. the average of all the software packages shipped in a distro :)
>
> Ah, mostly boring stuff :-)
>
> > > Yeah, but it helps quite a bit if your system (shared) libraries get all
> > > improvements they can as well.
> >
> > Well, glibc will still benefit automatically to a degree even if not built for a modern baseline, since it has runtime checks in place already; as for other things... well, at least for Void, I already mentioned before we're as much of a source distro as a binary one - people can easily rebuild things that bottleneck them, with modern CFLAGS, and still have things be interoperable.
>
> Yeah, good point there.
>
> > > I'm not trying to dissuade you from not requiring VSX and 2.07 -- this
> > > sounds like your best option, given the constraints. I'm just saying
> > > the cost is not trivial (even ignoring the ABI divergence).
> >
> > Of course the cost is there - it's just not something I can do anything about. I generally recommend that people who can run LE should run LE. We're a bi-endian distribution, so there is a complete, fully functional, ISA-2.07-baseline ppc64le variant (in fact, it's our best-supported port, with greatest repo coverage and testing), as well as the 970-targeting ppc64 variant.
>
> Ah, so your BE target is mostly for legacy hardware? That took a while
> to sink in, sorry! :-)
That's what the average user on BE is expected to be. I'm not opinionated enough to force BE on an average modern hardware user, there's just too many drawbacks nowadays, some of them inherent, like limited graphics hardware support (the choice of HW is limited, modern GPUs don't work at all, older GPUs are limited to OpenGL 3.2 even if they support newer API, and even if newer GPUs *were* working, they'd be crippled performance-wise as modern GPUs are always LE these days - as a gamedev person I need my graphics stuff working, and I expect my RX 5700 XT to be more than a paperweight), nevertheless, if someone is opinionated enough to use BE despite everything when they don't have to, they're welcome and so are their patches.
>
> > I know about the biarch case as well, and there is also multilib, as an even more elaborate form of that. That's not directly related to what I originally said, though
>
> Biarch is why -m32 and -m64 can work at all (for building user binaries).
> My point is that this does *not* work for most finer ABI (or OS) -related
> points -- you really do need a toolchain built specifically for that
> config.
Indeed. But target triples don't give you the necessary distinctions. This is why I find that the "we're an everything-compiler" approach of Clang that's supposedly meant to simplify things to the user actually complicates them; with gcc, you can configure your toolchain for the target env when building it, with clang you are not given this option, all you can do is patch its source code, as the ideas of targeting everything and of configuring the compiler details for a target are inherently in conflict. And when cross-building the real complexity for the user lies in setting up the sysroot anyway, at least for complex things with actual dependencies.
>
>
> Segher
>
Daniel
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-1 tag
From: Michael Ellerman @ 2020-06-06 0:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: ego, emmanuel.nicolet, chenzhou10, jniethe5, linuxram, kernelfans,
Linux Kernel Mailing List, st5pub, Oliver O'Halloran, huhai,
Markus Elfring, rzinsly, leobras.c, mikey, Herbert Xu,
Aneesh Kumar K.V, haren, michal.simek, mahesh, Takashi Iwai,
kjain, leonardo, Naveen N. Rao, Ravi Bangoria, ajd, Arnd Bergmann,
Stephen Rothwell, alistair, Nick Piggin, wangxiongfeng2, Qian Cai,
clg, Nathan Chancellor, hbathini, Christophe Leroy, geoff,
Dmitry Torokhov, Gustavo A. R. Silva, wsa, sbobroff, fbarrat,
Christophe JAILLET, Andrew Morton, linuxppc-dev
In-Reply-To: <CAHk-=wg33hLZHjqcMhvWzmgNrE6Gv+xpEcFXUx7iUHS2t5QtdQ@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, Jun 5, 2020 at 12:01 PM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> ..and then when I actually compared whether I otherwise got the same
>> result as you, I realized that this all depends on the module tree.
>>
>> I'll go merge that first, and then re-do this all. Oh well.
>
> Ok, redone and pushed out. Can you check that the end result makes sense?
Yep, looks good to me. Has passed all my basic build & boot tests.
cheers
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-1 tag
From: Michael Ellerman @ 2020-06-06 0:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: ego, emmanuel.nicolet, chenzhou10, jniethe5, linuxram, kernelfans,
Linux Kernel Mailing List, st5pub, Oliver O'Halloran, huhai,
Markus Elfring, rzinsly, leobras.c, mikey, Herbert Xu,
Aneesh Kumar K.V, haren, michal.simek, mahesh, Takashi Iwai,
kjain, leonardo, Naveen N. Rao, Ravi Bangoria, ajd, Arnd Bergmann,
Stephen Rothwell, alistair, Nick Piggin, wangxiongfeng2, Qian Cai,
clg, Nathan Chancellor, hbathini, Christophe Leroy, geoff,
Dmitry Torokhov, Gustavo A. R. Silva, wsa, sbobroff, fbarrat,
Christophe JAILLET, Andrew Morton, linuxppc-dev
In-Reply-To: <CAHk-=wh5vSwYqF=YiKOOGBHE=hCwnes_ndbP4QOyjPK_Xocz7w@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, Jun 5, 2020 at 9:38 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> I've pushed the result of my resolution of the conflicts to the powerpc/merge
>> branch, if you want to look at that, though I've also tried to describe it in
>> full below.
>
> I ended up doing the machine_check_exception() differently, because I
> felt the code itself was done wrong and I wanted to add a note about
> that.
>
> Having the same function have completely different semantics depending
> on a platform issue is just fundamentally wrong, and makes not just
> for fragile code, but also means that you can't do single image
> kernels.
Yeah I agree it's not that nicely structured.
In this case CONFIG_PPC_BOOK3S_64 is one of our top-level compile time
switches anyway, so the single image thing at least isn't a concern.
> It should be two different functions, possibly just
>
> non_nmi_fn() { ... }
>
> nmi_fn() { nmi_enter(); non_nmi_fn(); nmi_exit(); }
>
> and now you don't have odd rules for the same function that depends on
> how the platform happens to call it.
Agreed.
> I didn't do the above. I did something that looked like the old code,
> but had a comment. Oh well.
Thanks, we can restructure it later.
> But thanks for describing the merge, I'd have missed the place where
> there was a new use of pgd_oiffset().
Yeah I missed it to begin with :}
> ..and then when I actually compared whether I otherwise got the same
> result as you, I realized that this all depends on the module tree.
>
> I'll go merge that first, and then re-do this all. Oh well.
Darn it. I figured you'd have merged that by the time you saw my pull,
will mention anything similar in future.
cheers
^ permalink raw reply
* Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
From: Segher Boessenkool @ 2020-06-06 0:12 UTC (permalink / raw)
To: Daniel Kolesa
Cc: Rich Felker, libc-alpha, eery, musl, Will Springer,
Palmer Dabbelt via binutils, via libc-dev, Michal Suchánek,
linuxppc-dev, Joseph Myers
In-Reply-To: <6b987f87-1eee-4772-9ecc-f4d9ce9233b6@www.fastmail.com>
On Fri, Jun 05, 2020 at 11:59:32PM +0200, Daniel Kolesa wrote:
> On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote:
> > > Third party precompiled stuff doesn't really need to concern us, since none really exists.
> >
> > ... Yet. And if you claim you support ELFv2, not mentioning the ways
> > your implementation deviates from it, users will be unhappy.
>
> Will they?
Yes; not only *your* users, but also users of the "actual" ELFv2 (for
BE), if anything starts using that: the ABI is defined, and at least at
some point it worked, it is not unreasonable to think someone might
want to start using it).
Just don't pretend X and Y are the same if they are not, people do not
like to be misled. Just be clear upfront what the differences are, and
everyone will be happy. Confusing people and wasting their time won't
make you very popular though ;-)
> The system explicitly mentions that the minimum target in the binary packages is 970. Users can't be expecting features that the hardware we support doesn't support :)
But you are not the only user of ELFv2.
> Also, we're not the only ones that do this - there's musl of course, but there's also the BSDs. FreeBSD 13 uses ELFv2, and supports all the old hardware including processors without VMX, let alone VSX. OpenBSD is likely to take the same path. But I'm not opposed to making this explicit, if that's what it takes to make other people happy with it.
Yeah, please do :-)
> > > It's also still an upgrade over ELFv1 regardless (I mean, the same things apply there).
> >
> > Yeah, in mostly minor ways, but it all adds up for sure.
>
> It's made my life simpler on numerous occasions,
Great to hear that!
> and allowed us to bring in software that'd otherwise take significant patching (no software is complete until it has its own assembly implementation of coroutines or something like that :P),
.. but does it have a mail client?
> > That depends on what you call the average case. Code that is control
> > and memory-bound will not benefit much from *anything* :-)
>
> Average case is, quite literally, an average case - i.e. the average of all the software packages shipped in a distro :)
Ah, mostly boring stuff :-)
> > Yeah, but it helps quite a bit if your system (shared) libraries get all
> > improvements they can as well.
>
> Well, glibc will still benefit automatically to a degree even if not built for a modern baseline, since it has runtime checks in place already; as for other things... well, at least for Void, I already mentioned before we're as much of a source distro as a binary one - people can easily rebuild things that bottleneck them, with modern CFLAGS, and still have things be interoperable.
Yeah, good point there.
> > I'm not trying to dissuade you from not requiring VSX and 2.07 -- this
> > sounds like your best option, given the constraints. I'm just saying
> > the cost is not trivial (even ignoring the ABI divergence).
>
> Of course the cost is there - it's just not something I can do anything about. I generally recommend that people who can run LE should run LE. We're a bi-endian distribution, so there is a complete, fully functional, ISA-2.07-baseline ppc64le variant (in fact, it's our best-supported port, with greatest repo coverage and testing), as well as the 970-targeting ppc64 variant.
Ah, so your BE target is mostly for legacy hardware? That took a while
to sink in, sorry! :-)
> I know about the biarch case as well, and there is also multilib, as an even more elaborate form of that. That's not directly related to what I originally said, though
Biarch is why -m32 and -m64 can work at all (for building user binaries).
My point is that this does *not* work for most finer ABI (or OS) -related
points -- you really do need a toolchain built specifically for that
config.
Segher
^ permalink raw reply
* Re: ppc64le and 32-bit LE userland compatibility
From: Will Springer @ 2020-06-05 23:54 UTC (permalink / raw)
To: linuxppc-dev, Christophe Leroy
Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev
In-Reply-To: <2498690.q0ZmV6gNhb@sheen>
On Saturday, May 30, 2020 3:17:24 PM PDT Will Springer wrote:
> On Saturday, May 30, 2020 8:37:43 AM PDT Christophe Leroy wrote:
> > There is a series at
> > https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=173231
> > to switch powerpc to the Generic C VDSO.
> >
> > Can you try and see whether it fixes your issue ?
> >
> > Christophe
>
> Sure thing, I spotted that after making the initial post. Will report
> back with results.
>
> Will [she/her]
Sorry for the wait, I just sat down to work on this again yesterday.
Tested this series on top of stable/linux-5.7.y (5.7.0 at the time of
writing), plus the one-line signal handler patch. Had to rewind to the
state of powerpc/merge at the time of the mail before the patch would
apply, then cherry-picked to 5.6 until I realized the patchset used some
functionality that didn't land until 5.7, so I moved it there.
Good news is that `date` now works correctly with the vdso call in 32-bit
LE. Bad news is it seems to have broken things on the 64-bit side—in my
testing, Void kicks off runit but hangs after starting eudev, and in a
Debian Stretch system, systemd doesn't get to the point of printing
anything whatsoever. (I had to `init=/bin/sh` to confirm the date worked
in ppcle, although in ppc64le running `date` also hung the system when it
made the vdso call...) Not sure how to approach debugging that, so I'd
appreciate any pointers.
Will [she/her]
^ permalink raw reply
* Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
From: Segher Boessenkool @ 2020-06-05 23:45 UTC (permalink / raw)
To: Rich Felker
Cc: libc-alpha, eery, Daniel Kolesa, musl, Will Springer,
Palmer Dabbelt via binutils, via libc-dev, Michal Suchánek,
linuxppc-dev, Joseph Myers
In-Reply-To: <20200605175045.GW1079@brightrain.aerifal.cx>
Hi!
On Fri, Jun 05, 2020 at 01:50:46PM -0400, Rich Felker wrote:
> On Fri, Jun 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote:
> > > I'm also not really all that convinced that vectors make a huge difference in non-specialized code (autovectorization still has a way to go)
> >
> > They do make a huge difference, depending on the application of course.
> > But VSX is not just vectors even: it also gives you twice as many
> > floating point scalars (64 now), and in newer versions of the ISA it can
> > be beneficially used for integer scalars even.
>
> Vectorization is useful for a lot of things, and I'm sure there are
> specialized workloads that benefit from 64 scalars, but I've never
> encountered a place where having more than 16 registers made a
> practical difference.
20 years ago 32 FP registers was already often a limitation, making FFT
and similar kernels almost twice slower than they could otherwise be.
Things are only *worse* with short vectors, not better. In general with
floating point data you need more registers (because you have more state
to look at concurrently) than with integer data.
*Of course* having 64 floating point registers does not matter if your
whole program only ever uses three floating point values, total, let
alone concurrently.
> The fact that there are specialized areas where this stuff matters
> does not imply there aren't huge domains where it's completely
> irrelevant.
There are very few domains where ISA 2.07 does not have significant
advantages over ISA 2.01. That is Power8 vs. Power4.
> > No, that is exactly the point of requiring ISA 2.07. Anything can use
> > ISA 2.07 (incl. VSX) without checking first, and without having a
> > fallback to some other implementation. Going from ISA 2.01 to 2.07 is
> > more than a decade of improvements, it is not trivial at all.
>
> This only affects code that's non-portable and PPC-specific, which a
No, it does not. It is not only about vector registers, either.
> I think a lot of the unnecessary fighting on this topic is arising
> from differences of opinion over what an ABI entails. I would call
> what you're talking about a "platform" and more of a platform-specific
> *API* than an ABI -- it's about guarantees of interfaces available to
> the programmer, not implementation details of linkage.
No, this is very much about the ABI. The B stands for Binary. Which
is what this is about.
Segher
^ permalink raw reply
* Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
From: Daniel Kolesa @ 2020-06-05 21:59 UTC (permalink / raw)
To: Segher Boessenkool, musl
Cc: Rich Felker, libc-alpha, eery, Will Springer,
Palmer Dabbelt via binutils, via libc-dev, Michal Suchánek,
linuxppc-dev, Joseph Myers
In-Reply-To: <20200605172702.GP31009@gate.crashing.org>
On Fri, Jun 5, 2020, at 19:27, Segher Boessenkool wrote:
> On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote:
> > On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote:
> > > > The thing is, I've yet to see in which way the ELFv2 ABI *actually* requires VSX - I don't think compiling for 970 introduces any actual differences. There will be omissions, yes - but then the more accurate thing would be to say that a subset of ELFv2 is used, rather than it being a different ABI per se.
> > >
> > > Two big things are that binaries that someone else made are supposed to
> > > work for you as well -- including binaries using VSX registers, or any
> > > instructions that require ISA 2.07 (or some older ISA after 970). This
> > > includes DSOs (shared libraries). So for a distribution this means that
> > > they will not use VSX *anywhere*, or only in very specialised things.
> > > That is a many-years setback, for people/situations where it could be
> > > used.
> >
> > Third party precompiled stuff doesn't really need to concern us, since none really exists.
>
> ... Yet. And if you claim you support ELFv2, not mentioning the ways
> your implementation deviates from it, users will be unhappy.
Will they? The system explicitly mentions that the minimum target in the binary packages is 970. Users can't be expecting features that the hardware we support doesn't support :) Also, we're not the only ones that do this - there's musl of course, but there's also the BSDs. FreeBSD 13 uses ELFv2, and supports all the old hardware including processors without VMX, let alone VSX. OpenBSD is likely to take the same path. But I'm not opposed to making this explicit, if that's what it takes to make other people happy with it.
>
> > It's also still an upgrade over ELFv1 regardless (I mean, the same things apply there).
>
> Yeah, in mostly minor ways, but it all adds up for sure.
It's made my life simpler on numerous occasions, and allowed us to bring in software that'd otherwise take significant patching (no software is complete until it has its own assembly implementation of coroutines or something like that :P), or would be outright impossible without a lot of work (e.g. the lld linker).
>
> > I'm also not really all that convinced that vectors make a huge difference in non-specialized code (autovectorization still has a way to go)
>
> They do make a huge difference, depending on the application of course.
I've yet to see non-specialized things without explicit VSX impls where the difference is more than 5%, usually it's less.
> But VSX is not just vectors even: it also gives you twice as many
> floating point scalars (64 now), and in newer versions of the ISA it can
> be beneficially used for integer scalars even.
>
> > and code written to use vector instructions should probably check auxval and take those paths at runtime.
>
> No, that is exactly the point of requiring ISA 2.07. Anything can use
> ISA 2.07 (incl. VSX) without checking first, and without having a
> fallback to some other implementation. Going from ISA 2.01 to 2.07 is
> more than a decade of improvements, it is not trivial at all.
Portable code will need runtime checks anyway if they target big endian systems, especially existing ones, since modern vector instructions can be used even in legacy ABI, where you get no such guarantee. Sure, it's nice to not have to worry about it, but once everything is considered, going with a more modern ABI is still a big net gain for us, even if the guarantees are not all there :)
>
>
> > As for other instructions, fair enough, but from my rough testing, it doesn't make such a massive difference for average case
>
> That depends on what you call the average case. Code that is control
> and memory-bound will not benefit much from *anything* :-)
Average case is, quite literally, an average case - i.e. the average of all the software packages shipped in a distro :)
>
> > (and where it does, one can always rebuild their thing with CFLAGS=-mcpu=power9)
>
> Yeah, but it helps quite a bit if your system (shared) libraries get all
> improvements they can as well.
Well, glibc will still benefit automatically to a degree even if not built for a modern baseline, since it has runtime checks in place already; as for other things... well, at least for Void, I already mentioned before we're as much of a source distro as a binary one - people can easily rebuild things that bottleneck them, with modern CFLAGS, and still have things be interoperable.
>
>
> I'm not trying to dissuade you from not requiring VSX and 2.07 -- this
> sounds like your best option, given the constraints. I'm just saying
> the cost is not trivial (even ignoring the ABI divergence).
Of course the cost is there - it's just not something I can do anything about. I generally recommend that people who can run LE should run LE. We're a bi-endian distribution, so there is a complete, fully functional, ISA-2.07-baseline ppc64le variant (in fact, it's our best-supported port, with greatest repo coverage and testing), as well as the 970-targeting ppc64 variant.
The 970-targeting ppc64 variant is still capable of running on modern hardware, as there are people who wish to run big endian even on their modern machines, and I don't want to take that choice away from them (and since kernel 4.20, you can even have one generic kernel capable of booting POWER4-POWER9, previously separate kernels were needed for <= POWER6 and >= POWER7). Those people can either deal with their computers running a bit slower, or rebuild the packages that specifically bottleneck them with modern CFLAGS.
>
>
> > > The target name allows to make such distinctions: this could for example
> > > be powerpc64-*-linux-void (maybe I put the distinction in the wrong
> > > part of the name here? The glibc people will know better, and "void" is
> > > probably not a great name anyway).
> >
> > Hm, I'm not a huge fan of putting ABI specifics in the triplet, it feels wrong - there is no precedent for it with POWER (ARM did it with EABI though),
>
> Maybe look at what the various BSDs use? We do have things like this.
Briefly, the FreeBSD 13 powerpc64 target triple had an -elfv2 suffix, this was done in clang, but I noticed it was reverted in the end and replaced with checks not based on triples. I believe there is no ABI in BSD powerpc triples right now.
>
> > the last part should remain 'gnu' as it's still glibc; besides, gcc is compiled for exactly one target triplet, and traditionally with ppc compilers it's always been possible to target everything with just one compiler (endian, 32bit, 64bit, abi...).
>
> This isn't completely true.
>
> Yes, the compiler allows you to change word size, endianness, ABI, some
> more things. That does not mean you can actually build working binaries
> for all resulting combinations. As a trivial example, it will still
> pick up the same libraries from the same library paths usually, and
> those will spectacularly fail to work.
I know, I meant mostly from purely compiler perspective. It's good enough for bare-metal (in that way it matters for stuff like GRUB etc. where you still need to build a 32-bit big-endian ELF, etc)
>
> We are biarch for some targets, which means that both powerpc-linux
> targets and powerpc64-linux targets can actually handle both of those,
> with just -m32 or -m64 needed to switch which configuration is used.
> But you cannot magically transparently switch to many other
> configurations: for those, you just build a separate toolchain for that
> specfic (variant) configuration, in the general case.
I know about the biarch case as well, and there is also multilib, as an even more elaborate form of that. That's not directly related to what I originally said, though
>
> > The best way would probably be adding a new -mabi, e.g. -mabi=elfv2-novsx (just an example), which would behave exactly like -mabi=elfv2, except it'd emit some extra detection macro
>
> Yeah, that sounds like a good idea. Patches welcome :-)
>
> (A separate target name is still needed, but this will make development
> simpler for sure).
I don't think a separate target is strictly necessary - it can be done, sure, but with an ABI switch it's more just informative than anything else.
>
>
> Segher
>
Daniel
^ permalink raw reply
* Re: [PATCH v10 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods
From: Dan Williams @ 2020-06-05 20:58 UTC (permalink / raw)
To: Ira Weiny
Cc: Santosh Sivaraj, linux-nvdimm, Linux Kernel Mailing List,
Steven Rostedt, Oliver O'Halloran, Aneesh Kumar K . V,
Vaibhav Jain, linuxppc-dev
In-Reply-To: <20200605194952.GS1505637@iweiny-DESK2.sc.intel.com>
On Fri, Jun 5, 2020 at 12:50 PM Ira Weiny <ira.weiny@intel.com> wrote:
>
> On Fri, Jun 05, 2020 at 05:11:35AM +0530, Vaibhav Jain wrote:
> > Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
> > module and add the command family NVDIMM_FAMILY_PAPR to the white list
> > of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the
> > nvdimm command mask and implement necessary scaffolding in the module
> > to handle ND_CMD_CALL ioctl and PDSM requests that we receive.
> >
> > The layout of the PDSM request as we expect from libnvdimm/libndctl is
> > described in newly introduced uapi header 'papr_pdsm.h' which
> > defines a new 'struct nd_pdsm_cmd_pkg' header. This header is used
> > to communicate the PDSM request via member
> > 'nd_cmd_pkg.nd_command' and size of payload that need to be
> > sent/received for servicing the PDSM.
> >
> > A new function is_cmd_valid() is implemented that reads the args to
> > papr_scm_ndctl() and performs sanity tests on them. A new function
> > papr_scm_service_pdsm() is introduced and is called from
> > papr_scm_ndctl() in case of a PDSM request is received via ND_CMD_CALL
> > command from libnvdimm.
> >
> > Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> > ---
> > Changelog:
> >
> > v9..v10:
> > * Simplified 'struct nd_pdsm_cmd_pkg' by removing the
> > 'payload_version' field.
> > * Removed the corrosponding documentation on versioning and backward
> > compatibility from 'papr_pdsm.h'
> > * Reduced the size of reserved fields to 4-bytes making 'struct
> > nd_pdsm_cmd_pkg' 64 + 8 bytes long.
> > * Updated is_cmd_valid() to enforce validation checks on pdsm
> > commands. [ Dan Williams ]
> > * Added check for reserved fields being set to '0' in is_cmd_valid()
> > [ Ira ]
> > * Moved changes for checking cmd_rc == NULL and logging improvements
> > to a separate prelim patch [ Ira ].
> > * Moved pdsm package validation checks from papr_scm_service_pdsm()
> > to is_cmd_valid().
> > * Marked papr_scm_service_pdsm() return type as 'void' since errors
> > are reported in nd_pdsm_cmd_pkg.cmd_status field.
> >
> > Resend:
> > * Added ack from Aneesh.
> >
> > v8..v9:
> > * Reduced the usage of term SCM replacing it with appropriate
> > replacement [ Dan Williams, Aneesh ]
> > * Renamed 'papr_scm_pdsm.h' to 'papr_pdsm.h'
> > * s/PAPR_SCM_PDSM_*/PAPR_PDSM_*/g
> > * s/NVDIMM_FAMILY_PAPR_SCM/NVDIMM_FAMILY_PAPR/g
> > * Minor updates to 'papr_psdm.h' to replace usage of term 'SCM'.
> > * Minor update to patch description.
> >
> > v7..v8:
> > * Removed the 'payload_offset' field from 'struct
> > nd_pdsm_cmd_pkg'. Instead command payload is always assumed to start
> > at 'nd_pdsm_cmd_pkg.payload'. [ Aneesh ]
> > * To enable introducing new fields to 'struct nd_pdsm_cmd_pkg',
> > 'reserved' field of 10-bytes is introduced. [ Aneesh ]
> > * Fixed a typo in "Backward Compatibility" section of papr_scm_pdsm.h
> > [ Ira ]
> >
> > Resend:
> > * None
> >
> > v6..v7 :
> > * Removed the re-definitions of __packed macro from papr_scm_pdsm.h
> > [Mpe].
> > * Removed the usage of __KERNEL__ macros in papr_scm_pdsm.h [Mpe].
> > * Removed macros that were unused in papr_scm.c from papr_scm_pdsm.h
> > [Mpe].
> > * Made functions defined in papr_scm_pdsm.h as static inline. [Mpe]
> >
> > v5..v6 :
> > * Changed the usage of the term DSM to PDSM to distinguish it from the
> > ACPI term [ Dan Williams ]
> > * Renamed papr_scm_dsm.h to papr_scm_pdsm.h and updated various struct
> > to reflect the new terminology.
> > * Updated the patch description and title to reflect the new terminology.
> > * Squashed patch to introduce new command family in 'ndctl.h' with
> > this patch [ Dan Williams ]
> > * Updated the papr_scm_pdsm method starting index from 0x10000 to 0x0
> > [ Dan Williams ]
> > * Removed redundant license text from the papr_scm_psdm.h file.
> > [ Dan Williams ]
> > * s/envelop/envelope/ at various places [ Dan Williams ]
> > * Added '__packed' attribute to command package header to gaurd
> > against different compiler adding paddings between the fields.
> > [ Dan Williams]
> > * Converted various pr_debug to dev_debug [ Dan Williams ]
> >
> > v4..v5 :
> > * None
> >
> > v3..v4 :
> > * None
> >
> > v2..v3 :
> > * Updated the patch prefix to 'ndctl/uapi' [Aneesh]
> >
> > v1..v2 :
> > * None
> > ---
> > arch/powerpc/include/uapi/asm/papr_pdsm.h | 98 +++++++++++++++++++
> > arch/powerpc/platforms/pseries/papr_scm.c | 113 +++++++++++++++++++++-
> > include/uapi/linux/ndctl.h | 1 +
> > 3 files changed, 207 insertions(+), 5 deletions(-)
> > create mode 100644 arch/powerpc/include/uapi/asm/papr_pdsm.h
> >
> > diff --git a/arch/powerpc/include/uapi/asm/papr_pdsm.h b/arch/powerpc/include/uapi/asm/papr_pdsm.h
> > new file mode 100644
> > index 000000000000..8b1a4f8fa316
> > --- /dev/null
> > +++ b/arch/powerpc/include/uapi/asm/papr_pdsm.h
> > @@ -0,0 +1,98 @@
> > +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> > +/*
> > + * PAPR nvDimm Specific Methods (PDSM) and structs for libndctl
> > + *
> > + * (C) Copyright IBM 2020
> > + *
> > + * Author: Vaibhav Jain <vaibhav at linux.ibm.com>
> > + */
> > +
> > +#ifndef _UAPI_ASM_POWERPC_PAPR_PDSM_H_
> > +#define _UAPI_ASM_POWERPC_PAPR_PDSM_H_
> > +
> > +#include <linux/types.h>
> > +
> > +/*
> > + * PDSM Envelope:
> > + *
> > + * The ioctl ND_CMD_CALL transfers data between user-space and kernel via
> > + * envelope which consists of a header and user-defined payload sections.
> > + * The header is described by 'struct nd_pdsm_cmd_pkg' which expects a
> > + * payload following it and accessible via 'nd_pdsm_cmd_pkg.payload' field.
> > + * There is reserved field that can used to introduce new fields to the
> > + * structure in future. It also tries to ensure that 'nd_pdsm_cmd_pkg.payload'
> > + * lies at a 8-byte boundary.
> > + *
> > + * +-------------+---------------------+---------------------------+
> > + * | 64-Bytes | 8-Bytes | Max 184-Bytes |
> > + * +-------------+---------------------+---------------------------+
> > + * | nd_pdsm_cmd_pkg | |
> > + * |-------------+ | |
> > + * | nd_cmd_pkg | | |
> > + * +-------------+---------------------+---------------------------+
> > + * | nd_family | | |
> > + * | nd_size_out | cmd_status | |
> > + * | nd_size_in | reserved | payload |
> > + * | nd_command | | |
> > + * | nd_fw_size | | |
> > + * +-------------+---------------------+---------------------------+
> > + *
> > + * PDSM Header:
> > + *
> > + * The header is defined as 'struct nd_pdsm_cmd_pkg' which embeds a
> > + * 'struct nd_cmd_pkg' instance. The PDSM command is assigned to member
> > + * 'nd_cmd_pkg.nd_command'. Apart from size information of the envelope which is
> > + * contained in 'struct nd_cmd_pkg', the header also has members following
> > + * members:
> > + *
> > + * 'cmd_status' : (Out) Errors if any encountered while servicing PDSM.
> > + * 'reserved' : Not used, reserved for future and should be set to 0.
> > + *
> > + * PDSM Payload:
> > + *
> > + * The layout of the PDSM Payload is defined by various structs shared between
> > + * papr_scm and libndctl so that contents of payload can be interpreted. During
> > + * servicing of a PDSM the papr_scm module will read input args from the payload
> > + * field by casting its contents to an appropriate struct pointer based on the
> > + * PDSM command. Similarly the output of servicing the PDSM command will be
> > + * copied to the payload field using the same struct.
> > + *
> > + * 'libnvdimm' enforces a hard limit of 256 bytes on the envelope size, which
> > + * leaves around 184 bytes for the envelope payload (ignoring any padding that
> > + * the compiler may silently introduce).
> > + *
> > + */
> > +
> > +/* PDSM-header + payload expected with ND_CMD_CALL ioctl from libnvdimm */
> > +struct nd_pdsm_cmd_pkg {
> > + struct nd_cmd_pkg hdr; /* Package header containing sub-cmd */
> > + __s32 cmd_status; /* Out: Sub-cmd status returned back */
> > + __u16 reserved[2]; /* Ignored and to be used in future */
> > + __u8 payload[]; /* In/Out: Sub-cmd data buffer */
> > +} __packed;
> > +
> > +/*
> > + * Methods to be embedded in ND_CMD_CALL request. These are sent to the kernel
> > + * via 'nd_pdsm_cmd_pkg.hdr.nd_command' member of the ioctl struct
> > + */
> > +enum papr_pdsm {
> > + PAPR_PDSM_MIN = 0x0,
> > + PAPR_PDSM_MAX,
> > +};
> > +
> > +/* Convert a libnvdimm nd_cmd_pkg to pdsm specific pkg */
> > +static inline struct nd_pdsm_cmd_pkg *nd_to_pdsm_cmd_pkg(struct nd_cmd_pkg *cmd)
> > +{
> > + return (struct nd_pdsm_cmd_pkg *)cmd;
> > +}
> > +
> > +/* Return the payload pointer for a given pcmd */
> > +static inline void *pdsm_cmd_to_payload(struct nd_pdsm_cmd_pkg *pcmd)
> > +{
> > + if (pcmd->hdr.nd_size_in == 0 && pcmd->hdr.nd_size_out == 0)
> > + return NULL;
> > + else
> > + return (void *)(pcmd->payload);
> > +}
>
> I just realized these were in the uapi header. You don't want to do this as
> this code gets built into any user space program that uses it and there may be
> license issues if the user space code is not a compatible license.
Yes, include/uapi/linux/ndctl.h is specifically LGPL for this reason.
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-1 tag
From: Linus Torvalds @ 2020-06-05 20:39 UTC (permalink / raw)
To: Michael Ellerman
Cc: ego, emmanuel.nicolet, chenzhou10, jniethe5, linuxram, kernelfans,
Linux Kernel Mailing List, st5pub, Oliver O'Halloran, huhai,
Markus Elfring, rzinsly, leobras.c, mikey, Herbert Xu,
Aneesh Kumar K.V, haren, michal.simek, mahesh, Takashi Iwai,
kjain, leonardo, Naveen N. Rao, Ravi Bangoria, ajd, Arnd Bergmann,
Stephen Rothwell, alistair, Nick Piggin, wangxiongfeng2, Qian Cai,
clg, Nathan Chancellor, hbathini, Christophe Leroy, geoff,
Dmitry Torokhov, Gustavo A. R. Silva, wsa, sbobroff, fbarrat,
Christophe JAILLET, Andrew Morton, linuxppc-dev
In-Reply-To: <CAHk-=wh5vSwYqF=YiKOOGBHE=hCwnes_ndbP4QOyjPK_Xocz7w@mail.gmail.com>
On Fri, Jun 5, 2020 at 12:01 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> ..and then when I actually compared whether I otherwise got the same
> result as you, I realized that this all depends on the module tree.
>
> I'll go merge that first, and then re-do this all. Oh well.
Ok, redone and pushed out. Can you check that the end result makes sense?
Linus
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-1 tag
From: pr-tracker-bot @ 2020-06-05 20:40 UTC (permalink / raw)
To: Michael Ellerman
Cc: ego, emmanuel.nicolet, chenzhou10, jniethe5, linuxram, kernelfans,
linux-kernel, st5pub, oohall, huhai, elfring, rzinsly, leobras.c,
mikey, herbert, aneesh.kumar, haren, michal.simek, mahesh, tiwai,
kjain, leonardo, naveen.n.rao, ravi.bangoria, ajd, arnd, sfr,
alistair, npiggin, wangxiongfeng2, cai, clg, natechancellor,
hbathini, christophe.leroy, geoff, linuxppc-dev, dmitry.torokhov,
gustavoars, wsa, sbobroff, fbarrat, christophe.jaillet, akpm,
Linus Torvalds
In-Reply-To: <87eeqth3hi.fsf@mpe.ellerman.id.au>
The pull request you sent on Sat, 06 Jun 2020 02:38:49 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.8-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7ae77150d94d3b535c7b85e6b3647113095e79bf
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH v10 5/6] ndctl/papr_scm, uapi: Add support for PAPR nvdimm specific methods
From: Ira Weiny @ 2020-06-05 19:49 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, linux-nvdimm, linux-kernel, Steven Rostedt,
Oliver O'Halloran, Aneesh Kumar K . V, Dan Williams,
linuxppc-dev
In-Reply-To: <20200604234136.253703-6-vaibhav@linux.ibm.com>
On Fri, Jun 05, 2020 at 05:11:35AM +0530, Vaibhav Jain wrote:
> Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
> module and add the command family NVDIMM_FAMILY_PAPR to the white list
> of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the
> nvdimm command mask and implement necessary scaffolding in the module
> to handle ND_CMD_CALL ioctl and PDSM requests that we receive.
>
> The layout of the PDSM request as we expect from libnvdimm/libndctl is
> described in newly introduced uapi header 'papr_pdsm.h' which
> defines a new 'struct nd_pdsm_cmd_pkg' header. This header is used
> to communicate the PDSM request via member
> 'nd_cmd_pkg.nd_command' and size of payload that need to be
> sent/received for servicing the PDSM.
>
> A new function is_cmd_valid() is implemented that reads the args to
> papr_scm_ndctl() and performs sanity tests on them. A new function
> papr_scm_service_pdsm() is introduced and is called from
> papr_scm_ndctl() in case of a PDSM request is received via ND_CMD_CALL
> command from libnvdimm.
>
> Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> Changelog:
>
> v9..v10:
> * Simplified 'struct nd_pdsm_cmd_pkg' by removing the
> 'payload_version' field.
> * Removed the corrosponding documentation on versioning and backward
> compatibility from 'papr_pdsm.h'
> * Reduced the size of reserved fields to 4-bytes making 'struct
> nd_pdsm_cmd_pkg' 64 + 8 bytes long.
> * Updated is_cmd_valid() to enforce validation checks on pdsm
> commands. [ Dan Williams ]
> * Added check for reserved fields being set to '0' in is_cmd_valid()
> [ Ira ]
> * Moved changes for checking cmd_rc == NULL and logging improvements
> to a separate prelim patch [ Ira ].
> * Moved pdsm package validation checks from papr_scm_service_pdsm()
> to is_cmd_valid().
> * Marked papr_scm_service_pdsm() return type as 'void' since errors
> are reported in nd_pdsm_cmd_pkg.cmd_status field.
>
> Resend:
> * Added ack from Aneesh.
>
> v8..v9:
> * Reduced the usage of term SCM replacing it with appropriate
> replacement [ Dan Williams, Aneesh ]
> * Renamed 'papr_scm_pdsm.h' to 'papr_pdsm.h'
> * s/PAPR_SCM_PDSM_*/PAPR_PDSM_*/g
> * s/NVDIMM_FAMILY_PAPR_SCM/NVDIMM_FAMILY_PAPR/g
> * Minor updates to 'papr_psdm.h' to replace usage of term 'SCM'.
> * Minor update to patch description.
>
> v7..v8:
> * Removed the 'payload_offset' field from 'struct
> nd_pdsm_cmd_pkg'. Instead command payload is always assumed to start
> at 'nd_pdsm_cmd_pkg.payload'. [ Aneesh ]
> * To enable introducing new fields to 'struct nd_pdsm_cmd_pkg',
> 'reserved' field of 10-bytes is introduced. [ Aneesh ]
> * Fixed a typo in "Backward Compatibility" section of papr_scm_pdsm.h
> [ Ira ]
>
> Resend:
> * None
>
> v6..v7 :
> * Removed the re-definitions of __packed macro from papr_scm_pdsm.h
> [Mpe].
> * Removed the usage of __KERNEL__ macros in papr_scm_pdsm.h [Mpe].
> * Removed macros that were unused in papr_scm.c from papr_scm_pdsm.h
> [Mpe].
> * Made functions defined in papr_scm_pdsm.h as static inline. [Mpe]
>
> v5..v6 :
> * Changed the usage of the term DSM to PDSM to distinguish it from the
> ACPI term [ Dan Williams ]
> * Renamed papr_scm_dsm.h to papr_scm_pdsm.h and updated various struct
> to reflect the new terminology.
> * Updated the patch description and title to reflect the new terminology.
> * Squashed patch to introduce new command family in 'ndctl.h' with
> this patch [ Dan Williams ]
> * Updated the papr_scm_pdsm method starting index from 0x10000 to 0x0
> [ Dan Williams ]
> * Removed redundant license text from the papr_scm_psdm.h file.
> [ Dan Williams ]
> * s/envelop/envelope/ at various places [ Dan Williams ]
> * Added '__packed' attribute to command package header to gaurd
> against different compiler adding paddings between the fields.
> [ Dan Williams]
> * Converted various pr_debug to dev_debug [ Dan Williams ]
>
> v4..v5 :
> * None
>
> v3..v4 :
> * None
>
> v2..v3 :
> * Updated the patch prefix to 'ndctl/uapi' [Aneesh]
>
> v1..v2 :
> * None
> ---
> arch/powerpc/include/uapi/asm/papr_pdsm.h | 98 +++++++++++++++++++
> arch/powerpc/platforms/pseries/papr_scm.c | 113 +++++++++++++++++++++-
> include/uapi/linux/ndctl.h | 1 +
> 3 files changed, 207 insertions(+), 5 deletions(-)
> create mode 100644 arch/powerpc/include/uapi/asm/papr_pdsm.h
>
> diff --git a/arch/powerpc/include/uapi/asm/papr_pdsm.h b/arch/powerpc/include/uapi/asm/papr_pdsm.h
> new file mode 100644
> index 000000000000..8b1a4f8fa316
> --- /dev/null
> +++ b/arch/powerpc/include/uapi/asm/papr_pdsm.h
> @@ -0,0 +1,98 @@
> +/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
> +/*
> + * PAPR nvDimm Specific Methods (PDSM) and structs for libndctl
> + *
> + * (C) Copyright IBM 2020
> + *
> + * Author: Vaibhav Jain <vaibhav at linux.ibm.com>
> + */
> +
> +#ifndef _UAPI_ASM_POWERPC_PAPR_PDSM_H_
> +#define _UAPI_ASM_POWERPC_PAPR_PDSM_H_
> +
> +#include <linux/types.h>
> +
> +/*
> + * PDSM Envelope:
> + *
> + * The ioctl ND_CMD_CALL transfers data between user-space and kernel via
> + * envelope which consists of a header and user-defined payload sections.
> + * The header is described by 'struct nd_pdsm_cmd_pkg' which expects a
> + * payload following it and accessible via 'nd_pdsm_cmd_pkg.payload' field.
> + * There is reserved field that can used to introduce new fields to the
> + * structure in future. It also tries to ensure that 'nd_pdsm_cmd_pkg.payload'
> + * lies at a 8-byte boundary.
> + *
> + * +-------------+---------------------+---------------------------+
> + * | 64-Bytes | 8-Bytes | Max 184-Bytes |
> + * +-------------+---------------------+---------------------------+
> + * | nd_pdsm_cmd_pkg | |
> + * |-------------+ | |
> + * | nd_cmd_pkg | | |
> + * +-------------+---------------------+---------------------------+
> + * | nd_family | | |
> + * | nd_size_out | cmd_status | |
> + * | nd_size_in | reserved | payload |
> + * | nd_command | | |
> + * | nd_fw_size | | |
> + * +-------------+---------------------+---------------------------+
> + *
> + * PDSM Header:
> + *
> + * The header is defined as 'struct nd_pdsm_cmd_pkg' which embeds a
> + * 'struct nd_cmd_pkg' instance. The PDSM command is assigned to member
> + * 'nd_cmd_pkg.nd_command'. Apart from size information of the envelope which is
> + * contained in 'struct nd_cmd_pkg', the header also has members following
> + * members:
> + *
> + * 'cmd_status' : (Out) Errors if any encountered while servicing PDSM.
> + * 'reserved' : Not used, reserved for future and should be set to 0.
> + *
> + * PDSM Payload:
> + *
> + * The layout of the PDSM Payload is defined by various structs shared between
> + * papr_scm and libndctl so that contents of payload can be interpreted. During
> + * servicing of a PDSM the papr_scm module will read input args from the payload
> + * field by casting its contents to an appropriate struct pointer based on the
> + * PDSM command. Similarly the output of servicing the PDSM command will be
> + * copied to the payload field using the same struct.
> + *
> + * 'libnvdimm' enforces a hard limit of 256 bytes on the envelope size, which
> + * leaves around 184 bytes for the envelope payload (ignoring any padding that
> + * the compiler may silently introduce).
> + *
> + */
> +
> +/* PDSM-header + payload expected with ND_CMD_CALL ioctl from libnvdimm */
> +struct nd_pdsm_cmd_pkg {
> + struct nd_cmd_pkg hdr; /* Package header containing sub-cmd */
> + __s32 cmd_status; /* Out: Sub-cmd status returned back */
> + __u16 reserved[2]; /* Ignored and to be used in future */
> + __u8 payload[]; /* In/Out: Sub-cmd data buffer */
> +} __packed;
> +
> +/*
> + * Methods to be embedded in ND_CMD_CALL request. These are sent to the kernel
> + * via 'nd_pdsm_cmd_pkg.hdr.nd_command' member of the ioctl struct
> + */
> +enum papr_pdsm {
> + PAPR_PDSM_MIN = 0x0,
> + PAPR_PDSM_MAX,
> +};
> +
> +/* Convert a libnvdimm nd_cmd_pkg to pdsm specific pkg */
> +static inline struct nd_pdsm_cmd_pkg *nd_to_pdsm_cmd_pkg(struct nd_cmd_pkg *cmd)
> +{
> + return (struct nd_pdsm_cmd_pkg *)cmd;
> +}
> +
> +/* Return the payload pointer for a given pcmd */
> +static inline void *pdsm_cmd_to_payload(struct nd_pdsm_cmd_pkg *pcmd)
> +{
> + if (pcmd->hdr.nd_size_in == 0 && pcmd->hdr.nd_size_out == 0)
> + return NULL;
> + else
> + return (void *)(pcmd->payload);
> +}
I just realized these were in the uapi header. You don't want to do this as
this code gets built into any user space program that uses it and there may be
license issues if the user space code is not a compatible license.
Ira
> +
> +#endif /* _UAPI_ASM_POWERPC_PAPR_PDSM_H_ */
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 6512fe6a2874..05eb56ecab5e 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -15,13 +15,15 @@
> #include <linux/seq_buf.h>
>
> #include <asm/plpar_wrappers.h>
> +#include <asm/papr_pdsm.h>
>
> #define BIND_ANY_ADDR (~0ul)
>
> #define PAPR_SCM_DIMM_CMD_MASK \
> ((1ul << ND_CMD_GET_CONFIG_SIZE) | \
> (1ul << ND_CMD_GET_CONFIG_DATA) | \
> - (1ul << ND_CMD_SET_CONFIG_DATA))
> + (1ul << ND_CMD_SET_CONFIG_DATA) | \
> + (1ul << ND_CMD_CALL))
>
> /* DIMM health bitmap bitmap indicators */
> /* SCM device is unable to persist memory contents */
> @@ -349,22 +351,117 @@ static int papr_scm_meta_set(struct papr_scm_priv *p,
> return 0;
> }
>
> +/*
> + * Do a sanity checks on the inputs args to dimm-control function and return
> + * '0' if valid. This also does validation on ND_CMD_CALL sub-command packages.
> + */
> +static int is_cmd_valid(struct nvdimm *nvdimm, unsigned int cmd, void *buf,
> + unsigned int buf_len)
> +{
> + unsigned long cmd_mask = PAPR_SCM_DIMM_CMD_MASK;
> + struct nd_pdsm_cmd_pkg *pkg;
> + struct nd_cmd_pkg *nd_cmd;
> + struct papr_scm_priv *p;
> + enum papr_pdsm pdsm;
> +
> + /* Only dimm-specific calls are supported atm */
> + if (!nvdimm)
> + return -EINVAL;
> +
> + /* get the provider data from struct nvdimm */
> + p = nvdimm_provider_data(nvdimm);
> +
> + if (!test_bit(cmd, &cmd_mask)) {
> + dev_dbg(&p->pdev->dev, "Unsupported cmd=%u\n", cmd);
> + return -EINVAL;
> + }
> +
> + /* For CMD_CALL verify pdsm request */
> + if (cmd == ND_CMD_CALL) {
> + /* Verify the envelope package */
> + if (!buf || buf_len < sizeof(struct nd_pdsm_cmd_pkg)) {
> + dev_dbg(&p->pdev->dev, "Invalid pkg size=%u\n",
> + buf_len);
> + return -EINVAL;
> + }
> +
> + /* Verify that the nd_cmd_pkg.nd_family is correct */
> + nd_cmd = (struct nd_cmd_pkg *)buf;
> + if (nd_cmd->nd_family != NVDIMM_FAMILY_PAPR) {
> + dev_dbg(&p->pdev->dev, "Invalid pkg family=0x%llx\n",
> + nd_cmd->nd_family);
> + return -EINVAL;
> + }
> +
> + /* Get the pdsm request package and the command */
> + pkg = nd_to_pdsm_cmd_pkg(nd_cmd);
> + pdsm = pkg->hdr.nd_command;
> +
> + /* Verify if the psdm command is valid */
> + if (pdsm <= PAPR_PDSM_MIN || pdsm >= PAPR_PDSM_MAX) {
> + dev_dbg(&p->pdev->dev, "PDSM[0x%x]: Invalid PDSM\n", pdsm);
> + return -EINVAL;
> + }
> +
> + /* We except a payload with all PDSM commands */
> + if (!pdsm_cmd_to_payload(pkg)) {
> + dev_dbg(&p->pdev->dev, "PDSM[0x%x]: Empty payload\n", pdsm);
> + return -EINVAL;
> + }
> +
> + /* Ensure reserved fields of the pdsm header are set to 0 */
> + if (pkg->reserved[0] || pkg->reserved[1]) {
> + dev_dbg(&p->pdev->dev,
> + "PDSM[0x%x]: Invalid reserved field usage\n", pdsm);
> + return -EINVAL;
> + }
> + }
> +
> + /* Let the command be further processed */
> + return 0;
> +}
> +
> +/*
> + * For a given pdsm request call an appropriate service function.
> + * Note: Use 'nd_pdsm_cmd_pkg.cmd_status to report psdm servicing errors. Hence
> + * function marked as void.
> + */
> +static void papr_scm_service_pdsm(struct papr_scm_priv *p,
> + struct nd_pdsm_cmd_pkg *pkg)
> +{
> + const enum papr_pdsm pdsm = pkg->hdr.nd_command;
> +
> + dev_dbg(&p->pdev->dev, "PDSM[0x%x]: Servicing..\n", pdsm);
> +
> + /* Call pdsm service function */
> + switch (pdsm) {
> + default:
> + dev_dbg(&p->pdev->dev, "PDSM[0x%x]: Unsupported PDSM request\n",
> + pdsm);
> + pkg->cmd_status = -ENOENT;
> + break;
> + }
> +}
> +
> static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
> struct nvdimm *nvdimm, unsigned int cmd, void *buf,
> unsigned int buf_len, int *cmd_rc)
> {
> struct nd_cmd_get_config_size *get_size_hdr;
> + struct nd_pdsm_cmd_pkg *call_pkg = NULL;
> struct papr_scm_priv *p;
> int rc;
>
> - /* Only dimm-specific calls are supported atm */
> - if (!nvdimm)
> - return -EINVAL;
> -
> /* Use a local variable in case cmd_rc pointer is NULL */
> if (!cmd_rc)
> cmd_rc = &rc;
>
> + *cmd_rc = is_cmd_valid(nvdimm, cmd, buf, buf_len);
> + if (*cmd_rc) {
> + pr_debug("Invalid cmd=0x%x. Err=%d\n", cmd, *cmd_rc);
> + return *cmd_rc;
> + }
> +
> p = nvdimm_provider_data(nvdimm);
>
> switch (cmd) {
> @@ -385,6 +482,12 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
> *cmd_rc = papr_scm_meta_set(p, buf);
> break;
>
> + case ND_CMD_CALL:
> + call_pkg = nd_to_pdsm_cmd_pkg(buf);
> + papr_scm_service_pdsm(p, call_pkg);
> + *cmd_rc = 0;
> + break;
> +
> default:
> dev_dbg(&p->pdev->dev, "Unknown command = %d\n", cmd);
> *cmd_rc = -EINVAL;
> diff --git a/include/uapi/linux/ndctl.h b/include/uapi/linux/ndctl.h
> index de5d90212409..0e09dc5cec19 100644
> --- a/include/uapi/linux/ndctl.h
> +++ b/include/uapi/linux/ndctl.h
> @@ -244,6 +244,7 @@ struct nd_cmd_pkg {
> #define NVDIMM_FAMILY_HPE2 2
> #define NVDIMM_FAMILY_MSFT 3
> #define NVDIMM_FAMILY_HYPERV 4
> +#define NVDIMM_FAMILY_PAPR 5
>
> #define ND_IOCTL_CALL _IOWR(ND_IOCTL, ND_CMD_CALL,\
> struct nd_cmd_pkg)
> --
> 2.26.2
>
^ permalink raw reply
* Re: [PATCH v10 4/6] powerpc/papr_scm: Improve error logging and handling papr_scm_ndctl()
From: Dan Williams @ 2020-06-05 19:49 UTC (permalink / raw)
To: Ira Weiny
Cc: Santosh Sivaraj, linux-nvdimm, Linux Kernel Mailing List,
Steven Rostedt, Oliver O'Halloran, Aneesh Kumar K . V,
Vaibhav Jain, linuxppc-dev
In-Reply-To: <20200605171313.GO1505637@iweiny-DESK2.sc.intel.com>
On Fri, Jun 5, 2020 at 10:13 AM Ira Weiny <ira.weiny@intel.com> wrote:
>
> On Fri, Jun 05, 2020 at 05:11:34AM +0530, Vaibhav Jain wrote:
> > Since papr_scm_ndctl() can be called from outside papr_scm, its
> > exposed to the possibility of receiving NULL as value of 'cmd_rc'
> > argument. This patch updates papr_scm_ndctl() to protect against such
> > possibility by assigning it pointer to a local variable in case cmd_rc
> > == NULL.
> >
> > Finally the patch also updates the 'default' clause of the switch-case
> > block removing a 'return' statement thereby ensuring that value of
> > 'cmd_rc' is always logged when papr_scm_ndctl() returns.
> >
> > Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
> > Cc: Dan Williams <dan.j.williams@intel.com>
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Ira Weiny <ira.weiny@intel.com>
> > Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> > ---
> > Changelog:
> >
> > v9..v10
> > * New patch in the series
>
> Thanks for making this a separate patch it is easier to see what is going on
> here.
>
> > ---
> > arch/powerpc/platforms/pseries/papr_scm.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> > index 0c091622b15e..6512fe6a2874 100644
> > --- a/arch/powerpc/platforms/pseries/papr_scm.c
> > +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> > @@ -355,11 +355,16 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
> > {
> > struct nd_cmd_get_config_size *get_size_hdr;
> > struct papr_scm_priv *p;
> > + int rc;
> >
> > /* Only dimm-specific calls are supported atm */
> > if (!nvdimm)
> > return -EINVAL;
> >
> > + /* Use a local variable in case cmd_rc pointer is NULL */
> > + if (!cmd_rc)
> > + cmd_rc = &rc;
> > +
>
> This protects you from the NULL. However...
>
> > p = nvdimm_provider_data(nvdimm);
> >
> > switch (cmd) {
> > @@ -381,12 +386,13 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
> > break;
> >
> > default:
> > - return -EINVAL;
> > + dev_dbg(&p->pdev->dev, "Unknown command = %d\n", cmd);
> > + *cmd_rc = -EINVAL;
>
> ... I think you are conflating rc and cmd_rc...
>
> > }
> >
> > dev_dbg(&p->pdev->dev, "returned with cmd_rc = %d\n", *cmd_rc);
> >
> > - return 0;
> > + return *cmd_rc;
>
> ... this changes the behavior of the current commands. Now if the underlying
> papr_scm_meta_[get|set]() fails you return that failure as rc rather than 0.
>
> Is that ok?
The expectation is that rc is "did the command get sent to the device,
or did it fail for 'transport' reasons". The role of cmd_rc is to
translate the specific status response of the command into a common
error code. The expectations are:
rc < 0: Error code, Linux terminated the ioctl before talking to hardware
rc == 0: Linux successfully submitted the command to hardware, cmd_rc
is valid for command specific response
rc > 0: Linux successfully submitted the command, but detected that
only a subset of the data was accepted for "write"-style commands, or
that only subset of data was returned for "read"-style commands. I.e.
short-write / short-read semantics. cmd_rc is valid in this case and
its up to userspace to determine if a short transfer is an error or
not.
> Also 'logging cmd_rc' in the invalid cmd case does not seem quite right unless
> you really want rc to be cmd_rc.
>
> The architecture is designed to separate errors which occur in the kernel vs
> errors in the firmware/dimm. Are they always the same? The current code
> differentiates them.
Yeah, they're distinct, transport vs end-point / command-specific
status returns.
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-1 tag
From: Linus Torvalds @ 2020-06-05 19:01 UTC (permalink / raw)
To: Michael Ellerman
Cc: ego, emmanuel.nicolet, chenzhou10, jniethe5, linuxram, kernelfans,
Linux Kernel Mailing List, st5pub, Oliver O'Halloran, huhai,
Markus Elfring, rzinsly, leobras.c, mikey, Herbert Xu,
Aneesh Kumar K.V, haren, michal.simek, mahesh, Takashi Iwai,
kjain, leonardo, Naveen N. Rao, Ravi Bangoria, ajd, Arnd Bergmann,
Stephen Rothwell, alistair, Nick Piggin, wangxiongfeng2, Qian Cai,
clg, Nathan Chancellor, hbathini, Christophe Leroy, geoff,
Dmitry Torokhov, Gustavo A. R. Silva, wsa, sbobroff, fbarrat,
Christophe JAILLET, Andrew Morton, linuxppc-dev
In-Reply-To: <87eeqth3hi.fsf@mpe.ellerman.id.au>
On Fri, Jun 5, 2020 at 9:38 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> I've pushed the result of my resolution of the conflicts to the powerpc/merge
> branch, if you want to look at that, though I've also tried to describe it in
> full below.
I ended up doing the machine_check_exception() differently, because I
felt the code itself was done wrong and I wanted to add a note about
that.
Having the same function have completely different semantics depending
on a platform issue is just fundamentally wrong, and makes not just
for fragile code, but also means that you can't do single image
kernels.
It should be two different functions, possibly just
non_nmi_fn() { ... }
nmi_fn() { nmi_enter(); non_nmi_fn(); nmi_exit(); }
and now you don't have odd rules for the same function that depends on
how the platform happens to call it.
I didn't do the above. I did something that looked like the old code,
but had a comment. Oh well.
But thanks for describing the merge, I'd have missed the place where
there was a new use of pgd_oiffset().
..and then when I actually compared whether I otherwise got the same
result as you, I realized that this all depends on the module tree.
I'll go merge that first, and then re-do this all. Oh well.
Linus
^ permalink raw reply
* Re: [PATCH v10 6/6] powerpc/papr_scm: Implement support for PAPR_PDSM_HEALTH
From: Ira Weiny @ 2020-06-05 18:36 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, linux-nvdimm, linux-kernel, Steven Rostedt,
Oliver O'Halloran, Aneesh Kumar K . V, Dan Williams,
linuxppc-dev
In-Reply-To: <20200604234136.253703-7-vaibhav@linux.ibm.com>
On Fri, Jun 05, 2020 at 05:11:36AM +0530, Vaibhav Jain wrote:
> This patch implements support for PDSM request 'PAPR_PDSM_HEALTH'
> that returns a newly introduced 'struct nd_papr_pdsm_health' instance
> containing dimm health information back to user space in response to
> ND_CMD_CALL. This functionality is implemented in newly introduced
> papr_pdsm_health() that queries the nvdimm health information and
> then copies this information to the package payload whose layout is
> defined by 'struct nd_papr_pdsm_health'.
>
> Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> Changelog:
>
> v9..v10:
> * Removed code in papr_pdsm_health that performed validation on pdsm
> payload version and corrosponding struct and defines used for
> validation of payload version.
> * Dropped usage of struct papr_pdsm_health in 'struct
> papr_scm_priv'. Instead papr_psdm_health() now uses
> 'papr_scm_priv.health_bitmap' to populate the pdsm payload.
> * Above change also fixes the problem where this patch was removing
> the code that was previously introduced in this patch-series.
> [ Ira ]
> * Introduced a new def ND_PDSM_ENVELOPE_HDR_SIZE that indicates the
> space allocated to 'struct nd_pdsm_cmd_pkg' fields except 'struct
> nd_cmd_pkg'. This def is useful in validating payload sizes.
> * Reworked papr_pdsm_health() to enforce a specific payload size for
> 'PAPR_PDSM_HEALTH' pdsm request.
>
> Resend:
> * Added ack from Aneesh.
>
> v8..v9:
> * s/PAPR_SCM_PDSM_HEALTH/PAPR_PDSM_HEALTH/g [ Dan , Aneesh ]
> * s/PAPR_SCM_PSDM_DIMM_*/PAPR_PDSM_DIMM_*/g
> * Renamed papr_scm_get_health() to papr_psdm_health()
> * Updated patch description to replace papr-scm dimm with nvdimm.
>
> v7..v8:
> * None
>
> Resend:
> * None
>
> v6..v7:
> * Updated flags_show() to use seq_buf_printf(). [Mpe]
> * Updated papr_scm_get_health() to use newly introduced
> __drc_pmem_query_health() bypassing the cache [Mpe].
>
> v5..v6:
> * Added attribute '__packed' to 'struct nd_papr_pdsm_health_v1' to
> gaurd against possibility of different compilers adding different
> paddings to the struct [ Dan Williams ]
>
> * Updated 'struct nd_papr_pdsm_health_v1' to use __u8 instead of
> 'bool' and also updated drc_pmem_query_health() to take this into
> account. [ Dan Williams ]
>
> v4..v5:
> * None
>
> v3..v4:
> * Call the DSM_PAPR_SCM_HEALTH service function from
> papr_scm_service_dsm() instead of papr_scm_ndctl(). [Aneesh]
>
> v2..v3:
> * Updated struct nd_papr_scm_dimm_health_stat_v1 to use '__xx' types
> as its exported to the userspace [Aneesh]
> * Changed the constants DSM_PAPR_SCM_DIMM_XX indicating dimm health
> from enum to #defines [Aneesh]
>
> v1..v2:
> * New patch in the series
> ---
> arch/powerpc/include/uapi/asm/papr_pdsm.h | 33 +++++++++++
> arch/powerpc/platforms/pseries/papr_scm.c | 70 +++++++++++++++++++++++
> 2 files changed, 103 insertions(+)
>
> diff --git a/arch/powerpc/include/uapi/asm/papr_pdsm.h b/arch/powerpc/include/uapi/asm/papr_pdsm.h
> index 8b1a4f8fa316..c4c990ede5d4 100644
> --- a/arch/powerpc/include/uapi/asm/papr_pdsm.h
> +++ b/arch/powerpc/include/uapi/asm/papr_pdsm.h
> @@ -71,12 +71,17 @@ struct nd_pdsm_cmd_pkg {
> __u8 payload[]; /* In/Out: Sub-cmd data buffer */
> } __packed;
>
> +/* Calculate size used by the pdsm header fields minus 'struct nd_cmd_pkg' */
> +#define ND_PDSM_ENVELOPE_HDR_SIZE \
> + (sizeof(struct nd_pdsm_cmd_pkg) - sizeof(struct nd_cmd_pkg))
> +
This is kind of a weird name for this.
Isn't this just the ND PDSM header size? What is 'envelope' mean here?
> /*
> * Methods to be embedded in ND_CMD_CALL request. These are sent to the kernel
> * via 'nd_pdsm_cmd_pkg.hdr.nd_command' member of the ioctl struct
> */
> enum papr_pdsm {
> PAPR_PDSM_MIN = 0x0,
> + PAPR_PDSM_HEALTH,
> PAPR_PDSM_MAX,
> };
>
> @@ -95,4 +100,32 @@ static inline void *pdsm_cmd_to_payload(struct nd_pdsm_cmd_pkg *pcmd)
> return (void *)(pcmd->payload);
> }
>
> +/* Various nvdimm health indicators */
> +#define PAPR_PDSM_DIMM_HEALTHY 0
> +#define PAPR_PDSM_DIMM_UNHEALTHY 1
> +#define PAPR_PDSM_DIMM_CRITICAL 2
> +#define PAPR_PDSM_DIMM_FATAL 3
> +
> +/*
> + * Struct exchanged between kernel & ndctl in for PAPR_PDSM_HEALTH
> + * Various flags indicate the health status of the dimm.
> + *
> + * dimm_unarmed : Dimm not armed. So contents wont persist.
> + * dimm_bad_shutdown : Previous shutdown did not persist contents.
> + * dimm_bad_restore : Contents from previous shutdown werent restored.
> + * dimm_scrubbed : Contents of the dimm have been scrubbed.
> + * dimm_locked : Contents of the dimm cant be modified until CEC reboot
> + * dimm_encrypted : Contents of dimm are encrypted.
> + * dimm_health : Dimm health indicator. One of PAPR_PDSM_DIMM_XXXX
> + */
> +struct nd_papr_pdsm_health {
> + __u8 dimm_unarmed;
> + __u8 dimm_bad_shutdown;
> + __u8 dimm_bad_restore;
> + __u8 dimm_scrubbed;
> + __u8 dimm_locked;
> + __u8 dimm_encrypted;
> + __u16 dimm_health;
> +} __packed;
> +
> #endif /* _UAPI_ASM_POWERPC_PAPR_PDSM_H_ */
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 05eb56ecab5e..984942be24c1 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -421,6 +421,72 @@ static int is_cmd_valid(struct nvdimm *nvdimm, unsigned int cmd, void *buf,
> return 0;
> }
>
> +/* Fetch the DIMM health info and populate it in provided package. */
> +static int papr_pdsm_health(struct papr_scm_priv *p,
> + struct nd_pdsm_cmd_pkg *pkg)
> +{
> + int rc;
> + struct nd_papr_pdsm_health health = { 0 };
> + u16 copysize = sizeof(struct nd_papr_pdsm_health);
> + u16 payload_size = pkg->hdr.nd_size_out - ND_PDSM_ENVELOPE_HDR_SIZE;
> +
> + /* Ensure correct payload size that can hold struct nd_papr_pdsm_health */
> + if (payload_size != copysize) {
> + dev_dbg(&p->pdev->dev,
> + "Unexpected payload-size (%u). Expected (%u)",
> + pkg->hdr.nd_size_out, copysize);
> + rc = -ENOSPC;
> + goto out;
> + }
> +
> + /* Ensure dimm health mutex is taken preventing concurrent access */
> + rc = mutex_lock_interruptible(&p->health_mutex);
> + if (rc)
> + goto out;
> +
> + /* Always fetch upto date dimm health data ignoring cached values */
> + rc = __drc_pmem_query_health(p);
> + if (rc) {
> + mutex_unlock(&p->health_mutex);
> + goto out;
> + }
> +
> + /* update health struct with various flags derived from health bitmap */
> + health = (struct nd_papr_pdsm_health) {
> + .dimm_unarmed = p->health_bitmap & PAPR_PMEM_UNARMED_MASK,
> + .dimm_bad_shutdown = p->health_bitmap & PAPR_PMEM_BAD_SHUTDOWN_MASK,
> + .dimm_bad_restore = p->health_bitmap & PAPR_PMEM_BAD_RESTORE_MASK,
> + .dimm_encrypted = p->health_bitmap & PAPR_PMEM_ENCRYPTED,
> + .dimm_locked = p->health_bitmap & PAPR_PMEM_SCRUBBED_AND_LOCKED,
> + .dimm_scrubbed = p->health_bitmap & PAPR_PMEM_SCRUBBED_AND_LOCKED,
Are you sure these work? These are not assignments to a bool so I don't think
gcc will do what you want here.
Ira
> + .dimm_health = PAPR_PDSM_DIMM_HEALTHY,
> + };
> +
> + /* Update field dimm_health based on health_bitmap flags */
> + if (p->health_bitmap & PAPR_PMEM_HEALTH_FATAL)
> + health.dimm_health = PAPR_PDSM_DIMM_FATAL;
> + else if (p->health_bitmap & PAPR_PMEM_HEALTH_CRITICAL)
> + health.dimm_health = PAPR_PDSM_DIMM_CRITICAL;
> + else if (p->health_bitmap & PAPR_PMEM_HEALTH_UNHEALTHY)
> + health.dimm_health = PAPR_PDSM_DIMM_UNHEALTHY;
> +
> + /* struct populated hence can release the mutex now */
> + mutex_unlock(&p->health_mutex);
> +
> + dev_dbg(&p->pdev->dev, "Copying payload size=%u\n", copysize);
> +
> + /* Copy the health struct to the payload */
> + memcpy(pdsm_cmd_to_payload(pkg), &health, copysize);
> +
> + /* Update fw size including size of struct nd_pdsm_cmd_pkg fields */
> + pkg->hdr.nd_fw_size = copysize + ND_PDSM_ENVELOPE_HDR_SIZE;
> +
> +out:
> + dev_dbg(&p->pdev->dev, "completion code = %d\n", rc);
> +
> + return rc;
> +}
> +
> /*
> * For a given pdsm request call an appropriate service function.
> * Note: Use 'nd_pdsm_cmd_pkg.cmd_status to report psdm servicing errors. Hence
> @@ -435,6 +501,10 @@ static void papr_scm_service_pdsm(struct papr_scm_priv *p,
>
> /* Call pdsm service function */
> switch (pdsm) {
> + case PAPR_PDSM_HEALTH:
> + pkg->cmd_status = papr_pdsm_health(p, pkg);
> + break;
> +
> default:
> dev_dbg(&p->pdev->dev, "PDSM[0x%x]: Unsupported PDSM request\n",
> pdsm);
> --
> 2.26.2
>
^ permalink raw reply
* Re: [RESEND PATCH v9 4/5] ndctl/papr_scm,uapi: Add support for PAPR nvdimm specific methods
From: Dan Williams @ 2020-06-05 18:19 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, Weiny, Ira, linux-nvdimm@lists.01.org,
Aneesh Kumar K . V, linux-kernel@vger.kernel.org, Steven Rostedt,
Oliver O'Halloran, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <873679h72g.fsf@linux.ibm.com>
On Fri, Jun 5, 2020 at 8:22 AM Vaibhav Jain <vaibhav@linux.ibm.com> wrote:
[..]
> > Oh, why not define a maximal health payload with all the attributes
> > you know about today, leave some room for future expansion, and then
> > report a validity flag for each attribute? This is how the "intel"
> > smart-health payload works. If they ever needed to extend the payload
> > they would increase the size and add more validity flags. Old
> > userspace never groks the new fields, new userspace knows to ask for
> > and parse the larger payload.
> >
> > See the flags field in 'struct nd_intel_smart' (in ndctl) and the
> > translation of those flags to ndctl generic attribute flags
> > intel_cmd_smart_get_flags().
> >
> > In general I'd like ndctl to understand the superset of all health
> > attributes across all vendors. For the truly vendor specific ones it
> > would mean that the health flags with a specific "papr_scm" back-end
> > just would never be set on an "intel" device. I.e. look at the "hpe"
> > and "msft" health backends. They only set a subset of the valid flags
> > that could be reported.
>
> Thanks, this sounds good. Infact papr_scm implementation in ndctl does
> advertises support for only a subset of ND_SMART_* flags right now.
>
> Using 'flags' instead of 'version' was indeed discussed during
> v7..v9. However re-looking at the 'msft' and 'hpe' implementations the
> approach of maximal health payload tagged with a flags field looks more
> intuitive and I would prefer implementing this scheme in this patch-set.
>
> The current set health data exchanged with between libndctl and
> papr_scm via 'struct nd_papr_pdsm_health' (e.g various health status
> bits , nvdimm arming status etc) are guaranteed to be always available
> hence associating their availability with a flag wont be much useful as
> the flag will be always set.
>
> However as you suggested, extending the 'struct nd_papr_pdsm_health' in
> future to accommodate new attributes like 'life-remaining' can be done
> via adding them to the end of the struct and setting a flag field to
> indicate its presence.
>
> So I have the following proposal:
> * Add a new '__u32 extension_flags' field at beginning of 'struct
> nd_papr_pdsm_health'
> * Set the size of the struct to 184-bytes which is the maximum possible
> size for a pdsm payload.
> * 'papr_scm' kernel driver will currently set 'extension_flag' to 0
> indicating no extension fields.
>
> * Future patch that adds support for 'life-remaining' add the new-field
> at the end of known fields in 'struct nd_papr_pdsm_health'.
> * When provided to papr_scm kernel module, if 'life-remaining' data is
> available its populated and corresponding flag set in
> 'extension_flags' field indicating its presence.
> * When received by libndctl papr_scm implementation its tests if the
> extension_flags have associated 'life-remaining' flag set and if yes
> then return ND_SMART_USED_VALID flag back from
> ndctl_cmd_smart_get_flags().
>
> Implementing first 3 items above in the current patchset should be
> fairly trivial.
>
> Does that sounds reasonable ?
This sounds good to me.
^ permalink raw reply
* Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
From: Rich Felker @ 2020-06-05 17:50 UTC (permalink / raw)
To: Segher Boessenkool
Cc: libc-alpha, eery, Daniel Kolesa, musl, Will Springer,
Palmer Dabbelt via binutils, via libc-dev, Michal Suchánek,
linuxppc-dev, Joseph Myers
In-Reply-To: <20200605172702.GP31009@gate.crashing.org>
On Fri, Jun 05, 2020 at 12:27:02PM -0500, Segher Boessenkool wrote:
> On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote:
> > On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote:
> > > > The thing is, I've yet to see in which way the ELFv2 ABI *actually* requires VSX - I don't think compiling for 970 introduces any actual differences. There will be omissions, yes - but then the more accurate thing would be to say that a subset of ELFv2 is used, rather than it being a different ABI per se.
> > >
> > > Two big things are that binaries that someone else made are supposed to
> > > work for you as well -- including binaries using VSX registers, or any
> > > instructions that require ISA 2.07 (or some older ISA after 970). This
> > > includes DSOs (shared libraries). So for a distribution this means that
> > > they will not use VSX *anywhere*, or only in very specialised things.
> > > That is a many-years setback, for people/situations where it could be
> > > used.
> >
> > Third party precompiled stuff doesn't really need to concern us, since none really exists.
>
> .... Yet. And if you claim you support ELFv2, not mentioning the ways
> your implementation deviates from it, users will be unhappy.
>
> > It's also still an upgrade over ELFv1 regardless (I mean, the same things apply there).
>
> Yeah, in mostly minor ways, but it all adds up for sure.
>
> > I'm also not really all that convinced that vectors make a huge difference in non-specialized code (autovectorization still has a way to go)
>
> They do make a huge difference, depending on the application of course.
> But VSX is not just vectors even: it also gives you twice as many
> floating point scalars (64 now), and in newer versions of the ISA it can
> be beneficially used for integer scalars even.
Vectorization is useful for a lot of things, and I'm sure there are
specialized workloads that benefit from 64 scalars, but I've never
encountered a place where having more than 16 registers made a
practical difference.
The fact that there are specialized areas where this stuff matters
does not imply there aren't huge domains where it's completely
irrelevant.
> > and code written to use vector instructions should probably check
> > auxval and take those paths at runtime.
>
> No, that is exactly the point of requiring ISA 2.07. Anything can use
> ISA 2.07 (incl. VSX) without checking first, and without having a
> fallback to some other implementation. Going from ISA 2.01 to 2.07 is
> more than a decade of improvements, it is not trivial at all.
This only affects code that's non-portable and PPC-specific, which a
lot of people have no interest in and don't care about. Any portable
code is going to either only use vectors via the compiler's choice to
vectorize or conditionally on being one of a set of supported targets
with a vector ISA it supports available. Anyone building for a target
that doesn't have them just gets the portable version of the code.
I think a lot of the unnecessary fighting on this topic is arising
from differences of opinion over what an ABI entails. I would call
what you're talking about a "platform" and more of a platform-specific
*API* than an ABI -- it's about guarantees of interfaces available to
the programmer, not implementation details of linkage.
Rich
^ permalink raw reply
* Re: [musl] Re: ppc64le and 32-bit LE userland compatibility
From: Segher Boessenkool @ 2020-06-05 17:27 UTC (permalink / raw)
To: Daniel Kolesa
Cc: Rich Felker, libc-alpha, eery, musl, Will Springer,
Palmer Dabbelt via binutils, via libc-dev, Michal Suchánek,
linuxppc-dev, Joseph Myers
In-Reply-To: <17459c98-3bd3-4a5d-a828-993b6deef44f@www.fastmail.com>
On Fri, Jun 05, 2020 at 04:18:18AM +0200, Daniel Kolesa wrote:
> On Fri, Jun 5, 2020, at 01:35, Segher Boessenkool wrote:
> > > The thing is, I've yet to see in which way the ELFv2 ABI *actually* requires VSX - I don't think compiling for 970 introduces any actual differences. There will be omissions, yes - but then the more accurate thing would be to say that a subset of ELFv2 is used, rather than it being a different ABI per se.
> >
> > Two big things are that binaries that someone else made are supposed to
> > work for you as well -- including binaries using VSX registers, or any
> > instructions that require ISA 2.07 (or some older ISA after 970). This
> > includes DSOs (shared libraries). So for a distribution this means that
> > they will not use VSX *anywhere*, or only in very specialised things.
> > That is a many-years setback, for people/situations where it could be
> > used.
>
> Third party precompiled stuff doesn't really need to concern us, since none really exists.
... Yet. And if you claim you support ELFv2, not mentioning the ways
your implementation deviates from it, users will be unhappy.
> It's also still an upgrade over ELFv1 regardless (I mean, the same things apply there).
Yeah, in mostly minor ways, but it all adds up for sure.
> I'm also not really all that convinced that vectors make a huge difference in non-specialized code (autovectorization still has a way to go)
They do make a huge difference, depending on the application of course.
But VSX is not just vectors even: it also gives you twice as many
floating point scalars (64 now), and in newer versions of the ISA it can
be beneficially used for integer scalars even.
> and code written to use vector instructions should probably check auxval and take those paths at runtime.
No, that is exactly the point of requiring ISA 2.07. Anything can use
ISA 2.07 (incl. VSX) without checking first, and without having a
fallback to some other implementation. Going from ISA 2.01 to 2.07 is
more than a decade of improvements, it is not trivial at all.
> As for other instructions, fair enough, but from my rough testing, it doesn't make such a massive difference for average case
That depends on what you call the average case. Code that is control
and memory-bound will not benefit much from *anything* :-)
> (and where it does, one can always rebuild their thing with CFLAGS=-mcpu=power9)
Yeah, but it helps quite a bit if your system (shared) libraries get all
improvements they can as well.
I'm not trying to dissuade you from not requiring VSX and 2.07 -- this
sounds like your best option, given the constraints. I'm just saying
the cost is not trivial (even ignoring the ABI divergence).
> > The target name allows to make such distinctions: this could for example
> > be powerpc64-*-linux-void (maybe I put the distinction in the wrong
> > part of the name here? The glibc people will know better, and "void" is
> > probably not a great name anyway).
>
> Hm, I'm not a huge fan of putting ABI specifics in the triplet, it feels wrong - there is no precedent for it with POWER (ARM did it with EABI though),
Maybe look at what the various BSDs use? We do have things like this.
> the last part should remain 'gnu' as it's still glibc; besides, gcc is compiled for exactly one target triplet, and traditionally with ppc compilers it's always been possible to target everything with just one compiler (endian, 32bit, 64bit, abi...).
This isn't completely true.
Yes, the compiler allows you to change word size, endianness, ABI, some
more things. That does not mean you can actually build working binaries
for all resulting combinations. As a trivial example, it will still
pick up the same libraries from the same library paths usually, and
those will spectacularly fail to work.
We are biarch for some targets, which means that both powerpc-linux
targets and powerpc64-linux targets can actually handle both of those,
with just -m32 or -m64 needed to switch which configuration is used.
But you cannot magically transparently switch to many other
configurations: for those, you just build a separate toolchain for that
specfic (variant) configuration, in the general case.
> The best way would probably be adding a new -mabi, e.g. -mabi=elfv2-novsx (just an example), which would behave exactly like -mabi=elfv2, except it'd emit some extra detection macro
Yeah, that sounds like a good idea. Patches welcome :-)
(A separate target name is still needed, but this will make development
simpler for sure).
Segher
^ permalink raw reply
* Re: [PATCH v10 4/6] powerpc/papr_scm: Improve error logging and handling papr_scm_ndctl()
From: Ira Weiny @ 2020-06-05 17:13 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Santosh Sivaraj, linux-nvdimm, linux-kernel, Steven Rostedt,
Oliver O'Halloran, Aneesh Kumar K . V, Dan Williams,
linuxppc-dev
In-Reply-To: <20200604234136.253703-5-vaibhav@linux.ibm.com>
On Fri, Jun 05, 2020 at 05:11:34AM +0530, Vaibhav Jain wrote:
> Since papr_scm_ndctl() can be called from outside papr_scm, its
> exposed to the possibility of receiving NULL as value of 'cmd_rc'
> argument. This patch updates papr_scm_ndctl() to protect against such
> possibility by assigning it pointer to a local variable in case cmd_rc
> == NULL.
>
> Finally the patch also updates the 'default' clause of the switch-case
> block removing a 'return' statement thereby ensuring that value of
> 'cmd_rc' is always logged when papr_scm_ndctl() returns.
>
> Cc: "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> ---
> Changelog:
>
> v9..v10
> * New patch in the series
Thanks for making this a separate patch it is easier to see what is going on
here.
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index 0c091622b15e..6512fe6a2874 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -355,11 +355,16 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
> {
> struct nd_cmd_get_config_size *get_size_hdr;
> struct papr_scm_priv *p;
> + int rc;
>
> /* Only dimm-specific calls are supported atm */
> if (!nvdimm)
> return -EINVAL;
>
> + /* Use a local variable in case cmd_rc pointer is NULL */
> + if (!cmd_rc)
> + cmd_rc = &rc;
> +
This protects you from the NULL. However...
> p = nvdimm_provider_data(nvdimm);
>
> switch (cmd) {
> @@ -381,12 +386,13 @@ static int papr_scm_ndctl(struct nvdimm_bus_descriptor *nd_desc,
> break;
>
> default:
> - return -EINVAL;
> + dev_dbg(&p->pdev->dev, "Unknown command = %d\n", cmd);
> + *cmd_rc = -EINVAL;
... I think you are conflating rc and cmd_rc...
> }
>
> dev_dbg(&p->pdev->dev, "returned with cmd_rc = %d\n", *cmd_rc);
>
> - return 0;
> + return *cmd_rc;
... this changes the behavior of the current commands. Now if the underlying
papr_scm_meta_[get|set]() fails you return that failure as rc rather than 0.
Is that ok?
Also 'logging cmd_rc' in the invalid cmd case does not seem quite right unless
you really want rc to be cmd_rc.
The architecture is designed to separate errors which occur in the kernel vs
errors in the firmware/dimm. Are they always the same? The current code
differentiates them.
Ira
> }
>
> static ssize_t flags_show(struct device *dev,
> --
> 2.26.2
>
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.8-1 tag
From: Michael Ellerman @ 2020-06-05 16:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: ego, emmanuel.nicolet, chenzhou10, jniethe5, linuxram, kernelfans,
linux-kernel, st5pub, oohall, huhai, elfring, rzinsly, leobras.c,
mikey, herbert, aneesh.kumar, haren, michal.simek, mahesh, tiwai,
kjain, leonardo, naveen.n.rao, ravi.bangoria, ajd, arnd, sfr,
alistair, npiggin, wangxiongfeng2, cai, clg, natechancellor,
hbathini, christophe.leroy, geoff, dmitry.torokhov, gustavoars,
wsa, sbobroff, fbarrat, christophe.jaillet, akpm, linuxppc-dev
Hi Linus,
Please pull powerpc updates for 5.8.
Unfortunately we've ended up with quite a few conflicts, which is primarily my
fault for pushing things to next too late. Lesson learnt.
I've pushed the result of my resolution of the conflicts to the powerpc/merge
branch, if you want to look at that, though I've also tried to describe it in
full below.
Firstly there's a conflict in arch/powerpc/kernel/traps.c in
machine_check_exception() vs 69ea03b56ed2 ("hardirq/nmi: Allow nested
nmi_enter()"). That change made nmi_enter() handle nesting natively, but in
parallel we changed our code to only call nmi_enter() on some configurations
which interacts badly.
The condition on the call to nmi_enter() needs updating, as well as the two
calls to nmi_exit(), and then the comment as well. So I've just included the end
result for the bulk of the function:
void machine_check_exception(struct pt_regs *regs)
{
int recover = 0;
/*
* BOOK3S_64 does not call this handler as a non-maskable interrupt
* (it uses its own early real-mode handler to handle the MCE proper
* and then raises irq_work to call this handler when interrupts are
* enabled).
*/
if (!IS_ENABLED(CONFIG_PPC_BOOK3S_64))
nmi_enter();
__this_cpu_inc(irq_stat.mce_exceptions);
...
if (check_io_access(regs))
goto bail;
if (!IS_ENABLED(CONFIG_PPC_BOOK3S_64))
nmi_exit();
die("Machine check", regs, SIGBUS);
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
die("Unrecoverable Machine check", regs, SIGBUS);
return;
bail:
if (!IS_ENABLED(CONFIG_PPC_BOOK3S_64))
nmi_exit();
}
Then there's two conflicts with 2fb4706057bc ("powerpc: add support for folded
p4d page tables").
The first one in arch/powerpc/mm/kasan/kasan_init_32.c in
kasan_remap_early_shadow_ro() is simple, just remove the for loop entirely.
Then in arch/powerpc/mm/ptdump/ptdump.c, in walk_pagetables(), the for loop
should end up being:
for (i = pgd_index(addr); i < PTRS_PER_PGD; i++, pgd++, addr += PGDIR_SIZE) {
p4d_t *p4d = p4d_offset(pgd, 0);
if (p4d_none(*p4d) || p4d_is_leaf(*p4d))
note_page(st, addr, 1, p4d_val(*p4d), PGDIR_SIZE);
else if (is_hugepd(__hugepd(p4d_val(*p4d))))
walk_hugepd(st, (hugepd_t *)p4d, addr, PGDIR_SHIFT, 1);
else
/* p4d exists */
walk_pud(st, p4d, addr);
}
Finally, we need this hunk applied to avoid a build break:
diff --git a/arch/powerpc/include/asm/nohash/32/pgtable.h b/arch/powerpc/include/asm/nohash/32/pgtable.h
index 61fc9e8f12d3..af7f13cf90cf 100644
--- a/arch/powerpc/include/asm/nohash/32/pgtable.h
+++ b/arch/powerpc/include/asm/nohash/32/pgtable.h
@@ -239,7 +239,7 @@ static inline pte_basic_t pte_update(struct mm_struct *mm, unsigned long addr, p
pte_basic_t old = pte_val(*p);
pte_basic_t new = (old & ~(pte_basic_t)clr) | set;
int num, i;
- pmd_t *pmd = pmd_offset(pud_offset(pgd_offset(mm, addr), addr), addr);
+ pmd_t *pmd = pmd_offset(pud_offset(p4d_offset(pgd_offset(mm, addr), addr), addr), addr);
if (!huge)
num = PAGE_SIZE / SZ_4K;
Let me know if any of that doesn't make sense or otherwise causes problems.
There's also a few out-of-area changes which I'll highlight FYI:
arch/s390/include/asm/pgtable.h # 93a98695f2f9 mm: change pmdp_huge_get_and_clear_full take vm_area_struct as arg
include/asm-generic/pgtable.h
mm/huge_memory.c
drivers/input/serio/ # e4f4ffa8a98c input: i8042 - Remove special PowerPC handling
include/linux/hw_breakpoint.h # ef3534a94fdb hw-breakpoints: Fix build warnings with clang
kernel/events/hw_breakpoint.c # 29da4f91c0c1 powerpc/watchpoint: Don't allow concurrent perf and ptrace events
sound/... # f16dca3e30c1 sound: ac97: Remove sound driver for ancient platform
cheers
The following changes since commit ae83d0b416db002fe95601e7f97f64b59514d936:
Linux 5.7-rc2 (2020-04-19 14:35:30 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.8-1
for you to fetch changes up to 1395375c592770fe5158a592944aaeed67fa94ff:
Merge branch 'topic/ppc-kvm' into next (2020-06-03 13:44:51 +1000)
------------------------------------------------------------------
powerpc updates for 5.8
- Support for userspace to send requests directly to the on-chip GZIP
accelerator on Power9.
- Rework of our lockless page table walking (__find_linux_pte()) to make it
safe against parallel page table manipulations without relying on an IPI for
serialisation.
- A series of fixes & enhancements to make our machine check handling more
robust.
- Lots of plumbing to add support for "prefixed" (64-bit) instructions on
Power10.
- Support for using huge pages for the linear mapping on 8xx (32-bit).
- Remove obsolete Xilinx PPC405/PPC440 support, and an associated sound driver.
- Removal of some obsolete 40x platforms and associated cruft.
- Initial support for booting on Power10.
- Lots of other small features, cleanups & fixes.
Thanks to:
Alexey Kardashevskiy, Alistair Popple, Andrew Donnellan, Andrey Abramov,
Aneesh Kumar K.V, Balamuruhan S, Bharata B Rao, Bulent Abali, Cédric Le
Goater, Chen Zhou, Christian Zigotzky, Christophe JAILLET, Christophe Leroy,
Dmitry Torokhov, Emmanuel Nicolet, Erhard F., Gautham R. Shenoy, Geoff Levand,
George Spelvin, Greg Kurz, Gustavo A. R. Silva, Gustavo Walbon, Haren Myneni,
Hari Bathini, Joel Stanley, Jordan Niethe, Kajol Jain, Kees Cook, Leonardo
Bras, Madhavan Srinivasan., Mahesh Salgaonkar, Markus Elfring, Michael
Neuling, Michal Simek, Nathan Chancellor, Nathan Lynch, Naveen N. Rao,
Nicholas Piggin, Oliver O'Halloran, Paul Mackerras, Pingfan Liu, Qian Cai, Ram
Pai, Raphael Moreira Zinsly, Ravi Bangoria, Sam Bobroff, Sandipan Das, Segher
Boessenkool, Stephen Rothwell, Sukadev Bhattiprolu, Tyrel Datwyler, Wolfram
Sang, Xiongfeng Wang.
------------------------------------------------------------------
Alistair Popple (7):
powerpc: Enable Prefixed Instructions
powerpc: Add new HWCAP bits
powerpc: Add support for ISA v3.1
powerpc/dt_cpu_ftrs: Advertise support for ISA v3.1 if selected
powerpc/dt_cpu_ftrs: Enable Prefixed Instructions
powerpc/dt_cpu_ftrs: Add MMA feature
powerpc: Add POWER10 architected mode
Andrew Donnellan (2):
ocxl: Fix misleading comment
cxl: Remove dead Kconfig options
Andrey Abramov (1):
powerpc: module_[32|64].c: replace swap function with built-in one
Aneesh Kumar K.V (24):
mm: change pmdp_huge_get_and_clear_full take vm_area_struct as arg
powerpc/pkeys: Avoid using lockless page table walk
powerpc/pkeys: Check vma before returning key fault error to the user
powerpc/mm/hash64: use _PAGE_PTE when checking for pte_present
powerpc/hash64: Restrict page table lookup using init_mm with __flush_hash_table_range
powerpc/book3s64/hash: Use the pte_t address from the caller
powerpc/mce: Don't reload pte val in addr_to_pfn
powerpc/perf/callchain: Use __get_user_pages_fast in read_user_stack_slow
powerpc/kvm/book3s: switch from raw_spin_*lock to arch_spin_lock.
powerpc/kvm/book3s: Add helper to walk partition scoped linux page table.
powerpc/kvm/nested: Add helper to walk nested shadow linux page table.
powerpc/kvm/book3s: Use kvm helpers to walk shadow or secondary table
powerpc/kvm/book3s: Add helper for host page table walk
powerpc/kvm/book3s: Use find_kvm_host_pte in page fault handler
powerpc/kvm/book3s: Use find_kvm_host_pte in h_enter
powerpc/kvm/book3s: use find_kvm_host_pte in pute_tce functions
powerpc/kvm/book3s: Avoid using rmap to protect parallel page table update.
powerpc/kvm/book3s: use find_kvm_host_pte in kvmppc_book3s_instantiate_page
powerpc/kvm/book3s: Use find_kvm_host_pte in kvmppc_get_hpa
powerpc/kvm/book3s: Use pte_present instead of opencoding _PAGE_PRESENT check
powerpc/mm/book3s64: Avoid sending IPI on clearing PMD
powerpc/mm/book3s64: Fix MADV_DONTNEED and parallel page fault race
powerpc/book3s64/radix/tlb: Determine hugepage flush correctly
powerpc/book3s64/kvm: Fix secondary page table walk warning during migration
Chen Zhou (1):
powerpc/powernv: add NULL check after kzalloc
Christophe JAILLET (1):
powerpc/powernv: Fix a warning message
Christophe Leroy (83):
powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'
powerpc/uaccess: Implement unsafe_copy_to_user() as a simple loop
powerpc/uaccess: Implement user_read_access_begin and user_write_access_begin
powerpc/8xx: Update email address in MAINTAINERS
drivers/powerpc: Replace _ALIGN_UP() by ALIGN()
powerpc: Replace _ALIGN_DOWN() by ALIGN_DOWN()
powerpc: Replace _ALIGN_UP() by ALIGN()
powerpc: Replace _ALIGN() by ALIGN()
powerpc: Remove _ALIGN_UP(), _ALIGN_DOWN() and _ALIGN()
powerpc/kasan: Fix stack overflow by increasing THREAD_SHIFT
powerpc/kasan: Fix error detection on memory allocation
powerpc/kasan: Fix issues by lowering KASAN_SHADOW_END
powerpc/kasan: Fix shadow pages allocation failure
powerpc/kasan: Remove unnecessary page table locking
powerpc/kasan: Refactor update of early shadow mappings
powerpc/kasan: Declare kasan_init_region() weak
powerpc/ptdump: Add _PAGE_COHERENT flag
powerpc/ptdump: Display size of BATs
powerpc/ptdump: Standardise display of BAT flags
powerpc/ptdump: Properly handle non standard page size
powerpc/ptdump: Handle hugepd at PGD level
powerpc/32s: Don't warn when mapping RO data ROX.
powerpc/mm: Allocate static page tables for fixmap
powerpc/mm: Fix conditions to perform MMU specific management by blocks on PPC32.
powerpc/mm: PTE_ATOMIC_UPDATES is only for 40x
powerpc/mm: Refactor pte_update() on nohash/32
powerpc/mm: Refactor pte_update() on book3s/32
powerpc/mm: Standardise __ptep_test_and_clear_young() params between PPC32 and PPC64
powerpc/mm: Standardise pte_update() prototype between PPC32 and PPC64
powerpc/mm: Create a dedicated pte_update() for 8xx
powerpc/mm: Reduce hugepd size for 8M hugepages on 8xx
powerpc/8xx: Drop CONFIG_8xx_COPYBACK option
powerpc/8xx: Prepare handlers for _PAGE_HUGE for 512k pages.
powerpc/8xx: Manage 512k huge pages as standard pages.
powerpc/8xx: Only 8M pages are hugepte pages now
powerpc/8xx: MM_SLICE is not needed anymore
powerpc/8xx: Move PPC_PIN_TLB options into 8xx Kconfig
powerpc/8xx: Add function to set pinned TLBs
powerpc/8xx: Don't set IMMR map anymore at boot
powerpc/8xx: Always pin TLBs at startup.
powerpc/8xx: Drop special handling of Linear and IMMR mappings in I/D TLB handlers
powerpc/8xx: Remove now unused TLB miss functions
powerpc/8xx: Move DTLB perf handling closer.
powerpc/mm: Don't be too strict with _etext alignment on PPC32
powerpc/8xx: Refactor kernel address boundary comparison
powerpc/8xx: Add a function to early map kernel via huge pages
powerpc/8xx: Map IMMR with a huge page
powerpc/8xx: Map linear memory with huge pages
powerpc/8xx: Allow STRICT_KERNEL_RwX with pinned TLB
powerpc/8xx: Allow large TLBs with DEBUG_PAGEALLOC
powerpc/8xx: Implement dedicated kasan_init_region()
powerpc/32s: Allow mapping with BATs with DEBUG_PAGEALLOC
powerpc/32s: Implement dedicated kasan_init_region()
powerpc/40x: Rework 40x PTE access and TLB miss
powerpc/pgtable: Drop PTE_ATOMIC_UPDATES
powerpc/40x: Remove support for IBM 403GCX
powerpc/40x: Remove STB03xxx
powerpc/40x: Remove WALNUT
powerpc/40x: Remove EP405
powerpc/40x: Remove support for ISS Simulator
powerpc/40x: Remove support for IBM 405GP
powerpc/40x: Remove IBM405 Erratum #51
powerpc: Remove IBM405 Erratum #77
powerpc/40x: Avoid using r12 in TLB miss handlers
powerpc/40x: Don't save CR in SPRN_SPRG_SCRATCH6
powerpc/kprobes: Use probe_address() to read instructions
powerpc/52xx: Blacklist functions running with MMU disabled for kprobe
powerpc/82xx: Blacklist pq2_restart() for kprobe
powerpc/83xx: Blacklist mpc83xx_deep_resume() for kprobe
powerpc/powermac: Blacklist functions running with MMU disabled for kprobe
powerpc/mem: Blacklist flush_dcache_icache_phys() for kprobe
powerpc/32s: Make local symbols non visible in hash_low.
powerpc/32s: Blacklist functions running with MMU disabled for kprobe
powerpc/rtas: Remove machine_check_in_rtas()
powerpc/32: Blacklist functions running with MMU disabled for kprobe
powerpc/entry32: Blacklist exception entry points for kprobe.
powerpc/entry32: Blacklist syscall exit points for kprobe.
powerpc/entry32: Blacklist exception exit points for kprobe.
powerpc/8xx: Reduce time spent in allow_user_access() and friends
powerpc/uaccess: Don't set KUAP by default on book3s/32
powerpc/uaccess: Don't set KUEP by default on book3s/32
powerpc/32: Disable KASAN with pages bigger than 16k
powerpc/32s: Fix another build failure with CONFIG_PPC_KUAP_DEBUG
Cédric Le Goater (3):
powerpc/xive: Enforce load-after-store ordering when StoreEOI is active
powerpc/xive: Clear the page tables for the ESB IO mapping
powerpc/xive: Do not expose a debugfs file when XIVE is disabled
Dmitry Torokhov (1):
macintosh/ams-input: switch to using input device polling mode
Emmanuel Nicolet (1):
ps3disk: use the default segment boundary
Gautham R. Shenoy (5):
powerpc: Move idle_loop_prolog()/epilog() functions to header file
powerpc/idle: Store PURR snapshot in a per-cpu global variable
powerpc/pseries: Account for SPURR ticks on idle CPUs
powerpc/sysfs: Show idle_purr and idle_spurr for every CPU
Documentation: Document sysfs interfaces purr, spurr, idle_purr, idle_spurr
Geoff Levand (5):
powerpc/head_check: Automatic verbosity
powerpc/wrapper: Output linker map file
powerpc/head_check: Avoid broken pipe
powerpc/ps3: Fix kexec shutdown hang
powerpc/ps3: Add check for otheros image size
Gustavo A. R. Silva (2):
powerpc: Replace zero-length array with flexible-array
powerpc/mm: Replace zero-length array with flexible-array
Haren Myneni (23):
powerpc/xive: Define xive_native_alloc_irq_on_chip()
powerpc/vas: Define nx_fault_stamp in coprocessor_request_block
powerpc/vas: Alloc and setup IRQ and trigger port address
powerpc/vas: Setup fault window per VAS instance
powerpc/vas: Register NX with fault window ID and IRQ port value
powerpc/vas: Take reference to PID and mm for user space windows
powerpc/vas: Setup thread IRQ handler per VAS instance
powerpc/vas: Update CSB and notify process for fault CRBs
powerpc/vas: Return credits after handling fault
powerpc/vas: Print CRB and FIFO values
powerpc/vas: Do not use default credits for receive window
powerpc/vas: Display process stuck message
powerpc/vas: Free send window in VAS instance after credits returned
powerpc: Use mm_context vas_windows counter to issue CP_ABORT
powerpc/vas: Initialize window attributes for GZIP coprocessor type
powerpc/vas: Define VAS_TX_WIN_OPEN ioctl API
powerpc/vas: Add VAS user space API
crypto/nx: Initialize coproc entry with kzalloc
crypto/nx: Rename nx-842-powernv file name to nx-common-powernv
crypto/nx: Make enable code generic to add new GZIP compression type
crypto/nx: Enable and setup GZIP compression type
crypto/nx: Remove 'pid' in vas_tx_win_attr struct
Documentation/powerpc: VAS API
Hari Bathini (3):
powerpc/fadump: use static allocation for reserved memory ranges
powerpc/fadump: consider reserved ranges while reserving memory
powerpc/fadump: Account for memory_limit while reserving memory
Jordan Niethe (30):
powerpc/xmon: Remove store_inst() for patch_instruction()
powerpc/xmon: Move breakpoint instructions to own array
powerpc/xmon: Move breakpoints to text section
powerpc/xmon: Use bitwise calculations in_breakpoint_table()
powerpc: Change calling convention for create_branch() et. al.
powerpc: Use a macro for creating instructions from u32s
powerpc: Use an accessor for instructions
powerpc: Use a function for getting the instruction op code
powerpc: Use a function for byte swapping instructions
powerpc: Introduce functions for instruction equality
powerpc: Use a datatype for instructions
powerpc: Use a function for reading instructions
powerpc: Add a probe_user_read_inst() function
powerpc: Add a probe_kernel_read_inst() function
powerpc/kprobes: Use patch_instruction()
powerpc: Define and use get_user_instr() et. al.
powerpc: Introduce a function for reporting instruction length
powerpc/xmon: Use a function for reading instructions
powerpc/xmon: Move insertion of breakpoint for xol'ing
powerpc: Make test_translate_branch() independent of instruction length
powerpc: Define new SRR1 bits for a ISA v3.1
powerpc/optprobes: Add register argument to patch_imm64_load_insns()
powerpc: Add prefixed instructions to instruction data type
powerpc: Test prefixed code patching
powerpc: Test prefixed instructions in feature fixups
powerpc/xmon: Don't allow breakpoints on suffixes
powerpc/kprobes: Don't allow breakpoints on suffixes
powerpc: Support prefixed instructions in alignment handler
powerpc sstep: Add support for prefixed load/stores
powerpc sstep: Add support for prefixed fixed-point arithmetic
Kajol Jain (5):
powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run
powerpc/hv-24x7: Add rtas call in hv-24x7 driver to get processor details
powerpc/hv-24x7: Add sysfs files inside hv-24x7 device to show processor details
Documentation/ABI: Add ABI documentation for chips and sockets
powerpc/pseries: Update hv-24x7 information after migration
Leonardo Bras (4):
powerpc/kernel: Enables memory hot-remove after reboot on pseries guests
powerpc/crash: Use NMI context for printk when starting to crash
powerpc/rtas: Move type/struct definitions from rtas.h into rtas-types.h
powerpc/rtas: Implement reentrant rtas call
Markus Elfring (2):
drivers/ps3: Remove duplicate error messages
net/ps3_gelic_net: Remove duplicate error message
Michael Ellerman (24):
Merge VAS page fault handling into next
Merge NX gzip support into next
Merge branch 'topic/uaccess' into topic/uaccess-ppc
Merge tag 'kvm-ppc-fixes-5.7-1' into topic/ppc-kvm
Merge the lockless page table walk rework into next
powerpc/uaccess: Don't use "m<>" constraint
powerpc/64: Don't initialise init_task->thread.regs
powerpc: Drop unneeded cast in task_pt_regs()
selftests/powerpc: Add a test of counting larx/stcx
drivers/macintosh: Fix memleak in windfarm_pm112 driver
powerpc/64: Update Speculation_Store_Bypass in /proc/<pid>/status
Merge branch 'topic/uaccess-ppc' into next
Merge branch 'topic/ppc-kvm' into next
Merge "Use hugepages to map kernel mem on 8xx" into next
Merge branch 'fixes' into next
powerpc: Add ppc_inst_next()
powerpc: Add ppc_inst_as_u64()
powerpc/configs/64s: Enable CONFIG_PRINTK_CALLER
powerpc/xmon: Show task->thread.regs in process display
powerpc/64s: Don't init FSCR_DSCR in __init_FSCR()
powerpc/64s: Don't let DT CPU features set FSCR_DSCR
powerpc/64s: Save FSCR to init_task.thread.fscr after feature init
powerpc/64s: Don't set FSCR bits in INIT_THREAD
Merge branch 'topic/ppc-kvm' into next
Michael Neuling (3):
powerpc/tm: Document h/rfid and mtmsrd quirk
powerpc: Fix misleading small cores print
powerpc/configs: Add LIBNVDIMM to ppc64_defconfig
Michal Simek (2):
powerpc: Remove Xilinx PPC405/PPC440 support
sound: ac97: Remove sound driver for ancient platform
Nathan Chancellor (2):
powerpc/wii: Fix declaration made after definition
input: i8042 - Remove special PowerPC handling
Naveen N. Rao (4):
powerpc/64: Have MPROFILE_KERNEL depend on FUNCTION_TRACER
powerpc/module_64: Consolidate ftrace code
powerpc/module_64: Simplify check for -mprofile-kernel ftrace relocations
powerpc/module_64: Use special stub for _mcount() with -mprofile-kernel
Nicholas Piggin (26):
powerpc/64s: Always has full regs, so remove remnant checks
powerpc: Use set_trap() and avoid open-coding trap masking
powerpc: trap_is_syscall() helper to hide syscall trap number
powerpc: Use trap metadata to prevent double restart rather than zeroing trap
powerpc/64s/exception: Fix machine check no-loss idle wakeup
powerpc/64s/exceptions: Fix in_mce accounting in unrecoverable path
powerpc/64s/exceptions: Change irq reconcile for NMIs from reusing _DAR to RESULT
powerpc/64s/exceptions: Machine check reconcile irq state
powerpc/pseries/ras: Avoid calling rtas_token() in NMI paths
powerpc/pseries/ras: Fix FWNMI_VALID off by one
powerpc/pseries/ras: fwnmi avoid modifying r3 in error case
powerpc/pseries/ras: fwnmi sreset should not interlock
powerpc/pseries: Limit machine check stack to 4GB
powerpc/pseries: Machine check use rtas_call_unlocked() with args on stack
powerpc/64s: machine check interrupt update NMI accounting
powerpc: Implement ftrace_enabled() helpers
powerpc/64s: machine check do not trace real-mode handler
powerpc/traps: Do not trace system reset
powerpc/traps: Make unrecoverable NMIs die instead of panic
powerpc/64s: Fix early_init_mmu section mismatch
powerpc/64s/hash: Add stress_slb kernel boot option to increase SLB faults
powerpc/64s/radix: Don't prefetch DAR in update_mmu_cache
powerpc/64: Refactor interrupt exit irq disabling sequence
powerpc/64s/kuap: Add missing isync to KUAP restore paths
powerpc/64/kuap: Conditionally restore AMR in interrupt exit
powerpc/64s/kuap: Conditionally restore AMR in kuap_restore_amr asm
Oliver O'Halloran (14):
powerpc/powernv/npu: Clean up compound table group initialisation
powerpc/powernv/iov: Don't add VFs to iommu group during PE config
powerpc/powernv/pci: Register iommu group at PE DMA setup
powerpc/powernv/pci: Add device to iommu group during dma_dev_setup()
powerpc/powernv/pci: Delete old iommu recursive iommu setup
powerpc/powernv/pci: Move tce size parsing to pci-ioda-tce.c
powerpc/powernv/npu: Move IOMMU group setup into npu-dma.c
powerpc/powernv: Add a print indicating when an IODA PE is released
powerpc/powernv/pci: Add an explaination for PNV_IODA_PE_BUS_ALL
powerpc/powernv/pci: Add helper to find ioda_pe from BDFN
powerpc/powernv/pci: Re-work bus PE configuration
powerpc/powernv/pci: Reserve the root bus PE during init
powerpc/powernv/pci: Sprinkle around some WARN_ON()s
powerpc/pseries: Make vio and ibmebus initcalls pseries specific
Pingfan Liu (1):
powerpc/crashkernel: Take "mem=" option into account
Qian Cai (1):
powerpc/64s/pgtable: fix an undefined behaviour
Ram Pai (1):
powerpc/xive: Share the event-queue page with the Hypervisor.
Raphael Moreira Zinsly (5):
selftests/powerpc: Add header files for GZIP engine test
selftests/powerpc: Add header files for NX compresion/decompression
selftests/powerpc: Add NX-GZIP engine compress testcase
selftests/powerpc: Add NX-GZIP engine decompress testcase
selftests/powerpc: Add README for GZIP engine tests
Ravi Bangoria (17):
powerpc/watchpoint: Rename current DAWR macros
powerpc/watchpoint: Add SPRN macros for second DAWR
powerpc/watchpoint: Introduce function to get nr watchpoints dynamically
powerpc/watchpoint/ptrace: Return actual num of available watchpoints
powerpc/watchpoint: Provide DAWR number to set_dawr
powerpc/watchpoint: Provide DAWR number to __set_breakpoint
powerpc/watchpoint: Get watchpoint count dynamically while disabling them
powerpc/watchpoint: Disable all available watchpoints when !dawr_force_enable
powerpc/watchpoint: Convert thread_struct->hw_brk to an array
powerpc/watchpoint: Use loop for thread_struct->ptrace_bps
powerpc/watchpoint: Introduce is_ptrace_bp() function
powerpc/watchpoint: Use builtin ALIGN*() macros
powerpc/watchpoint: Prepare handler to handle more than one watchpoint
powerpc/watchpoint: Don't allow concurrent perf and ptrace events
powerpc/watchpoint/xmon: Don't allow breakpoint overwriting
powerpc/watchpoint/xmon: Support 2nd DAWR
hw-breakpoints: Fix build warnings with clang
Sam Bobroff (2):
powerpc/eeh: Fix pseries_eeh_configure_bridge()
powerpc/eeh: Release EEH device state synchronously
Stephen Rothwell (1):
powerpc/vas: Include linux/types.h in uapi/asm/vas-api.h
Wolfram Sang (1):
powerpc/5200: update contact email
Xiongfeng Wang (1):
powerpc/ps3: Move static keyword to the front of declaration
huhai (1):
powerpc/4xx: Don't unmap NULL mbase
Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 | 21 +
Documentation/ABI/testing/sysfs-devices-system-cpu | 39 +
Documentation/admin-guide/kernel-parameters.txt | 5 +
Documentation/devicetree/bindings/xilinx.txt | 143 ---
Documentation/powerpc/bootwrapper.rst | 28 +-
Documentation/powerpc/index.rst | 1 +
Documentation/powerpc/transactional_memory.rst | 27 +
Documentation/powerpc/vas-api.rst | 292 +++++
Documentation/userspace-api/ioctl/ioctl-number.rst | 1 +
MAINTAINERS | 2 +-
arch/powerpc/Kconfig | 69 +-
arch/powerpc/Kconfig.debug | 2 +-
arch/powerpc/boot/Makefile | 14 +-
arch/powerpc/boot/dts/Makefile | 1 -
arch/powerpc/boot/dts/ep405.dts | 230 ----
arch/powerpc/boot/dts/pcm032.dts | 4 +-
arch/powerpc/boot/dts/virtex440-ml507.dts | 406 ------
arch/powerpc/boot/dts/virtex440-ml510.dts | 466 -------
arch/powerpc/boot/dts/walnut.dts | 246 ----
arch/powerpc/boot/ep405.c | 71 --
arch/powerpc/boot/ops.h | 1 -
arch/powerpc/boot/serial.c | 5 -
arch/powerpc/boot/treeboot-walnut.c | 81 --
arch/powerpc/boot/uartlite.c | 79 --
arch/powerpc/boot/virtex.c | 97 --
arch/powerpc/boot/virtex405-head.S | 31 -
arch/powerpc/boot/wrapper | 26 +-
arch/powerpc/configs/40x/acadia_defconfig | 1 -
arch/powerpc/configs/40x/ep405_defconfig | 62 -
arch/powerpc/configs/40x/kilauea_defconfig | 1 -
arch/powerpc/configs/40x/klondike_defconfig | 1 -
arch/powerpc/configs/40x/makalu_defconfig | 1 -
arch/powerpc/configs/40x/obs600_defconfig | 1 -
arch/powerpc/configs/40x/virtex_defconfig | 75 --
arch/powerpc/configs/44x/virtex5_defconfig | 74 --
arch/powerpc/configs/adder875_defconfig | 1 -
arch/powerpc/configs/ep88xc_defconfig | 1 -
arch/powerpc/configs/mpc866_ads_defconfig | 1 -
arch/powerpc/configs/mpc885_ads_defconfig | 1 -
arch/powerpc/configs/powernv_defconfig | 1 +
arch/powerpc/configs/ppc40x_defconfig | 9 -
arch/powerpc/configs/ppc44x_defconfig | 8 -
arch/powerpc/configs/ppc64_defconfig | 2 +
arch/powerpc/configs/pseries_defconfig | 1 +
arch/powerpc/configs/tqm8xx_defconfig | 1 -
arch/powerpc/include/asm/asm-405.h | 19 -
arch/powerpc/include/asm/atomic.h | 11 -
arch/powerpc/include/asm/bitops.h | 4 -
arch/powerpc/include/asm/book3s/32/kup.h | 7 +-
arch/powerpc/include/asm/book3s/32/pgtable.h | 82 +-
arch/powerpc/include/asm/book3s/64/kup-radix.h | 41 +-
arch/powerpc/include/asm/book3s/64/mmu.h | 5 +-
arch/powerpc/include/asm/book3s/64/pgtable.h | 50 +-
arch/powerpc/include/asm/book3s/64/tlbflush-hash.h | 3 +-
arch/powerpc/include/asm/cache.h | 2 +-
arch/powerpc/include/asm/cmpxchg.h | 11 -
arch/powerpc/include/asm/code-patching.h | 37 +-
arch/powerpc/include/asm/cputable.h | 22 +-
arch/powerpc/include/asm/debug.h | 2 +-
arch/powerpc/include/asm/drmem.h | 1 +
arch/powerpc/include/asm/fadump-internal.h | 4 +-
arch/powerpc/include/asm/firmware.h | 1 +
arch/powerpc/include/asm/fixmap.h | 4 +
arch/powerpc/include/asm/ftrace.h | 14 +
arch/powerpc/include/asm/futex.h | 3 -
arch/powerpc/include/asm/hugetlb.h | 4 -
arch/powerpc/include/asm/hw_breakpoint.h | 31 +-
arch/powerpc/include/asm/icswx.h | 20 +-
arch/powerpc/include/asm/idle.h | 93 ++
arch/powerpc/include/asm/inst.h | 131 ++
arch/powerpc/include/asm/iommu.h | 4 +-
arch/powerpc/include/asm/kasan.h | 10 +-
arch/powerpc/include/asm/kprobes.h | 2 +-
arch/powerpc/include/asm/kup.h | 14 +-
arch/powerpc/include/asm/kvm_book3s.h | 2 +-
arch/powerpc/include/asm/kvm_book3s_64.h | 44 +-
arch/powerpc/include/asm/mmu.h | 10 +-
arch/powerpc/include/asm/mmu_context.h | 30 +
arch/powerpc/include/asm/module.h | 3 -
arch/powerpc/include/asm/nohash/32/hugetlb-8xx.h | 32 +-
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 90 +-
arch/powerpc/include/asm/nohash/32/pgtable.h | 120 +-
arch/powerpc/include/asm/nohash/32/pte-40x.h | 23 +-
arch/powerpc/include/asm/nohash/32/pte-8xx.h | 4 +-
arch/powerpc/include/asm/nohash/32/slice.h | 20 -
arch/powerpc/include/asm/nohash/64/pgtable.h | 28 +-
arch/powerpc/include/asm/nohash/pgtable.h | 4 +-
arch/powerpc/include/asm/paca.h | 2 +
arch/powerpc/include/asm/page.h | 7 -
arch/powerpc/include/asm/pgtable.h | 2 +
arch/powerpc/include/asm/ppc-opcode.h | 3 +
arch/powerpc/include/asm/processor.h | 11 +-
arch/powerpc/include/asm/prom.h | 1 +
arch/powerpc/include/asm/ptrace.h | 46 +-
arch/powerpc/include/asm/reg.h | 19 +-
arch/powerpc/include/asm/reg_booke.h | 54 -
arch/powerpc/include/asm/rtas-types.h | 124 ++
arch/powerpc/include/asm/rtas.h | 125 +-
arch/powerpc/include/asm/slice.h | 2 -
arch/powerpc/include/asm/spinlock.h | 4 -
arch/powerpc/include/asm/sstep.h | 17 +-
arch/powerpc/include/asm/switch_to.h | 2 -
arch/powerpc/include/asm/syscall.h | 5 +-
arch/powerpc/include/asm/time.h | 12 -
arch/powerpc/include/asm/uaccess.h | 149 ++-
arch/powerpc/include/asm/uprobes.h | 7 +-
arch/powerpc/include/asm/vas.h | 13 +-
arch/powerpc/include/asm/xilinx_intc.h | 16 -
arch/powerpc/include/asm/xilinx_pci.h | 21 -
arch/powerpc/include/asm/xive-regs.h | 8 +
arch/powerpc/include/asm/xive.h | 9 +-
arch/powerpc/include/uapi/asm/cputable.h | 2 +
arch/powerpc/include/uapi/asm/vas-api.h | 24 +
arch/powerpc/kernel/align.c | 18 +-
arch/powerpc/kernel/asm-offsets.c | 8 +
arch/powerpc/kernel/cpu_setup_6xx.S | 2 +
arch/powerpc/kernel/cpu_setup_power.S | 22 +-
arch/powerpc/kernel/cputable.c | 124 +-
arch/powerpc/kernel/crash_dump.c | 7 +-
arch/powerpc/kernel/dawr.c | 23 +-
arch/powerpc/kernel/dt_cpu_ftrs.c | 32 +-
arch/powerpc/kernel/eeh.c | 31 +
arch/powerpc/kernel/entry_32.S | 69 +-
arch/powerpc/kernel/entry_64.S | 8 +-
arch/powerpc/kernel/epapr_paravirt.c | 7 +-
arch/powerpc/kernel/exceptions-64s.S | 51 +-
arch/powerpc/kernel/fadump.c | 155 ++-
arch/powerpc/kernel/fpu.S | 1 +
arch/powerpc/kernel/head_32.S | 2 +-
arch/powerpc/kernel/head_40x.S | 316 +----
arch/powerpc/kernel/head_64.S | 9 +-
arch/powerpc/kernel/head_8xx.S | 354 +++---
arch/powerpc/kernel/head_booke.h | 2 +-
arch/powerpc/kernel/hw_breakpoint.c | 641 ++++++++--
arch/powerpc/kernel/idle_6xx.S | 1 +
arch/powerpc/kernel/idle_e500.S | 1 +
arch/powerpc/kernel/jump_label.c | 5 +-
arch/powerpc/kernel/kgdb.c | 9 +-
arch/powerpc/kernel/kprobes.c | 47 +-
arch/powerpc/kernel/l2cr_6xx.S | 1 +
arch/powerpc/kernel/mce.c | 16 +-
arch/powerpc/kernel/mce_power.c | 19 +-
arch/powerpc/kernel/misc.S | 2 +
arch/powerpc/kernel/misc_32.S | 11 +-
arch/powerpc/kernel/module_32.c | 17 +-
arch/powerpc/kernel/module_64.c | 301 ++---
arch/powerpc/kernel/nvram_64.c | 4 +-
arch/powerpc/kernel/optprobes.c | 99 +-
arch/powerpc/kernel/optprobes_head.S | 3 +
arch/powerpc/kernel/paca.c | 32 +
arch/powerpc/kernel/pci-hotplug.c | 2 -
arch/powerpc/kernel/pci_64.c | 6 +-
arch/powerpc/kernel/process.c | 113 +-
arch/powerpc/kernel/prom.c | 38 +-
arch/powerpc/kernel/prom_init.c | 36 +-
arch/powerpc/kernel/ptrace/ptrace-noadv.c | 72 +-
arch/powerpc/kernel/ptrace/ptrace-tm.c | 2 +-
arch/powerpc/kernel/ptrace/ptrace-view.c | 2 +-
arch/powerpc/kernel/ptrace/ptrace32.c | 4 +-
arch/powerpc/kernel/rtas.c | 52 +
arch/powerpc/kernel/security.c | 48 +-
arch/powerpc/kernel/setup-common.c | 4 -
arch/powerpc/kernel/setup_32.c | 10 +-
arch/powerpc/kernel/setup_64.c | 15 +-
arch/powerpc/kernel/signal.c | 22 +-
arch/powerpc/kernel/signal_32.c | 2 +-
arch/powerpc/kernel/signal_64.c | 10 +-
arch/powerpc/kernel/smp.c | 2 +-
arch/powerpc/kernel/swsusp_32.S | 2 +
arch/powerpc/kernel/syscall_64.c | 72 +-
arch/powerpc/kernel/sysfs.c | 82 +-
arch/powerpc/kernel/trace/ftrace.c | 168 +--
arch/powerpc/kernel/traps.c | 46 +-
arch/powerpc/kernel/uprobes.c | 5 +-
arch/powerpc/kernel/vecemu.c | 20 +-
arch/powerpc/kernel/vector.S | 1 +
arch/powerpc/kernel/vmlinux.lds.S | 3 +-
arch/powerpc/kexec/core.c | 8 +-
arch/powerpc/kexec/crash.c | 3 +
arch/powerpc/kvm/book3s_64_mmu_hv.c | 13 +-
arch/powerpc/kvm/book3s_64_mmu_radix.c | 71 +-
arch/powerpc/kvm/book3s_64_vio_hv.c | 66 +-
arch/powerpc/kvm/book3s_hv.c | 15 +-
arch/powerpc/kvm/book3s_hv_nested.c | 39 +-
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 60 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 23 +-
arch/powerpc/kvm/book3s_xive_native.c | 6 +
arch/powerpc/kvm/book3s_xive_template.c | 3 +
arch/powerpc/kvm/emulate_loadstore.c | 2 +-
arch/powerpc/lib/Makefile | 2 +-
arch/powerpc/lib/code-patching.c | 307 +++--
arch/powerpc/lib/feature-fixups-test.S | 69 ++
arch/powerpc/lib/feature-fixups.c | 163 ++-
arch/powerpc/lib/inst.c | 73 ++
arch/powerpc/lib/sstep.c | 460 ++++---
arch/powerpc/lib/test_code-patching.S | 20 +
arch/powerpc/lib/test_emulate_step.c | 56 +-
arch/powerpc/mm/book3s32/hash_low.S | 32 +-
arch/powerpc/mm/book3s32/mmu.c | 12 +-
arch/powerpc/mm/book3s64/hash_pgtable.c | 11 -
arch/powerpc/mm/book3s64/hash_tlb.c | 22 +-
arch/powerpc/mm/book3s64/hash_utils.c | 72 +-
arch/powerpc/mm/book3s64/internal.h | 16 +
arch/powerpc/mm/book3s64/pgtable.c | 37 +-
arch/powerpc/mm/book3s64/radix_pgtable.c | 21 +-
arch/powerpc/mm/book3s64/radix_tlb.c | 4 +-
arch/powerpc/mm/book3s64/slb.c | 166 ++-
arch/powerpc/mm/fault.c | 92 +-
arch/powerpc/mm/hugetlbpage.c | 43 +-
arch/powerpc/mm/init_32.c | 12 +-
arch/powerpc/mm/init_64.c | 4 +-
arch/powerpc/mm/kasan/8xx.c | 74 ++
arch/powerpc/mm/kasan/Makefile | 2 +
arch/powerpc/mm/kasan/book3s_32.c | 57 +
arch/powerpc/mm/kasan/kasan_init_32.c | 88 +-
arch/powerpc/mm/mem.c | 2 +
arch/powerpc/mm/mmu_decl.h | 4 +
arch/powerpc/mm/nohash/40x.c | 4 +-
arch/powerpc/mm/nohash/8xx.c | 227 ++--
arch/powerpc/mm/pgtable.c | 34 +-
arch/powerpc/mm/pgtable_32.c | 22 +-
arch/powerpc/mm/ptdump/8xx.c | 5 +
arch/powerpc/mm/ptdump/bats.c | 41 +-
arch/powerpc/mm/ptdump/ptdump.c | 73 +-
arch/powerpc/mm/ptdump/ptdump.h | 3 +
arch/powerpc/mm/ptdump/shared.c | 5 +
arch/powerpc/mm/slice.c | 2 +-
arch/powerpc/perf/8xx-pmu.c | 19 +-
arch/powerpc/perf/callchain_64.c | 46 +-
arch/powerpc/perf/core-book3s.c | 4 +-
arch/powerpc/perf/hv-24x7.c | 96 +-
arch/powerpc/platforms/40x/Kconfig | 76 --
arch/powerpc/platforms/40x/Makefile | 3 -
arch/powerpc/platforms/40x/ep405.c | 123 --
arch/powerpc/platforms/40x/virtex.c | 54 -
arch/powerpc/platforms/40x/walnut.c | 65 -
arch/powerpc/platforms/44x/Kconfig | 40 +-
arch/powerpc/platforms/44x/Makefile | 2 -
arch/powerpc/platforms/44x/virtex.c | 60 -
arch/powerpc/platforms/44x/virtex_ml510.c | 30 -
arch/powerpc/platforms/4xx/pci.c | 4 +-
arch/powerpc/platforms/52xx/lite5200_sleep.S | 2 +
arch/powerpc/platforms/82xx/pq2.c | 3 +
arch/powerpc/platforms/83xx/suspend-asm.S | 1 +
arch/powerpc/platforms/86xx/mpc86xx_smp.c | 5 +-
arch/powerpc/platforms/8xx/Kconfig | 50 +-
arch/powerpc/platforms/Kconfig | 4 -
arch/powerpc/platforms/Kconfig.cputype | 6 +-
arch/powerpc/platforms/cell/iommu.c | 6 +-
arch/powerpc/platforms/embedded6xx/wii.c | 25 +-
arch/powerpc/platforms/powermac/bootx_init.c | 14 +-
arch/powerpc/platforms/powermac/cache.S | 2 +
arch/powerpc/platforms/powermac/nvram.c | 2 +-
arch/powerpc/platforms/powermac/sleep.S | 5 +-
arch/powerpc/platforms/powermac/smp.c | 5 +-
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/idle.c | 2 +-
arch/powerpc/platforms/powernv/npu-dma.c | 117 +-
arch/powerpc/platforms/powernv/opal-fadump.c | 2 +-
arch/powerpc/platforms/powernv/opal.c | 4 +
arch/powerpc/platforms/powernv/pci-ioda-tce.c | 28 +
arch/powerpc/platforms/powernv/pci-ioda.c | 299 ++---
arch/powerpc/platforms/powernv/pci.c | 20 -
arch/powerpc/platforms/powernv/pci.h | 28 +-
arch/powerpc/platforms/powernv/vas-api.c | 278 +++++
arch/powerpc/platforms/powernv/vas-debug.c | 2 +-
arch/powerpc/platforms/powernv/vas-fault.c | 382 ++++++
arch/powerpc/platforms/powernv/vas-window.c | 238 +++-
arch/powerpc/platforms/powernv/vas.c | 85 +-
arch/powerpc/platforms/powernv/vas.h | 59 +-
arch/powerpc/platforms/ps3/mm.c | 52 +-
arch/powerpc/platforms/ps3/setup.c | 2 +-
arch/powerpc/platforms/pseries/eeh_pseries.c | 8 +-
arch/powerpc/platforms/pseries/ibmebus.c | 3 +-
arch/powerpc/platforms/pseries/mobility.c | 3 +
arch/powerpc/platforms/pseries/ras.c | 62 +-
arch/powerpc/platforms/pseries/rtas-fadump.c | 2 +-
arch/powerpc/platforms/pseries/setup.c | 22 +-
arch/powerpc/platforms/pseries/vio.c | 7 +-
arch/powerpc/sysdev/Makefile | 2 -
arch/powerpc/sysdev/cpm_common.c | 2 +
arch/powerpc/sysdev/xics/ics-rtas.c | 22 +-
arch/powerpc/sysdev/xilinx_intc.c | 88 --
arch/powerpc/sysdev/xilinx_pci.c | 132 --
arch/powerpc/sysdev/xive/common.c | 13 +-
arch/powerpc/sysdev/xive/native.c | 6 +-
arch/powerpc/sysdev/xive/spapr.c | 7 +
arch/powerpc/tools/head_check.sh | 8 +-
arch/powerpc/xmon/Makefile | 2 +-
arch/powerpc/xmon/xmon.c | 229 ++--
arch/powerpc/xmon/xmon_bpts.S | 11 +
arch/powerpc/xmon/xmon_bpts.h | 14 +
arch/s390/include/asm/pgtable.h | 4 +-
drivers/block/ps3disk.c | 1 -
drivers/char/Kconfig | 2 +-
drivers/cpuidle/cpuidle-pseries.c | 39 +-
drivers/crypto/nx/Makefile | 2 +-
drivers/crypto/nx/{nx-842-powernv.c => nx-common-powernv.c} | 204 ++-
drivers/input/serio/i8042-ppcio.h | 57 -
drivers/input/serio/i8042.h | 2 -
drivers/macintosh/Kconfig | 1 -
drivers/macintosh/ams/ams-input.c | 37 +-
drivers/macintosh/ams/ams.h | 4 +-
drivers/macintosh/windfarm_pm112.c | 21 +-
drivers/misc/cxl/Kconfig | 8 -
drivers/misc/ocxl/context.c | 2 +-
drivers/net/ethernet/toshiba/ps3_gelic_net.c | 2 -
drivers/ps3/ps3-lpm.c | 8 +-
drivers/ps3/ps3-vuart.c | 5 +-
drivers/vfio/pci/vfio_pci_nvlink2.c | 2 +-
drivers/video/fbdev/Kconfig | 2 +-
drivers/video/fbdev/ps3fb.c | 4 +-
include/asm-generic/pgtable.h | 4 +-
include/linux/hw_breakpoint.h | 4 +
kernel/events/hw_breakpoint.c | 16 +
mm/huge_memory.c | 4 +-
sound/drivers/Kconfig | 12 -
sound/drivers/Makefile | 2 -
sound/drivers/ml403-ac97cr.c | 1298 --------------------
sound/drivers/pcm-indirect2.c | 560 ---------
sound/drivers/pcm-indirect2.h | 127 --
sound/ppc/snd_ps3.c | 2 +-
tools/testing/selftests/powerpc/Makefile | 1 +
tools/testing/selftests/powerpc/nx-gzip/99-nx-gzip.rules | 1 +
tools/testing/selftests/powerpc/nx-gzip/Makefile | 8 +
tools/testing/selftests/powerpc/nx-gzip/README | 45 +
tools/testing/selftests/powerpc/nx-gzip/gunz_test.c | 1028 ++++++++++++++++
tools/testing/selftests/powerpc/nx-gzip/gzfht_test.c | 433 +++++++
tools/testing/selftests/powerpc/nx-gzip/gzip_vas.c | 316 +++++
tools/testing/selftests/powerpc/nx-gzip/include/copy-paste.h | 56 +
tools/testing/selftests/powerpc/nx-gzip/include/crb.h | 155 +++
tools/testing/selftests/powerpc/nx-gzip/include/nx.h | 38 +
tools/testing/selftests/powerpc/nx-gzip/include/nx_dbg.h | 95 ++
tools/testing/selftests/powerpc/nx-gzip/include/nxu.h | 650 ++++++++++
tools/testing/selftests/powerpc/nx-gzip/include/vas-api.h | 1 +
tools/testing/selftests/powerpc/nx-gzip/nx-gzip-test.sh | 46 +
tools/testing/selftests/powerpc/pmu/.gitignore | 1 +
tools/testing/selftests/powerpc/pmu/Makefile | 8 +-
tools/testing/selftests/powerpc/pmu/count_stcx_fail.c | 161 +++
tools/testing/selftests/powerpc/pmu/ebb/trace.h | 4 +-
tools/testing/selftests/powerpc/pmu/loop.S | 35 +
tools/testing/selftests/powerpc/signal/Makefile | 2 +-
tools/testing/selftests/powerpc/signal/sig_sc_double_restart.c | 174 +++
343 files changed, 10392 insertions(+), 8589 deletions(-)
create mode 100644 Documentation/powerpc/vas-api.rst
delete mode 100644 arch/powerpc/boot/dts/ep405.dts
delete mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
delete mode 100644 arch/powerpc/boot/dts/virtex440-ml510.dts
delete mode 100644 arch/powerpc/boot/dts/walnut.dts
delete mode 100644 arch/powerpc/boot/ep405.c
delete mode 100644 arch/powerpc/boot/treeboot-walnut.c
delete mode 100644 arch/powerpc/boot/uartlite.c
delete mode 100644 arch/powerpc/boot/virtex.c
delete mode 100644 arch/powerpc/boot/virtex405-head.S
delete mode 100644 arch/powerpc/configs/40x/ep405_defconfig
delete mode 100644 arch/powerpc/configs/40x/virtex_defconfig
delete mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
delete mode 100644 arch/powerpc/include/asm/asm-405.h
create mode 100644 arch/powerpc/include/asm/idle.h
create mode 100644 arch/powerpc/include/asm/inst.h
delete mode 100644 arch/powerpc/include/asm/nohash/32/slice.h
create mode 100644 arch/powerpc/include/asm/rtas-types.h
delete mode 100644 arch/powerpc/include/asm/xilinx_intc.h
delete mode 100644 arch/powerpc/include/asm/xilinx_pci.h
create mode 100644 arch/powerpc/include/uapi/asm/vas-api.h
create mode 100644 arch/powerpc/lib/inst.c
create mode 100644 arch/powerpc/lib/test_code-patching.S
create mode 100644 arch/powerpc/mm/book3s64/internal.h
create mode 100644 arch/powerpc/mm/kasan/8xx.c
create mode 100644 arch/powerpc/mm/kasan/book3s_32.c
delete mode 100644 arch/powerpc/platforms/40x/ep405.c
delete mode 100644 arch/powerpc/platforms/40x/virtex.c
delete mode 100644 arch/powerpc/platforms/40x/walnut.c
delete mode 100644 arch/powerpc/platforms/44x/virtex.c
delete mode 100644 arch/powerpc/platforms/44x/virtex_ml510.c
create mode 100644 arch/powerpc/platforms/powernv/vas-api.c
create mode 100644 arch/powerpc/platforms/powernv/vas-fault.c
delete mode 100644 arch/powerpc/sysdev/xilinx_intc.c
delete mode 100644 arch/powerpc/sysdev/xilinx_pci.c
create mode 100644 arch/powerpc/xmon/xmon_bpts.S
create mode 100644 arch/powerpc/xmon/xmon_bpts.h
rename drivers/crypto/nx/{nx-842-powernv.c => nx-common-powernv.c} (87%)
delete mode 100644 drivers/input/serio/i8042-ppcio.h
delete mode 100644 sound/drivers/ml403-ac97cr.c
delete mode 100644 sound/drivers/pcm-indirect2.c
delete mode 100644 sound/drivers/pcm-indirect2.h
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/99-nx-gzip.rules
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/Makefile
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/README
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/gunz_test.c
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/gzfht_test.c
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/gzip_vas.c
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/include/copy-paste.h
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/include/crb.h
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/include/nx.h
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/include/nx_dbg.h
create mode 100644 tools/testing/selftests/powerpc/nx-gzip/include/nxu.h
create mode 120000 tools/testing/selftests/powerpc/nx-gzip/include/vas-api.h
create mode 100755 tools/testing/selftests/powerpc/nx-gzip/nx-gzip-test.sh
create mode 100644 tools/testing/selftests/powerpc/pmu/count_stcx_fail.c
create mode 100644 tools/testing/selftests/powerpc/signal/sig_sc_double_restart.c
^ permalink raw reply related
* Re: Boot issue with the latest Git kernel
From: Christian Zigotzky @ 2020-06-05 16:23 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev, jroedel
Cc: Darren Stevens, Christoph Hellwig, R.T.Dickinson,
Christian Zigotzky
In-Reply-To: <014e1268-dcce-61a3-8bcd-a06c43e0dfaf@csgroup.eu>
On 04 June 2020 at 7:15 pm, Christophe Leroy wrote:
> Yes today's linux-next boots on my powerpc 8xx board.
>
> Christophe
Hello Christophe,
Thanks for testing.
I was able to perform a 'git bisect' [1] and identified the bad commit.
[2] I reverted this commit and after that the kernel boots and works
without any problems.
Could you please check this commit?
Thanks,
Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=50772#p50772
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ba3e6947aed9bb9575eb1603c0ac6e39185d32a
^ permalink raw reply
* Re: [PATCH v2] cxl: Remove dead Kconfig option
From: Michael Ellerman @ 2020-06-05 16:16 UTC (permalink / raw)
To: Andrew Donnellan, linuxppc-dev; +Cc: fbarrat
In-Reply-To: <20200602070545.11942-1-ajd@linux.ibm.com>
Andrew Donnellan <ajd@linux.ibm.com> writes:
> The CXL_AFU_DRIVER_OPS Kconfig option was added to coordinate merging of
> new features. It no longer serves any purpose, so remove it.
>
> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
>
> ---
> v1->v2:
> - keep CXL_LIB for now to avoid breaking a driver that is currently out of tree
Sorry I already merged v1.
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