* [PATCH 28/30] usb-dmac.c: Fix a typo
From: Bhaskar Chowdhury @ 2021-03-28 23:53 UTC (permalink / raw)
To: dmaengine, dri-devel, hch, iommu, linuxppc-dev, dave.jiang,
dan.j.williams
Cc: rdunlap, Bhaskar Chowdhury, linux-kernel
In-Reply-To: <cover.1616971780.git.unixbhaskar@gmail.com>
s/descritpor/descriptor/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
drivers/dma/sh/usb-dmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c
index 8f7ceb698226..7092a657932b 100644
--- a/drivers/dma/sh/usb-dmac.c
+++ b/drivers/dma/sh/usb-dmac.c
@@ -301,7 +301,7 @@ static struct usb_dmac_desc *usb_dmac_desc_get(struct usb_dmac_chan *chan,
struct usb_dmac_desc *desc = NULL;
unsigned long flags;
- /* Get a freed descritpor */
+ /* Get a freed descriptor */
spin_lock_irqsave(&chan->vc.lock, flags);
list_for_each_entry(desc, &chan->desc_freed, node) {
if (sg_len <= desc->sg_allocated_len) {
--
2.26.3
^ permalink raw reply related
* [PATCH 29/30] edma.c: Fix a typo
From: Bhaskar Chowdhury @ 2021-03-28 23:53 UTC (permalink / raw)
To: dmaengine, dri-devel, hch, iommu, linuxppc-dev, dave.jiang,
dan.j.williams
Cc: rdunlap, Bhaskar Chowdhury, linux-kernel
In-Reply-To: <cover.1616971780.git.unixbhaskar@gmail.com>
s/transfering/transferring/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
drivers/dma/ti/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index 35d81bd857f1..5ad771e34457 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -1815,7 +1815,7 @@ static void edma_issue_pending(struct dma_chan *chan)
* This limit exists to avoid a possible infinite loop when waiting for proof
* that a particular transfer is completed. This limit can be hit if there
* are large bursts to/from slow devices or the CPU is never able to catch
- * the DMA hardware idle. On an AM335x transfering 48 bytes from the UART
+ * the DMA hardware idle. On an AM335x transferring 48 bytes from the UART
* RX-FIFO, as many as 55 loops have been seen.
*/
#define EDMA_MAX_TR_WAIT_LOOPS 1000
--
2.26.3
^ permalink raw reply related
* [PATCH 30/30] xilinx_dma.c: Fix a typo
From: Bhaskar Chowdhury @ 2021-03-28 23:53 UTC (permalink / raw)
To: dmaengine, dri-devel, hch, iommu, linuxppc-dev, dave.jiang,
dan.j.williams
Cc: rdunlap, Bhaskar Chowdhury, linux-kernel
In-Reply-To: <cover.1616971780.git.unixbhaskar@gmail.com>
s/interace/interface/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
drivers/dma/xilinx/xilinx_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
index 3aded7861fef..63d2f447ad79 100644
--- a/drivers/dma/xilinx/xilinx_dma.c
+++ b/drivers/dma/xilinx/xilinx_dma.c
@@ -483,7 +483,7 @@ struct xilinx_dma_config {
* @ext_addr: Indicates 64 bit addressing is supported by dma device
* @pdev: Platform device structure pointer
* @dma_config: DMA config structure
- * @axi_clk: DMA Axi4-lite interace clock
+ * @axi_clk: DMA Axi4-lite interface clock
* @tx_clk: DMA mm2s clock
* @txs_clk: DMA mm2s stream clock
* @rx_clk: DMA s2mm clock
--
2.26.3
^ permalink raw reply related
* RE: [PATCH v3 09/17] nios2: Convert to GENERIC_CMDLINE
From: Tan, Ley Foon @ 2021-03-29 1:35 UTC (permalink / raw)
To: Christophe Leroy, will@kernel.org, danielwa@cisco.com,
robh@kernel.org, daniel@gimpelevich.san-francisco.ca.us
Cc: linux-arch@vger.kernel.org, devicetree@vger.kernel.org,
microblaze, linux-xtensa@linux-xtensa.org,
linux-sh@vger.kernel.org, linux-hexagon@vger.kernel.org,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-mips@vger.kernel.org, openrisc@lists.librecores.org,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <85b1dc6339351cbc46d179e8fdb9dfc398e58303.1616765870.git.christophe.leroy@csgroup.eu>
> -----Original Message-----
> From: Christophe Leroy <christophe.leroy@csgroup.eu>
> Sent: Friday, March 26, 2021 9:45 PM
> To: will@kernel.org; danielwa@cisco.com; robh@kernel.org;
> daniel@gimpelevich.san-francisco.ca.us
> Cc: linux-arch@vger.kernel.org; devicetree@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org; microblaze
> <monstr@monstr.eu>; linux-mips@vger.kernel.org; Tan, Ley Foon
> <ley.foon.tan@intel.com>; openrisc@lists.librecores.org; linux-
> hexagon@vger.kernel.org; linux-riscv@lists.infradead.org; x86@kernel.org;
> linux-xtensa@linux-xtensa.org; linux-sh@vger.kernel.org;
> sparclinux@vger.kernel.org
> Subject: [PATCH v3 09/17] nios2: Convert to GENERIC_CMDLINE
>
> This converts the architecture to GENERIC_CMDLINE.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/nios2/Kconfig | 24 +-----------------------
> arch/nios2/kernel/setup.c | 13 ++++---------
> 2 files changed, 5 insertions(+), 32 deletions(-)
>
> diff --git a/arch/nios2/Kconfig b/arch/nios2/Kconfig index
> c24955c81c92..f66c97b15813 100644
> --- a/arch/nios2/Kconfig
> +++ b/arch/nios2/Kconfig
> @@ -90,31 +90,9 @@ config NIOS2_ALIGNMENT_TRAP
>
> comment "Boot options"
>
> -config CMDLINE_BOOL
> - bool "Default bootloader kernel arguments"
> - default y
> -
> -config CMDLINE
> - string "Default kernel command string"
> - default ""
> - depends on CMDLINE_BOOL
> - help
> - On some platforms, there is currently no way for the boot loader to
> - pass arguments to the kernel. For these platforms, you can supply
> - some command-line options at build time by entering them here. In
> - other cases you can specify kernel args so that you don't have
> - to set them up in board prom initialization routines.
> -
> -config CMDLINE_FORCE
> - bool "Force default kernel command string"
> - depends on CMDLINE_BOOL
> - help
> - Set this to have arguments from the default kernel command string
> - override those passed by the boot loader.
> -
> config NIOS2_CMDLINE_IGNORE_DTB
> bool "Ignore kernel command string from DTB"
> - depends on CMDLINE_BOOL
> + depends on CMDLINE != ""
> depends on !CMDLINE_FORCE
> default y
> help
Missing " select GENERIC_CMDLINE" ?
> diff --git a/arch/nios2/kernel/setup.c b/arch/nios2/kernel/setup.c index
> d2f21957e99c..42464f457a6d 100644
> --- a/arch/nios2/kernel/setup.c
> +++ b/arch/nios2/kernel/setup.c
> @@ -20,6 +20,7 @@
> #include <linux/initrd.h>
> #include <linux/of_fdt.h>
> #include <linux/screen_info.h>
> +#include <linux/cmdline.h>
>
> #include <asm/mmu_context.h>
> #include <asm/sections.h>
> @@ -108,7 +109,7 @@ asmlinkage void __init nios2_boot_init(unsigned r4,
> unsigned r5, unsigned r6,
> unsigned r7)
> {
> unsigned dtb_passed = 0;
> - char cmdline_passed[COMMAND_LINE_SIZE] __maybe_unused =
> { 0, };
> + char cmdline_passed[COMMAND_LINE_SIZE] = { 0, };
>
> #if defined(CONFIG_NIOS2_PASS_CMDLINE)
> if (r4 == 0x534f494e) { /* r4 is magic NIOS */ @@ -127,14 +128,8 @@
> asmlinkage void __init nios2_boot_init(unsigned r4, unsigned r5, unsigned r6,
>
> early_init_devtree((void *)dtb_passed);
>
> -#ifndef CONFIG_CMDLINE_FORCE
> - if (cmdline_passed[0])
> - strlcpy(boot_command_line, cmdline_passed,
> COMMAND_LINE_SIZE);
> -#ifdef CONFIG_NIOS2_CMDLINE_IGNORE_DTB
> - else
> - strlcpy(boot_command_line, CONFIG_CMDLINE,
> COMMAND_LINE_SIZE);
> -#endif
> -#endif
> + if (cmdline_passed[0] ||
> IS_ENABLED(CONFIG_NIOS2_CMDLINE_IGNORE_DTB))
> + cmdline_build(boot_command_line, cmdline_passed,
> COMMAND_LINE_SIZE);
>
> parse_early_param();
> }
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
From: Chen Huang @ 2021-03-29 2:00 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: Don Zickus, linux-kernel, Nicholas Piggin, Hulk Robot,
Andrew Morton, linuxppc-dev
In-Reply-To: <dd6b25d3-006b-be1e-9c4f-89e66aefb519@csgroup.eu>
在 2021/3/28 19:06, Christophe Leroy 写道:
>
>
> Le 27/03/2021 à 10:49, Chen Huang a écrit :
>> 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....
>>
>> We found that powerpc used ipi to implement hardlockup watchdog, so the
>> HAVE_HARDLOCKUP_DETECTOR_ARCH should depend on the SMP.
>>
>> Fixes: 2104180a5369 ("powerpc/64s: implement arch-specific hardlockup watchdog")
>> Reported-by: Hulk Robot <hulkci@huawei.com>
>> Signed-off-by: Chen Huang <chenhuang5@huawei.com>
>> ---
>> arch/powerpc/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 764df010baee..2d4f37b117ce 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -225,7 +225,7 @@ config PPC
>> select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
>> select HAVE_MOD_ARCH_SPECIFIC
>> select HAVE_NMI if PERF_EVENTS || (PPC64 && PPC_BOOK3S)
>> - select HAVE_HARDLOCKUP_DETECTOR_ARCH if (PPC64 && PPC_BOOK3S)
>> + select HAVE_HARDLOCKUP_DETECTOR_ARCH if PPC64 && PPC_BOOK3S && SMP
>
> While modifying this line, you should restore the alphabetic order by moving it up.
>
> You can use PPC_BOOK3S_64 instead of PPC64 && PPC_BOOK3S
>
I will modify it. Thanks!
>> select HAVE_OPTPROBES if PPC64
>> select HAVE_PERF_EVENTS
>> select HAVE_PERF_EVENTS_NMI if PPC64
>>
> .
^ permalink raw reply
* [PATCH v2] powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration
From: Chen Huang @ 2021-03-29 2:27 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras
Cc: Don Zickus, linux-kernel, Nicholas Piggin, Hulk Robot,
Andrew Morton, linuxppc-dev
In-Reply-To: <e8eddfd4-ca07-f2ba-42de-19e636dc2ce9@huawei.com>
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....
We found that powerpc used ipi to implement hardlockup watchdog, so the
HAVE_HARDLOCKUP_DETECTOR_ARCH should depend on the SMP.
Fixes: 2104180a5369 ("powerpc/64s: implement arch-specific hardlockup watchdog")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Huang <chenhuang5@huawei.com>
---
arch/powerpc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 764df010baee..a5196e1a1281 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -210,6 +210,7 @@ config PPC
select HAVE_FUNCTION_TRACER
select HAVE_GCC_PLUGINS if GCC_VERSION >= 50200 # plugin support on gcc <= 5.1 is buggy on PPC
select HAVE_GENERIC_VDSO
+ select HAVE_HARDLOCKUP_DETECTOR_ARCH if PPC_BOOK3S_64 && SMP
select HAVE_HW_BREAKPOINT if PERF_EVENTS && (PPC_BOOK3S || PPC_8xx)
select HAVE_IDE
select HAVE_IOREMAP_PROT
@@ -225,7 +226,6 @@ config PPC
select HAVE_LIVEPATCH if HAVE_DYNAMIC_FTRACE_WITH_REGS
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_NMI if PERF_EVENTS || (PPC64 && PPC_BOOK3S)
- select HAVE_HARDLOCKUP_DETECTOR_ARCH if (PPC64 && PPC_BOOK3S)
select HAVE_OPTPROBES if PPC64
select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI if PPC64
--
2.17.1
^ permalink raw reply related
* [PATCH] ASoC: fsl_rpmsg: initialise pointers to NULL
From: Shengjiu Wang @ 2021-03-29 3:34 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, lgirdwood, broonie,
perex, tiwai, alsa-devel, linuxppc-dev, linux-kernel
This fixes the following sparse warnings:
sound/soc/fsl/fsl_rpmsg.c:45:45: sparse: sparse: Using plain integer as NULL pointer
sound/soc/fsl/fsl_rpmsg.c:45:56: sparse: sparse: Using plain integer as NULL pointer
Fixes: b73d9e6225e8 ("ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reported-by: kernel test robot <lkp@intel.com>
---
sound/soc/fsl/fsl_rpmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c
index 2d09d8850e2c..ea5c973e2e84 100644
--- a/sound/soc/fsl/fsl_rpmsg.c
+++ b/sound/soc/fsl/fsl_rpmsg.c
@@ -42,7 +42,7 @@ static int fsl_rpmsg_hw_params(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct fsl_rpmsg *rpmsg = snd_soc_dai_get_drvdata(dai);
- struct clk *p = rpmsg->mclk, *pll = 0, *npll = 0;
+ struct clk *p = rpmsg->mclk, *pll = NULL, *npll = NULL;
u64 rate = params_rate(params);
int ret = 0;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] powerpc/64s: power4 nap fixup in C
From: Michael Ellerman @ 2021-03-29 4:40 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20210312012044.3660743-1-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> There is no need for this to be in asm, use the new intrrupt entry wrapper.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> Hopefully this works on a real G5 now, but I couldn't reproduce the
> problem with QEMU.
It still prevents my G5 from booting.
Next time someone is in the office I'll ask them to check the display to
see if there's an oops.
cheers
^ permalink raw reply
* Re: [PATCH 00/30] DMA: Mundane typo fixes
From: Christoph Hellwig @ 2021-03-29 5:29 UTC (permalink / raw)
To: Bhaskar Chowdhury, Linus Torvalds
Cc: dave.jiang, rdunlap, linux-kernel, dri-devel, iommu, dmaengine,
dan.j.williams, linuxppc-dev, hch
In-Reply-To: <cover.1616971780.git.unixbhaskar@gmail.com>
I really don't think these typo patchbomb are that useful. I'm all
for fixing typos when working with a subsystem, but I'm not sure these
patchbombs help anything.
On Mon, Mar 29, 2021 at 05:22:56AM +0530, Bhaskar Chowdhury wrote:
> This patch series fixes some trivial and rudimentary spellings in the COMMENT
> sections.
>
> Bhaskar Chowdhury (30):
> acpi-dma.c: Fix couple of typos
> altera-msgdma.c: Couple of typos fixed
> amba-pl08x.c: Fixed couple of typos
> bcm-sba-raid.c: Few typos fixed
> bcm2835-dma.c: Fix a typo
> idma64.c: Fix couple of typos
> iop-adma.c: Few typos fixed
> mv_xor.c: Fix a typo
> mv_xor.h: Fixed a typo
> mv_xor_v2.c: Fix a typo
> nbpfaxi.c: Fixed a typo
> of-dma.c: Fixed a typo
> s3c24xx-dma.c: Fix a typo
> Revert "s3c24xx-dma.c: Fix a typo"
> s3c24xx-dma.c: Few typos fixed
> st_fdma.h: Fix couple of typos
> ste_dma40_ll.h: Fix a typo
> tegra20-apb-dma.c: Fixed a typo
> xgene-dma.c: Few spello fixes
> at_hdmac.c: Quite a few spello fixes
> owl-dma.c: Fix a typo
> at_hdmac_regs.h: Couple of typo fixes
> dma-jz4780.c: Fix a typo
> Kconfig: Change Synopsys to Synopsis
> ste_dma40.c: Few spello fixes
> dw-axi-dmac-platform.c: Few typos fixed
> dpaa2-qdma.c: Fix a typo
> usb-dmac.c: Fix a typo
> edma.c: Fix a typo
> xilinx_dma.c: Fix a typo
>
> drivers/dma/Kconfig | 8 ++++----
> drivers/dma/acpi-dma.c | 4 ++--
> drivers/dma/altera-msgdma.c | 4 ++--
> drivers/dma/amba-pl08x.c | 4 ++--
> drivers/dma/at_hdmac.c | 14 +++++++-------
> drivers/dma/at_hdmac_regs.h | 4 ++--
> drivers/dma/bcm-sba-raid.c | 8 ++++----
> drivers/dma/bcm2835-dma.c | 2 +-
> drivers/dma/dma-jz4780.c | 2 +-
> drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 8 ++++----
> drivers/dma/idma64.c | 4 ++--
> drivers/dma/iop-adma.c | 6 +++---
> drivers/dma/mv_xor.c | 2 +-
> drivers/dma/mv_xor.h | 2 +-
> drivers/dma/mv_xor_v2.c | 2 +-
> drivers/dma/nbpfaxi.c | 2 +-
> drivers/dma/of-dma.c | 2 +-
> drivers/dma/owl-dma.c | 2 +-
> drivers/dma/s3c24xx-dma.c | 6 +++---
> drivers/dma/sh/shdmac.c | 2 +-
> drivers/dma/sh/usb-dmac.c | 2 +-
> drivers/dma/st_fdma.h | 4 ++--
> drivers/dma/ste_dma40.c | 10 +++++-----
> drivers/dma/ste_dma40_ll.h | 2 +-
> drivers/dma/tegra20-apb-dma.c | 2 +-
> drivers/dma/ti/edma.c | 2 +-
> drivers/dma/xgene-dma.c | 6 +++---
> drivers/dma/xilinx/xilinx_dma.c | 2 +-
> 28 files changed, 59 insertions(+), 59 deletions(-)
>
> --
> 2.26.3
---end quoted text---
^ permalink raw reply
* Re: [PATCH 00/30] DMA: Mundane typo fixes
From: Bhaskar Chowdhury @ 2021-03-29 5:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dave.jiang, Linus Torvalds, rdunlap, linux-kernel, dri-devel,
iommu, dmaengine, dan.j.williams, linuxppc-dev
In-Reply-To: <20210329052910.GB26495@lst.de>
[-- Attachment #1: Type: text/plain, Size: 3433 bytes --]
On 07:29 Mon 29 Mar 2021, Christoph Hellwig wrote:
>I really don't think these typo patchbomb are that useful. I'm all
>for fixing typos when working with a subsystem, but I'm not sure these
>patchbombs help anything.
>
I am sure you are holding the wrong end of the wand and grossly failing to
understand.
Anyway, I hope I give a heads up ...find "your way" to fix those damn
thing...it's glaring....
>On Mon, Mar 29, 2021 at 05:22:56AM +0530, Bhaskar Chowdhury wrote:
>> This patch series fixes some trivial and rudimentary spellings in the COMMENT
>> sections.
>>
>> Bhaskar Chowdhury (30):
>> acpi-dma.c: Fix couple of typos
>> altera-msgdma.c: Couple of typos fixed
>> amba-pl08x.c: Fixed couple of typos
>> bcm-sba-raid.c: Few typos fixed
>> bcm2835-dma.c: Fix a typo
>> idma64.c: Fix couple of typos
>> iop-adma.c: Few typos fixed
>> mv_xor.c: Fix a typo
>> mv_xor.h: Fixed a typo
>> mv_xor_v2.c: Fix a typo
>> nbpfaxi.c: Fixed a typo
>> of-dma.c: Fixed a typo
>> s3c24xx-dma.c: Fix a typo
>> Revert "s3c24xx-dma.c: Fix a typo"
>> s3c24xx-dma.c: Few typos fixed
>> st_fdma.h: Fix couple of typos
>> ste_dma40_ll.h: Fix a typo
>> tegra20-apb-dma.c: Fixed a typo
>> xgene-dma.c: Few spello fixes
>> at_hdmac.c: Quite a few spello fixes
>> owl-dma.c: Fix a typo
>> at_hdmac_regs.h: Couple of typo fixes
>> dma-jz4780.c: Fix a typo
>> Kconfig: Change Synopsys to Synopsis
>> ste_dma40.c: Few spello fixes
>> dw-axi-dmac-platform.c: Few typos fixed
>> dpaa2-qdma.c: Fix a typo
>> usb-dmac.c: Fix a typo
>> edma.c: Fix a typo
>> xilinx_dma.c: Fix a typo
>>
>> drivers/dma/Kconfig | 8 ++++----
>> drivers/dma/acpi-dma.c | 4 ++--
>> drivers/dma/altera-msgdma.c | 4 ++--
>> drivers/dma/amba-pl08x.c | 4 ++--
>> drivers/dma/at_hdmac.c | 14 +++++++-------
>> drivers/dma/at_hdmac_regs.h | 4 ++--
>> drivers/dma/bcm-sba-raid.c | 8 ++++----
>> drivers/dma/bcm2835-dma.c | 2 +-
>> drivers/dma/dma-jz4780.c | 2 +-
>> drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c | 8 ++++----
>> drivers/dma/idma64.c | 4 ++--
>> drivers/dma/iop-adma.c | 6 +++---
>> drivers/dma/mv_xor.c | 2 +-
>> drivers/dma/mv_xor.h | 2 +-
>> drivers/dma/mv_xor_v2.c | 2 +-
>> drivers/dma/nbpfaxi.c | 2 +-
>> drivers/dma/of-dma.c | 2 +-
>> drivers/dma/owl-dma.c | 2 +-
>> drivers/dma/s3c24xx-dma.c | 6 +++---
>> drivers/dma/sh/shdmac.c | 2 +-
>> drivers/dma/sh/usb-dmac.c | 2 +-
>> drivers/dma/st_fdma.h | 4 ++--
>> drivers/dma/ste_dma40.c | 10 +++++-----
>> drivers/dma/ste_dma40_ll.h | 2 +-
>> drivers/dma/tegra20-apb-dma.c | 2 +-
>> drivers/dma/ti/edma.c | 2 +-
>> drivers/dma/xgene-dma.c | 6 +++---
>> drivers/dma/xilinx/xilinx_dma.c | 2 +-
>> 28 files changed, 59 insertions(+), 59 deletions(-)
>>
>> --
>> 2.26.3
>---end quoted text---
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] powerpc/8xx: Load modules closer to kernel text
From: Christophe Leroy @ 2021-03-29 7:07 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
On the 8xx, TASK_SIZE is 0x80000000. The space between TASK_SIZE and
PAGE_OFFSET is not used.
Use it to load modules in order to minimise the distance between
kernel text and modules and avoid trampolines in modules to access
kernel functions or other module functions.
Define a 16Mbytes area for modules, that's more than enough.
DEBUG logs in module_32.c without the patch:
[ 1572.588822] module_32: Applying ADD relocate section 13 to 12
[ 1572.588891] module_32: Doing plt for call to 0xc00671a4 at 0xcae04024
[ 1572.588964] module_32: Initialized plt for 0xc00671a4 at cae04000
[ 1572.589037] module_32: REL24 value = CAE04000. location = CAE04024
[ 1572.589110] module_32: Location before: 48000001.
[ 1572.589171] module_32: Location after: 4BFFFFDD.
[ 1572.589231] module_32: ie. jump to 03FFFFDC+CAE04024 = CEE04000
[ 1572.589317] module_32: Applying ADD relocate section 15 to 14
[ 1572.589386] module_32: Doing plt for call to 0xc00671a4 at 0xcadfc018
[ 1572.589457] module_32: Initialized plt for 0xc00671a4 at cadfc000
[ 1572.589529] module_32: REL24 value = CADFC000. location = CADFC018
[ 1572.589601] module_32: Location before: 48000000.
[ 1572.589661] module_32: Location after: 4BFFFFE8.
[ 1572.589723] module_32: ie. jump to 03FFFFE8+CADFC018 = CEDFC000
With the patch:
[ 279.404671] module_32: Applying ADD relocate section 13 to 12
[ 279.404741] module_32: REL24 value = C00671B4. location = BF808024
[ 279.404814] module_32: Location before: 48000001.
[ 279.404874] module_32: Location after: 4885F191.
[ 279.404933] module_32: ie. jump to 0085F190+BF808024 = C00671B4
[ 279.405016] module_32: Applying ADD relocate section 15 to 14
[ 279.405085] module_32: REL24 value = C00671B4. location = BF800018
[ 279.405156] module_32: Location before: 48000000.
[ 279.405215] module_32: Location after: 4886719C.
[ 279.405275] module_32: ie. jump to 0086719C+BF800018 = C00671B4
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/nohash/32/mmu-8xx.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
index 478249959baa..7902a42d6d3e 100644
--- a/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
+++ b/arch/powerpc/include/asm/nohash/32/mmu-8xx.h
@@ -172,6 +172,9 @@
#define mmu_linear_psize MMU_PAGE_8M
+#define MODULES_VADDR (PAGE_OFFSET - SZ_16M)
+#define MODULES_END PAGE_OFFSET
+
#ifndef __ASSEMBLY__
#include <linux/mmdebug.h>
--
2.25.0
^ permalink raw reply related
* Re: [PATCH] powerpc/64s: power4 nap fixup in C
From: Benjamin Herrenschmidt @ 2021-03-29 8:33 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev
In-Reply-To: <20210312012044.3660743-1-npiggin@gmail.com>
On Fri, 2021-03-12 at 11:20 +1000, Nicholas Piggin wrote:
>
> +static inline void nap_adjust_return(struct pt_regs *regs)
>
> +{
>
> +#ifdef CONFIG_PPC_970_NAP
>
> + if (unlikely(test_thread_local_flags(_TLF_NAPPING))) {
> + /* Can avoid a test-and-clear because NMIs do not call this */
> + clear_thread_local_flags(_TLF_NAPPING);
> + regs->nip = (unsigned long)power4_idle_nap_return;
> + }
Is this a pointer to a function descriptor or the actual code ?
Cheers,
Ben.
> +#endif
>
> +}
>
> +
>
> struct interrupt_state {
>
> #ifdef CONFIG_PPC_BOOK3E_64
>
> enum ctx_state ctx_state;
>
> @@ -111,6 +122,9 @@ static inline void interrupt_async_exit_prepare(struct pt_regs *regs, struct int
>
> {
>
> irq_exit();
>
> interrupt_exit_prepare(regs, state);
>
> +
>
> + /* Adjust at exit so the main handler sees the true NIA */
>
> + nap_adjust_return(regs);
>
> }
>
>
>
> struct interrupt_nmi_state {
>
> @@ -164,6 +178,11 @@ static inline void interrupt_nmi_exit_prepare(struct pt_regs *regs, struct inter
>
> radix_enabled() || (mfmsr() & MSR_DR))
>
> nmi_exit();
>
>
>
> + /*
>
> + * nmi does not call nap_adjust_return because nmi should not create
>
> + * new work to do (must use irq_work for that).
>
> + */
>
> +
>
> #ifdef CONFIG_PPC64
>
> if (TRAP(regs) != 0x900 && TRAP(regs) != 0xf00 && TRAP(regs) != 0x260)
>
> this_cpu_set_ftrace_enabled(state->ftrace_enabled);
>
> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
>
> index 8acc3590c971..eedc3c775141 100644
>
> --- a/arch/powerpc/include/asm/processor.h
>
> +++ b/arch/powerpc/include/asm/processor.h
>
> @@ -393,6 +393,7 @@ extern unsigned long isa300_idle_stop_mayloss(unsigned long psscr_val);
>
> extern unsigned long isa206_idle_insn_mayloss(unsigned long type);
>
> #ifdef CONFIG_PPC_970_NAP
>
> extern void power4_idle_nap(void);
>
> +void power4_idle_nap_return(void);
>
> #endif
>
>
>
> extern unsigned long cpuidle_disable;
>
> diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
>
> index 386d576673a1..bf137151100b 100644
>
> --- a/arch/powerpc/include/asm/thread_info.h
>
> +++ b/arch/powerpc/include/asm/thread_info.h
>
> @@ -152,6 +152,12 @@ void arch_setup_new_exec(void);
>
>
>
> #ifndef __ASSEMBLY__
>
>
>
> +static inline void clear_thread_local_flags(unsigned int flags)
>
> +{
>
> + struct thread_info *ti = current_thread_info();
>
> + ti->local_flags &= ~flags;
>
> +}
>
> +
>
> static inline bool test_thread_local_flags(unsigned int flags)
>
> {
>
> struct thread_info *ti = current_thread_info();
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>
> index 60d3051a8bc8..ea7a443488d2 100644
>
> --- a/arch/powerpc/kernel/exceptions-64s.S
>
> +++ b/arch/powerpc/kernel/exceptions-64s.S
>
> @@ -692,25 +692,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
>
> ld r1,GPR1(r1)
>
> .endm
>
>
>
> -/*
>
> - * When the idle code in power4_idle puts the CPU into NAP mode,
>
> - * it has to do so in a loop, and relies on the external interrupt
>
> - * and decrementer interrupt entry code to get it out of the loop.
>
> - * It sets the _TLF_NAPPING bit in current_thread_info()->local_flags
>
> - * to signal that it is in the loop and needs help to get out.
>
> - */
>
> -#ifdef CONFIG_PPC_970_NAP
>
> -#define FINISH_NAP \
>
> -BEGIN_FTR_SECTION \
>
> - ld r11, PACA_THREAD_INFO(r13); \
>
> - ld r9,TI_LOCAL_FLAGS(r11); \
>
> - andi. r10,r9,_TLF_NAPPING; \
>
> - bnel power4_fixup_nap; \
>
> -END_FTR_SECTION_IFSET(CPU_FTR_CAN_NAP)
>
> -#else
>
> -#define FINISH_NAP
>
> -#endif
>
> -
>
> /*
>
> * There are a few constraints to be concerned with.
>
> * - Real mode exceptions code/data must be located at their physical location.
>
> @@ -1248,7 +1229,6 @@ EXC_COMMON_BEGIN(machine_check_common)
>
> */
>
> GEN_COMMON machine_check
>
>
>
> - FINISH_NAP
>
> /* Enable MSR_RI when finished with PACA_EXMC */
>
> li r10,MSR_RI
>
> mtmsrd r10,1
>
> @@ -1571,7 +1551,6 @@ EXC_VIRT_BEGIN(hardware_interrupt, 0x4500, 0x100)
>
> EXC_VIRT_END(hardware_interrupt, 0x4500, 0x100)
>
> EXC_COMMON_BEGIN(hardware_interrupt_common)
>
> GEN_COMMON hardware_interrupt
>
> - FINISH_NAP
>
> addi r3,r1,STACK_FRAME_OVERHEAD
>
> bl do_IRQ
>
> b interrupt_return
>
> @@ -1801,7 +1780,6 @@ EXC_VIRT_BEGIN(decrementer, 0x4900, 0x80)
>
> EXC_VIRT_END(decrementer, 0x4900, 0x80)
>
> EXC_COMMON_BEGIN(decrementer_common)
>
> GEN_COMMON decrementer
>
> - FINISH_NAP
>
> addi r3,r1,STACK_FRAME_OVERHEAD
>
> bl timer_interrupt
>
> b interrupt_return
>
> @@ -1886,7 +1864,6 @@ EXC_VIRT_BEGIN(doorbell_super, 0x4a00, 0x100)
>
> EXC_VIRT_END(doorbell_super, 0x4a00, 0x100)
>
> EXC_COMMON_BEGIN(doorbell_super_common)
>
> GEN_COMMON doorbell_super
>
> - FINISH_NAP
>
> addi r3,r1,STACK_FRAME_OVERHEAD
>
> #ifdef CONFIG_PPC_DOORBELL
>
> bl doorbell_exception
>
> @@ -2237,7 +2214,6 @@ EXC_COMMON_BEGIN(hmi_exception_early_common)
>
>
>
> EXC_COMMON_BEGIN(hmi_exception_common)
>
> GEN_COMMON hmi_exception
>
> - FINISH_NAP
>
> addi r3,r1,STACK_FRAME_OVERHEAD
>
> bl handle_hmi_exception
>
> b interrupt_return
>
> @@ -2266,7 +2242,6 @@ EXC_VIRT_BEGIN(h_doorbell, 0x4e80, 0x20)
>
> EXC_VIRT_END(h_doorbell, 0x4e80, 0x20)
>
> EXC_COMMON_BEGIN(h_doorbell_common)
>
> GEN_COMMON h_doorbell
>
> - FINISH_NAP
>
> addi r3,r1,STACK_FRAME_OVERHEAD
>
> #ifdef CONFIG_PPC_DOORBELL
>
> bl doorbell_exception
>
> @@ -2299,7 +2274,6 @@ EXC_VIRT_BEGIN(h_virt_irq, 0x4ea0, 0x20)
>
> EXC_VIRT_END(h_virt_irq, 0x4ea0, 0x20)
>
> EXC_COMMON_BEGIN(h_virt_irq_common)
>
> GEN_COMMON h_virt_irq
>
> - FINISH_NAP
>
> addi r3,r1,STACK_FRAME_OVERHEAD
>
> bl do_IRQ
>
> b interrupt_return
>
> @@ -2345,7 +2319,6 @@ EXC_VIRT_BEGIN(performance_monitor, 0x4f00, 0x20)
>
> EXC_VIRT_END(performance_monitor, 0x4f00, 0x20)
>
> EXC_COMMON_BEGIN(performance_monitor_common)
>
> GEN_COMMON performance_monitor
>
> - FINISH_NAP
>
> addi r3,r1,STACK_FRAME_OVERHEAD
>
> bl performance_monitor_exception
>
> b interrupt_return
>
> @@ -3096,24 +3069,6 @@ USE_FIXED_SECTION(virt_trampolines)
>
> __end_interrupts:
>
> DEFINE_FIXED_SYMBOL(__end_interrupts)
>
>
>
> -#ifdef CONFIG_PPC_970_NAP
>
> - /*
>
> - * Called by exception entry code if _TLF_NAPPING was set, this clears
>
> - * the NAPPING flag, and redirects the exception exit to
>
> - * power4_fixup_nap_return.
>
> - */
>
> - .globl power4_fixup_nap
>
> -EXC_COMMON_BEGIN(power4_fixup_nap)
>
> - andc r9,r9,r10
>
> - std r9,TI_LOCAL_FLAGS(r11)
>
> - LOAD_REG_ADDR(r10, power4_idle_nap_return)
>
> - std r10,_NIP(r1)
>
> - blr
>
> -
>
> -power4_idle_nap_return:
>
> - blr
>
> -#endif
>
> -
>
> CLOSE_FIXED_SECTION(real_vectors);
>
> CLOSE_FIXED_SECTION(real_trampolines);
>
> CLOSE_FIXED_SECTION(virt_vectors);
>
> diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S
>
> index f9e6d83e6720..abb719b21cae 100644
>
> --- a/arch/powerpc/kernel/idle_book3s.S
>
> +++ b/arch/powerpc/kernel/idle_book3s.S
>
> @@ -209,4 +209,8 @@ _GLOBAL(power4_idle_nap)
>
> mtmsrd r7
>
> isync
>
> b 1b
>
> +
>
> + .globl power4_idle_nap_return
>
> +power4_idle_nap_return:
>
> + blr
>
> #endif
>
> --
>
> 2.23.0
^ permalink raw reply
* [PATCH] PCI: Try to find two continuous regions for child resource
From: Kai-Heng Feng @ 2021-03-29 8:47 UTC (permalink / raw)
To: bhelgaas
Cc: Qian Cai, Michal Simek, Arnd Bergmann,
open list:SPARC + UltraSPARC sparc/sparc64, Alexey Kardashevskiy,
open list:PCI SUBSYSTEM, open list, Dominik Brodowski,
Qinglang Miao, Chen Zhou, Kai-Heng Feng, Paul Mackerras,
Cédric Le Goater, Frederic Barrat, Oliver O'Halloran,
Andrew Morton, open list:LINUX FOR POWERPC 32-BIT AND 64-BIT,
David S. Miller, Mike Rapoport
Built-in grahpics on HP EliteDesk 805 G6 doesn't work because graphics
can't get the BAR it needs:
[ 0.611504] pci_bus 0000:00: root bus resource [mem 0x10020200000-0x100303fffff window]
[ 0.611505] pci_bus 0000:00: root bus resource [mem 0x10030400000-0x100401fffff window]
...
[ 0.638083] pci 0000:00:08.1: bridge window [mem 0xd2000000-0xd23fffff]
[ 0.638086] pci 0000:00:08.1: bridge window [mem 0x10030000000-0x100401fffff 64bit pref]
[ 0.962086] pci 0000:00:08.1: can't claim BAR 15 [mem 0x10030000000-0x100401fffff 64bit pref]: no compatible bridge window
[ 0.962086] pci 0000:00:08.1: [mem 0x10030000000-0x100401fffff 64bit pref] clipped to [mem 0x10030000000-0x100303fffff 64bit pref]
[ 0.962086] pci 0000:00:08.1: bridge window [mem 0x10030000000-0x100303fffff 64bit pref]
[ 0.962086] pci 0000:07:00.0: can't claim BAR 0 [mem 0x10030000000-0x1003fffffff 64bit pref]: no compatible bridge window
[ 0.962086] pci 0000:07:00.0: can't claim BAR 2 [mem 0x10040000000-0x100401fffff 64bit pref]: no compatible bridge window
However, the root bus has two continuous regions that can contain the
child resource requested.
So try to find another parent region if two regions are continuous and
can contain child resource. This change makes the grahpics works on the
system in question.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212013
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
arch/microblaze/pci/pci-common.c | 4 +--
arch/powerpc/kernel/pci-common.c | 8 ++---
arch/sparc/kernel/pci.c | 4 +--
drivers/pci/pci.c | 60 +++++++++++++++++++++++++++-----
drivers/pci/setup-res.c | 21 +++++++----
drivers/pcmcia/rsrc_nonstatic.c | 4 +--
include/linux/pci.h | 6 ++--
7 files changed, 80 insertions(+), 27 deletions(-)
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 557585f1be41..8e65832fb510 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -669,7 +669,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
{
struct pci_bus *b;
int i;
- struct resource *res, *pr;
+ struct resource *res, *pr = NULL;
pr_debug("PCI: Allocating bus resources for %04x:%02x...\n",
pci_domain_nr(bus), bus->number);
@@ -688,7 +688,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
* and as such ensure proper re-allocation
* later.
*/
- pr = pci_find_parent_resource(bus->self, res);
+ pci_find_parent_resource(bus->self, res, &pr, NULL);
if (pr == res) {
/* this happens when the generic PCI
* code (wrongly) decides that this
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 001e90cd8948..f865354b746d 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1196,7 +1196,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
{
struct pci_bus *b;
int i;
- struct resource *res, *pr;
+ struct resource *res, *pr = NULL;
pr_debug("PCI: Allocating bus resources for %04x:%02x...\n",
pci_domain_nr(bus), bus->number);
@@ -1213,7 +1213,7 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
pr = (res->flags & IORESOURCE_IO) ?
&ioport_resource : &iomem_resource;
else {
- pr = pci_find_parent_resource(bus->self, res);
+ pci_find_parent_resource(bus->self, res, &pr, NULL);
if (pr == res) {
/* this happens when the generic PCI
* code (wrongly) decides that this
@@ -1265,12 +1265,12 @@ static void pcibios_allocate_bus_resources(struct pci_bus *bus)
static inline void alloc_resource(struct pci_dev *dev, int idx)
{
- struct resource *pr, *r = &dev->resource[idx];
+ struct resource *pr = NULL, *r = &dev->resource[idx];
pr_debug("PCI: Allocating %s: Resource %d: %pR\n",
pci_name(dev), idx, r);
- pr = pci_find_parent_resource(dev, r);
+ pci_find_parent_resource(dev, r, &pr, NULL);
if (!pr || (pr->flags & IORESOURCE_UNSET) ||
request_resource(pr, r) < 0) {
printk(KERN_WARNING "PCI: Cannot allocate resource region %d"
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 9c2b720bfd20..b4006798e4e1 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -621,7 +621,7 @@ static void pci_bus_register_of_sysfs(struct pci_bus *bus)
static void pci_claim_legacy_resources(struct pci_dev *dev)
{
struct pci_bus_region region;
- struct resource *p, *root, *conflict;
+ struct resource *p, *root = NULL, *conflict;
if ((dev->class >> 8) != PCI_CLASS_DISPLAY_VGA)
return;
@@ -637,7 +637,7 @@ static void pci_claim_legacy_resources(struct pci_dev *dev)
region.end = region.start + 0x1ffffUL;
pcibios_bus_to_resource(dev->bus, p, ®ion);
- root = pci_find_parent_resource(dev, p);
+ pci_find_parent_resource(dev, p, &root, NULL);
if (!root) {
pci_info(dev, "can't claim VGA legacy %pR: no compatible bridge window\n", p);
goto err;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 16a17215f633..abbcd2dcdc02 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -693,20 +693,25 @@ u8 pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
EXPORT_SYMBOL_GPL(pci_find_ht_capability);
/**
- * pci_find_parent_resource - return resource region of parent bus of given
+ * pci_find_parent_resource - find resource region of parent bus of given
* region
* @dev: PCI device structure contains resources to be searched
* @res: child resource record for which parent is sought
+ * @first: the first region that contains the child resource
+ * @second: the second region that combines with the first region to fully
+ * contains the child resource
*
* For given resource region of given device, return the resource region of
* parent bus the given region is contained in.
*/
-struct resource *pci_find_parent_resource(const struct pci_dev *dev,
- struct resource *res)
+void pci_find_parent_resource(const struct pci_dev *dev,
+ struct resource *res,
+ struct resource **first,
+ struct resource **second)
{
const struct pci_bus *bus = dev->bus;
struct resource *r;
- int i;
+ int i, overlaps = 0;
pci_bus_for_each_resource(bus, r, i) {
if (!r)
@@ -718,8 +723,10 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev,
* not, the allocator made a mistake.
*/
if (r->flags & IORESOURCE_PREFETCH &&
- !(res->flags & IORESOURCE_PREFETCH))
- return NULL;
+ !(res->flags & IORESOURCE_PREFETCH)) {
+ *first = NULL;
+ return;
+ }
/*
* If we're below a transparent bridge, there may
@@ -729,10 +736,47 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev,
* on pci_bus_for_each_resource() giving us those
* first.
*/
- return r;
+ *first = r;
+ return;
}
}
- return NULL;
+
+ if (!second)
+ return;
+
+ pci_bus_for_each_resource(bus, r, i) {
+ if (!r)
+ continue;
+ if (resource_overlaps(r, res)) {
+ if (r->flags & IORESOURCE_PREFETCH &&
+ !(res->flags & IORESOURCE_PREFETCH))
+ continue;
+
+ if (!overlaps++)
+ *first = r;
+ else {
+ *second = r;
+ break;
+ }
+ }
+ }
+
+ if (overlaps != 2)
+ goto out;
+
+ if ((*first)->start > (*second)->start)
+ swap(*first, *second);
+
+ if ((*first)->end + 1 != (*second)->start)
+ goto out;
+
+ if ((*first)->start <= res->start && (*second)->end >= res->end)
+ return;
+out:
+
+ *first = NULL;
+ *second = NULL;
+ return;
}
EXPORT_SYMBOL(pci_find_parent_resource);
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 7f1acb3918d0..e39615321d81 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -131,7 +131,7 @@ void pci_update_resource(struct pci_dev *dev, int resno)
int pci_claim_resource(struct pci_dev *dev, int resource)
{
struct resource *res = &dev->resource[resource];
- struct resource *root, *conflict;
+ struct resource *first = NULL, *second = NULL, *conflict;
if (res->flags & IORESOURCE_UNSET) {
pci_info(dev, "can't claim BAR %d %pR: no address assigned\n",
@@ -147,21 +147,28 @@ int pci_claim_resource(struct pci_dev *dev, int resource)
if (res->flags & IORESOURCE_ROM_SHADOW)
return 0;
- root = pci_find_parent_resource(dev, res);
- if (!root) {
+ pci_find_parent_resource(dev, res, &first, &second);
+ if (!first) {
pci_info(dev, "can't claim BAR %d %pR: no compatible bridge window\n",
resource, res);
res->flags |= IORESOURCE_UNSET;
return -EINVAL;
}
- conflict = request_resource_conflict(root, res);
+ if (second)
+ first->end = second->end;
+
+ conflict = request_resource_conflict(first, res);
if (conflict) {
+ if (second)
+ first->end = second->start - 1;
+
pci_info(dev, "can't claim BAR %d %pR: address conflict with %s %pR\n",
resource, res, conflict->name, conflict);
res->flags |= IORESOURCE_UNSET;
return -EBUSY;
- }
+ } else if (second)
+ second->start = second->end = 0;
return 0;
}
@@ -195,7 +202,7 @@ resource_size_t __weak pcibios_retrieve_fw_addr(struct pci_dev *dev, int idx)
static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
int resno, resource_size_t size)
{
- struct resource *root, *conflict;
+ struct resource *root = NULL, *conflict;
resource_size_t fw_addr, start, end;
fw_addr = pcibios_retrieve_fw_addr(dev, resno);
@@ -208,7 +215,7 @@ static int pci_revert_fw_address(struct resource *res, struct pci_dev *dev,
res->end = res->start + size - 1;
res->flags &= ~IORESOURCE_UNSET;
- root = pci_find_parent_resource(dev, res);
+ pci_find_parent_resource(dev, res, &root, NULL);
if (!root) {
if (res->flags & IORESOURCE_IO)
root = &ioport_resource;
diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
index 3b05760e69d6..2fba42d7486e 100644
--- a/drivers/pcmcia/rsrc_nonstatic.c
+++ b/drivers/pcmcia/rsrc_nonstatic.c
@@ -73,7 +73,7 @@ static struct resource *
claim_region(struct pcmcia_socket *s, resource_size_t base,
resource_size_t size, int type, char *name)
{
- struct resource *res, *parent;
+ struct resource *res, *parent = NULL;
parent = type & IORESOURCE_MEM ? &iomem_resource : &ioport_resource;
res = pcmcia_make_resource(base, size, type | IORESOURCE_BUSY, name);
@@ -81,7 +81,7 @@ claim_region(struct pcmcia_socket *s, resource_size_t base,
if (res) {
#ifdef CONFIG_PCI
if (s && s->cb_dev)
- parent = pci_find_parent_resource(s->cb_dev, res);
+ pci_find_parent_resource(s->cb_dev, res, &parent, NULL);
#endif
if (!parent || request_resource(parent, res)) {
kfree(res);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 86c799c97b77..dd1455be5247 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1049,8 +1049,10 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus);
unsigned int pci_scan_child_bus(struct pci_bus *bus);
void pci_bus_add_device(struct pci_dev *dev);
void pci_read_bridge_bases(struct pci_bus *child);
-struct resource *pci_find_parent_resource(const struct pci_dev *dev,
- struct resource *res);
+void pci_find_parent_resource(const struct pci_dev *dev,
+ struct resource *res,
+ struct resource **first,
+ struct resource **second);
u8 pci_swizzle_interrupt_pin(const struct pci_dev *dev, u8 pin);
int pci_get_interrupt_pin(struct pci_dev *dev, struct pci_dev **bridge);
u8 pci_common_swizzle(struct pci_dev *dev, u8 *pinp);
--
2.30.2
^ permalink raw reply related
* Re: [PATCH] powerpc/64s: power4 nap fixup in C
From: Christophe Leroy @ 2021-03-29 9:04 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Nicholas Piggin, linuxppc-dev
In-Reply-To: <a01d923737cb1d4a603dc5046b67787233051c12.camel@kernel.crashing.org>
Le 29/03/2021 à 10:33, Benjamin Herrenschmidt a écrit :
> On Fri, 2021-03-12 at 11:20 +1000, Nicholas Piggin wrote:
>>
>> +static inline void nap_adjust_return(struct pt_regs *regs)
>>
>> +{
>>
>> +#ifdef CONFIG_PPC_970_NAP
>>
>> + if (unlikely(test_thread_local_flags(_TLF_NAPPING))) {
>> + /* Can avoid a test-and-clear because NMIs do not call this */
>> + clear_thread_local_flags(_TLF_NAPPING);
>> + regs->nip = (unsigned long)power4_idle_nap_return;
>> + }
>
> Is this a pointer to a function descriptor or the actual code ?
>
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -209,4 +209,8 @@ _GLOBAL(power4_idle_nap)
mtmsrd r7
isync
b 1b
+
+ .globl power4_idle_nap_return
+power4_idle_nap_return:
+ blr
#endif
^ permalink raw reply
* Re: [PATCH] powerpc/vdso: Separate vvar vma from vdso
From: Laurent Dufour @ 2021-03-29 9:51 UTC (permalink / raw)
To: Dmitry Safonov, Christophe Leroy, linux-kernel
Cc: Dmitry Safonov, stable, Andrei Vagin, Paul Mackerras,
Andy Lutomirski, linuxppc-dev
In-Reply-To: <1b1494a8-da80-e170-78fa-48dfb3226e75@arista.com>
Hi Christophe and Dimitry,
Le 27/03/2021 à 18:43, Dmitry Safonov a écrit :
> Hi Christophe,
>
> On 3/27/21 5:19 PM, Christophe Leroy wrote:
> [..]
>>> I opportunistically Cc stable on it: I understand that usually such
>>> stuff isn't a stable material, but that will allow us in CRIU have
>>> one workaround less that is needed just for one release (v5.11) on
>>> one platform (ppc64), which we otherwise have to maintain.
>>
>> Why is that a workaround, and why for one release only ? I think the
>> solution proposed by Laurentto use the aux vector AT_SYSINFO_EHDR should
>> work with any past and future release.
>
> Yeah, I guess.
> Previously, (before v5.11/power) all kernels had ELF start at "[vdso]"
> VMA start, now we'll have to carry the offset in the VMA. Probably, not
> the worst thing, but as it will be only for v5.11 release it can break,
> so needs separate testing.
> Kinda life was a bit easier without this additional code.
The assumption that ELF header is at the start of "[vdso]" is perhaps not a good
one, but using a "[vvar]" section looks more conventional and allows to clearly
identify the data part. I'd argue for this option.
>
>>> I wouldn't go as far as to say that the commit 511157ab641e is ABI
>>> regression as no other userspace got broken, but I'd really appreciate
>>> if it gets backported to v5.11 after v5.12 is released, so as not
>>> to complicate already non-simple CRIU-vdso code. Thanks!
>>>
>>> Cc: Andrei Vagin <avagin@gmail.com>
>>> Cc: Andy Lutomirski <luto@kernel.org>
>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> Cc: Laurent Dufour <ldufour@linux.ibm.com>
>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>> Cc: Paul Mackerras <paulus@samba.org>
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>> Cc: stable@vger.kernel.org # v5.11
>>> [1]: https://github.com/checkpoint-restore/criu/issues/1417
>>> Signed-off-by: Dmitry Safonov <dima@arista.com>
>>> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
>>
>> I tested it with sifreturn_vdso selftest and it worked, because that
>> selftest doesn't involve VDSO data.
>
> Thanks again on helping with testing it, I appreciate it!
>
>> But if I do a mremap() on the VDSO text vma without remapping VVAR to
>> keep the same distance between the two vmas, gettimeofday() crashes. The
>> reason is that the code obtains the address of the data by calculating a
>> fix difference from its own address with the below macro, the delta
>> being resolved at link time:
>>
>> .macro get_datapage ptr
>> bcl 20, 31, .+4
>> 999:
>> mflr \ptr
>> #if CONFIG_PPC_PAGE_SHIFT > 14
>> addis \ptr, \ptr, (_vdso_datapage - 999b)@ha
>> #endif
>> addi \ptr, \ptr, (_vdso_datapage - 999b)@l
>> .endm
>>
>> So the datapage needs to remain at the same distance from the code at
>> all time.
>>
>> Wondering how the other architectures do to have two independent VMAs
>> and be able to move one independently of the other.
>
> It's alright as far as I know. If userspace remaps vdso/vvar it should
> be aware of this (CRIU keeps this in mind, also old vdso image is dumped
> to compare on restore with the one that the host has).
I do agree, playing with the VDSO mapping needs the application to be aware of
the mapping details, and prior to 83d3f0e90c6c "powerpc/mm: tracking vDSO
remap", remapping the VDSO was not working on PowerPC and nobody complained...
Laurent.
^ permalink raw reply
* Re: [PATCH next v1 2/3] printk: remove safe buffers
From: Petr Mladek @ 2021-03-29 10:04 UTC (permalink / raw)
To: John Ogness
Cc: Sergey Senozhatsky, Peter Zijlstra, Paul Mackerras, Tiezhu Yang,
Rafael Aquini, Alexey Kardashevskiy, Yue Hu, Jordan Niethe,
Kees Cook, Paul E. McKenney, Alistair Popple,
Guilherme G. Piccoli, Nicholas Piggin, Steven Rostedt,
Thomas Gleixner, kexec, linux-kernel, Sergey Senozhatsky,
Eric Biederman, Andrew Morton, linuxppc-dev,
Cédric Le Goater
In-Reply-To: <87pmzmi2xm.fsf@jogness.linutronix.de>
On Fri 2021-03-26 12:12:37, John Ogness wrote:
> On 2021-03-23, Petr Mladek <pmladek@suse.com> wrote:
> >> --- a/kernel/printk/printk.c
> >> +++ b/kernel/printk/printk.c
> >> -
> >> if (seq != prb_next_seq(&printk_rb_static)) {
> >> pr_err("dropped %llu messages\n",
> >> prb_next_seq(&printk_rb_static) - seq);
> >> @@ -2666,7 +2631,6 @@ void console_unlock(void)
> >> size_t ext_len = 0;
> >> size_t len;
> >>
> >> - printk_safe_enter_irqsave(flags);
> >> skip:
> >> if (!prb_read_valid(prb, console_seq, &r))
> >> break;
> >> @@ -2711,6 +2675,8 @@ void console_unlock(void)
> >> printk_time);
> >> console_seq++;
> >>
> >> + printk_safe_enter_irqsave(flags);
> >
> > What is the purpose of the printk_safe context here, please?
>
> console_lock_spinning_enable() needs to be called with interrupts
> disabled. I should have just used local_irq_save().
>
> I could add local_irq_save() to console_lock_spinning_enable() and
> restore them at the end of console_lock_spinning_disable_and_check(),
> but then I would need to add a @flags argument to both functions. I
> think it is simpler to just do the disable/enable from the caller,
> console_unlock().
I see. I have missed it that all this code have to be called with
interrupts disabled.
OK, it is a must-to-have because of the spinning. But I wonder if some
console drivers rely on the fact that the write() callback is
called with interrupts disabled.
IMHO, it would be a bug when any write() callback expects that
callers disabled the interrupts.
Do you plan to remove the console-spinning stuff after offloading
consoles to the kthreads?
Will you call console write() callback with irq enabled from
the kthread?
Anyway, we should at least add a comment why the interrupts are
disabled.
> BTW, I could not find any sane way of disabling interrupts via a
> raw_spin_lock_irqsave() of @console_owner_lock because of the how it is
> used with lockdep. In particular for
> console_lock_spinning_disable_and_check().
I see. IMHO, we would need to explicitly call local_irq_save()/restore()
if we moved them to console_lock_spinning_enable()/disable_and_check().
I mean to do:
static void console_lock_spinning_enable(unsigned long *flags)
{
local_irq_save(*flags);
raw_spin_lock(&console_owner_lock);
console_owner = current;
raw_spin_unlock(&console_owner_lock);
/* The waiter may spin on us after setting console_owner */
spin_acquire(&console_owner_dep_map, 0, 0, _THIS_IP_);
}
...
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v2 3/7] powerpc: convert config files to generic cmdline
From: Will Deacon @ 2021-03-29 10:07 UTC (permalink / raw)
To: Daniel Walker
Cc: Rob Herring, Daniel Gimpelevich, X86 ML, open list:MIPS,
linux-kernel@vger.kernel.org, Paul Mackerras, xe-linux-external,
Andrew Morton, linuxppc-dev
In-Reply-To: <20210325195956.GM109100@zorba>
On Thu, Mar 25, 2021 at 12:59:56PM -0700, Daniel Walker 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.
FWIW, they're useful for arm64 and I will gladly review the updated series.
I don't think asking people to stop submitting patches is ever the right
answer. Please don't do that.
Will
^ permalink raw reply
* [PATCH] powerpc/papr_scm: Mark nvdimm as unarmed if needed during probe
From: Vaibhav Jain @ 2021-03-29 11:31 UTC (permalink / raw)
To: linux-nvdimm, linuxppc-dev
Cc: Santosh Sivaraj, Shivaprasad G Bhat, Aneesh Kumar K . V,
Vaibhav Jain, Dan Williams, Ira Weiny
In case an nvdimm is found to be unarmed during probe then set its
NDD_UNARMED flag before nvdimm_create(). This would enforce a
read-only access to the ndimm region. Presently even if an nvdimm is
unarmed its not marked as read-only on ppc64 guests.
The patch updates papr_scm_nvdimm_init() to force query of nvdimm
health via __drc_pmem_query_health() and if nvdimm is found to be
unarmed then set the nvdimm flag ND_UNARMED for nvdimm_create().
Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
---
arch/powerpc/platforms/pseries/papr_scm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
index 835163f54244..7e8168e19427 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -914,6 +914,15 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
dimm_flags = 0;
set_bit(NDD_LABELING, &dimm_flags);
+ /*
+ * Check if the nvdimm is unarmed. No locking needed as we are still
+ * initializing. Ignore error encountered if any.
+ */
+ __drc_pmem_query_health(p);
+
+ if (p->health_bitmap & PAPR_PMEM_UNARMED_MASK)
+ set_bit(NDD_UNARMED, &dimm_flags);
+
p->nvdimm = nvdimm_create(p->bus, p, papr_nd_attr_groups,
dimm_flags, PAPR_SCM_DIMM_CMD_MASK, 0, NULL);
if (!p->nvdimm) {
--
2.30.2
^ permalink raw reply related
* Re: [PATCH 00/30] DMA: Mundane typo fixes
From: Greg KH @ 2021-03-29 11:48 UTC (permalink / raw)
To: Bhaskar Chowdhury, Christoph Hellwig, Linus Torvalds, dmaengine,
dri-devel, iommu, linuxppc-dev, dave.jiang, dan.j.williams,
rdunlap, linux-kernel
In-Reply-To: <YGFrvwX8QngvwPbA@Gentoo>
On Mon, Mar 29, 2021 at 11:25:11AM +0530, Bhaskar Chowdhury wrote:
> On 07:29 Mon 29 Mar 2021, Christoph Hellwig wrote:
> > I really don't think these typo patchbomb are that useful. I'm all
> > for fixing typos when working with a subsystem, but I'm not sure these
> > patchbombs help anything.
> >
> I am sure you are holding the wrong end of the wand and grossly failing to
> understand.
Please stop statements like this, it is not helpful and is doing nothing
but ensure that your patches will not be looked at in the future.
> Anyway, I hope I give a heads up ...find "your way" to fix those damn
> thing...it's glaring....
There is no requirement that anyone accept patches that are sent to
them. When you complain when receiving comments on them, that
shows you do not wish to work with others.
Sorry, but you are now on my local blacklist for a while, and I
encourage other maintainers to just ignore these patches as well.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc/64s: power4 nap fixup in C
From: Andreas Schwab @ 2021-03-29 11:56 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linuxppc-dev, Nicholas Piggin
In-Reply-To: <236a67a4-1609-5fec-3c68-41db02cd1a4c__18973.8760514714$1617008745$gmane$org@csgroup.eu>
On Mär 29 2021, Christophe Leroy wrote:
> Le 29/03/2021 à 10:33, Benjamin Herrenschmidt a écrit :
>> On Fri, 2021-03-12 at 11:20 +1000, Nicholas Piggin wrote:
>>>
>>> +static inline void nap_adjust_return(struct pt_regs *regs)
>>>
>>> +{
>>>
>>> +#ifdef CONFIG_PPC_970_NAP
>>>
>>> + if (unlikely(test_thread_local_flags(_TLF_NAPPING))) {
>>> + /* Can avoid a test-and-clear because NMIs do not call this */
>>> + clear_thread_local_flags(_TLF_NAPPING);
>>> + regs->nip = (unsigned long)power4_idle_nap_return;
>>> + }
>> Is this a pointer to a function descriptor or the actual code ?
>>
>
> --- a/arch/powerpc/kernel/idle_book3s.S
> +++ b/arch/powerpc/kernel/idle_book3s.S
> @@ -209,4 +209,8 @@ _GLOBAL(power4_idle_nap)
> mtmsrd r7
> isync
> b 1b
> +
> + .globl power4_idle_nap_return
> +power4_idle_nap_return:
> + blr
> #endif
The problem is not the definition, it is the reference. In C, a
function symbol always resolves to the address of the descriptor.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 00/30] DMA: Mundane typo fixes
From: Bhaskar Chowdhury @ 2021-03-29 12:57 UTC (permalink / raw)
To: Greg KH
Cc: dave.jiang, Linus Torvalds, rdunlap, linux-kernel, dri-devel,
iommu, dmaengine, dan.j.williams, linuxppc-dev, Christoph Hellwig
In-Reply-To: <YGG+l1EfRuWp0J3A@kroah.com>
[-- Attachment #1: Type: text/plain, Size: 1418 bytes --]
On 13:48 Mon 29 Mar 2021, Greg KH wrote:
>On Mon, Mar 29, 2021 at 11:25:11AM +0530, Bhaskar Chowdhury wrote:
>> On 07:29 Mon 29 Mar 2021, Christoph Hellwig wrote:
>> > I really don't think these typo patchbomb are that useful. I'm all
>> > for fixing typos when working with a subsystem, but I'm not sure these
>> > patchbombs help anything.
>> >
>> I am sure you are holding the wrong end of the wand and grossly failing to
>> understand.
>
>Please stop statements like this, it is not helpful and is doing nothing
>but ensure that your patches will not be looked at in the future.
>
Greg, don't you think you are bit harsh and have an one sided view? People can
say in better way if they don't like some work. I Have always try to get
along.
>> Anyway, I hope I give a heads up ...find "your way" to fix those damn
>> thing...it's glaring....
>
>There is no requirement that anyone accept patches that are sent to
>them. When you complain when receiving comments on them, that
>shows you do not wish to work with others.
>
Unfortunate you are only seeing my complains...I don't know why you are so
blindfolded.
>Sorry, but you are now on my local blacklist for a while, and I
>encourage other maintainers to just ignore these patches as well.
>
I can not overrule that ...I know my pathes are trivial ..but it seems some
other problems are looming large.
NOT good Greg....not good seriously.
>thanks,
>
>greg k-h
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT
From: Michael Ellerman @ 2021-03-29 13:40 UTC (permalink / raw)
To: linuxppc-dev, Aneesh Kumar K.V, mpe; +Cc: Murilo Opsfelder Araujo
In-Reply-To: <20210326070755.304625-1-aneesh.kumar@linux.ibm.com>
On Fri, 26 Mar 2021 12:37:55 +0530, Aneesh Kumar K.V wrote:
> H_PROTECT expect the flag value to include
> flags: AVPN, pp0, pp1, pp2, key0-key4, Noexec, CMO Option flags
>
> This patch updates hpte_updatepp() to fetch the storage key value from the linux page
> table and use the same in H_PROTECT hcall.
>
> native_hpte_updatepp() is not updated because the kernel doesn't clear the existing
> storage key value there. The kernel also doesn't use hpte_updatepp() callback for
> updating storage keys.
>
> [...]
Applied to powerpc/fixes.
[1/1] powerpc/mm/book3s64: Use the correct storage key value when calling H_PROTECT
https://git.kernel.org/powerpc/c/53f1d31708f6240e4615b0927df31f182e389e2f
cheers
^ permalink raw reply
* Re: [PATCH next v1 2/3] printk: remove safe buffers
From: John Ogness @ 2021-03-29 15:10 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Peter Zijlstra, Paul Mackerras, Tiezhu Yang,
Rafael Aquini, Alexey Kardashevskiy, Yue Hu, Jordan Niethe,
Kees Cook, Paul E. McKenney, Alistair Popple,
Guilherme G. Piccoli, Nicholas Piggin, Steven Rostedt,
Thomas Gleixner, kexec, linux-kernel, Sergey Senozhatsky,
Eric Biederman, Andrew Morton, linuxppc-dev,
Cédric Le Goater
In-Reply-To: <YGGmNu5ilDnSKH3g@alley>
On 2021-03-29, Petr Mladek <pmladek@suse.com> wrote:
> I wonder if some console drivers rely on the fact that the write()
> callback is called with interrupts disabled.
>
> IMHO, it would be a bug when any write() callback expects that
> callers disabled the interrupts.
Agreed.
> Do you plan to remove the console-spinning stuff after offloading
> consoles to the kthreads?
Yes. Although a similar concept will be introduced to allow the threaded
printers and the atomic consoles to compete.
> Will you call console write() callback with irq enabled from the
> kthread?
No. That defeats the fundamental purpose of this entire rework
excercise. ;-)
> Anyway, we should at least add a comment why the interrupts are
> disabled.
I decided to move the local_irq_save/restore inside the console-spinning
functions and added a comment for v2.
John Ogness
^ permalink raw reply
* Re: [PATCH next v1 2/3] printk: remove safe buffers
From: John Ogness @ 2021-03-29 15:13 UTC (permalink / raw)
To: Petr Mladek
Cc: Sergey Senozhatsky, Peter Zijlstra, Paul Mackerras, Tiezhu Yang,
Rafael Aquini, Alexey Kardashevskiy, Yue Hu, Jordan Niethe,
Kees Cook, Paul E. McKenney, Alistair Popple,
Guilherme G. Piccoli, Nicholas Piggin, Steven Rostedt,
Thomas Gleixner, kexec, linux-kernel, Sergey Senozhatsky,
Eric Biederman, Andrew Morton, linuxppc-dev,
Cédric Le Goater
In-Reply-To: <87sg4e6lo5.fsf@jogness.linutronix.de>
On 2021-03-29, John Ogness <john.ogness@linutronix.de> wrote:
>> Will you call console write() callback with irq enabled from the
>> kthread?
>
> No. That defeats the fundamental purpose of this entire rework
> excercise. ;-)
Sorry, I misread your question. The answer is "yes". We want to avoid a
local_irq_save() when calling into console->write().
John Ogness
^ permalink raw reply
* Re: [PATCH] powerpc/vdso: Separate vvar vma from vdso
From: Laurent Dufour @ 2021-03-29 15:14 UTC (permalink / raw)
To: Dmitry Safonov, linux-kernel
Cc: Dmitry Safonov, Andrei Vagin, Paul Mackerras, stable,
Andy Lutomirski, linuxppc-dev
In-Reply-To: <20210326191720.138155-1-dima@arista.com>
Le 26/03/2021 à 20:17, Dmitry Safonov a écrit :
> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
> VVAR page is in front of the VDSO area. In result it breaks CRIU
> (Checkpoint Restore In Userspace) [1], where CRIU expects that "[vdso]"
> from /proc/../maps points at ELF/vdso image, rather than at VVAR data page.
> Laurent made a patch to keep CRIU working (by reading aux vector).
> But I think it still makes sence to separate two mappings into different
> VMAs. It will also make ppc64 less "special" for userspace and as
> a side-bonus will make VVAR page un-writable by debugger (which previously
> would COW page and can be unexpected).
>
> I opportunistically Cc stable on it: I understand that usually such
> stuff isn't a stable material, but that will allow us in CRIU have
> one workaround less that is needed just for one release (v5.11) on
> one platform (ppc64), which we otherwise have to maintain.
> I wouldn't go as far as to say that the commit 511157ab641e is ABI
> regression as no other userspace got broken, but I'd really appreciate
> if it gets backported to v5.11 after v5.12 is released, so as not
> to complicate already non-simple CRIU-vdso code. Thanks!
>
> Cc: Andrei Vagin <avagin@gmail.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Laurent Dufour <ldufour@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: stable@vger.kernel.org # v5.11
> [1]: https://github.com/checkpoint-restore/criu/issues/1417
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu>
I run the CRIU's test suite and except the usual suspects, all the tests passed.
Tested-by: Laurent Dufour <ldufour@linux.ibm.com>
> ---
> arch/powerpc/include/asm/mmu_context.h | 2 +-
> arch/powerpc/kernel/vdso.c | 54 +++++++++++++++++++-------
> 2 files changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
> index 652ce85f9410..4bc45d3ed8b0 100644
> --- a/arch/powerpc/include/asm/mmu_context.h
> +++ b/arch/powerpc/include/asm/mmu_context.h
> @@ -263,7 +263,7 @@ extern void arch_exit_mmap(struct mm_struct *mm);
> static inline void arch_unmap(struct mm_struct *mm,
> unsigned long start, unsigned long end)
> {
> - unsigned long vdso_base = (unsigned long)mm->context.vdso - PAGE_SIZE;
> + unsigned long vdso_base = (unsigned long)mm->context.vdso;
>
> if (start <= vdso_base && vdso_base < end)
> mm->context.vdso = NULL;
> diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
> index e839a906fdf2..b14907209822 100644
> --- a/arch/powerpc/kernel/vdso.c
> +++ b/arch/powerpc/kernel/vdso.c
> @@ -55,10 +55,10 @@ static int vdso_mremap(const struct vm_special_mapping *sm, struct vm_area_struc
> {
> unsigned long new_size = new_vma->vm_end - new_vma->vm_start;
>
> - if (new_size != text_size + PAGE_SIZE)
> + if (new_size != text_size)
> return -EINVAL;
>
> - current->mm->context.vdso = (void __user *)new_vma->vm_start + PAGE_SIZE;
> + current->mm->context.vdso = (void __user *)new_vma->vm_start;
>
> return 0;
> }
> @@ -73,6 +73,10 @@ static int vdso64_mremap(const struct vm_special_mapping *sm, struct vm_area_str
> return vdso_mremap(sm, new_vma, &vdso64_end - &vdso64_start);
> }
>
> +static struct vm_special_mapping vvar_spec __ro_after_init = {
> + .name = "[vvar]",
> +};
> +
> static struct vm_special_mapping vdso32_spec __ro_after_init = {
> .name = "[vdso]",
> .mremap = vdso32_mremap,
> @@ -89,11 +93,11 @@ static struct vm_special_mapping vdso64_spec __ro_after_init = {
> */
> static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
> {
> - struct mm_struct *mm = current->mm;
> + unsigned long vdso_size, vdso_base, mappings_size;
> struct vm_special_mapping *vdso_spec;
> + unsigned long vvar_size = PAGE_SIZE;
> + struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> - unsigned long vdso_size;
> - unsigned long vdso_base;
>
> if (is_32bit_task()) {
> vdso_spec = &vdso32_spec;
> @@ -110,8 +114,8 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
> vdso_base = 0;
> }
>
> - /* Add a page to the vdso size for the data page */
> - vdso_size += PAGE_SIZE;
> + mappings_size = vdso_size + vvar_size;
> + mappings_size += (VDSO_ALIGNMENT - 1) & PAGE_MASK;
>
> /*
> * pick a base address for the vDSO in process space. We try to put it
> @@ -119,9 +123,7 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
> * and end up putting it elsewhere.
> * Add enough to the size so that the result can be aligned.
> */
> - vdso_base = get_unmapped_area(NULL, vdso_base,
> - vdso_size + ((VDSO_ALIGNMENT - 1) & PAGE_MASK),
> - 0, 0);
> + vdso_base = get_unmapped_area(NULL, vdso_base, mappings_size, 0, 0);
> if (IS_ERR_VALUE(vdso_base))
> return vdso_base;
>
> @@ -133,7 +135,13 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
> * install_special_mapping or the perf counter mmap tracking code
> * will fail to recognise it as a vDSO.
> */
> - mm->context.vdso = (void __user *)vdso_base + PAGE_SIZE;
> + mm->context.vdso = (void __user *)vdso_base + vvar_size;
> +
> + vma = _install_special_mapping(mm, vdso_base, vvar_size,
> + VM_READ | VM_MAYREAD | VM_IO |
> + VM_DONTDUMP | VM_PFNMAP, &vvar_spec);
> + if (IS_ERR(vma))
> + return PTR_ERR(vma);
>
> /*
> * our vma flags don't have VM_WRITE so by default, the process isn't
> @@ -145,9 +153,12 @@ static int __arch_setup_additional_pages(struct linux_binprm *bprm, int uses_int
> * It's fine to use that for setting breakpoints in the vDSO code
> * pages though.
> */
> - vma = _install_special_mapping(mm, vdso_base, vdso_size,
> + vma = _install_special_mapping(mm, vdso_base + vvar_size, vdso_size,
> VM_READ | VM_EXEC | VM_MAYREAD |
> VM_MAYWRITE | VM_MAYEXEC, vdso_spec);
> + if (IS_ERR(vma))
> + do_munmap(mm, vdso_base, vvar_size, NULL);
> +
> return PTR_ERR_OR_ZERO(vma);
> }
>
> @@ -249,11 +260,22 @@ static struct page ** __init vdso_setup_pages(void *start, void *end)
> if (!pagelist)
> panic("%s: Cannot allocate page list for VDSO", __func__);
>
> - pagelist[0] = virt_to_page(vdso_data);
> -
> for (i = 0; i < pages; i++)
> - pagelist[i + 1] = virt_to_page(start + i * PAGE_SIZE);
> + pagelist[i] = virt_to_page(start + i * PAGE_SIZE);
> +
> + return pagelist;
> +}
> +
> +static struct page ** __init vvar_setup_pages(void)
> +{
> + struct page **pagelist;
>
> + /* .pages is NULL-terminated */
> + pagelist = kcalloc(2, sizeof(struct page *), GFP_KERNEL);
> + if (!pagelist)
> + panic("%s: Cannot allocate page list for VVAR", __func__);
> +
> + pagelist[0] = virt_to_page(vdso_data);
> return pagelist;
> }
>
> @@ -295,6 +317,8 @@ static int __init vdso_init(void)
> if (IS_ENABLED(CONFIG_PPC64))
> vdso64_spec.pages = vdso_setup_pages(&vdso64_start, &vdso64_end);
>
> + vvar_spec.pages = vvar_setup_pages();
> +
> smp_wmb();
>
> return 0;
>
^ 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