* Re: [PATCH 1/2] firmware: include drivers/firmware/Kconfig unconditionally
From: Arnd Bergmann @ 2021-10-11 9:45 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-ia64@vger.kernel.org, Geert Uytterhoeven, Catalin Marinas,
Linus Walleij, Bjorn Andersson, James E.J. Bottomley,
H. Peter Anvin, linux-riscv, Will Deacon, Helge Deller,
the arch/x86 maintainers, Russell King, Ingo Molnar,
open list:BROADCOM NVRAM DRIVER, Paul Menzel, Albert Ou,
Charles Keepax, Arnd Bergmann, Simon Trimmer, Mark Brown,
Borislav Petkov, Paul Walmsley, Thomas Gleixner, Linux ARM,
Thomas Bogendoerfer, Parisc List, Greg Kroah-Hartman,
Liam Girdwood, Linux Kernel Mailing List, Palmer Dabbelt,
Andrew Morton, linuxppc-dev
In-Reply-To: <CAMuHMdXspk27xd95YAsXa73ES8rfKxii3RUEtsBtxQTk9qLztA@mail.gmail.com>
On Mon, Oct 11, 2021 at 10:42 AM Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Sat, Oct 9, 2021 at 11:24 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> > Am 28.09.21 um 09:50 schrieb Arnd Bergmann:
> > > From: Arnd Bergmann <arnd@arndb.de>
> > +#
> > +# ARM System Control and Management Interface Protocol
> > +#
> > +# end of ARM System Control and Management Interface Protocol
> > +
> > +# CONFIG_FIRMWARE_MEMMAP is not set
> > +# CONFIG_GOOGLE_FIRMWARE is not set
> > +
> > +#
> > +# Tegra firmware driver
> > +#
> > +# end of Tegra firmware driver
> > +# end of Firmware Drivers
> > +
> > # CONFIG_GNSS is not set
> > CONFIG_MTD=m
> > # CONFIG_MTD_TESTS is not set
> > ```
> >
> > No idea if the entries could be hidden for platforms not supporting them.
> >
> > ARM System Control and Management Interface Protocol ----
> > [ ] Add firmware-provided memory map to sysfs
> > [ ] Google Firmware Drivers ----
> > Tegra firmware driver ----
>
> GOOGLE_FIRMWARE should probably depend on something.
> I highly doubt Google is running servers on e.g. h8300 and nds32.
GOOGLE_FIRMWARE is only the 'menuconfig' option that contains
the other options, but on architectures that have neither CONFIG_OF
nor CONFIG_ACPI, this is empty. Most architectures of course
do support or require CONFIG_OF, so it's unclear whether we should
show the options for coreboot. Since it's a software-only driver, I
would tend to keep showing it, given that coreboot can be ported
to every architecture. The DT binding [1] seems to be neither
Google nor Arm specific.
CONFIG_FIRMWARE_MEMMAP in turn can be used for
anything that has memory hotplug, and in theory additional
drivers that register with this interface.
I'd lean towards "leave as is" for both, to avoid having to
change the dependencies again whenever something else
can use these.
Arnd
[1] Documentation/devicetree/bindings/firmware/coreboot.txt
^ permalink raw reply
* Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Wolfram Sang @ 2021-10-11 9:37 UTC (permalink / raw)
To: Hector Martin
Cc: Darren Stevens, Arnd Bergmann, Sven Peter, linux-kernel,
linux-i2c, Paul Mackerras, linux-arm-kernel, Christian Zigotzky,
Olof Johansson, Mohamed Mediouni, R.T.Dickinson, Mark Kettenis,
linuxppc-dev, Matthew Leaman, Alyssa Rosenzweig, Stan Skowronek
In-Reply-To: <5ae30425-d6d4-5688-36e3-58cc6c6ff264@marcan.st>
[-- Attachment #1: Type: text/plain, Size: 436 bytes --]
> > Because MAINTAINER dependencies can be a bit nasty, I suggest I drop the
> > MAINTAINER additions for now and we add them later. Then, you can add
> > the pasemi-core as well. D'accord?
> >
>
> We can just split the MAINTAINERS changes into a separate patch and I can
> push that one through the SoC tree, along with other MAINTAINERS updates.
> Does that work for everyone?
That would also work for me. Thank you!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Wolfram Sang @ 2021-10-11 8:54 UTC (permalink / raw)
To: Sven Peter
Cc: Hector Martin, Arnd Bergmann, Christian Zigotzky, linux-kernel,
linux-i2c, Darren Stevens, Paul Mackerras, linux-arm-kernel,
Olof Johansson, Mohamed Mediouni, R.T.Dickinson, Mark Kettenis,
linuxppc-dev, Matthew Leaman, Alyssa Rosenzweig, Stan Skowronek
In-Reply-To: <11d8f784-c90a-4e6c-9abd-564cb5241cb7@www.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 362 bytes --]
> MAINTAINERS. It'll probably apply cleanly to 5.15-rc5 but if that happens again
It doesn't because Linus' git doesn't have:
Documentation/devicetree/bindings/pci/apple,pcie.yaml
Because MAINTAINER dependencies can be a bit nasty, I suggest I drop the
MAINTAINER additions for now and we add them later. Then, you can add
the pasemi-core as well. D'accord?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] firmware: include drivers/firmware/Kconfig unconditionally
From: Geert Uytterhoeven @ 2021-10-11 8:42 UTC (permalink / raw)
To: Paul Menzel
Cc: linux-ia64@vger.kernel.org, Geert Uytterhoeven, Catalin Marinas,
Linus Walleij, Bjorn Andersson, James E.J. Bottomley,
H. Peter Anvin, linux-riscv, Will Deacon, Helge Deller,
the arch/x86 maintainers, Russell King, Ingo Molnar,
open list:BROADCOM NVRAM DRIVER, Albert Ou, Charles Keepax,
Arnd Bergmann, Simon Trimmer, Mark Brown, Borislav Petkov,
Paul Walmsley, Thomas Gleixner, Linux ARM, Arnd Bergmann,
Thomas Bogendoerfer, Parisc List, Greg Kroah-Hartman,
Liam Girdwood, Linux Kernel Mailing List, Palmer Dabbelt,
Andrew Morton, linuxppc-dev
In-Reply-To: <9dedf9bb-5377-9f2c-cbb1-2a57b40493da@molgen.mpg.de>
On Sat, Oct 9, 2021 at 11:24 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
> [Cc: +linuxppc-dev@lists.ozlabs.org]
>
> Am 28.09.21 um 09:50 schrieb Arnd Bergmann:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > Compile-testing drivers that require access to a firmware layer
> > fails when that firmware symbol is unavailable. This happened
> > twice this week:
> >
> > - My proposed to change to rework the QCOM_SCM firmware symbol
> > broke on ppc64 and others.
> >
> > - The cs_dsp firmware patch added device specific firmware loader
> > into drivers/firmware, which broke on the same set of
> > architectures.
> >
> > We should probably do the same thing for other subsystems as well,
> > but fix this one first as this is a dependency for other patches
> > getting merged.
> >
> With this change, I have the new entries below in my .config:
>
> ```
> $ diff -u .config.old .config
> --- .config.old 2021-10-07 11:38:39.544000000 +0200
> +++ .config 2021-10-09 10:02:03.156000000 +0200
> @@ -1992,6 +1992,25 @@
>
> CONFIG_CONNECTOR=y
> CONFIG_PROC_EVENTS=y
> +
> +#
> +# Firmware Drivers
> +#
> +
> +#
> +# ARM System Control and Management Interface Protocol
> +#
> +# end of ARM System Control and Management Interface Protocol
> +
> +# CONFIG_FIRMWARE_MEMMAP is not set
> +# CONFIG_GOOGLE_FIRMWARE is not set
> +
> +#
> +# Tegra firmware driver
> +#
> +# end of Tegra firmware driver
> +# end of Firmware Drivers
> +
> # CONFIG_GNSS is not set
> CONFIG_MTD=m
> # CONFIG_MTD_TESTS is not set
> ```
>
> No idea if the entries could be hidden for platforms not supporting them.
>
> ARM System Control and Management Interface Protocol ----
> [ ] Add firmware-provided memory map to sysfs
> [ ] Google Firmware Drivers ----
> Tegra firmware driver ----
GOOGLE_FIRMWARE should probably depend on something.
I highly doubt Google is running servers on e.g. h8300 and nds32.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] powerpc/boot: Use CONFIG_PPC_POWERNV to compile OPAL support
From: Cédric Le Goater @ 2021-10-11 7:03 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cédric Le Goater
CONFIG_PPC64_BOOT_WRAPPER is selected by CPU_LITTLE_ENDIAN which is
used to compile support for other platforms such as Microwatt. There
is no need for OPAL calls on these.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/boot/serial.c | 2 +-
arch/powerpc/boot/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/serial.c b/arch/powerpc/boot/serial.c
index 9a19e5905485..54d2522be485 100644
--- a/arch/powerpc/boot/serial.c
+++ b/arch/powerpc/boot/serial.c
@@ -132,7 +132,7 @@ int serial_console_init(void)
else if (dt_is_compatible(devp, "fsl,mpc5200-psc-uart"))
rc = mpc5200_psc_console_init(devp, &serial_cd);
#endif
-#ifdef CONFIG_PPC64_BOOT_WRAPPER
+#ifdef CONFIG_PPC_POWERNV
else if (dt_is_compatible(devp, "ibm,opal-console-raw"))
rc = opal_console_init(devp, &serial_cd);
#endif
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 089ee3ea55c8..9993c6256ad2 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -123,7 +123,7 @@ src-wlib-y := string.S crt0.S stdio.c decompress.c main.c \
oflib.c ofconsole.c cuboot.c
src-wlib-$(CONFIG_PPC_MPC52xx) += mpc52xx-psc.c
-src-wlib-$(CONFIG_PPC64_BOOT_WRAPPER) += opal-calls.S opal.c
+src-wlib-$(CONFIG_PPC_POWERNV) += opal-calls.S opal.c
ifndef CONFIG_PPC64_BOOT_WRAPPER
src-wlib-y += crtsavres.S
endif
--
2.31.1
^ permalink raw reply related
* [PATCH] powerpc/xive: Discard disabled interrupts in get_irqchip_state()
From: Cédric Le Goater @ 2021-10-11 7:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Cédric Le Goater, stable
When an interrupt is passed through, the KVM XIVE device calls the
set_vcpu_affinity() handler which raises the P bit to mask the
interrupt and to catch any in-flight interrupts while routing the
interrupt to the guest.
On the guest side, drivers (like some Intels) can request at probe
time some MSIs and call synchronize_irq() to check that there are no
in flight interrupts. This will call the XIVE get_irqchip_state()
handler which will always return true as the interrupt P bit has been
set on the host side and lock the CPU in an infinite loop.
Fix that by discarding disabled interrupts in get_irqchip_state().
Fixes: da15c03b047d ("powerpc/xive: Implement get_irqchip_state method for XIVE to fix shutdown race")
Cc: stable@vger.kernel.org#v5.4+
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
arch/powerpc/sysdev/xive/common.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/xive/common.c b/arch/powerpc/sysdev/xive/common.c
index c732ce5a3e1a..c5d75c02ad8b 100644
--- a/arch/powerpc/sysdev/xive/common.c
+++ b/arch/powerpc/sysdev/xive/common.c
@@ -945,7 +945,8 @@ static int xive_get_irqchip_state(struct irq_data *data,
* interrupt to be inactive in that case.
*/
*state = (pq != XIVE_ESB_INVALID) && !xd->stale_p &&
- (xd->saved_p || !!(pq & XIVE_ESB_VAL_P));
+ (xd->saved_p || (!!(pq & XIVE_ESB_VAL_P) &&
+ !irqd_irq_disabled(data)));
return 0;
default:
return -EINVAL;
--
2.31.1
^ permalink raw reply related
* Re: [PATCH v6 19/22] powerpc/book3s64/hash/kuap: Enable kuap on hash
From: Michael Ellerman @ 2021-10-11 3:28 UTC (permalink / raw)
To: Christophe Leroy, Aneesh Kumar K.V, linuxppc-dev; +Cc: Sandipan Das
In-Reply-To: <b2ab09a4-7f30-deee-e983-9459d93cb9b3@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 25/11/2020 à 06:16, Aneesh Kumar K.V a écrit :
>> Reviewed-by: Sandipan Das <sandipan@linux.ibm.com>
>> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
>> ---
>> arch/powerpc/mm/book3s64/pkeys.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/mm/book3s64/pkeys.c b/arch/powerpc/mm/book3s64/pkeys.c
>> index f747d66cc87d..84f8664ffc47 100644
>> --- a/arch/powerpc/mm/book3s64/pkeys.c
>> +++ b/arch/powerpc/mm/book3s64/pkeys.c
>> @@ -257,7 +257,12 @@ void __init setup_kuep(bool disabled)
>> #ifdef CONFIG_PPC_KUAP
>> void __init setup_kuap(bool disabled)
>> {
>> - if (disabled || !early_radix_enabled())
>> + if (disabled)
>> + return;
>> + /*
>> + * On hash if PKEY feature is not enabled, disable KUAP too.
>> + */
>> + if (!early_radix_enabled() && !early_mmu_has_feature(MMU_FTR_PKEY))
>
> pkey_early_init_devtree() bails out without setting MMU_FTR_PKEY with
> the following:
>
> /*
> * Only P7 and above supports SPRN_AMR update with MSR[PR] = 1
> */
> if (!early_cpu_has_feature(CPU_FTR_ARCH_206))
> return;
>
>
>
> Why would it be impossible to do KUAP in that case ? KUAP doesn't
> require updating SPRN_AMR with MSR[PR] = 1
You're right, it would be possible to do KUAP in that case.
That's an artifact of KUAP being implemented using PKEYs on hash. For
the PKEYs user-visible API we want AMR to be user controlled.
It's possible we could untangle all that, allowing KUAP to be
implemented on earlier CPUs, but I'm not sure it's going to be high on
anyone's todo list.
cheers
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS ece9c55cc2f2c408240cd5627ea46926e9d4e5eb
From: kernel test robot @ 2021-10-11 1:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: ece9c55cc2f2c408240cd5627ea46926e9d4e5eb Automatic merge of 'master' into merge (2021-10-10 22:52)
elapsed time: 723m
configs tested: 208
configs skipped: 4
The following configs have been built successfully.
More configs may be tested in the coming days.
gcc tested configs:
arm defconfig
arm64 allyesconfig
arm64 defconfig
arm allyesconfig
arm allmodconfig
i386 randconfig-c001-20211010
mips randconfig-c004-20211010
powerpc ge_imp3a_defconfig
m68k m5249evb_defconfig
arm viper_defconfig
openrisc simple_smp_defconfig
arm omap2plus_defconfig
m68k m5475evb_defconfig
sh allmodconfig
powerpc lite5200b_defconfig
arm imote2_defconfig
powerpc motionpro_defconfig
mips tb0219_defconfig
ia64 tiger_defconfig
arm milbeaut_m10v_defconfig
mips rb532_defconfig
s390 zfcpdump_defconfig
mips loongson2k_defconfig
mips maltaup_defconfig
sh apsh4ad0a_defconfig
powerpc ppc40x_defconfig
arm xcep_defconfig
arm badge4_defconfig
mips maltasmvp_defconfig
mips cobalt_defconfig
sh se7780_defconfig
arm cm_x300_defconfig
sh rts7751r2d1_defconfig
powerpc ep8248e_defconfig
powerpc ksi8560_defconfig
mips ip28_defconfig
arm bcm2835_defconfig
powerpc rainier_defconfig
arm exynos_defconfig
arm simpad_defconfig
arm imx_v4_v5_defconfig
powerpc redwood_defconfig
sparc64 defconfig
powerpc wii_defconfig
ia64 bigsur_defconfig
mips bcm63xx_defconfig
arm pleb_defconfig
arm mvebu_v7_defconfig
m68k multi_defconfig
mips sb1250_swarm_defconfig
powerpc64 defconfig
powerpc mvme5100_defconfig
powerpc warp_defconfig
xtensa defconfig
openrisc or1ksim_defconfig
sh sh7785lcr_32bit_defconfig
powerpc mpc836x_mds_defconfig
nios2 alldefconfig
powerpc adder875_defconfig
sh se7343_defconfig
h8300 defconfig
sh lboxre2_defconfig
powerpc sam440ep_defconfig
powerpc amigaone_defconfig
sh apsh4a3a_defconfig
sh j2_defconfig
powerpc eiger_defconfig
arm axm55xx_defconfig
arm sama7_defconfig
arm iop32x_defconfig
powerpc ps3_defconfig
riscv nommu_k210_defconfig
nds32 defconfig
h8300 alldefconfig
powerpc iss476-smp_defconfig
mips rt305x_defconfig
arm lpc18xx_defconfig
powerpc g5_defconfig
m68k amcore_defconfig
m68k bvme6000_defconfig
ia64 gensparse_defconfig
arm pxa_defconfig
sh se7206_defconfig
sh se7724_defconfig
arm oxnas_v6_defconfig
arm realview_defconfig
powerpc sequoia_defconfig
sparc sparc32_defconfig
arm orion5x_defconfig
arm colibri_pxa300_defconfig
powerpc acadia_defconfig
xtensa iss_defconfig
arm pxa910_defconfig
h8300 h8s-sim_defconfig
sh se7750_defconfig
powerpc mpc832x_rdb_defconfig
mips decstation_64_defconfig
sh shx3_defconfig
powerpc mgcoge_defconfig
mips malta_defconfig
riscv nommu_k210_sdcard_defconfig
powerpc cell_defconfig
arc axs103_defconfig
m68k mvme16x_defconfig
arm cns3420vb_defconfig
arm hisi_defconfig
arc tb10x_defconfig
arm vf610m4_defconfig
sh espt_defconfig
s390 alldefconfig
arm integrator_defconfig
sh ap325rxa_defconfig
arm pcm027_defconfig
arm colibri_pxa270_defconfig
um defconfig
arm randconfig-c002-20211010
x86_64 randconfig-c001-20211010
arm randconfig-c002-20211011
i386 randconfig-c001-20211011
x86_64 randconfig-c001-20211011
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k defconfig
m68k allmodconfig
m68k allyesconfig
nios2 defconfig
arc allyesconfig
nds32 allnoconfig
csky defconfig
alpha defconfig
alpha allyesconfig
nios2 allyesconfig
h8300 allyesconfig
arc defconfig
xtensa allyesconfig
parisc defconfig
parisc allyesconfig
s390 defconfig
s390 allyesconfig
s390 allmodconfig
i386 allyesconfig
sparc allyesconfig
i386 defconfig
sparc defconfig
mips allyesconfig
mips allmodconfig
powerpc allyesconfig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20211010
x86_64 randconfig-a006-20211010
x86_64 randconfig-a001-20211010
x86_64 randconfig-a005-20211010
x86_64 randconfig-a002-20211010
x86_64 randconfig-a003-20211010
i386 randconfig-a001-20211010
i386 randconfig-a003-20211010
i386 randconfig-a004-20211010
i386 randconfig-a005-20211010
i386 randconfig-a002-20211010
i386 randconfig-a006-20211010
x86_64 randconfig-a015-20211011
x86_64 randconfig-a012-20211011
x86_64 randconfig-a016-20211011
x86_64 randconfig-a014-20211011
x86_64 randconfig-a013-20211011
x86_64 randconfig-a011-20211011
arc randconfig-r043-20211010
riscv nommu_virt_defconfig
riscv allnoconfig
riscv defconfig
riscv rv32_defconfig
riscv allyesconfig
riscv allmodconfig
um x86_64_defconfig
um i386_defconfig
x86_64 rhel-8.3-kselftests
x86_64 defconfig
x86_64 rhel-8.3
x86_64 kexec
x86_64 allyesconfig
clang tested configs:
arm randconfig-c002-20211010
mips randconfig-c004-20211010
i386 randconfig-c001-20211010
s390 randconfig-c005-20211010
x86_64 randconfig-c007-20211010
powerpc randconfig-c003-20211010
riscv randconfig-c006-20211010
x86_64 randconfig-a015-20211010
x86_64 randconfig-a012-20211010
x86_64 randconfig-a016-20211010
x86_64 randconfig-a014-20211010
x86_64 randconfig-a013-20211010
x86_64 randconfig-a011-20211010
i386 randconfig-a016-20211010
i386 randconfig-a014-20211010
i386 randconfig-a011-20211010
i386 randconfig-a015-20211010
i386 randconfig-a012-20211010
i386 randconfig-a013-20211010
x86_64 randconfig-a004-20211011
x86_64 randconfig-a006-20211011
x86_64 randconfig-a001-20211011
x86_64 randconfig-a005-20211011
x86_64 randconfig-a002-20211011
x86_64 randconfig-a003-20211011
hexagon randconfig-r041-20211010
s390 randconfig-r044-20211010
riscv randconfig-r042-20211010
hexagon randconfig-r045-20211010
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: linux-next: build warnings in Linus' tree
From: Stephen Rothwell @ 2021-10-10 21:27 UTC (permalink / raw)
To: Michael Ellerman, PowerPC
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Rob Herring
In-Reply-To: <20211008164728.30e3d3a3@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2919 bytes --]
Hi all,
[Cc'ing Rob]
Rob: these warnings have been there for a long time ...
On Fri, 8 Oct 2021 16:47:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the origin tree, today's linux-next build (powerpc
> allyesconfig) produced these warnings (along with many others):
>
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
> arch/powerpc/boot/dts/mpc5200b.dtsi:182.18-186.5: Warning (spi_bus_bridge): /soc5200@f0000000/psc@2000: node name for SPI buses should be 'spi'
> arch/powerpc/boot/dts/mpc5200b.dtsi:267.20-280.4: Warning (pci_bridge): /pci@f0000d00: missing ranges for PCI bridge (or not a bridge)
>
> Given that arch/powerpc/boot/dts/mpc5200b.dtsi is oncluded by several
> other dts files, fixing this one file would go quite a long way to
> silencing our allyesoncig build. Unfotunatley, I have no idea how to
> fix this file (ad maybe some fo the interactions it has with other files).
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.15-3 tag
From: pr-tracker-bot @ 2021-10-10 17:17 UTC (permalink / raw)
To: Michael Ellerman
Cc: songliubraving, johan.almbladh, aik, linuxppc-dev, npiggin,
linux-kernel, mahesh, clg, naveen.n.rao, Linus Torvalds
In-Reply-To: <87y271m5ft.fsf@mpe.ellerman.id.au>
The pull request you sent on Sun, 10 Oct 2021 23:26:30 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.15-3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/efb52a7d9511df818391f1afa459507425833438
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [PATCH] tpm: ibmvtpm: Make use of dma_alloc_coherent()
From: Cai Huoqing @ 2021-10-10 16:01 UTC (permalink / raw)
To: caihuoqing
Cc: linux-kernel, Jason Gunthorpe, Jarkko Sakkinen, Paul Mackerras,
Peter Huewe, linuxppc-dev, linux-integrity
Replacing kmalloc/kfree/get_zeroed_page/free_page/dma_map_single/
dma_unmap_single() with dma_alloc_coherent/dma_free_coherent()
helps to reduce code size, and simplify the code, and coherent
DMA will not clear the cache every time.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/char/tpm/tpm_ibmvtpm.c | 61 ++++++++++------------------------
1 file changed, 18 insertions(+), 43 deletions(-)
diff --git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index 3af4c07a9342..5f55a14ee824 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -356,15 +356,12 @@ static void tpm_ibmvtpm_remove(struct vio_dev *vdev)
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
} while (rc == H_BUSY || H_IS_LONG_BUSY(rc));
- dma_unmap_single(ibmvtpm->dev, ibmvtpm->crq_dma_handle,
- CRQ_RES_BUF_SIZE, DMA_BIDIRECTIONAL);
- free_page((unsigned long)ibmvtpm->crq_queue.crq_addr);
-
- if (ibmvtpm->rtce_buf) {
- dma_unmap_single(ibmvtpm->dev, ibmvtpm->rtce_dma_handle,
- ibmvtpm->rtce_size, DMA_BIDIRECTIONAL);
- kfree(ibmvtpm->rtce_buf);
- }
+ dma_free_coherent(ibmvtpm->dev, CRQ_RES_BUF_SIZE,
+ crq_q->crq_addr, crq_q->crq_dma_handle);
+
+ if (ibmvtpm->rtce_buf)
+ dma_free_coherent(ibmvtpm->dev, ibmvtpm->rtce_size,
+ ibmvtpm->rtce_buf, ibmvtpm->rtce_dma_handle);
kfree(ibmvtpm);
/* For tpm_ibmvtpm_get_desired_dma */
@@ -522,23 +519,12 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
return;
}
ibmvtpm->rtce_size = be16_to_cpu(crq->len);
- ibmvtpm->rtce_buf = kmalloc(ibmvtpm->rtce_size,
- GFP_ATOMIC);
- if (!ibmvtpm->rtce_buf) {
- dev_err(ibmvtpm->dev, "Failed to allocate memory for rtce buffer\n");
- return;
- }
-
- ibmvtpm->rtce_dma_handle = dma_map_single(ibmvtpm->dev,
- ibmvtpm->rtce_buf, ibmvtpm->rtce_size,
- DMA_BIDIRECTIONAL);
-
- if (dma_mapping_error(ibmvtpm->dev,
- ibmvtpm->rtce_dma_handle)) {
- kfree(ibmvtpm->rtce_buf);
- ibmvtpm->rtce_buf = NULL;
- dev_err(ibmvtpm->dev, "Failed to dma map rtce buffer\n");
- }
+ ibmvtpm->rtce_buf = dma_alloc_coherent(ibmvtpm->dev,
+ ibmvtpm->rtce_size,
+ &ibmvtpm->rtce_dma_handle,
+ GFP_ATOMIC);
+ if (!ibmvtpm->rtce_buf)
+ dev_err(ibmvtpm->dev, "Failed to dma allocate rtce buffer\n");
return;
case VTPM_GET_VERSION_RES:
@@ -618,22 +604,13 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
ibmvtpm->vdev = vio_dev;
crq_q = &ibmvtpm->crq_queue;
- crq_q->crq_addr = (struct ibmvtpm_crq *)get_zeroed_page(GFP_KERNEL);
- if (!crq_q->crq_addr) {
- dev_err(dev, "Unable to allocate memory for crq_addr\n");
- goto cleanup;
- }
crq_q->num_entry = CRQ_RES_BUF_SIZE / sizeof(*crq_q->crq_addr);
init_waitqueue_head(&crq_q->wq);
- ibmvtpm->crq_dma_handle = dma_map_single(dev, crq_q->crq_addr,
- CRQ_RES_BUF_SIZE,
- DMA_BIDIRECTIONAL);
-
- if (dma_mapping_error(dev, ibmvtpm->crq_dma_handle)) {
- dev_err(dev, "dma mapping failed\n");
+ crq_q->crq_addr = dma_alloc_coherent(dev, CRQ_RES_BUF_SIZE,
+ &ibmvtpm->crq_dma_handle, GFP_KERNEL);
+ if (!crq_q->crq_addr)
goto cleanup;
- }
rc = plpar_hcall_norets(H_REG_CRQ, vio_dev->unit_address,
ibmvtpm->crq_dma_handle, CRQ_RES_BUF_SIZE);
@@ -642,7 +619,7 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
if (rc) {
dev_err(dev, "Unable to register CRQ rc=%d\n", rc);
- goto reg_crq_cleanup;
+ goto cleanup;
}
rc = request_irq(vio_dev->irq, ibmvtpm_interrupt, 0,
@@ -704,13 +681,11 @@ static int tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
do {
rc1 = plpar_hcall_norets(H_FREE_CRQ, vio_dev->unit_address);
} while (rc1 == H_BUSY || H_IS_LONG_BUSY(rc1));
-reg_crq_cleanup:
- dma_unmap_single(dev, ibmvtpm->crq_dma_handle, CRQ_RES_BUF_SIZE,
- DMA_BIDIRECTIONAL);
cleanup:
if (ibmvtpm) {
if (crq_q->crq_addr)
- free_page((unsigned long)crq_q->crq_addr);
+ dma_free_coherent(dev, CRQ_RES_BUF_SIZE,
+ crq_q->crq_addr, crq_q->crq_dma_handle);
kfree(ibmvtpm);
}
--
2.25.1
^ permalink raw reply related
* [PATCH] scsi: ibmvscsi: Use dma_alloc_coherent() instead of get_zeroed_page/dma_map_single()
From: Cai Huoqing @ 2021-10-10 16:01 UTC (permalink / raw)
To: caihuoqing
Cc: Tyrel Datwyler, linux-scsi, Martin K. Petersen,
James E.J. Bottomley, linux-kernel, Paul Mackerras, linuxppc-dev
Replacing get_zeroed_page/free_page/dma_map_single/dma_unmap_single()
with dma_alloc_coherent/dma_free_coherent() helps to reduce
code size, and simplify the code, and coherent DMA will not
clear the cache every time.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
---
drivers/scsi/ibmvscsi/ibmvfc.c | 15 +++------------
drivers/scsi/ibmvscsi/ibmvscsi.c | 26 ++++++--------------------
2 files changed, 9 insertions(+), 32 deletions(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 1f1586ad48fe..f65d1a78b272 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -869,8 +869,7 @@ static void ibmvfc_free_queue(struct ibmvfc_host *vhost,
{
struct device *dev = vhost->dev;
- dma_unmap_single(dev, queue->msg_token, PAGE_SIZE, DMA_BIDIRECTIONAL);
- free_page((unsigned long)queue->msgs.handle);
+ dma_free_coherent(dev, PAGE_SIZE, queue->msgs.handle, queue->msg_token);
queue->msgs.handle = NULL;
ibmvfc_free_event_pool(vhost, queue);
@@ -5663,19 +5662,11 @@ static int ibmvfc_alloc_queue(struct ibmvfc_host *vhost,
return -ENOMEM;
}
- queue->msgs.handle = (void *)get_zeroed_page(GFP_KERNEL);
+ queue->msgs.handle = dma_alloc_coherent(dev, PAGE_SIZE,
+ &queue->msg_token, GFP_KERNEL);
if (!queue->msgs.handle)
return -ENOMEM;
- queue->msg_token = dma_map_single(dev, queue->msgs.handle, PAGE_SIZE,
- DMA_BIDIRECTIONAL);
-
- if (dma_mapping_error(dev, queue->msg_token)) {
- free_page((unsigned long)queue->msgs.handle);
- queue->msgs.handle = NULL;
- return -ENOMEM;
- }
-
queue->cur = 0;
queue->fmt = fmt;
queue->size = PAGE_SIZE / fmt_size;
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
index ea8e01f49cba..61b315d1edbc 100644
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -151,10 +151,7 @@ static void ibmvscsi_release_crq_queue(struct crq_queue *queue,
msleep(100);
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
} while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
- dma_unmap_single(hostdata->dev,
- queue->msg_token,
- queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL);
- free_page((unsigned long)queue->msgs);
+ dma_free_coherent(hostdata->dev, PAGE_SIZE, queue->msgs, queue->msg_token);
}
/**
@@ -331,18 +328,11 @@ static int ibmvscsi_init_crq_queue(struct crq_queue *queue,
int retrc;
struct vio_dev *vdev = to_vio_dev(hostdata->dev);
- queue->msgs = (struct viosrp_crq *)get_zeroed_page(GFP_KERNEL);
-
- if (!queue->msgs)
- goto malloc_failed;
queue->size = PAGE_SIZE / sizeof(*queue->msgs);
-
- queue->msg_token = dma_map_single(hostdata->dev, queue->msgs,
- queue->size * sizeof(*queue->msgs),
- DMA_BIDIRECTIONAL);
-
- if (dma_mapping_error(hostdata->dev, queue->msg_token))
- goto map_failed;
+ queue->msgs = dma_alloc_coherent(hostdata->dev, PAGE_SIZE,
+ &queue->msg_token, GFP_KERNEL);
+ if (!queue->msg)
+ goto malloc_failed;
gather_partition_info();
set_adapter_info(hostdata);
@@ -395,11 +385,7 @@ static int ibmvscsi_init_crq_queue(struct crq_queue *queue,
rc = plpar_hcall_norets(H_FREE_CRQ, vdev->unit_address);
} while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
reg_crq_failed:
- dma_unmap_single(hostdata->dev,
- queue->msg_token,
- queue->size * sizeof(*queue->msgs), DMA_BIDIRECTIONAL);
- map_failed:
- free_page((unsigned long)queue->msgs);
+ dma_free_coherent(hostdata->dev, PAGE_SIZE, queue->msg, queue->msg_token);
malloc_failed:
return -1;
}
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Sven Peter @ 2021-10-10 13:17 UTC (permalink / raw)
To: Christian Zigotzky, Wolfram Sang, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Olof Johansson,
Arnd Bergmann, Hector Martin, Mohamed Mediouni, Stan Skowronek,
Mark Kettenis, Alyssa Rosenzweig, linux-arm-kernel, linuxppc-dev,
linux-i2c, linux-kernel, R.T.Dickinson, Matthew Leaman,
Darren Stevens
In-Reply-To: <8a8afc73-3756-a305-ce5f-70b4bce6999f@xenosoft.de>
On Sat, Oct 9, 2021, at 15:57, Christian Zigotzky wrote:
> On 09 October 2021 at 12:10 pm, Wolfram Sang wrote:
>>> I still don't have access to any old PASemi hardware but the changes from
>>> v1 are pretty small and I expect them to still work. Would still be nice
>>> if someone with access to such hardware could give this a quick test.
>> Looks good to me. I will wait a few more days so that people can report
>> their tests. But it will be in the next merge window.
>>
> Series v2:
>
> Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> [1]
thanks a lot, glad to hear everything works on P.A Semi CPUs as well!
And regarding that git am issue you wrote about: I think I based this series on
torvald's tree instead of 5.15-rc4 and there have been some changes to at least
MAINTAINERS. It'll probably apply cleanly to 5.15-rc5 but if that happens again
in the future you can try
git am -3 mbox
instead. It'll try to do a three way merge if the patch doesn't apply cleanly.
Sven
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.15-3 tag
From: Michael Ellerman @ 2021-10-10 12:26 UTC (permalink / raw)
To: Linus Torvalds
Cc: songliubraving, johan.almbladh, aik, npiggin, linux-kernel,
mahesh, clg, naveen.n.rao, linuxppc-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.15.
A bit of a big batch, partly because I didn't send any last week, and also just because
the BPF fixes happened to land this week.
cheers
The following changes since commit e4e737bb5c170df6135a127739a9e6148ee3da82:
Linux 5.15-rc2 (2021-09-19 17:28:22 -0700)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.15-3
for you to fetch changes up to eb8257a12192f43ffd41bd90932c39dade958042:
pseries/eeh: Fix the kdump kernel crash during eeh_pseries_init (2021-10-07 23:37:22 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.15 #3
Fix a regression hit by the IPR SCSI driver, introduced by the recent addition of MSI
domains on pseries.
A big series including 8 BPF fixes, some with potential security impact and the rest
various code generation issues.
Fix our program check assembler entry path, which was accidentally jumping into a gas
macro and generating strange stack frames, which could confuse find_bug().
A couple of fixes, and related changes, to fix corner cases in our machine check handling.
Fix our DMA IOMMU ops, which were not always returning the optimal DMA mask, leading to
at least one device falling back to 32-bit DMA when it shouldn't.
A fix for KUAP handling on 32-bit Book3S.
Fix crashes seen when kdumping on some pseries systems.
Thanks to: Naveen N. Rao, Nicholas Piggin, Alexey Kardashevskiy, Cédric Le Goater,
Christophe Leroy, Mahesh Salgaonkar, Abdul Haleem, Christoph Hellwig, Johan Almbladh, Stan
Johnson.
- ------------------------------------------------------------------
Alexey Kardashevskiy (1):
powerpc/iommu: Report the correct most efficient DMA mask for PCI devices
Christophe Leroy (1):
powerpc/32s: Fix kuap_kernel_restore()
Cédric Le Goater (1):
powerpc/pseries/msi: Add an empty irq_write_msi_msg() handler
Mahesh Salgaonkar (1):
pseries/eeh: Fix the kdump kernel crash during eeh_pseries_init
Naveen N. Rao (10):
powerpc/lib: Add helper to check if offset is within conditional branch range
powerpc/bpf: Validate branch ranges
powerpc/bpf: Fix BPF_MOD when imm == 1
powerpc/bpf: Fix BPF_SUB when imm == 0x80000000
powerpc/security: Add a helper to query stf_barrier type
powerpc/bpf: Emit stf barrier instruction sequences for BPF_NOSPEC
powerpc/bpf ppc32: Fix ALU32 BPF_ARSH operation
powerpc/bpf ppc32: Fix JMP32_JSET_K
powerpc/bpf ppc32: Do not emit zero extend instruction for 64-bit BPF_END
powerpc/bpf ppc32: Fix BPF_SUB when imm == 0x80000000
Nicholas Piggin (5):
powerpc/64s: fix program check interrupt emergency stack path
powerpc/traps: do not enable irqs in _exception
powerpc/64: warn if local irqs are enabled in NMI or hardirq context
powerpc/64/interrupt: Reconcile soft-mask state in NMI and fix false BUG
powerpc/64s: Fix unrecoverable MCE calling async handler from NMI
arch/powerpc/include/asm/book3s/32/kup.h | 8 ++
arch/powerpc/include/asm/code-patching.h | 1 +
arch/powerpc/include/asm/interrupt.h | 18 ++--
arch/powerpc/include/asm/security_features.h | 5 +
arch/powerpc/kernel/dma-iommu.c | 9 ++
arch/powerpc/kernel/exceptions-64s.S | 25 +++--
arch/powerpc/kernel/irq.c | 6 ++
arch/powerpc/kernel/security.c | 5 +
arch/powerpc/kernel/traps.c | 43 +++++----
arch/powerpc/lib/code-patching.c | 7 +-
arch/powerpc/net/bpf_jit.h | 33 ++++---
arch/powerpc/net/bpf_jit64.h | 8 +-
arch/powerpc/net/bpf_jit_comp.c | 6 +-
arch/powerpc/net/bpf_jit_comp32.c | 16 ++--
arch/powerpc/net/bpf_jit_comp64.c | 100 ++++++++++++++++----
arch/powerpc/platforms/pseries/eeh_pseries.c | 4 +
arch/powerpc/platforms/pseries/msi.c | 15 +++
17 files changed, 234 insertions(+), 75 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmFi26IACgkQUevqPMjh
pYCMSxAAh40nmRryws4rJ6R6UQlp5eKKAitlFo5y/P3h/qNzu5kelwkS93tog5CA
9i/uznMlyu3jpauHiDaeZCU0WYBqs3AL3qE11pHeG4HkGCCQ/D5eX3KxFRYuqbWh
mfGvgRGxr4Rew3ACgQ/eUGwU9DkzmAr49CX9/5MR8chpNzeERpPMcq4jolEjkfJl
Jf74WoIhHkuDMXFWVC8Aj6AKuQM+Ia9bXhSAFUIk2yjKRdADFgnR8stjzebW8B5v
rSJ9WWNFt97UcgpTcvE+0gEuXFdD3cR16Ov6ObdZjsT1Y3ubC9jTZXy/pO8+YZbq
jjGjNfxp7eWr6umgd2bhO5RKDwu/PbKvhM3l8OPQxOkoGK4L8trPm2IGEFjVyV/1
/vhMa439vbPtT7eItmXEuEqgouUCzwA11Du7KhZu+IkdWyJCXsRzkExTI+rYGAYU
nokOmE6A9VI4sgqLXAOxVSWDQSURhBfXx5cGeu9sdWNZ1V/F1TCi9kslE4eSlJie
NjT5X1rEnM4HDMBKuiSkmu2GzcCAP5IktrkzAmWt1CbFWtLqdOExTmQGR/3DNMwp
SniCYTgAw9GdGz46Zkiprr1X8fEqyrGBY6kjrAJ6Yior2Oy5GxU23w7UmE5iddFx
jXsVMOh6dWIvJlhkeFEjLed3NezkpQuKehM0inOcAiPcCpnZhYc=
=hYTj
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v10 2/3] tty: hvc: pass DMA capable memory to put_chars()
From: Greg KH @ 2021-10-10 5:33 UTC (permalink / raw)
To: Xianting Tian
Cc: arnd, amit, jirislaby, shile.zhang, linux-kernel, virtualization,
linuxppc-dev, osandov
In-Reply-To: <3516c58c-e8e6-2e5a-2bc8-ad80e2124d37@linux.alibaba.com>
On Sat, Oct 09, 2021 at 11:45:23PM +0800, Xianting Tian wrote:
>
> 在 2021/10/9 下午7:58, Greg KH 写道:
> > Did you look at the placement using pahole as to how this structure now
> > looks?
>
> thanks for all your commnts. for this one, do you mean I need to remove the
> blank line? thanks
>
No, I mean to use the tool 'pahole' to see the structure layout that you
just created and determine if it really is the best way to add these new
fields, especially as you are adding huge buffers with odd alignment.
thanks,
greg k-h
^ permalink raw reply
* [PATCH v7 2/3] powerpc: Move script to check relocations at compile time in scripts/
From: Alexandre Ghiti @ 2021-10-09 17:12 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Paul Walmsley, Palmer Dabbelt, Albert Ou, linuxppc-dev,
linux-kernel, linux-riscv
Cc: Anup Patel, Alexandre Ghiti
In-Reply-To: <20211009171259.2515351-1-alexandre.ghiti@canonical.com>
From: Alexandre Ghiti <alex@ghiti.fr>
Relocating kernel at runtime is done very early in the boot process, so
it is not convenient to check for relocations there and react in case a
relocation was not expected.
Powerpc architecture has a script that allows to check at compile time
for such unexpected relocations: extract the common logic to scripts/
so that other architectures can take advantage of it.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Reviewed-by: Anup Patel <anup@brainfault.org>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
---
arch/powerpc/tools/relocs_check.sh | 18 ++----------------
scripts/relocs_check.sh | 20 ++++++++++++++++++++
2 files changed, 22 insertions(+), 16 deletions(-)
create mode 100755 scripts/relocs_check.sh
diff --git a/arch/powerpc/tools/relocs_check.sh b/arch/powerpc/tools/relocs_check.sh
index 014e00e74d2b..e367895941ae 100755
--- a/arch/powerpc/tools/relocs_check.sh
+++ b/arch/powerpc/tools/relocs_check.sh
@@ -15,21 +15,8 @@ if [ $# -lt 3 ]; then
exit 1
fi
-# Have Kbuild supply the path to objdump and nm so we handle cross compilation.
-objdump="$1"
-nm="$2"
-vmlinux="$3"
-
-# Remove from the bad relocations those that match an undefined weak symbol
-# which will result in an absolute relocation to 0.
-# Weak unresolved symbols are of that form in nm output:
-# " w _binary__btf_vmlinux_bin_end"
-undef_weak_symbols=$($nm "$vmlinux" | awk '$1 ~ /w/ { print $2 }')
-
bad_relocs=$(
-$objdump -R "$vmlinux" |
- # Only look at relocation lines.
- grep -E '\<R_' |
+${srctree}/scripts/relocs_check.sh "$@" |
# These relocations are okay
# On PPC64:
# R_PPC64_RELATIVE, R_PPC64_NONE
@@ -43,8 +30,7 @@ R_PPC_ADDR16_LO
R_PPC_ADDR16_HI
R_PPC_ADDR16_HA
R_PPC_RELATIVE
-R_PPC_NONE' |
- ([ "$undef_weak_symbols" ] && grep -F -w -v "$undef_weak_symbols" || cat)
+R_PPC_NONE'
)
if [ -z "$bad_relocs" ]; then
diff --git a/scripts/relocs_check.sh b/scripts/relocs_check.sh
new file mode 100755
index 000000000000..137c660499f3
--- /dev/null
+++ b/scripts/relocs_check.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+# Get a list of all the relocations, remove from it the relocations
+# that are known to be legitimate and return this list to arch specific
+# script that will look for suspicious relocations.
+
+objdump="$1"
+nm="$2"
+vmlinux="$3"
+
+# Remove from the possible bad relocations those that match an undefined
+# weak symbol which will result in an absolute relocation to 0.
+# Weak unresolved symbols are of that form in nm output:
+# " w _binary__btf_vmlinux_bin_end"
+undef_weak_symbols=$($nm "$vmlinux" | awk '$1 ~ /w/ { print $2 }')
+
+$objdump -R "$vmlinux" |
+ grep -E '\<R_' |
+ ([ "$undef_weak_symbols" ] && grep -F -w -v "$undef_weak_symbols" || cat)
--
2.30.2
^ permalink raw reply related
* [PATCH v7 0/3] Introduce 64b relocatable kernel
From: Alexandre Ghiti @ 2021-10-09 17:12 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Paul Walmsley, Palmer Dabbelt, Albert Ou, linuxppc-dev,
linux-kernel, linux-riscv
Cc: Alexandre Ghiti
After multiple attempts, this patchset is now based on the fact that the
64b kernel mapping was moved outside the linear mapping.
The first patch allows to build relocatable kernels but is not selected
by default. That patch should ease KASLR implementation a lot.
The second and third patches take advantage of an already existing powerpc
script that checks relocations at compile-time, and uses it for riscv.
This patchset was tested on:
* qemu riscv64 defconfig: OK
* Unmatched ubuntu config: OK
Changes in v7:
* Rebase on top of v5.15
* Fix LDFLAGS_vmlinux which was overriden when CONFIG_DYNAMIC_FTRACE was
set
* Make relocate_kernel static
* Add Ack from Michael
Changes in v6:
* Remove the kernel move to vmalloc zone
* Rebased on top of for-next
* Remove relocatable property from 32b kernel as the kernel is mapped in
the linear mapping and would then need to be copied physically too
* CONFIG_RELOCATABLE depends on !XIP_KERNEL
* Remove Reviewed-by from first patch as it changed a bit
Changes in v5:
* Add "static __init" to create_kernel_page_table function as reported by
Kbuild test robot
* Add reviewed-by from Zong
* Rebase onto v5.7
Changes in v4:
* Fix BPF region that overlapped with kernel's as suggested by Zong
* Fix end of module region that could be larger than 2GB as suggested by Zong
* Fix the size of the vm area reserved for the kernel as we could lose
PMD_SIZE if the size was already aligned on PMD_SIZE
* Split compile time relocations check patch into 2 patches as suggested by Anup
* Applied Reviewed-by from Zong and Anup
Changes in v3:
* Move kernel mapping to vmalloc
Changes in v2:
* Make RELOCATABLE depend on MMU as suggested by Anup
* Rename kernel_load_addr into kernel_virt_addr as suggested by Anup
* Use __pa_symbol instead of __pa, as suggested by Zong
* Rebased on top of v5.6-rc3
* Tested with sv48 patchset
* Add Reviewed/Tested-by from Zong and Anup
Alexandre Ghiti (3):
riscv: Introduce CONFIG_RELOCATABLE
powerpc: Move script to check relocations at compile time in scripts/
riscv: Check relocations at compile time
arch/powerpc/tools/relocs_check.sh | 18 ++--------
arch/riscv/Kconfig | 12 +++++++
arch/riscv/Makefile | 7 ++--
arch/riscv/Makefile.postlink | 36 ++++++++++++++++++++
arch/riscv/kernel/vmlinux.lds.S | 6 ++++
arch/riscv/mm/Makefile | 4 +++
arch/riscv/mm/init.c | 54 +++++++++++++++++++++++++++++-
arch/riscv/tools/relocs_check.sh | 26 ++++++++++++++
scripts/relocs_check.sh | 20 +++++++++++
9 files changed, 164 insertions(+), 19 deletions(-)
create mode 100644 arch/riscv/Makefile.postlink
create mode 100755 arch/riscv/tools/relocs_check.sh
create mode 100755 scripts/relocs_check.sh
--
2.30.2
^ permalink raw reply
* [PATCH v7 3/3] riscv: Check relocations at compile time
From: Alexandre Ghiti @ 2021-10-09 17:12 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Paul Walmsley, Palmer Dabbelt, Albert Ou, linuxppc-dev,
linux-kernel, linux-riscv
Cc: Anup Patel, Alexandre Ghiti
In-Reply-To: <20211009171259.2515351-1-alexandre.ghiti@canonical.com>
From: Alexandre Ghiti <alex@ghiti.fr>
Relocating kernel at runtime is done very early in the boot process, so
it is not convenient to check for relocations there and react in case a
relocation was not expected.
There exists a script in scripts/ that extracts the relocations from
vmlinux that is then used at postlink to check the relocations.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
Reviewed-by: Anup Patel <anup@brainfault.org>
---
arch/riscv/Makefile.postlink | 36 ++++++++++++++++++++++++++++++++
arch/riscv/tools/relocs_check.sh | 26 +++++++++++++++++++++++
2 files changed, 62 insertions(+)
create mode 100644 arch/riscv/Makefile.postlink
create mode 100755 arch/riscv/tools/relocs_check.sh
diff --git a/arch/riscv/Makefile.postlink b/arch/riscv/Makefile.postlink
new file mode 100644
index 000000000000..bf2b2bca1845
--- /dev/null
+++ b/arch/riscv/Makefile.postlink
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0
+# ===========================================================================
+# Post-link riscv pass
+# ===========================================================================
+#
+# Check that vmlinux relocations look sane
+
+PHONY := __archpost
+__archpost:
+
+-include include/config/auto.conf
+include scripts/Kbuild.include
+
+quiet_cmd_relocs_check = CHKREL $@
+cmd_relocs_check = \
+ $(CONFIG_SHELL) $(srctree)/arch/riscv/tools/relocs_check.sh "$(OBJDUMP)" "$(NM)" "$@"
+
+# `@true` prevents complaint when there is nothing to be done
+
+vmlinux: FORCE
+ @true
+ifdef CONFIG_RELOCATABLE
+ $(call if_changed,relocs_check)
+endif
+
+%.ko: FORCE
+ @true
+
+clean:
+ @true
+
+PHONY += FORCE clean
+
+FORCE:
+
+.PHONY: $(PHONY)
diff --git a/arch/riscv/tools/relocs_check.sh b/arch/riscv/tools/relocs_check.sh
new file mode 100755
index 000000000000..baeb2e7b2290
--- /dev/null
+++ b/arch/riscv/tools/relocs_check.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0-or-later
+# Based on powerpc relocs_check.sh
+
+# This script checks the relocations of a vmlinux for "suspicious"
+# relocations.
+
+if [ $# -lt 3 ]; then
+ echo "$0 [path to objdump] [path to nm] [path to vmlinux]" 1>&2
+ exit 1
+fi
+
+bad_relocs=$(
+${srctree}/scripts/relocs_check.sh "$@" |
+ # These relocations are okay
+ # R_RISCV_RELATIVE
+ grep -F -w -v 'R_RISCV_RELATIVE'
+)
+
+if [ -z "$bad_relocs" ]; then
+ exit 0
+fi
+
+num_bad=$(echo "$bad_relocs" | wc -l)
+echo "WARNING: $num_bad bad relocations"
+echo "$bad_relocs"
--
2.30.2
^ permalink raw reply related
* [PATCH v7 1/3] riscv: Introduce CONFIG_RELOCATABLE
From: Alexandre Ghiti @ 2021-10-09 17:12 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Paul Walmsley, Palmer Dabbelt, Albert Ou, linuxppc-dev,
linux-kernel, linux-riscv
Cc: Alexandre Ghiti
In-Reply-To: <20211009171259.2515351-1-alexandre.ghiti@canonical.com>
From: Alexandre Ghiti <alex@ghiti.fr>
This config allows to compile 64b kernel as PIE and to relocate it at
any virtual address at runtime: this paves the way to KASLR.
Runtime relocation is possible since relocation metadata are embedded into
the kernel.
Note that relocating at runtime introduces an overhead even if the
kernel is loaded at the same address it was linked at and that the compiler
options are those used in arm64 which uses the same RELA relocation
format.
Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
---
arch/riscv/Kconfig | 12 ++++++++
arch/riscv/Makefile | 7 +++--
arch/riscv/kernel/vmlinux.lds.S | 6 ++++
arch/riscv/mm/Makefile | 4 +++
arch/riscv/mm/init.c | 54 ++++++++++++++++++++++++++++++++-
5 files changed, 80 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ea16fa2dd768..043ba92559fa 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -213,6 +213,18 @@ config PGTABLE_LEVELS
config LOCKDEP_SUPPORT
def_bool y
+config RELOCATABLE
+ bool
+ depends on MMU && 64BIT && !XIP_KERNEL
+ help
+ This builds a kernel as a Position Independent Executable (PIE),
+ which retains all relocation metadata required to relocate the
+ kernel binary at runtime to a different virtual address than the
+ address it was linked at.
+ Since RISCV uses the RELA relocation format, this requires a
+ relocation pass at runtime even if the kernel is loaded at the
+ same address it was linked at.
+
source "arch/riscv/Kconfig.socs"
source "arch/riscv/Kconfig.erratas"
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 0eb4568fbd29..2f509915f246 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -9,9 +9,12 @@
#
OBJCOPYFLAGS := -O binary
-LDFLAGS_vmlinux :=
+ifeq ($(CONFIG_RELOCATABLE),y)
+ LDFLAGS_vmlinux += -shared -Bsymbolic -z notext -z norelro
+ KBUILD_CFLAGS += -fPIE
+endif
ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
- LDFLAGS_vmlinux := --no-relax
+ LDFLAGS_vmlinux += --no-relax
KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
CC_FLAGS_FTRACE := -fpatchable-function-entry=8
endif
diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
index 5104f3a871e3..862a8c09723c 100644
--- a/arch/riscv/kernel/vmlinux.lds.S
+++ b/arch/riscv/kernel/vmlinux.lds.S
@@ -133,6 +133,12 @@ SECTIONS
BSS_SECTION(PAGE_SIZE, PAGE_SIZE, 0)
+ .rela.dyn : ALIGN(8) {
+ __rela_dyn_start = .;
+ *(.rela .rela*)
+ __rela_dyn_end = .;
+ }
+
#ifdef CONFIG_EFI
. = ALIGN(PECOFF_SECTION_ALIGNMENT);
__pecoff_data_virt_size = ABSOLUTE(. - __pecoff_text_end);
diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
index 7ebaef10ea1b..2d33ec574bbb 100644
--- a/arch/riscv/mm/Makefile
+++ b/arch/riscv/mm/Makefile
@@ -1,6 +1,10 @@
# SPDX-License-Identifier: GPL-2.0-only
CFLAGS_init.o := -mcmodel=medany
+ifdef CONFIG_RELOCATABLE
+CFLAGS_init.o += -fno-pie
+endif
+
ifdef CONFIG_FTRACE
CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_cacheflush.o = $(CC_FLAGS_FTRACE)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index c0cddf0fc22d..42041c12d496 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -20,6 +20,9 @@
#include <linux/dma-map-ops.h>
#include <linux/crash_dump.h>
#include <linux/hugetlb.h>
+#ifdef CONFIG_RELOCATABLE
+#include <linux/elf.h>
+#endif
#include <asm/fixmap.h>
#include <asm/tlbflush.h>
@@ -103,7 +106,7 @@ static void __init print_vm_layout(void)
print_mlm("lowmem", (unsigned long)PAGE_OFFSET,
(unsigned long)high_memory);
#ifdef CONFIG_64BIT
- print_mlm("kernel", (unsigned long)KERNEL_LINK_ADDR,
+ print_mlm("kernel", (unsigned long)kernel_map.virt_addr,
(unsigned long)ADDRESS_SPACE_END);
#endif
}
@@ -518,6 +521,44 @@ static __init pgprot_t pgprot_from_va(uintptr_t va)
#error "setup_vm() is called from head.S before relocate so it should not use absolute addressing."
#endif
+#ifdef CONFIG_RELOCATABLE
+extern unsigned long __rela_dyn_start, __rela_dyn_end;
+
+static void __init relocate_kernel(void)
+{
+ Elf64_Rela *rela = (Elf64_Rela *)&__rela_dyn_start;
+ /*
+ * This holds the offset between the linked virtual address and the
+ * relocated virtual address.
+ */
+ uintptr_t reloc_offset = kernel_map.virt_addr - KERNEL_LINK_ADDR;
+ /*
+ * This holds the offset between kernel linked virtual address and
+ * physical address.
+ */
+ uintptr_t va_kernel_link_pa_offset = KERNEL_LINK_ADDR - kernel_map.phys_addr;
+
+ for ( ; rela < (Elf64_Rela *)&__rela_dyn_end; rela++) {
+ Elf64_Addr addr = (rela->r_offset - va_kernel_link_pa_offset);
+ Elf64_Addr relocated_addr = rela->r_addend;
+
+ if (rela->r_info != R_RISCV_RELATIVE)
+ continue;
+
+ /*
+ * Make sure to not relocate vdso symbols like rt_sigreturn
+ * which are linked from the address 0 in vmlinux since
+ * vdso symbol addresses are actually used as an offset from
+ * mm->context.vdso in VDSO_OFFSET macro.
+ */
+ if (relocated_addr >= KERNEL_LINK_ADDR)
+ relocated_addr += reloc_offset;
+
+ *(Elf64_Addr *)addr = relocated_addr;
+ }
+}
+#endif /* CONFIG_RELOCATABLE */
+
#ifdef CONFIG_XIP_KERNEL
static void __init create_kernel_page_table(pgd_t *pgdir,
__always_unused bool early)
@@ -625,6 +666,17 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
BUG_ON((kernel_map.virt_addr + kernel_map.size) > ADDRESS_SPACE_END - SZ_4K);
#endif
+#ifdef CONFIG_RELOCATABLE
+ /*
+ * Early page table uses only one PGDIR, which makes it possible
+ * to map PGDIR_SIZE aligned on PGDIR_SIZE: if the relocation offset
+ * makes the kernel cross over a PGDIR_SIZE boundary, raise a bug
+ * since a part of the kernel would not get mapped.
+ */
+ BUG_ON(PGDIR_SIZE - (kernel_map.virt_addr & (PGDIR_SIZE - 1)) < kernel_map.size);
+ relocate_kernel();
+#endif
+
pt_ops.alloc_pte = alloc_pte_early;
pt_ops.get_pte_virt = get_pte_virt_early;
#ifndef __PAGETABLE_PMD_FOLDED
--
2.30.2
^ permalink raw reply related
* Re: [PATCH v7 1/3] riscv: Introduce CONFIG_RELOCATABLE
From: Alexandre ghiti @ 2021-10-09 17:20 UTC (permalink / raw)
To: Alexandre Ghiti, Michael Ellerman, Benjamin Herrenschmidt,
Paul Mackerras, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linuxppc-dev, linux-kernel, linux-riscv
In-Reply-To: <20211009171259.2515351-2-alexandre.ghiti@canonical.com>
Arf, I have sent this patchset with the wrong email address. @Palmer
tell me if you want me to resend it correctly.
Thanks,
Alex
On 10/9/21 7:12 PM, Alexandre Ghiti wrote:
> From: Alexandre Ghiti <alex@ghiti.fr>
>
> This config allows to compile 64b kernel as PIE and to relocate it at
> any virtual address at runtime: this paves the way to KASLR.
> Runtime relocation is possible since relocation metadata are embedded into
> the kernel.
>
> Note that relocating at runtime introduces an overhead even if the
> kernel is loaded at the same address it was linked at and that the compiler
> options are those used in arm64 which uses the same RELA relocation
> format.
>
> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
> ---
> arch/riscv/Kconfig | 12 ++++++++
> arch/riscv/Makefile | 7 +++--
> arch/riscv/kernel/vmlinux.lds.S | 6 ++++
> arch/riscv/mm/Makefile | 4 +++
> arch/riscv/mm/init.c | 54 ++++++++++++++++++++++++++++++++-
> 5 files changed, 80 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index ea16fa2dd768..043ba92559fa 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -213,6 +213,18 @@ config PGTABLE_LEVELS
> config LOCKDEP_SUPPORT
> def_bool y
>
> +config RELOCATABLE
> + bool
> + depends on MMU && 64BIT && !XIP_KERNEL
> + help
> + This builds a kernel as a Position Independent Executable (PIE),
> + which retains all relocation metadata required to relocate the
> + kernel binary at runtime to a different virtual address than the
> + address it was linked at.
> + Since RISCV uses the RELA relocation format, this requires a
> + relocation pass at runtime even if the kernel is loaded at the
> + same address it was linked at.
> +
> source "arch/riscv/Kconfig.socs"
> source "arch/riscv/Kconfig.erratas"
>
> diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> index 0eb4568fbd29..2f509915f246 100644
> --- a/arch/riscv/Makefile
> +++ b/arch/riscv/Makefile
> @@ -9,9 +9,12 @@
> #
>
> OBJCOPYFLAGS := -O binary
> -LDFLAGS_vmlinux :=
> +ifeq ($(CONFIG_RELOCATABLE),y)
> + LDFLAGS_vmlinux += -shared -Bsymbolic -z notext -z norelro
> + KBUILD_CFLAGS += -fPIE
> +endif
> ifeq ($(CONFIG_DYNAMIC_FTRACE),y)
> - LDFLAGS_vmlinux := --no-relax
> + LDFLAGS_vmlinux += --no-relax
> KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY
> CC_FLAGS_FTRACE := -fpatchable-function-entry=8
> endif
> diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
> index 5104f3a871e3..862a8c09723c 100644
> --- a/arch/riscv/kernel/vmlinux.lds.S
> +++ b/arch/riscv/kernel/vmlinux.lds.S
> @@ -133,6 +133,12 @@ SECTIONS
>
> BSS_SECTION(PAGE_SIZE, PAGE_SIZE, 0)
>
> + .rela.dyn : ALIGN(8) {
> + __rela_dyn_start = .;
> + *(.rela .rela*)
> + __rela_dyn_end = .;
> + }
> +
> #ifdef CONFIG_EFI
> . = ALIGN(PECOFF_SECTION_ALIGNMENT);
> __pecoff_data_virt_size = ABSOLUTE(. - __pecoff_text_end);
> diff --git a/arch/riscv/mm/Makefile b/arch/riscv/mm/Makefile
> index 7ebaef10ea1b..2d33ec574bbb 100644
> --- a/arch/riscv/mm/Makefile
> +++ b/arch/riscv/mm/Makefile
> @@ -1,6 +1,10 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> CFLAGS_init.o := -mcmodel=medany
> +ifdef CONFIG_RELOCATABLE
> +CFLAGS_init.o += -fno-pie
> +endif
> +
> ifdef CONFIG_FTRACE
> CFLAGS_REMOVE_init.o = $(CC_FLAGS_FTRACE)
> CFLAGS_REMOVE_cacheflush.o = $(CC_FLAGS_FTRACE)
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index c0cddf0fc22d..42041c12d496 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -20,6 +20,9 @@
> #include <linux/dma-map-ops.h>
> #include <linux/crash_dump.h>
> #include <linux/hugetlb.h>
> +#ifdef CONFIG_RELOCATABLE
> +#include <linux/elf.h>
> +#endif
>
> #include <asm/fixmap.h>
> #include <asm/tlbflush.h>
> @@ -103,7 +106,7 @@ static void __init print_vm_layout(void)
> print_mlm("lowmem", (unsigned long)PAGE_OFFSET,
> (unsigned long)high_memory);
> #ifdef CONFIG_64BIT
> - print_mlm("kernel", (unsigned long)KERNEL_LINK_ADDR,
> + print_mlm("kernel", (unsigned long)kernel_map.virt_addr,
> (unsigned long)ADDRESS_SPACE_END);
> #endif
> }
> @@ -518,6 +521,44 @@ static __init pgprot_t pgprot_from_va(uintptr_t va)
> #error "setup_vm() is called from head.S before relocate so it should not use absolute addressing."
> #endif
>
> +#ifdef CONFIG_RELOCATABLE
> +extern unsigned long __rela_dyn_start, __rela_dyn_end;
> +
> +static void __init relocate_kernel(void)
> +{
> + Elf64_Rela *rela = (Elf64_Rela *)&__rela_dyn_start;
> + /*
> + * This holds the offset between the linked virtual address and the
> + * relocated virtual address.
> + */
> + uintptr_t reloc_offset = kernel_map.virt_addr - KERNEL_LINK_ADDR;
> + /*
> + * This holds the offset between kernel linked virtual address and
> + * physical address.
> + */
> + uintptr_t va_kernel_link_pa_offset = KERNEL_LINK_ADDR - kernel_map.phys_addr;
> +
> + for ( ; rela < (Elf64_Rela *)&__rela_dyn_end; rela++) {
> + Elf64_Addr addr = (rela->r_offset - va_kernel_link_pa_offset);
> + Elf64_Addr relocated_addr = rela->r_addend;
> +
> + if (rela->r_info != R_RISCV_RELATIVE)
> + continue;
> +
> + /*
> + * Make sure to not relocate vdso symbols like rt_sigreturn
> + * which are linked from the address 0 in vmlinux since
> + * vdso symbol addresses are actually used as an offset from
> + * mm->context.vdso in VDSO_OFFSET macro.
> + */
> + if (relocated_addr >= KERNEL_LINK_ADDR)
> + relocated_addr += reloc_offset;
> +
> + *(Elf64_Addr *)addr = relocated_addr;
> + }
> +}
> +#endif /* CONFIG_RELOCATABLE */
> +
> #ifdef CONFIG_XIP_KERNEL
> static void __init create_kernel_page_table(pgd_t *pgdir,
> __always_unused bool early)
> @@ -625,6 +666,17 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
> BUG_ON((kernel_map.virt_addr + kernel_map.size) > ADDRESS_SPACE_END - SZ_4K);
> #endif
>
> +#ifdef CONFIG_RELOCATABLE
> + /*
> + * Early page table uses only one PGDIR, which makes it possible
> + * to map PGDIR_SIZE aligned on PGDIR_SIZE: if the relocation offset
> + * makes the kernel cross over a PGDIR_SIZE boundary, raise a bug
> + * since a part of the kernel would not get mapped.
> + */
> + BUG_ON(PGDIR_SIZE - (kernel_map.virt_addr & (PGDIR_SIZE - 1)) < kernel_map.size);
> + relocate_kernel();
> +#endif
> +
> pt_ops.alloc_pte = alloc_pte_early;
> pt_ops.get_pte_virt = get_pte_virt_early;
> #ifndef __PAGETABLE_PMD_FOLDED
^ permalink raw reply
* [PATCH v3 10/10] ocxl: Use pci core's DVSEC functionality
From: Dan Williams @ 2021-10-09 16:44 UTC (permalink / raw)
To: linux-cxl
Cc: Ben Widawsky, Andrew Donnellan, linux-pci, linux-kernel,
Frederic Barrat, linuxppc-dev, hch
In-Reply-To: <163379783658.692348.16064992154261275220.stgit@dwillia2-desk3.amr.corp.intel.com>
From: Ben Widawsky <ben.widawsky@intel.com>
Reduce maintenance burden of DVSEC query implementation by using the
centralized PCI core implementation.
There are two obvious places to simply drop in the new core
implementation. There remains find_dvsec_from_pos() which would benefit
from using a core implementation. As that change is less trivial it is
reserved for later.
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <ajd@linux.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com> (v1)
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
arch/powerpc/platforms/powernv/ocxl.c | 3 ++-
drivers/misc/ocxl/config.c | 13 +------------
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/ocxl.c b/arch/powerpc/platforms/powernv/ocxl.c
index 9105efcf242a..28b009b46464 100644
--- a/arch/powerpc/platforms/powernv/ocxl.c
+++ b/arch/powerpc/platforms/powernv/ocxl.c
@@ -107,7 +107,8 @@ static int get_max_afu_index(struct pci_dev *dev, int *afu_idx)
int pos;
u32 val;
- pos = find_dvsec_from_pos(dev, OCXL_DVSEC_FUNC_ID, 0);
+ pos = pci_find_dvsec_capability(dev, PCI_VENDOR_ID_IBM,
+ OCXL_DVSEC_FUNC_ID);
if (!pos)
return -ESRCH;
diff --git a/drivers/misc/ocxl/config.c b/drivers/misc/ocxl/config.c
index a68738f38252..e401a51596b9 100644
--- a/drivers/misc/ocxl/config.c
+++ b/drivers/misc/ocxl/config.c
@@ -33,18 +33,7 @@
static int find_dvsec(struct pci_dev *dev, int dvsec_id)
{
- int vsec = 0;
- u16 vendor, id;
-
- while ((vsec = pci_find_next_ext_capability(dev, vsec,
- OCXL_EXT_CAP_ID_DVSEC))) {
- pci_read_config_word(dev, vsec + OCXL_DVSEC_VENDOR_OFFSET,
- &vendor);
- pci_read_config_word(dev, vsec + OCXL_DVSEC_ID_OFFSET, &id);
- if (vendor == PCI_VENDOR_ID_IBM && id == dvsec_id)
- return vsec;
- }
- return 0;
+ return pci_find_dvsec_capability(dev, PCI_VENDOR_ID_IBM, dvsec_id);
}
static int find_dvsec_afu_ctrl(struct pci_dev *dev, u8 afu_idx)
^ permalink raw reply related
* [PATCH v3 08/10] PCI: Add pci_find_dvsec_capability to find designated VSEC
From: Dan Williams @ 2021-10-09 16:44 UTC (permalink / raw)
To: linux-cxl
Cc: Ben Widawsky, Andrew Donnellan, linux-pci, linux-kernel,
Frederic Barrat, David E. Box, Jonathan Cameron, Bjorn Helgaas,
Kan Liang, linuxppc-dev, hch, Lu Baolu
In-Reply-To: <163379783658.692348.16064992154261275220.stgit@dwillia2-desk3.amr.corp.intel.com>
From: Ben Widawsky <ben.widawsky@intel.com>
Add pci_find_dvsec_capability to locate a Designated Vendor-Specific
Extended Capability with the specified Vendor ID and Capability ID.
The Designated Vendor-Specific Extended Capability (DVSEC) allows one or
more "vendor" specific capabilities that are not tied to the Vendor ID
of the PCI component. Where the DVSEC Vendor may be a standards body
like CXL.
Cc: David E. Box <david.e.box@linux.intel.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: linux-pci@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Andrew Donnellan <ajd@linux.ibm.com>
Cc: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Signed-off-by: Ben Widawsky <ben.widawsky@intel.com>
Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Kan Liang <kan.liang@linux.intel.com>
Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/pci/pci.c | 32 ++++++++++++++++++++++++++++++++
include/linux/pci.h | 1 +
2 files changed, 33 insertions(+)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index ce2ab62b64cf..94ac86ff28b0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -732,6 +732,38 @@ u16 pci_find_vsec_capability(struct pci_dev *dev, u16 vendor, int cap)
}
EXPORT_SYMBOL_GPL(pci_find_vsec_capability);
+/**
+ * pci_find_dvsec_capability - Find DVSEC for vendor
+ * @dev: PCI device to query
+ * @vendor: Vendor ID to match for the DVSEC
+ * @dvsec: Designated Vendor-specific capability ID
+ *
+ * If DVSEC has Vendor ID @vendor and DVSEC ID @dvsec return the capability
+ * offset in config space; otherwise return 0.
+ */
+u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec)
+{
+ int pos;
+
+ pos = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_DVSEC);
+ if (!pos)
+ return 0;
+
+ while (pos) {
+ u16 v, id;
+
+ pci_read_config_word(dev, pos + PCI_DVSEC_HEADER1, &v);
+ pci_read_config_word(dev, pos + PCI_DVSEC_HEADER2, &id);
+ if (vendor == v && dvsec == id)
+ return pos;
+
+ pos = pci_find_next_ext_capability(dev, pos, PCI_EXT_CAP_ID_DVSEC);
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pci_find_dvsec_capability);
+
/**
* pci_find_parent_resource - return resource region of parent bus of given
* region
diff --git a/include/linux/pci.h b/include/linux/pci.h
index cd8aa6fce204..c93ccfa4571b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1130,6 +1130,7 @@ u16 pci_find_ext_capability(struct pci_dev *dev, int cap);
u16 pci_find_next_ext_capability(struct pci_dev *dev, u16 pos, int cap);
struct pci_bus *pci_find_next_bus(const struct pci_bus *from);
u16 pci_find_vsec_capability(struct pci_dev *dev, u16 vendor, int cap);
+u16 pci_find_dvsec_capability(struct pci_dev *dev, u16 vendor, u16 dvsec);
u64 pci_get_dsn(struct pci_dev *dev);
^ permalink raw reply related
* [PATCH v3 00/10] cxl_pci refactor for reusability
From: Dan Williams @ 2021-10-09 16:43 UTC (permalink / raw)
To: linux-cxl
Cc: Ben Widawsky, Andrew Donnellan, linux-pci, linuxppc-dev, stable,
linux-kernel, Bjorn Helgaas, David E. Box, Jonathan Cameron,
Frederic Barrat, Kan Liang, Ira Weiny, hch, Lu Baolu
Changes since v2 [1]:
- Rework some of the changelogs per feedback (Bjorn, and I)
- Move the cxl_register_map refactor earlier in the series to make the
cxl_setup_pci_regs() refactor easier to read.
- Fix a bug added in v5.14 for handling the error return case
cxl_pci_map_regblock()
- Split the addition of @base to cxl_register_map to its own patch
- Drop the cxl_pci_dvsec() wrapper (Christoph)
- Drop the SIOV conversion patch given Baolu's feedback about it being
dead code
[1]: https://lore.kernel.org/r/20210923172647.72738-1-ben.widawsky@intel.com
---
I am helping out with the review feedback on this set while Ben is
focusing on region provisioning. It appears this rework will be suitable
to just carry in cxl/next, no need to make a cross-tree dependency for
"PCI: Add pci_find_dvsec_capability to find designated VSEC" at this
time.
Ben's original cover:
Provide the ability to obtain CXL register blocks as discrete functionality.
This functionality will become useful for other CXL drivers that need access to
CXL register blocks. It is also in line with other additions to core which moves
register mapping functionality.
At the introduction of the CXL driver the only user of CXL MMIO was cxl_pci
(then known as cxl_mem). As the driver has evolved it is clear that cxl_pci will
not be the only entity that needs access to CXL MMIO. This series stops short of
moving the generalized functionality into cxl_core for the sake of getting eyes
on the important foundational bits sooner rather than later. The ultimate plan
is to move much of the code into cxl_core.
Via review of two previous patches [1] & [2] it has been suggested that the bits
which are being used for DVSEC enumeration move into PCI core. As CXL core is
soon going to require these, let's try to get the ball rolling now on making
that happen.
---
[1]: https://lore.kernel.org/linux-pci/20210913190131.xiiszmno46qie7v5@intel.com/
[2]: https://lore.kernel.org/linux-cxl/20210920225638.1729482-1-ben.widawsky@intel.com/
[3]: https://lore.kernel.org/linux-cxl/20210921220459.2437386-1-ben.widawsky@intel.com/
---
Ben Widawsky (8):
cxl/pci: Convert register block identifiers to an enum
cxl/pci: Remove dev_dbg for unknown register blocks
cxl/pci: Remove pci request/release regions
cxl/pci: Make more use of cxl_register_map
cxl/pci: Split cxl_pci_setup_regs()
PCI: Add pci_find_dvsec_capability to find designated VSEC
cxl/pci: Use pci core's DVSEC functionality
ocxl: Use pci core's DVSEC functionality
Dan Williams (2):
cxl/pci: Fix NULL vs ERR_PTR confusion
cxl/pci: Add @base to cxl_register_map
arch/powerpc/platforms/powernv/ocxl.c | 3 -
drivers/cxl/cxl.h | 1
drivers/cxl/pci.c | 157 +++++++++++++--------------------
drivers/cxl/pci.h | 14 ++-
drivers/misc/ocxl/config.c | 13 ---
drivers/pci/pci.c | 32 +++++++
include/linux/pci.h | 1
7 files changed, 105 insertions(+), 116 deletions(-)
base-commit: ed97afb53365cd03dde266c9644334a558fe5a16
^ permalink raw reply
* Re: [PATCH v10 2/3] tty: hvc: pass DMA capable memory to put_chars()
From: Xianting Tian @ 2021-10-09 15:45 UTC (permalink / raw)
To: Greg KH
Cc: arnd, amit, jirislaby, shile.zhang, linux-kernel, virtualization,
linuxppc-dev, osandov
In-Reply-To: <YWGD8y9VfBIQBu2h@kroah.com>
在 2021/10/9 下午7:58, Greg KH 写道:
> Did you look at the placement using pahole as to how this structure now
> looks?
thanks for all your commnts. for this one, do you mean I need to remove
the blank line? thanks
^ permalink raw reply
* Re: [PATCH v2 00/11] Add Apple M1 support to PASemi i2c driver
From: Christian Zigotzky @ 2021-10-09 13:57 UTC (permalink / raw)
To: Wolfram Sang, Sven Peter, Michael Ellerman,
Benjamin Herrenschmidt, Paul Mackerras, Olof Johansson,
Arnd Bergmann, Hector Martin, Mohamed Mediouni, Stan Skowronek,
Mark Kettenis, Alyssa Rosenzweig, linux-arm-kernel, linuxppc-dev,
linux-i2c, linux-kernel, R.T.Dickinson, Matthew Leaman,
Darren Stevens
In-Reply-To: <YWFqr4uQGlNgnT1z@ninjato>
On 09 October 2021 at 12:10 pm, Wolfram Sang wrote:
>> I still don't have access to any old PASemi hardware but the changes from
>> v1 are pretty small and I expect them to still work. Would still be nice
>> if someone with access to such hardware could give this a quick test.
> Looks good to me. I will wait a few more days so that people can report
> their tests. But it will be in the next merge window.
>
Series v2:
Tested-by: Christian Zigotzky <chzigotzky@xenosoft.de> [1]
- Christian
[1] https://forum.hyperion-entertainment.com/viewtopic.php?p=54213#p54213
^ 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