* Re: [PATCH v3 01/17] cmdline: Add generic function to build command line.
From: H. Nikolaus Schaller @ 2021-03-30 18:07 UTC (permalink / raw)
To: Daniel Walker, Christophe Leroy
Cc: linux-arch, Rob Herring, microblaze, daniel, devicetree, linux-sh,
will, linux-xtensa, x86, Linux Kernel Mailing List, nios2,
linux-mips, openrisc, linux-hexagon, sparclinux, linux-riscv,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20210330172714.GR109100@zorba>
> Am 30.03.2021 um 19:27 schrieb Daniel Walker <danielwa@cisco.com>:
>
> On Fri, Mar 26, 2021 at 01:44:48PM +0000, Christophe Leroy wrote:
>> This code provides architectures with a way to build command line
>> based on what is built in the kernel and what is handed over by the
>> bootloader, based on selected compile-time options.
>>
>> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>> ---
>> v3:
>> - Addressed comments from Will
>> - Added capability to have src == dst
>> ---
>> include/linux/cmdline.h | 57 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 57 insertions(+)
>> create mode 100644 include/linux/cmdline.h
>>
>> diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
>> new file mode 100644
>> index 000000000000..dea87edd41be
>> --- /dev/null
>> +++ b/include/linux/cmdline.h
>> @@ -0,0 +1,57 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +#ifndef _LINUX_CMDLINE_H
>> +#define _LINUX_CMDLINE_H
>> +
>> +#include <linux/string.h>
>> +
>> +/* Allow architectures to override strlcat, powerpc can't use strings so early */
>> +#ifndef cmdline_strlcat
>> +#define cmdline_strlcat strlcat
>> +#endif
>> +
>> +/*
>> + * This function will append or prepend a builtin command line to the command
>> + * line provided by the bootloader. Kconfig options can be used to alter
>> + * the behavior of this builtin command line.
>> + * @dst: The destination of the final appended/prepended string.
>> + * @src: The starting string or NULL if there isn't one.
>> + * @len: the length of dest buffer.
>> + */
>
> Append or prepend ? Cisco requires both at the same time. This is why my
> implementation provides both. I can't use this with both at once.
Just an idea: what about defining CMDLINE as a pattern where e.g. "$$" or "%%"
is replaced by the boot loader command line?
Then you can formulate replace, prepend, append, prepend+append with a single
CONFIG setting.
It may be a little more complex in code (scanning for the pattern and replacing
it and take care to temporary memory) but IMHO it could be worth to consider.
BR,
Nikolaus Schaller
^ permalink raw reply
* Re: [PATCH v3 01/17] cmdline: Add generic function to build command line.
From: Daniel Walker @ 2021-03-30 18:23 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: linux-arch, Rob Herring, microblaze, daniel, devicetree, linux-sh,
linuxppc-dev, linux-xtensa, x86, Linux Kernel Mailing List,
linux-mips, openrisc, nios2, linux-hexagon, sparclinux,
linux-riscv, will, linux-arm-kernel
In-Reply-To: <D8C1FBF6-E5C0-4233-BCB8-694274EA28F9@goldelico.com>
On Tue, Mar 30, 2021 at 08:07:30PM +0200, H. Nikolaus Schaller wrote:
>
> > Am 30.03.2021 um 19:27 schrieb Daniel Walker <danielwa@cisco.com>:
> >
> > On Fri, Mar 26, 2021 at 01:44:48PM +0000, Christophe Leroy wrote:
> >> This code provides architectures with a way to build command line
> >> based on what is built in the kernel and what is handed over by the
> >> bootloader, based on selected compile-time options.
> >>
> >> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> >> ---
> >> v3:
> >> - Addressed comments from Will
> >> - Added capability to have src == dst
> >> ---
> >> include/linux/cmdline.h | 57 +++++++++++++++++++++++++++++++++++++++++
> >> 1 file changed, 57 insertions(+)
> >> create mode 100644 include/linux/cmdline.h
> >>
> >> diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
> >> new file mode 100644
> >> index 000000000000..dea87edd41be
> >> --- /dev/null
> >> +++ b/include/linux/cmdline.h
> >> @@ -0,0 +1,57 @@
> >> +/* SPDX-License-Identifier: GPL-2.0 */
> >> +#ifndef _LINUX_CMDLINE_H
> >> +#define _LINUX_CMDLINE_H
> >> +
> >> +#include <linux/string.h>
> >> +
> >> +/* Allow architectures to override strlcat, powerpc can't use strings so early */
> >> +#ifndef cmdline_strlcat
> >> +#define cmdline_strlcat strlcat
> >> +#endif
> >> +
> >> +/*
> >> + * This function will append or prepend a builtin command line to the command
> >> + * line provided by the bootloader. Kconfig options can be used to alter
> >> + * the behavior of this builtin command line.
> >> + * @dst: The destination of the final appended/prepended string.
> >> + * @src: The starting string or NULL if there isn't one.
> >> + * @len: the length of dest buffer.
> >> + */
> >
> > Append or prepend ? Cisco requires both at the same time. This is why my
> > implementation provides both. I can't use this with both at once.
>
> Just an idea: what about defining CMDLINE as a pattern where e.g. "$$" or "%%"
> is replaced by the boot loader command line?
>
> Then you can formulate replace, prepend, append, prepend+append with a single
> CONFIG setting.
>
> It may be a little more complex in code (scanning for the pattern and replacing
> it and take care to temporary memory) but IMHO it could be worth to consider.
In some cases this code could be used extremely early in boot up. For example in the
prom_init.c powerpc code, or in efi changes. The flexibility to find and replace
like that is not always an option due to the nature of the environment. It's not
impossible of course.
Daniel
^ permalink raw reply
* Re: [PATCH 2/8] CMDLINE: drivers: of: ifdef out cmdline section
From: Rob Herring @ 2021-03-30 19:49 UTC (permalink / raw)
To: Daniel Walker
Cc: devicetree, Ruslan Ruslichenko, Daniel Gimpelevich, Frank Rowand,
linuxppc-dev, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, xe-linux-external, Andrew Morton,
Will Deacon
In-Reply-To: <0c4b839f023f87c451c8aa3c4f7a8d92729c2f02.1617126961.git.danielwa@cisco.com>
On Tue, Mar 30, 2021 at 12:57 PM Daniel Walker <danielwa@cisco.com> wrote:
>
> It looks like there's some seepage of cmdline stuff into
> the generic device tree code. This conflicts with the
> generic cmdline implementation so I remove it in the case
> when that's enabled.
>
> Cc: xe-linux-external@cisco.com
> Signed-off-by: Ruslan Ruslichenko <rruslich@cisco.com>
> Signed-off-by: Daniel Walker <danielwa@cisco.com>
> ---
> drivers/of/fdt.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index dcc1dd96911a..d8805cd9717a 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -25,6 +25,7 @@
> #include <linux/serial_core.h>
> #include <linux/sysfs.h>
> #include <linux/random.h>
> +#include <linux/cmdline.h>
>
> #include <asm/setup.h> /* for COMMAND_LINE_SIZE */
> #include <asm/page.h>
> @@ -1050,6 +1051,18 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
>
> /* Retrieve command line */
> p = of_get_flat_dt_prop(node, "bootargs", &l);
> +
> +#if defined(CONFIG_GENERIC_CMDLINE) && defined(CONFIG_GENERIC_CMDLINE_OF)
Moving in the wrong direction... This code already has too many
#ifdef's. I like Christophe's version as it gets rid of all the code
here.
> + /*
> + * The builtin command line will be added here, or it can override
> + * with the DT bootargs.
> + */
> + cmdline_add_builtin(data,
> + (l > 0 ? p : NULL), /* This is sanity checking */
> + COMMAND_LINE_SIZE);
> +#elif defined(CONFIG_GENERIC_CMDLINE)
> + strlcpy(data, p, COMMAND_LINE_SIZE);
> +#else
> if (p != NULL && l > 0)
> strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
>
> @@ -1070,6 +1083,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
> strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> #endif
> #endif /* CONFIG_CMDLINE */
> +#endif /* CONFIG_GENERIC_CMDLINE */
>
> pr_debug("Command line is: %s\n", (char *)data);
>
> --
> 2.25.1
>
^ permalink raw reply
* Re: [PATCH] powerpc/pseries: Only register vio drivers if vio bus exists
From: Tyrel Datwyler @ 2021-03-30 19:57 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: pmenzel
In-Reply-To: <20210316010938.525657-1-mpe@ellerman.id.au>
On 3/15/21 6:09 PM, Michael Ellerman wrote:
> The vio bus is a fake bus, which we use on pseries LPARs (guests) to
> discover devices provided by the hypervisor. There's no need or sense
> in creating the vio bus on bare metal systems.
>
> Which is why commit 4336b9337824 ("powerpc/pseries: Make vio and
> ibmebus initcalls pseries specific") made the initialisation of the
> vio bus only happen in LPARs.
>
> However as a result of that commit we now see errors at boot on bare
> metal systems:
>
> Driver 'hvc_console' was unable to register with bus_type 'vio' because the bus was not initialized.
> Driver 'tpm_ibmvtpm' was unable to register with bus_type 'vio' because the bus was not initialized.
>
> This happens because those drivers are built-in, and are calling
> vio_register_driver(). It in turn calls driver_register() with a
> reference to vio_bus_type, but we haven't registered vio_bus_type with
> the driver core.
>
> Fix it by also guarding vio_register_driver() with a check to see if
> we are on pseries.
>
> Fixes: 4336b9337824 ("powerpc/pseries: Make vio and ibmebus initcalls pseries specific")
> Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> ---
Reviewed-by: Tyrel Datwyler <tyreld@linux.ibm.com>
^ permalink raw reply
* Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
From: Rob Herring @ 2021-03-30 20:13 UTC (permalink / raw)
To: Daniel Walker
Cc: Daniel Gimpelevich, linuxppc-dev, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, Paul Mackerras, xe-linux-external,
Andrew Morton, Will Deacon
In-Reply-To: <20210330173254.GS109100@zorba>
On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker <danielwa@cisco.com> wrote:
>
> On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote:
> > On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker <danielwa@cisco.com> wrote:
> > >
> > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote:
> > > >
> > > > Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.
> > > >
> > > > Let's only provide once CMDLINE as of today, and ask the user to select
> > > > whether he wants it appended or prepended or replacee. Then no need to
> > > > change all existing config to rename CONFIG_CMDLINE into either of the new
> > > > ones.
> > > >
> > > > That's the main difference between my series and Daniel's series. So I'll
> > > > finish taking Will's comment into account and we'll send out a v3 soon.
> > >
> > > It doesn't solve the needs of Cisco, I've stated many times your changes have
> > > little value. Please stop submitting them.
> >
> > Can you please outline what those needs are which aren't met?
>
> append AND prepend at the same time on all architectures. Christophe doesn't
> understand the need, and hence tries to minimize the feature set which is
> incompatible with Cisco needs and all the other out of tree users.
Okay, but that's never been a feature in upstream. For upstream, we
refactor first and add features 2nd. In this case, the difference is
largely the kconfig and it would be better to not change the options
twice, but that's not a blocker for taking the refactoring. You won't
find a maintainer that's going to take adding a feature over cleanups
and unification.
Rob
^ permalink raw reply
* Re: [PATCH 14/30] Revert "s3c24xx-dma.c: Fix a typo"
From: Bhaskar Chowdhury @ 2021-03-30 21:12 UTC (permalink / raw)
To: Vinod Koul
Cc: dave.jiang, rdunlap, linux-kernel, dri-devel, iommu, dmaengine,
dan.j.williams, linuxppc-dev, hch
In-Reply-To: <YGNgFuLWc91aGoQj@vkoul-mobl.Dlink>
[-- Attachment #1: Type: text/plain, Size: 579 bytes --]
On 22:59 Tue 30 Mar 2021, Vinod Koul wrote:
>On 29-03-21, 05:23, Bhaskar Chowdhury wrote:
>> s/transferred/transfered/
>>
>> This reverts commit a2ddb8aea8106bd5552f8516ad7a8a26b9282a8f.
>
>This is not upstream, why not squash in. Also would make sense to write
>sensible changelog and not phrases and use the right subsystem
>conventions!
>
Changes like this don't deserve a history to tell, specific to changelog, one
line is suffice.
>Droped the series now
>
This is a bad commit slip in , not suppose to be there, thanks for catching
it.
Sorry for the noise.
>
>--
>~Vinod
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 24/30] Kconfig: Change Synopsys to Synopsis
From: Bhaskar Chowdhury @ 2021-03-30 21:14 UTC (permalink / raw)
To: Robin Murphy
Cc: dave.jiang, rdunlap, linux-kernel, dri-devel, iommu, dmaengine,
dan.j.williams, linuxppc-dev, hch
In-Reply-To: <8f80fb1b-b2d0-b66a-24b0-bd92dc6cd4b6@arm.com>
[-- Attachment #1: Type: text/plain, Size: 2285 bytes --]
On 12:43 Tue 30 Mar 2021, Robin Murphy wrote:
>On 2021-03-29 00:53, Bhaskar Chowdhury wrote:
>> s/Synopsys/Synopsis/ .....two different places.
>
>Erm, that is definitely not a typo... :/
>
>> ..and for some unknown reason it introduce a empty line deleted and added
>> back.
>
>Presumably your editor is configured to trim trailing whitespace on save.
>
>Furthermore, there are several instances in the other patches where your
>"corrections" are grammatically incorrect, I'm not sure what the deal is
>with patch #14, and you've also used the wrong subsystem name (it should
>be "dmaengine"). It's great to want to clean things up, but please pay a
>bit of care and attention to what you're actually doing.
Thank you so much, I shall be more careful.
>
>Robin.
>
>> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
>> ---
>> drivers/dma/Kconfig | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
>> index 0c2827fd8c19..30e8cc26f43b 100644
>> --- a/drivers/dma/Kconfig
>> +++ b/drivers/dma/Kconfig
>> @@ -170,15 +170,15 @@ config DMA_SUN6I
>> Support for the DMA engine first found in Allwinner A31 SoCs.
>>
>> config DW_AXI_DMAC
>> - tristate "Synopsys DesignWare AXI DMA support"
>> + tristate "Synopsis DesignWare AXI DMA support"
>> depends on OF || COMPILE_TEST
>> depends on HAS_IOMEM
>> select DMA_ENGINE
>> select DMA_VIRTUAL_CHANNELS
>> help
>> - Enable support for Synopsys DesignWare AXI DMA controller.
>> + Enable support for Synopsis DesignWare AXI DMA controller.
>> NOTE: This driver wasn't tested on 64 bit platform because
>> - of lack 64 bit platform with Synopsys DW AXI DMAC.
>> + of lack 64 bit platform with Synopsis DW AXI DMAC.
>>
>> config EP93XX_DMA
>> bool "Cirrus Logic EP93xx DMA support"
>> @@ -394,7 +394,7 @@ config MOXART_DMA
>> select DMA_VIRTUAL_CHANNELS
>> help
>> Enable support for the MOXA ART SoC DMA controller.
>> -
>> +
>> Say Y here if you enabled MMP ADMA, otherwise say N.
>>
>> config MPC512X_DMA
>> --
>> 2.26.3
>>
>> _______________________________________________
>> iommu mailing list
>> iommu@lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] MAINTAINERS: Update entry for ibmvmc driver
From: Brad Warrum @ 2021-03-30 21:22 UTC (permalink / raw)
To: Arnd Bergmann, Greg Kroah-Hartman
Cc: Steven Royer, linuxppc-dev, Brad Warrum, Ritu Agarwal,
linux-kernel
Steve Royer has moved on to a different project and has asked
that Ritu and I take over maintainership of the IBM Power
Virtual Management Channel Driver.
Signed-off-by: Brad Warrum <bwarrum@linux.ibm.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6e91994b8d3b..d9fb56b544c6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8544,7 +8544,8 @@ S: Supported
F: drivers/scsi/ibmvscsi/ibmvfc*
IBM Power Virtual Management Channel Driver
-M: Steven Royer <seroyer@linux.ibm.com>
+M: Brad Warrum <bwarrum@linux.ibm.com>
+M: Ritu Agarwal <rituagar@linux.ibm.com>
S: Supported
F: drivers/misc/ibmvmc.*
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/8] CMDLINE: drivers: of: ifdef out cmdline section
From: Daniel Walker @ 2021-03-30 23:17 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Ruslan Ruslichenko, Daniel Gimpelevich, Frank Rowand,
linuxppc-dev, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, xe-linux-external, Andrew Morton,
Will Deacon
In-Reply-To: <CAL_Jsq+_gF9Cy7H6ic2q8dxnPf4+FsBa5pFYYRydJsEmDhnNhA@mail.gmail.com>
On Tue, Mar 30, 2021 at 02:49:13PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 12:57 PM Daniel Walker <danielwa@cisco.com> wrote:
> >
> > It looks like there's some seepage of cmdline stuff into
> > the generic device tree code. This conflicts with the
> > generic cmdline implementation so I remove it in the case
> > when that's enabled.
> >
> > Cc: xe-linux-external@cisco.com
> > Signed-off-by: Ruslan Ruslichenko <rruslich@cisco.com>
> > Signed-off-by: Daniel Walker <danielwa@cisco.com>
> > ---
> > drivers/of/fdt.c | 14 ++++++++++++++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index dcc1dd96911a..d8805cd9717a 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -25,6 +25,7 @@
> > #include <linux/serial_core.h>
> > #include <linux/sysfs.h>
> > #include <linux/random.h>
> > +#include <linux/cmdline.h>
> >
> > #include <asm/setup.h> /* for COMMAND_LINE_SIZE */
> > #include <asm/page.h>
> > @@ -1050,6 +1051,18 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
> >
> > /* Retrieve command line */
> > p = of_get_flat_dt_prop(node, "bootargs", &l);
> > +
> > +#if defined(CONFIG_GENERIC_CMDLINE) && defined(CONFIG_GENERIC_CMDLINE_OF)
>
> Moving in the wrong direction... This code already has too many
> #ifdef's. I like Christophe's version as it gets rid of all the code
> here.
It's temporary .. Notice CONFIG_GENERIC_CMDLINE_OF is only used on PowerPC. I
experienced doubling on arm64 when this was used (i.e. the append and prepend
was added twice).
I don't think there are any other users which can't be moved outside the device
tree code, but powerpc uses this function three times during boot up plus the
prom_init user. It's possible to use the generic command line in all four places,
but it become space inefficient.
So the plan would be make the other architectures call the generic cmdline
directly without this code, then powerpc would need to be reworked to call the
generic commandline in it's own code hopefully just once.
The end results would be this section would reduce down to one string copy and
no command line stuff.
Maybe you would rather I just use the generic command line in those three place
and reduce this at the space code of powerpc ?
Daniel
^ permalink raw reply
* Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
From: Daniel Walker @ 2021-03-30 23:31 UTC (permalink / raw)
To: Rob Herring
Cc: Daniel Gimpelevich, linuxppc-dev, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, Paul Mackerras, xe-linux-external,
Andrew Morton, Will Deacon
In-Reply-To: <CAL_JsqJKBeAgaHQJwOL9G2qLbQSh32L5LtN+cSUgn5sV_P8How@mail.gmail.com>
On Tue, Mar 30, 2021 at 03:13:04PM -0500, Rob Herring wrote:
> On Tue, Mar 30, 2021 at 12:33 PM Daniel Walker <danielwa@cisco.com> wrote:
> >
> > On Thu, Mar 25, 2021 at 05:29:44PM -0600, Rob Herring wrote:
> > > On Thu, Mar 25, 2021 at 2:00 PM Daniel Walker <danielwa@cisco.com> wrote:
> > > >
> > > > On Thu, Mar 25, 2021 at 01:03:55PM +0100, Christophe Leroy wrote:
> > > > >
> > > > > Ok, so you agree we don't need to provide two CMDLINE, one to be appended and one to be prepended.
> > > > >
> > > > > Let's only provide once CMDLINE as of today, and ask the user to select
> > > > > whether he wants it appended or prepended or replacee. Then no need to
> > > > > change all existing config to rename CONFIG_CMDLINE into either of the new
> > > > > ones.
> > > > >
> > > > > That's the main difference between my series and Daniel's series. So I'll
> > > > > finish taking Will's comment into account and we'll send out a v3 soon.
> > > >
> > > > It doesn't solve the needs of Cisco, I've stated many times your changes have
> > > > little value. Please stop submitting them.
> > >
> > > Can you please outline what those needs are which aren't met?
> >
> > append AND prepend at the same time on all architectures. Christophe doesn't
> > understand the need, and hence tries to minimize the feature set which is
> > incompatible with Cisco needs and all the other out of tree users.
>
> Okay, but that's never been a feature in upstream. For upstream, we
> refactor first and add features 2nd. In this case, the difference is
> largely the kconfig and it would be better to not change the options
> twice, but that's not a blocker for taking the refactoring. You won't
> find a maintainer that's going to take adding a feature over cleanups
> and unification.
It kind of is a feature in upstream, it's a matter of opinion. Some platform
used append and some use prepend, and it's likely because the maintainers needed
one or the other for development.
I'm not sure why you think I can't add the features in one go. It would be
horrid to take Christophe's changes, then have to do basically all the same work
a second time which is what Christophe's changes would force me to do.
Say for example I implement this change only on one architecture. In that case
the maintainer would be accepting a feature enhancement , but there would be no
stopping it. I shouldn't have to go two strokes on one architecture, but each
change I'm making is essentially a single architecture. They can go in all
together or one at a time.
Daniel
^ permalink raw reply
* [PATCH v2 3/6] powerpc/64s: Use htab_convert_pte_flags() in hash__mark_rodata_ro()
From: Michael Ellerman @ 2021-03-31 0:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20210331003845.216246-1-mpe@ellerman.id.au>
In hash__mark_rodata_ro() we pass the raw PP_RXXX value to
hash__change_memory_range(). That has the effect of setting the key to
zero, because PP_RXXX contains no key value.
Fix it by using htab_convert_pte_flags(), which knows how to convert a
pgprot into a pp value, including the key.
Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Daniel Axtens <dja@axtens.net>
---
arch/powerpc/mm/book3s64/hash_pgtable.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
v2: Unchanged.
diff --git a/arch/powerpc/mm/book3s64/hash_pgtable.c b/arch/powerpc/mm/book3s64/hash_pgtable.c
index 567e0c6b3978..03819c259f0a 100644
--- a/arch/powerpc/mm/book3s64/hash_pgtable.c
+++ b/arch/powerpc/mm/book3s64/hash_pgtable.c
@@ -428,12 +428,14 @@ static bool hash__change_memory_range(unsigned long start, unsigned long end,
void hash__mark_rodata_ro(void)
{
- unsigned long start, end;
+ unsigned long start, end, pp;
start = (unsigned long)_stext;
end = (unsigned long)__init_begin;
- WARN_ON(!hash__change_memory_range(start, end, PP_RXXX));
+ pp = htab_convert_pte_flags(pgprot_val(PAGE_KERNEL_ROX), HPTE_USE_KERNEL_KEY);
+
+ WARN_ON(!hash__change_memory_range(start, end, pp));
}
void hash__mark_initmem_nx(void)
--
2.25.1
^ permalink raw reply related
* [PATCH v2 5/6] powerpc/mm/64s/hash: Add real-mode change_memory_range() for hash LPAR
From: Michael Ellerman @ 2021-03-31 0:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20210331003845.216246-1-mpe@ellerman.id.au>
When we enabled STRICT_KERNEL_RWX we received some reports of boot
failures when using the Hash MMU and running under phyp. The crashes
are intermittent, and often exhibit as a completely unresponsive
system, or possibly an oops.
One example, which was caught in xmon:
[ 14.068327][ T1] devtmpfs: mounted
[ 14.069302][ T1] Freeing unused kernel memory: 5568K
[ 14.142060][ T347] BUG: Unable to handle kernel instruction fetch
[ 14.142063][ T1] Run /sbin/init as init process
[ 14.142074][ T347] Faulting instruction address: 0xc000000000004400
cpu 0x2: Vector: 400 (Instruction Access) at [c00000000c7475e0]
pc: c000000000004400: exc_virt_0x4400_instruction_access+0x0/0x80
lr: c0000000001862d4: update_rq_clock+0x44/0x110
sp: c00000000c747880
msr: 8000000040001031
current = 0xc00000000c60d380
paca = 0xc00000001ec9de80 irqmask: 0x03 irq_happened: 0x01
pid = 347, comm = kworker/2:1
...
enter ? for help
[c00000000c747880] c0000000001862d4 update_rq_clock+0x44/0x110 (unreliable)
[c00000000c7478f0] c000000000198794 update_blocked_averages+0xb4/0x6d0
[c00000000c7479f0] c000000000198e40 update_nohz_stats+0x90/0xd0
[c00000000c747a20] c0000000001a13b4 _nohz_idle_balance+0x164/0x390
[c00000000c747b10] c0000000001a1af8 newidle_balance+0x478/0x610
[c00000000c747be0] c0000000001a1d48 pick_next_task_fair+0x58/0x480
[c00000000c747c40] c000000000eaab5c __schedule+0x12c/0x950
[c00000000c747cd0] c000000000eab3e8 schedule+0x68/0x120
[c00000000c747d00] c00000000016b730 worker_thread+0x130/0x640
[c00000000c747da0] c000000000174d50 kthread+0x1a0/0x1b0
[c00000000c747e10] c00000000000e0f0 ret_from_kernel_thread+0x5c/0x6c
This shows that CPU 2, which was idle, woke up and then appears to
randomly take an instruction fault on a completely valid area of
kernel text.
The cause turns out to be the call to hash__mark_rodata_ro(), late in
boot. Due to the way we layout text and rodata, that function actually
changes the permissions for all of text and rodata to read-only plus
execute.
To do the permission change we use a hypervisor call, H_PROTECT. On
phyp that appears to be implemented by briefly removing the mapping of
the kernel text, before putting it back with the updated permissions.
If any other CPU is executing during that window, it will see spurious
faults on the kernel text and/or data, leading to crashes.
To fix it we use stop machine to collect all other CPUs, and then have
them drop into real mode (MMU off), while we change the mapping. That
way they are unaffected by the mapping temporarily disappearing.
We don't see this bug on KVM because KVM always use VPM=1, where
faults are directed to the hypervisor, and the fault will be
serialised vs the h_protect() by HPTE_V_HVLOCK.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/mm/book3s64/hash_pgtable.c | 105 +++++++++++++++++++++++-
1 file changed, 104 insertions(+), 1 deletion(-)
v2: Add mention of why we don't see the issue on KVM.
Use hard_irq_disable() not __hard_EE_RI_disable() as noticed by Nick.
diff --git a/arch/powerpc/mm/book3s64/hash_pgtable.c b/arch/powerpc/mm/book3s64/hash_pgtable.c
index 3663d3cdffac..ad5eff097d31 100644
--- a/arch/powerpc/mm/book3s64/hash_pgtable.c
+++ b/arch/powerpc/mm/book3s64/hash_pgtable.c
@@ -8,6 +8,7 @@
#include <linux/sched.h>
#include <linux/mm_types.h>
#include <linux/mm.h>
+#include <linux/stop_machine.h>
#include <asm/sections.h>
#include <asm/mmu.h>
@@ -400,6 +401,19 @@ EXPORT_SYMBOL_GPL(hash__has_transparent_hugepage);
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#ifdef CONFIG_STRICT_KERNEL_RWX
+
+struct change_memory_parms {
+ unsigned long start, end, newpp;
+ unsigned int step, nr_cpus, master_cpu;
+ atomic_t cpu_counter;
+};
+
+// We'd rather this was on the stack but it has to be in the RMO
+static struct change_memory_parms chmem_parms;
+
+// And therefore we need a lock to protect it from concurrent use
+static DEFINE_MUTEX(chmem_lock);
+
static void change_memory_range(unsigned long start, unsigned long end,
unsigned int step, unsigned long newpp)
{
@@ -414,6 +428,73 @@ static void change_memory_range(unsigned long start, unsigned long end,
mmu_kernel_ssize);
}
+static int notrace chmem_secondary_loop(struct change_memory_parms *parms)
+{
+ unsigned long msr, tmp, flags;
+ int *p;
+
+ p = &parms->cpu_counter.counter;
+
+ local_irq_save(flags);
+ hard_irq_disable();
+
+ asm volatile (
+ // Switch to real mode and leave interrupts off
+ "mfmsr %[msr] ;"
+ "li %[tmp], %[MSR_IR_DR] ;"
+ "andc %[tmp], %[msr], %[tmp] ;"
+ "mtmsrd %[tmp] ;"
+
+ // Tell the master we are in real mode
+ "1: "
+ "lwarx %[tmp], 0, %[p] ;"
+ "addic %[tmp], %[tmp], -1 ;"
+ "stwcx. %[tmp], 0, %[p] ;"
+ "bne- 1b ;"
+
+ // Spin until the counter goes to zero
+ "2: ;"
+ "lwz %[tmp], 0(%[p]) ;"
+ "cmpwi %[tmp], 0 ;"
+ "bne- 2b ;"
+
+ // Switch back to virtual mode
+ "mtmsrd %[msr] ;"
+
+ : // outputs
+ [msr] "=&r" (msr), [tmp] "=&b" (tmp), "+m" (*p)
+ : // inputs
+ [p] "b" (p), [MSR_IR_DR] "i" (MSR_IR | MSR_DR)
+ : // clobbers
+ "cc", "xer"
+ );
+
+ local_irq_restore(flags);
+
+ return 0;
+}
+
+static int change_memory_range_fn(void *data)
+{
+ struct change_memory_parms *parms = data;
+
+ if (parms->master_cpu != smp_processor_id())
+ return chmem_secondary_loop(parms);
+
+ // Wait for all but one CPU (this one) to call-in
+ while (atomic_read(&parms->cpu_counter) > 1)
+ barrier();
+
+ change_memory_range(parms->start, parms->end, parms->step, parms->newpp);
+
+ mb();
+
+ // Signal the other CPUs that we're done
+ atomic_dec(&parms->cpu_counter);
+
+ return 0;
+}
+
static bool hash__change_memory_range(unsigned long start, unsigned long end,
unsigned long newpp)
{
@@ -428,7 +509,29 @@ static bool hash__change_memory_range(unsigned long start, unsigned long end,
if (start >= end)
return false;
- change_memory_range(start, end, step, newpp);
+ if (firmware_has_feature(FW_FEATURE_LPAR)) {
+ mutex_lock(&chmem_lock);
+
+ chmem_parms.start = start;
+ chmem_parms.end = end;
+ chmem_parms.step = step;
+ chmem_parms.newpp = newpp;
+ chmem_parms.master_cpu = smp_processor_id();
+
+ cpus_read_lock();
+
+ atomic_set(&chmem_parms.cpu_counter, num_online_cpus());
+
+ // Ensure state is consistent before we call the other CPUs
+ mb();
+
+ stop_machine_cpuslocked(change_memory_range_fn, &chmem_parms,
+ cpu_online_mask);
+
+ cpus_read_unlock();
+ mutex_unlock(&chmem_lock);
+ } else
+ change_memory_range(start, end, step, newpp);
return true;
}
--
2.25.1
^ permalink raw reply related
* [PATCH v2 6/6] powerpc/mm/64s: Allow STRICT_KERNEL_RWX again
From: Michael Ellerman @ 2021-03-31 0:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20210331003845.216246-1-mpe@ellerman.id.au>
We have now fixed the known bugs in STRICT_KERNEL_RWX for Book3S
64-bit Hash and Radix MMUs, see preceding commits, so allow the
option to be selected again.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
v2: Unchanged.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c1344c05226c..2a99ca409117 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -135,7 +135,7 @@ config PPC
select ARCH_HAS_MEMBARRIER_CALLBACKS
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_SCALED_CPUTIME if VIRT_CPU_ACCOUNTING_NATIVE && PPC_BOOK3S_64
- select ARCH_HAS_STRICT_KERNEL_RWX if (PPC32 && !HIBERNATION)
+ select ARCH_HAS_STRICT_KERNEL_RWX if ((PPC_BOOK3S_64 || PPC32) && !HIBERNATION)
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UACCESS_FLUSHCACHE
select ARCH_HAS_COPY_MC if PPC64
--
2.25.1
^ permalink raw reply related
* [PATCH v2 4/6] powerpc/mm/64s/hash: Factor out change_memory_range()
From: Michael Ellerman @ 2021-03-31 0:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20210331003845.216246-1-mpe@ellerman.id.au>
Pull the loop calling hpte_updateboltedpp() out of
hash__change_memory_range() into a helper function. We need it to be a
separate function for the next patch.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/mm/book3s64/hash_pgtable.c | 23 +++++++++++++++--------
1 file changed, 15 insertions(+), 8 deletions(-)
v2: Unchanged.
diff --git a/arch/powerpc/mm/book3s64/hash_pgtable.c b/arch/powerpc/mm/book3s64/hash_pgtable.c
index 03819c259f0a..3663d3cdffac 100644
--- a/arch/powerpc/mm/book3s64/hash_pgtable.c
+++ b/arch/powerpc/mm/book3s64/hash_pgtable.c
@@ -400,10 +400,23 @@ EXPORT_SYMBOL_GPL(hash__has_transparent_hugepage);
#endif /* CONFIG_TRANSPARENT_HUGEPAGE */
#ifdef CONFIG_STRICT_KERNEL_RWX
+static void change_memory_range(unsigned long start, unsigned long end,
+ unsigned int step, unsigned long newpp)
+{
+ unsigned long idx;
+
+ pr_debug("Changing page protection on range 0x%lx-0x%lx, to 0x%lx, step 0x%x\n",
+ start, end, newpp, step);
+
+ for (idx = start; idx < end; idx += step)
+ /* Not sure if we can do much with the return value */
+ mmu_hash_ops.hpte_updateboltedpp(newpp, idx, mmu_linear_psize,
+ mmu_kernel_ssize);
+}
+
static bool hash__change_memory_range(unsigned long start, unsigned long end,
unsigned long newpp)
{
- unsigned long idx;
unsigned int step, shift;
shift = mmu_psize_defs[mmu_linear_psize].shift;
@@ -415,13 +428,7 @@ static bool hash__change_memory_range(unsigned long start, unsigned long end,
if (start >= end)
return false;
- pr_debug("Changing page protection on range 0x%lx-0x%lx, to 0x%lx, step 0x%x\n",
- start, end, newpp, step);
-
- for (idx = start; idx < end; idx += step)
- /* Not sure if we can do much with the return value */
- mmu_hash_ops.hpte_updateboltedpp(newpp, idx, mmu_linear_psize,
- mmu_kernel_ssize);
+ change_memory_range(start, end, step, newpp);
return true;
}
--
2.25.1
^ permalink raw reply related
* [PATCH v2 1/6] powerpc/mm/64s: Add _PAGE_KERNEL_ROX
From: Michael Ellerman @ 2021-03-31 0:38 UTC (permalink / raw)
To: linuxppc-dev
In the past we had a fallback definition for _PAGE_KERNEL_ROX, but we
removed that in commit d82fd29c5a8c ("powerpc/mm: Distribute platform
specific PAGE and PMD flags and definitions") and added definitions
for each MMU family.
However we missed adding a definition for 64s, which was not really a
bug because it's currently not used.
But we'd like to use PAGE_KERNEL_ROX in a future patch so add a
definition now.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/include/asm/book3s/64/pgtable.h | 1 +
1 file changed, 1 insertion(+)
v2: Unchanged.
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 058601efbc8a..0c89977ec10b 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -116,6 +116,7 @@
*/
#define _PAGE_KERNEL_RW (_PAGE_PRIVILEGED | _PAGE_RW | _PAGE_DIRTY)
#define _PAGE_KERNEL_RO (_PAGE_PRIVILEGED | _PAGE_READ)
+#define _PAGE_KERNEL_ROX (_PAGE_PRIVILEGED | _PAGE_READ | _PAGE_EXEC)
#define _PAGE_KERNEL_RWX (_PAGE_PRIVILEGED | _PAGE_DIRTY | \
_PAGE_RW | _PAGE_EXEC)
/*
--
2.25.1
^ permalink raw reply related
* [PATCH v2 2/6] powerpc/pseries: Add key to flags in pSeries_lpar_hpte_updateboltedpp()
From: Michael Ellerman @ 2021-03-31 0:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20210331003845.216246-1-mpe@ellerman.id.au>
The flags argument to plpar_pte_protect() (aka. H_PROTECT), includes
the key in bits 9-13, but currently we always set those bits to zero.
In the past that hasn't been a problem because we always used key 0
for the kernel, and updateboltedpp() is only used for kernel mappings.
However since commit d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3
for kernel mapping with hash translation") we are now inadvertently
changing the key (to zero) when we call plpar_pte_protect().
That hasn't broken anything because updateboltedpp() is only used for
STRICT_KERNEL_RWX, which is currently disabled on 64s due to other
bugs.
But we want to fix that, so first we need to pass the key correctly to
plpar_pte_protect(). We can't pass our newpp value directly in, we
have to convert it into the form expected by the hcall.
The hcall we're using here is H_PROTECT, which is specified in section
14.5.4.1.6 of LoPAPR v1.1.
It takes a `flags` parameter, and the description for flags says:
* flags: AVPN, pp0, pp1, pp2, key0-key4, n, and for the CMO
option: CMO Option flags as defined in Table 189‚
If you then go to the start of the parent section, 14.5.4.1, on page
405, it says:
Register Linkage (For hcall() tokens 0x04 - 0x18)
* On Call
* R3 function call token
* R4 flags (see Table 178‚ “Page Frame Table Access flags field
definition‚” on page 401)
Then you have to go to section 14.5.3, and on page 394 there is a list
of hcalls and their tokens (table 176), and there you can see that
H_PROTECT == 0x18.
Finally you can look at table 178, on page 401, where it specifies the
layout of the bits for the key:
Bit Function
-----------------
50-54 | key0-key4
Those are big-endian bit numbers, converting to normal bit numbers you
get bits 9-13, or 0x3e00.
In the kernel we have:
#define HPTE_R_KEY_HI ASM_CONST(0x3000000000000000)
#define HPTE_R_KEY_LO ASM_CONST(0x0000000000000e00)
So the LO bits of newpp are already in the right place, and the HI
bits need to be shifted down by 48.
Fixes: d94b827e89dc ("powerpc/book3s64/kuap: Use Key 3 for kernel mapping with hash translation")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/pseries/lpar.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
v2: Expand change log with explanation of where the format of the
flags parameter comes from, prompted by dja.
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 764170fdb0f7..8bbbddff7226 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -976,11 +976,13 @@ static void pSeries_lpar_hpte_updateboltedpp(unsigned long newpp,
slot = pSeries_lpar_hpte_find(vpn, psize, ssize);
BUG_ON(slot == -1);
- flags = newpp & 7;
+ flags = newpp & (HPTE_R_PP | HPTE_R_N);
if (mmu_has_feature(MMU_FTR_KERNEL_RO))
/* Move pp0 into bit 8 (IBM 55) */
flags |= (newpp & HPTE_R_PP0) >> 55;
+ flags |= ((newpp & HPTE_R_KEY_HI) >> 48) | (newpp & HPTE_R_KEY_LO);
+
lpar_rc = plpar_pte_protect(flags, slot, 0);
BUG_ON(lpar_rc != H_SUCCESS);
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] powerpc/book3s64/kuap: Move Kconfig varriables to BOOK3S_64
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: mpe, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20210318034829.72255-1-aneesh.kumar@linux.ibm.com>
On Thu, 18 Mar 2021 09:18:29 +0530, Aneesh Kumar K.V wrote:
> With below two commits:
> commit c91435d95c49 ("powerpc/book3s64/hash/kuep: Enable KUEP on hash")
> commit b2ff33a10c8b ("powerpc/book3s64/hash/kuap: Enable kuap on hash")
> the kernel now supports kuap/kuep with hash translation. Hence select the
> Kconfig even when radix is disabled.
Applied to powerpc/next.
[1/1] powerpc/book3s64/kuap: Move Kconfig varriables to BOOK3S_64
https://git.kernel.org/powerpc/c/8b8adeb3007f67076141f547f0b2f62b299a383c
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Move the linear_mapping_mutex to the ifdef where it is used
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: linuxppc-dev, Sebastian Andrzej Siewior; +Cc: Thomas Gleixner, Paul Mackerras
In-Reply-To: <20210219165648.2505482-1-bigeasy@linutronix.de>
On Fri, 19 Feb 2021 17:56:48 +0100, Sebastian Andrzej Siewior wrote:
> The mutex linear_mapping_mutex is defined at the of the file while its
> only two user are within the CONFIG_MEMORY_HOTPLUG block.
> A compile without CONFIG_MEMORY_HOTPLUG set fails on PREEMPT_RT because
> its mutex implementation is smart enough to realize that it is unused.
>
> Move the definition of linear_mapping_mutex to ifdef block where it is
> used.
Applied to powerpc/next.
[1/1] powerpc/mm: Move the linear_mapping_mutex to the ifdef where it is used
https://git.kernel.org/powerpc/c/9be77e11dade414d2fa63750aa5c754fac49d619
cheers
^ permalink raw reply
* Re: [PATCH] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: Michael Ellerman, Chen Huang, Paul Mackerras,
Benjamin Herrenschmidt
Cc: Don Zickus, linux-kernel, Nicholas Piggin, Hulk Robot,
Andrew Morton, linuxppc-dev
In-Reply-To: <20210327094900.938555-1-chenhuang5@huawei.com>
On Sat, 27 Mar 2021 09:49:00 +0000, Chen Huang wrote:
> When compiling the powerpc with the SMP disabled, it shows the issue:
>
> arch/powerpc/kernel/watchdog.c: In function ‘watchdog_smp_panic’:
> arch/powerpc/kernel/watchdog.c:177:4: error: implicit declaration of function ‘smp_send_nmi_ipi’; did you mean ‘smp_send_stop’? [-Werror=implicit-function-declaration]
> 177 | smp_send_nmi_ipi(c, wd_lockup_ipi, 1000000);
> | ^~~~~~~~~~~~~~~~
> | smp_send_stop
> cc1: all warnings being treated as errors
> make[2]: *** [scripts/Makefile.build:273: arch/powerpc/kernel/watchdog.o] Error 1
> make[1]: *** [scripts/Makefile.build:534: arch/powerpc/kernel] Error 2
> make: *** [Makefile:1980: arch/powerpc] Error 2
> make: *** Waiting for unfinished jobs....
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
https://git.kernel.org/powerpc/c/4fe529449d85e78972fa327999961ecc83a0b6db
cheers
^ permalink raw reply
* Re: [PATCH v2] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Chen Huang, Christophe Leroy,
Benjamin Herrenschmidt
Cc: Don Zickus, linux-kernel, Nicholas Piggin, Hulk Robot,
Andrew Morton, linuxppc-dev
In-Reply-To: <4b8f8335-0a29-93fc-7943-b4dc16efb908@huawei.com>
On Mon, 29 Mar 2021 10:27:00 +0800, Chen Huang wrote:
> When compiling the powerpc with the SMP disabled, it shows the issue:
>
> arch/powerpc/kernel/watchdog.c: In function ‘watchdog_smp_panic’:
> arch/powerpc/kernel/watchdog.c:177:4: error: implicit declaration of function ‘smp_send_nmi_ipi’; did you mean ‘smp_send_stop’? [-Werror=implicit-function-declaration]
> 177 | smp_send_nmi_ipi(c, wd_lockup_ipi, 1000000);
> | ^~~~~~~~~~~~~~~~
> | smp_send_stop
> cc1: all warnings being treated as errors
> make[2]: *** [scripts/Makefile.build:273: arch/powerpc/kernel/watchdog.o] Error 1
> make[1]: *** [scripts/Makefile.build:534: arch/powerpc/kernel] Error 2
> make: *** [Makefile:1980: arch/powerpc] Error 2
> make: *** Waiting for unfinished jobs....
>
> [...]
Applied to powerpc/next.
[1/1] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
https://git.kernel.org/powerpc/c/4fe529449d85e78972fa327999961ecc83a0b6db
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/asm-offsets: GPR14 is not needed either
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, rashmicy, Christophe Leroy,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <9881c68fbca004f9ea18fc9473f630e11ccd6417.1615806071.git.christophe.leroy@csgroup.eu>
On Mon, 15 Mar 2021 11:01:26 +0000 (UTC), Christophe Leroy wrote:
> Commit aac6a91fea93 ("powerpc/asm: Remove unused symbols in
> asm-offsets.c") removed GPR15 to GPR31 but kept GPR14,
> probably because it pops up in a couple of comments when doing
> a grep.
>
> However, it was never used either, so remove it as well.
Applied to powerpc/next.
[1/1] powerpc/asm-offsets: GPR14 is not needed either
https://git.kernel.org/powerpc/c/6eeca7a11379e9dd05493bbdba57515b36a2e3cf
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/embedded6xx: Remove CONFIG_MV64X60
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Christophe Leroy,
Benjamin Herrenschmidt, Wolfram Sang
Cc: linuxppc-dev, linux-kernel, linux-i2c
In-Reply-To: <19e57d16692dcd1ca67ba880d7273a57fab416aa.1616085654.git.christophe.leroy@csgroup.eu>
On Thu, 18 Mar 2021 17:25:07 +0000 (UTC), Christophe Leroy wrote:
> Commit 92c8c16f3457 ("powerpc/embedded6xx: Remove C2K board support")
> moved the last selector of CONFIG_MV64X60.
>
> As it is not a user selectable config, it can be removed.
Applied to powerpc/next.
[1/1] powerpc/embedded6xx: Remove CONFIG_MV64X60
https://git.kernel.org/powerpc/c/a329ddd472fa2af0c19a73b8658898ae7fd658ad
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/Makefile: Remove workaround for gcc versions below 4.9
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Benjamin Herrenschmidt,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <a1e552006b8c51f23edd2f6cabdd9a986c631146.1615380184.git.christophe.leroy@csgroup.eu>
On Wed, 10 Mar 2021 12:43:12 +0000 (UTC), Christophe Leroy wrote:
> Commit 6ec4476ac825 ("Raise gcc version requirement to 4.9")
> made it impossible to build with gcc 4.8 and under.
>
> Remove related workaround.
Applied to powerpc/next.
[1/1] powerpc/Makefile: Remove workaround for gcc versions below 4.9
https://git.kernel.org/powerpc/c/802b5560393423166e436c7914b565f3cda9e6b9
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/math: Fix missing __user qualifier for get_user() and other sparse warnings
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Benjamin Herrenschmidt,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <e4d1aae7604d89c98a52dfd8ce8443462e595670.1615809591.git.christophe.leroy@csgroup.eu>
On Mon, 15 Mar 2021 12:00:09 +0000 (UTC), Christophe Leroy wrote:
> Sparse reports the following problems:
>
> arch/powerpc/math-emu/math.c:228:21: warning: Using plain integer as NULL pointer
> arch/powerpc/math-emu/math.c:228:31: warning: Using plain integer as NULL pointer
> arch/powerpc/math-emu/math.c:228:41: warning: Using plain integer as NULL pointer
> arch/powerpc/math-emu/math.c:228:51: warning: Using plain integer as NULL pointer
> arch/powerpc/math-emu/math.c:237:13: warning: incorrect type in initializer (different address spaces)
> arch/powerpc/math-emu/math.c:237:13: expected unsigned int [noderef] __user *_gu_addr
> arch/powerpc/math-emu/math.c:237:13: got unsigned int [usertype] *
> arch/powerpc/math-emu/math.c:226:1: warning: symbol 'do_mathemu' was not declared. Should it be static?
>
> [...]
Applied to powerpc/next.
[1/1] powerpc/math: Fix missing __user qualifier for get_user() and other sparse warnings
https://git.kernel.org/powerpc/c/e448e1e774dc0ca307c17e961daf7ede2e635c57
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/mm: Remove unneeded #ifdef CONFIG_PPC_MEM_KEYS
From: Michael Ellerman @ 2021-03-31 1:09 UTC (permalink / raw)
To: Michael Ellerman, Paul Mackerras, Benjamin Herrenschmidt,
Christophe Leroy
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <8038392f38d81f2ad169347efac29146f553b238.1615819955.git.christophe.leroy@csgroup.eu>
On Mon, 15 Mar 2021 14:52:51 +0000 (UTC), Christophe Leroy wrote:
> In fault.c, #ifdef CONFIG_PPC_MEM_KEYS is not needed because all
> functions are always defined, and arch_vma_access_permitted()
> always returns true when CONFIG_PPC_MEM_KEYS is not defined so
> access_pkey_error() will return false so bad_access_pkey()
> will never be called.
>
> Include linux/pkeys.h to get a definition of vma_pkeys() for
> bad_access_pkey().
Applied to powerpc/next.
[1/1] powerpc/mm: Remove unneeded #ifdef CONFIG_PPC_MEM_KEYS
https://git.kernel.org/powerpc/c/98c26a72751ecb2ed247cdfd6cb2385f37195707
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