Re: [PATCH v6 06/13] ARC: hardware floating point support
On 5/29/20 4:50 PM, Vineet Gupta via Libc-alpha wrote:
>>> Although this code follow other architectures, I think it woudl be better
>>> to move forward a macro that emulates function calls and use proper
>>> static inline function instead for _FPU_* (as for get-rounding-mode.h).
>> OK. do you have a preference for names, existing upper case names OK ?
> Something like below ?
>
> +# define _FPU_FPSR_FWE 0x8000
> +
> -# define _FPU_GETCW(cw) __asm__ volatile ("lr %0, [0x300]" : "=r" (cw))
> -# define _FPU_SETCW(cw) __asm__ volatile ("sr %0, [0x300]" : : "r" (cw))
> +static inline unsigned int arc_fpu_getcw(void)
> +{
> + unsigned int cw;
> + __asm__ volatile ("lr %0, [0x300]" : "=r" (cw));
> + return cw;
> +}
> +
> +static inline void arc_fpu_setcw(unsigned int cw)
> +{
> + __asm__ volatile ("sr %0, [0x300]" : : "r" (cw));
> +}
It seems there is more discussiosn to be had here. Can we just punt on this
specific item and keep the status quo macros please. We are heading towards july
and I'd rather have the port go in this cycle !
-Vineet
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 01/13] ARC: ABI Implementation
On 6/4/20 12:01 PM, Vineet Gupta wrote: > On 6/4/20 2:04 AM, Florian Weimer via Libc-alpha wrote: >> * Vineet Gupta via Libc-alpha: >> >>> On 5/27/20 11:26 AM, Adhemerval Zanella via Libc-alpha wrote: +ENTRY (__longjmp) + + ld_s r13, [r0] + ld_s r14, [r0,4] + ld r15, [r0,8] + ld r16, [r0,12] + ld r17, [r0,16] + ld r18, [r0,20] + ld r19, [r0,24] + ld r20, [r0,28] + ld r21, [r0,32] + ld r22, [r0,36] + ld r23, [r0,40] + ld r24, [r0,44] + ld r25, [r0,48] + + ld blink, [r0,60] + ld fp,[r0,52] + ld sp,[r0,56] + + mov.f r0, r1 ; get the setjmp return value(due to longjmp) in place + + j.d[blink] ; to caller of setjmp location, right after the call + mov.z r0, 1; can't let setjmp return 0 when it is due to longjmp + +END (__longjmp) >>> >>> So wanted to pick your brains on this thing. While longjmp is not >>> necessarily an >>> application hotspot, it seems bulk load/store can in general benefit from >>> with >>> ARCv2 double load/store instructions LDD/STD which work with register pairs. >>> >>> So we could have 2 variants which compile differently to one runtime >>> implementation or better still have 2 runtime implementations which could be >>> switched to using hwcaps (which I can add to kernel). Does that require >>> IFUNC >>> which ARC toolchain doesn't support ATM. >> >> Without IFUNCs, you would have to use a conditional branch in the >> (single) __longjmp implementation. >> >> With IFUNCs, all internal callers will have to go through a function >> pointer—or those internal callers would have to turn into IFUNCs as >> well. >> >> So it's doubtful whether this is beneficial in this case. >> >> Also, please double-check the register list. The ABI manual says this: >> >> | The scratch registers are not preserved across function calls. When >> | calling an external function, the compiler assumes that registers %r0 >> | through %r12 and %r30 are trashed; and that %r13 through %r29 are >> | preserved. The EV6x processor reserves %r25. >> >> r27 and r28 are handled as fp and sp. That leaves r26 and r29 as >> unhandled. > > r29 is ILINK1 (Interrupt Link Register) and accessible only in kernel mode so > can > be ignored here. > > r26 is GP and indeed could be potential problem and thus needs saving. The > reason > it is missing in first place is the historic use of GP as "PIC assist" > register > which has since been reworked in compiler). As of today the register > allocator is > simply ignoring GP. > >> r25 seems to be the thread pointer. It cannot change its value between >> setjmp and longjmp because you cannot longjmp onto another thread, so >> saving and restoring it should not be necessary. > > Good point. This can be removed. > > It seems that *jmp and *context routines deal with same set of regs (in > different > structures) and perhaps I should make them reuse asm code. It seems better to keep them seperate afterall. On the topic of ABI, and considering the future port to ARCv3 with slightly different ABI I'm thinking I should simplify the existing sysdeps/unix/sysv/linux/arc/sys/ucontext.h (patch 8/13) by not naming specific registers (while still being compliant with the kernel exported interface). -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 3/4] ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board
On Thu, Jun 4, 2020 at 11:39 AM Eugeniy Paltsev
wrote:
>
Need to cc the DT list.
> This initial port adds support of ARC HS4x/HS4xD Development Kit board
> with some basic features such serial port, USB, SD/MMC, SPI flash,
> Ethernet and others.
>
> The HSDK-4xD board has much in common with its predecessor - HSDK board.
> However HSDK-4xD has some differences in comparison with its predecessor:
> * based on quad core ARC HS48/HS47D processor (instead of quad core
>ARC HS38)
> * has ThinkSilicon GPU (instead of Vivante GPU)
> * has ARC PGU and HDMI output
> * has separate SDIO controller for WiFi module
> * has additional timers with clocksource independent from CPU clocksource
>(required for DVFS)
> * has performance counters interrupt
> * other minor stuff
>
> NOTE:
> HSDK-4xD and HSDK may share part of DTS so we can move this common part
> to one .dtsi file (as we have done it in U-boot). However we have quite
> enough out of the tree patches for tweaking HSDK DTS (patches in out
> Linux kernel verification flow, patches for run in simulation, etc...),
> so I'd prefer to keep HSDK DTS untouched. That's why HSDK-4xD DTS is
> created as an separate file.
>
> Cc: Rob Herring
> Signed-off-by: Eugeniy Paltsev
> ---
> arch/arc/boot/dts/hsdk-4xd.dts | 322
Please check this using W=1 and also build 'dtbs_check' (which needs
dt-schema installed).
> arch/arc/configs/hsdk_4xd_defconfig | 98 +
> arch/arc/kernel/devtree.c | 1 +
> arch/arc/plat-hsdk/Kconfig | 3 +-
> arch/arc/plat-hsdk/platform.c | 1 +
> 5 files changed, 424 insertions(+), 1 deletion(-)
> create mode 100644 arch/arc/boot/dts/hsdk-4xd.dts
> create mode 100644 arch/arc/configs/hsdk_4xd_defconfig
>
> diff --git a/arch/arc/boot/dts/hsdk-4xd.dts b/arch/arc/boot/dts/hsdk-4xd.dts
> new file mode 100644
> index ..2b7f76a01e3e
> --- /dev/null
> +++ b/arch/arc/boot/dts/hsdk-4xd.dts
> @@ -0,0 +1,322 @@
> +// SPDX-License-Identifier: GPL-2.0-only
Don't care about non-GPL OS's?
> +/*
> + * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
> + */
> +
> +/*
> + * Device Tree for ARC HS4x/HS4xD Development Kit
> + */
> +/dts-v1/;
> +
> +#include
> +#include
> +
> +/ {
> + model = "snps,hsdk-4xd";
> + compatible = "snps,hsdk-4xd";
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + chosen {
> + bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8
> console=ttyS0,115200n8 debug print-fatal-signals=1";
You shouldn't really put debug options here like 'earlycon'. Also, use
'stdout-path' instead for the console.
> + };
> +
> + aliases {
> + ethernet =
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
Not documented.
> + reg = <0>;
> + clocks = <_clk>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <1>;
> + clocks = <_clk>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <2>;
> + clocks = <_clk>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "snps,archs48";
> + reg = <3>;
> + clocks = <_clk>;
> + };
> + };
> +
> + input_clk: input-clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <>;
> + };
> +
> + reg_5v0: regulator-5v0 {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "5v0-supply";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + };
> +
> + cpu_intc: cpu-interrupt-controller {
> + compatible = "snps,archs-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> +
> + idu_intc: idu-interrupt-controller {
> + compatible = "snps,archs-idu-intc";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + interrupt-parent = <_intc>;
> + };
> +
> + arcpct: pct {
> + compatible = "snps,archs-pct";
> + interrupt-parent = <_intc>;
> + interrupts = <20>;
> + };
> +
> + /* TIMER0 with interrupt for clockevent */
> + timer {
> + compatible =
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Thu, Jun 04, 2020 at 12:41:33PM +0300, Mike Rapoport wrote:
> On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
> >
> > sparc32 smp images in next-20200603 still crash for me with a spinlock
> > recursion. s390 images hang early in boot. Several others (alpha, arm64,
> > various ppc) don't even compile. I can run some more bisects over time,
> > but this is becoming a full-time job :-(.
>
> I've been able to bisect s390 hang to commit b614345f52bc ("x86/entry:
> Clarify irq_{enter,exit}_rcu()").
>
> After this commit, lockdep_hardirq_exit() is called twice on s390 (and
> others) - one time in irq_exit_rcu() and another one in irq_exit():
>
> /**
> * irq_exit_rcu() - Exit an interrupt context without updating RCU
> *
> * Also processes softirqs if needed and possible.
> */
> void irq_exit_rcu(void)
> {
> __irq_exit_rcu();
>/* must be last! */
> lockdep_hardirq_exit();
> }
>
> /**
> * irq_exit - Exit an interrupt context, update RCU and lockdep
> *
> * Also processes softirqs if needed and possible.
> */
> void irq_exit(void)
> {
> irq_exit_rcu();
> rcu_irq_exit();
>/* must be last! */
> lockdep_hardirq_exit();
> }
>
> Removing the call in irq_exit() make s390 boot again, and judgung by the
> x86 entry code, the comment /* must be last! */ is stale...
FWIW I got s390 to compile and this patch fixes s390 booting for me as well.
13:05:25 > /home/iweiny/dev/linux-build-test/rootfs/s390/run-qemu-s390.sh
Build reference: next-20200603-4-g840714292d8c
Building s390:defconfig:initrd ... running ... passed
Building s390:defconfig:virtio-blk-ccw:rootfs ... running ... passed
Building s390:defconfig:scsi[virtio-ccw]:rootfs ... running ..
passed
Building s390:defconfig:virtio-pci:rootfs ... running ... passed
Building s390:defconfig:scsi[virtio-pci]:rootfs ... running ... passed
Ira
>
> @Peter, @Thomas, can you comment please?
>
> From e51d50ee6f4d1f446decf91c2c67230da14ff82c Mon Sep 17 00:00:00 2001
> From: Mike Rapoport
> Date: Thu, 4 Jun 2020 12:37:03 +0300
> Subject: [PATCH] softirq: don't call lockdep_hardirq_exit() twice
>
> After commit b614345f52bc ("x86/entry: Clarify irq_{enter,exit}_rcu()")
> lockdep_hardirq_exit() is called twice on every architecture that uses
> irq_exit(): one time in irq_exit_rcu() and another one in irq_exit().
>
> Remove the extra call in irq_exit().
>
> Signed-off-by: Mike Rapoport
> ---
> kernel/softirq.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index a3eb6eba8c41..7523f4ce4c1d 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -427,7 +427,6 @@ static inline void __irq_exit_rcu(void)
> void irq_exit_rcu(void)
> {
> __irq_exit_rcu();
> - /* must be last! */
> lockdep_hardirq_exit();
> }
>
> @@ -440,8 +439,6 @@ void irq_exit(void)
> {
> irq_exit_rcu();
> rcu_irq_exit();
> - /* must be last! */
> - lockdep_hardirq_exit();
> }
>
> /*
> --
> 2.26.2
>
>
>
> > Guenter
>
> --
> Sincerely yours,
> Mike.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 0/4] ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board
On 6/4/20 10:39 AM, Eugeniy Paltsev wrote: > Changes v1->v2: > * Fallback to ISA default mcpu flag if custom one isn't supported by >compiler. > * Drop HSDK custom Kconfig options (choose between HSDK and HSDK-4xD) as >we don't need it (at least for now). Instead we select ARC_LPB_DISABLE >for both boards but it's totally OK as HSDK doesn't have LPB so >disabling will be skipped by BCR check in runtime. > * Add missing HSDK-4xD device tree bindings. Convert HSDK device tree >bindings to json-schema. > > Eugeniy Paltsev (4): > ARC: allow to override default mcpu compiler flag > ARC: ARCv2: support loop buffer (LPB) disabling > ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board > ARC: [plat-hsdk*] document HSDK-4xD board/SoC bindings LTGM overall. Dropping of new Kconfig items is nice too. -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] ieee754/dbl-64: Reduce the scope of temporary storage variables
On 6/2/20 1:31 PM, Vineet Gupta via Libc-alpha wrote: > On 6/2/20 11:16 AM, Joseph Myers wrote: >> On Mon, 1 Jun 2020, Vineet Gupta via Libc-alpha wrote: >> >>> Also as suggested by Joseph [1] used --strip and compared the libs with >>> and w/o patch and their sizes are exactly same (with gcc 9). >> >> My suggestion was to compare the *contents* of the libraries, not just >> their sizes. Either they should be byte-for-byte identical, or if there >> are other differences (register allocation, line numbers in assertions, >> etc.) a more detailed investigation will be needed. >> > > Here's my diff of the 2 --strip builds > > for i in `find . -name libm-2.31.9000.so`; do echo $i; diff $i > /SCRATCH/vgupta/gnu2/install/glibcs/$i ; echo $?; done > > ./aarch64-linux-gnu/lib64/libm-2.31.9000.so > 0 > ./arm-linux-gnueabi/lib/libm-2.31.9000.so > 0 > ./x86_64-linux-gnu/lib64/libm-2.31.9000.so > 0 > ./arm-linux-gnueabihf/lib/libm-2.31.9000.so > 0 > ./riscv64-linux-gnu-rv64imac-lp64/lib64/lp64/libm-2.31.9000.so > 0 > ./riscv64-linux-gnu-rv64imafdc-lp64/lib64/lp64/libm-2.31.9000.so > 0 > ./powerpc-linux-gnu/lib/libm-2.31.9000.so > 0 > ./microblaze-linux-gnu/lib/libm-2.31.9000.so > 0 > ./nios2-linux-gnu/lib/libm-2.31.9000.so > 0 > ./hppa-linux-gnu/lib/libm-2.31.9000.so > 0 > ./s390x-linux-gnu/lib64/libm-2.31.9000.so > 0 Is this sufficient for comparison ? -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 01/13] ARC: ABI Implementation
On 6/4/20 2:04 AM, Florian Weimer via Libc-alpha wrote: > * Vineet Gupta via Libc-alpha: > >> On 5/27/20 11:26 AM, Adhemerval Zanella via Libc-alpha wrote: >>> +ENTRY (__longjmp) >>> + >>> + ld_s r13, [r0] >>> + ld_s r14, [r0,4] >>> + ld r15, [r0,8] >>> + ld r16, [r0,12] >>> + ld r17, [r0,16] >>> + ld r18, [r0,20] >>> + ld r19, [r0,24] >>> + ld r20, [r0,28] >>> + ld r21, [r0,32] >>> + ld r22, [r0,36] >>> + ld r23, [r0,40] >>> + ld r24, [r0,44] >>> + ld r25, [r0,48] >>> + >>> + ld blink, [r0,60] >>> + ld fp,[r0,52] >>> + ld sp,[r0,56] >>> + >>> + mov.f r0, r1 ; get the setjmp return value(due to longjmp) in place >>> + >>> + j.d[blink] ; to caller of setjmp location, right after the call >>> + mov.z r0, 1; can't let setjmp return 0 when it is due to longjmp >>> + >>> +END (__longjmp) >> >> So wanted to pick your brains on this thing. While longjmp is not >> necessarily an >> application hotspot, it seems bulk load/store can in general benefit from >> with >> ARCv2 double load/store instructions LDD/STD which work with register pairs. >> >> So we could have 2 variants which compile differently to one runtime >> implementation or better still have 2 runtime implementations which could be >> switched to using hwcaps (which I can add to kernel). Does that require IFUNC >> which ARC toolchain doesn't support ATM. > > Without IFUNCs, you would have to use a conditional branch in the > (single) __longjmp implementation. > > With IFUNCs, all internal callers will have to go through a function > pointer—or those internal callers would have to turn into IFUNCs as > well. > > So it's doubtful whether this is beneficial in this case. > > Also, please double-check the register list. The ABI manual says this: > > | The scratch registers are not preserved across function calls. When > | calling an external function, the compiler assumes that registers %r0 > | through %r12 and %r30 are trashed; and that %r13 through %r29 are > | preserved. The EV6x processor reserves %r25. > > r27 and r28 are handled as fp and sp. That leaves r26 and r29 as > unhandled. r29 is ILINK1 (Interrupt Link Register) and accessible only in kernel mode so can be ignored here. r26 is GP and indeed could be potential problem and thus needs saving. The reason it is missing in first place is the historic use of GP as "PIC assist" register which has since been reworked in compiler). As of today the register allocator is simply ignoring GP. > r25 seems to be the thread pointer. It cannot change its value between > setjmp and longjmp because you cannot longjmp onto another thread, so > saving and restoring it should not be necessary. Good point. This can be removed. It seems that *jmp and *context routines deal with same set of regs (in different structures) and perhaps I should make them reuse asm code. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 1/4] ARC: allow to override default mcpu compiler flag
On 6/4/20 10:39 AM, Eugeniy Paltsev wrote: > Kernel builds set their own default -mcpu for a given ISA build. > But that gets in the way of "custom" -mcpu flags from propagating > into kernel build. > > This will also be used in next patches for HSDK-4xD board support which > uses a different -mcpu to effect dual issue scheduling. > > Signed-off-by: Eugeniy Paltsev Much better. Ack with nit below. > --- > arch/arc/Kconfig | 9 + > arch/arc/Makefile | 21 +++-- > 2 files changed, 28 insertions(+), 2 deletions(-) > > diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig > index ff306246d0f8..7034c217708f 100644 > --- a/arch/arc/Kconfig > +++ b/arch/arc/Kconfig > @@ -377,6 +377,15 @@ config ARC_HAS_SWAPE > bool "Insn: SWAPE (endian-swap)" > default y > > +config ARC_TUNE_MCPU > + string "Override default -mcpu compiler flag" > + default "" > + help > + Override default -mcpu=xxx compiler flag (which is set depending on > + the ISA version) with the specified value. > + NOTE: If specified flag isn't supported by current compiler the > + ISA default value will be used as a fallback. > + > if ISA_ARCV2 > > config ARC_USE_UNALIGNED_MEM_ACCESS > diff --git a/arch/arc/Makefile b/arch/arc/Makefile > index 20e9ab6cc521..2b66e8264174 100644 > --- a/arch/arc/Makefile > +++ b/arch/arc/Makefile > @@ -10,8 +10,25 @@ CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- > arceb-linux-) > endif > > cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__ > -cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7 > -cflags-$(CONFIG_ISA_ARCV2) += -mcpu=hs38 > + > +tune-mcpu-def-$(CONFIG_ISA_ARCOMPACT):= -mA7 > +tune-mcpu-def-$(CONFIG_ISA_ARCV2):= -mcpu=hs38 > + > +ifeq ($(CONFIG_ARC_TUNE_MCPU),"") > +cflags-y += $(tune-mcpu-def-y) > +else > +tune-mcpu:= $(shell echo $(CONFIG_ARC_TUNE_MCPU)) > +tune-mcpu-ok := $(call cc-option-yn, > $(tune-mcpu)) > +ifeq ($(tune-mcpu-ok),y) > +cflags-y += $(tune-mcpu) > +else > +# The flag provided by 'CONFIG_ARC_TUNE_MCPU' option isn't known by this > compiler > +# (probably the compiler is too old). Use ISA default mcpu flag instead as a > safe option. It is obvious what is done here and the comments can be skipped (no need to repost). > +$(warning ** WARNING ** CONFIG_ARC_TUNE_MCPU flag '$(tune-mcpu)' is unknown, > fallback to '$(tune-mcpu-def-y)') > +cflags-y += $(tune-mcpu-def-y) > +endif > +endif -Vineet ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 2/4] ARC: ARCv2: support loop buffer (LPB) disabling
On HS cores, loop buffer (LPB) is programmable in runtime and can be optionally disabled. Signed-off-by: Eugeniy Paltsev --- arch/arc/Kconfig | 6 ++ arch/arc/kernel/head.S | 8 2 files changed, 14 insertions(+) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 7034c217708f..2dc142c8e1f5 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -473,6 +473,12 @@ config ARC_IRQ_NO_AUTOSAVE This is programmable and can be optionally disabled in which case software INTERRUPT_PROLOGUE/EPILGUE do the needed work +config ARC_LPB_DISABLE + bool "Disable loop buffer (LPB)" + help + On HS cores, loop buffer (LPB) is programmable in runtime and can + be optionally disabled. + endif # ISA_ARCV2 endmenu # "ARC CPU Configuration" diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S index 6eb23f1545ee..17fd1ed700cc 100644 --- a/arch/arc/kernel/head.S +++ b/arch/arc/kernel/head.S @@ -59,6 +59,14 @@ bclrr5, r5, STATUS_AD_BIT #endif kflag r5 + +#ifdef CONFIG_ARC_LPB_DISABLE + lr r5, [ARC_REG_LPB_BUILD] + breqr5, 0, 1f ; LPB doesn't exist + mov r5, 1 + sr r5, [ARC_REG_LPB_CTRL] +1: +#endif /* CONFIG_ARC_LPB_DISABLE */ #endif ; Config DSP_CTRL properly, so kernel may use integer multiply, ; multiply-accumulate, and divide operations -- 2.21.3 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 0/4] ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board
Changes v1->v2: * Fallback to ISA default mcpu flag if custom one isn't supported by compiler. * Drop HSDK custom Kconfig options (choose between HSDK and HSDK-4xD) as we don't need it (at least for now). Instead we select ARC_LPB_DISABLE for both boards but it's totally OK as HSDK doesn't have LPB so disabling will be skipped by BCR check in runtime. * Add missing HSDK-4xD device tree bindings. Convert HSDK device tree bindings to json-schema. Eugeniy Paltsev (4): ARC: allow to override default mcpu compiler flag ARC: ARCv2: support loop buffer (LPB) disabling ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board ARC: [plat-hsdk*] document HSDK-4xD board/SoC bindings .../devicetree/bindings/arc/hsdk.txt | 7 - .../devicetree/bindings/arc/hsdk.yaml | 26 ++ arch/arc/Kconfig | 15 + arch/arc/Makefile | 21 +- arch/arc/boot/dts/hsdk-4xd.dts| 322 ++ arch/arc/configs/hsdk_4xd_defconfig | 98 ++ arch/arc/kernel/devtree.c | 1 + arch/arc/kernel/head.S| 8 + arch/arc/plat-hsdk/Kconfig| 3 +- arch/arc/plat-hsdk/platform.c | 1 + 10 files changed, 492 insertions(+), 10 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arc/hsdk.txt create mode 100644 Documentation/devicetree/bindings/arc/hsdk.yaml create mode 100644 arch/arc/boot/dts/hsdk-4xd.dts create mode 100644 arch/arc/configs/hsdk_4xd_defconfig -- 2.21.3 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 1/4] ARC: allow to override default mcpu compiler flag
Kernel builds set their own default -mcpu for a given ISA build. But that gets in the way of "custom" -mcpu flags from propagating into kernel build. This will also be used in next patches for HSDK-4xD board support which uses a different -mcpu to effect dual issue scheduling. Signed-off-by: Eugeniy Paltsev --- arch/arc/Kconfig | 9 + arch/arc/Makefile | 21 +++-- 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index ff306246d0f8..7034c217708f 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -377,6 +377,15 @@ config ARC_HAS_SWAPE bool "Insn: SWAPE (endian-swap)" default y +config ARC_TUNE_MCPU + string "Override default -mcpu compiler flag" + default "" + help + Override default -mcpu=xxx compiler flag (which is set depending on + the ISA version) with the specified value. + NOTE: If specified flag isn't supported by current compiler the + ISA default value will be used as a fallback. + if ISA_ARCV2 config ARC_USE_UNALIGNED_MEM_ACCESS diff --git a/arch/arc/Makefile b/arch/arc/Makefile index 20e9ab6cc521..2b66e8264174 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -10,8 +10,25 @@ CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- arceb-linux-) endif cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__ -cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7 -cflags-$(CONFIG_ISA_ARCV2) += -mcpu=hs38 + +tune-mcpu-def-$(CONFIG_ISA_ARCOMPACT) := -mA7 +tune-mcpu-def-$(CONFIG_ISA_ARCV2) := -mcpu=hs38 + +ifeq ($(CONFIG_ARC_TUNE_MCPU),"") +cflags-y += $(tune-mcpu-def-y) +else +tune-mcpu := $(shell echo $(CONFIG_ARC_TUNE_MCPU)) +tune-mcpu-ok := $(call cc-option-yn, $(tune-mcpu)) +ifeq ($(tune-mcpu-ok),y) +cflags-y += $(tune-mcpu) +else +# The flag provided by 'CONFIG_ARC_TUNE_MCPU' option isn't known by this compiler +# (probably the compiler is too old). Use ISA default mcpu flag instead as a safe option. +$(warning ** WARNING ** CONFIG_ARC_TUNE_MCPU flag '$(tune-mcpu)' is unknown, fallback to '$(tune-mcpu-def-y)') +cflags-y += $(tune-mcpu-def-y) +endif +endif + ifdef CONFIG_ARC_CURR_IN_REG # For a global register defintion, make sure it gets passed to every file -- 2.21.3 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 4/4] ARC: [plat-hsdk*] document HSDK-4xD board/SoC bindings
Add documentation for HSDK-4xD board/SoC bindings. While I'm at it convert HSDK board/SoC bindings to DT schema format using json-schema. Cc: Rob Herring Signed-off-by: Eugeniy Paltsev --- .../devicetree/bindings/arc/hsdk.txt | 7 - .../devicetree/bindings/arc/hsdk.yaml | 26 +++ 2 files changed, 26 insertions(+), 7 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arc/hsdk.txt create mode 100644 Documentation/devicetree/bindings/arc/hsdk.yaml diff --git a/Documentation/devicetree/bindings/arc/hsdk.txt b/Documentation/devicetree/bindings/arc/hsdk.txt deleted file mode 100644 index be50654bbf61.. --- a/Documentation/devicetree/bindings/arc/hsdk.txt +++ /dev/null @@ -1,7 +0,0 @@ -Synopsys DesignWare ARC HS Development Kit Device Tree Bindings - -ARC HSDK Board with quad-core ARC HS38x4 in silicon. - -Required root node properties: -- compatible = "snps,hsdk"; diff --git a/Documentation/devicetree/bindings/arc/hsdk.yaml b/Documentation/devicetree/bindings/arc/hsdk.yaml new file mode 100644 index ..3a269423b3d3 --- /dev/null +++ b/Documentation/devicetree/bindings/arc/hsdk.yaml @@ -0,0 +1,26 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arc/hsdk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare ARC HS Development Kits device tree bindings. + +maintainers: + - Eugeniy Paltsev + +properties: + $nodename: +const: '/' + compatible: +oneOf: + - description: ARC HS Development Kit based on quad core ARC HS38 + processor in silicon +items: + - const: snps,hsdk + - description: ARC HS4x/HS4xD Development Kit based on quad core + ARC HS48/HS47D processor in silicon +items: + - const: snps,hsdk-4xd + +... -- 2.21.3 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2 3/4] ARC: [plat-hsdk-4xd] initial port for HSDK-4xD board
This initial port adds support of ARC HS4x/HS4xD Development Kit board
with some basic features such serial port, USB, SD/MMC, SPI flash,
Ethernet and others.
The HSDK-4xD board has much in common with its predecessor - HSDK board.
However HSDK-4xD has some differences in comparison with its predecessor:
* based on quad core ARC HS48/HS47D processor (instead of quad core
ARC HS38)
* has ThinkSilicon GPU (instead of Vivante GPU)
* has ARC PGU and HDMI output
* has separate SDIO controller for WiFi module
* has additional timers with clocksource independent from CPU clocksource
(required for DVFS)
* has performance counters interrupt
* other minor stuff
NOTE:
HSDK-4xD and HSDK may share part of DTS so we can move this common part
to one .dtsi file (as we have done it in U-boot). However we have quite
enough out of the tree patches for tweaking HSDK DTS (patches in out
Linux kernel verification flow, patches for run in simulation, etc...),
so I'd prefer to keep HSDK DTS untouched. That's why HSDK-4xD DTS is
created as an separate file.
Cc: Rob Herring
Signed-off-by: Eugeniy Paltsev
---
arch/arc/boot/dts/hsdk-4xd.dts | 322
arch/arc/configs/hsdk_4xd_defconfig | 98 +
arch/arc/kernel/devtree.c | 1 +
arch/arc/plat-hsdk/Kconfig | 3 +-
arch/arc/plat-hsdk/platform.c | 1 +
5 files changed, 424 insertions(+), 1 deletion(-)
create mode 100644 arch/arc/boot/dts/hsdk-4xd.dts
create mode 100644 arch/arc/configs/hsdk_4xd_defconfig
diff --git a/arch/arc/boot/dts/hsdk-4xd.dts b/arch/arc/boot/dts/hsdk-4xd.dts
new file mode 100644
index ..2b7f76a01e3e
--- /dev/null
+++ b/arch/arc/boot/dts/hsdk-4xd.dts
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
+ */
+
+/*
+ * Device Tree for ARC HS4x/HS4xD Development Kit
+ */
+/dts-v1/;
+
+#include
+#include
+
+/ {
+ model = "snps,hsdk-4xd";
+ compatible = "snps,hsdk-4xd";
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen {
+ bootargs = "earlycon=uart8250,mmio32,0xf0005000,115200n8
console=ttyS0,115200n8 debug print-fatal-signals=1";
+ };
+
+ aliases {
+ ethernet =
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "snps,archs48";
+ reg = <0>;
+ clocks = <_clk>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "snps,archs48";
+ reg = <1>;
+ clocks = <_clk>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "snps,archs48";
+ reg = <2>;
+ clocks = <_clk>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "snps,archs48";
+ reg = <3>;
+ clocks = <_clk>;
+ };
+ };
+
+ input_clk: input-clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "5v0-supply";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ cpu_intc: cpu-interrupt-controller {
+ compatible = "snps,archs-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ idu_intc: idu-interrupt-controller {
+ compatible = "snps,archs-idu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <_intc>;
+ };
+
+ arcpct: pct {
+ compatible = "snps,archs-pct";
+ interrupt-parent = <_intc>;
+ interrupts = <20>;
+ };
+
+ /* TIMER0 with interrupt for clockevent */
+ timer {
+ compatible = "snps,arc-timer";
+ interrupts = <16>;
+ interrupt-parent = <_intc>;
+ clocks = <_clk>;
+ };
+
+ /* 64-bit Global Free Running Counter */
+ gfrc {
+ compatible = "snps,archs-timer-gfrc";
+ clocks = <_clk>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <_intc>;
+
+ ranges = <0x 0x0 0xf000 0x1000>;
+
+ cgu_rst: reset-controller@8a0 {
+
Re: [PATCH v6 11/13] ARC: Build Infrastructure
On 04/06/2020 12:25, Vineet Gupta wrote:
> On 6/3/20 12:58 PM, Adhemerval Zanella via Libc-alpha wrote:
>>
>>>
>>> diff --git a/config.h.in b/config.h.in
>>> index dea43df438f6..08962dfed075 100644
>>> --- a/config.h.in
>>> +++ b/config.h.in
>>> @@ -109,6 +109,9 @@
>>> /* AArch64 big endian ABI */
>>> #undef HAVE_AARCH64_BE
>>>
>>> +/* ARC big endian ABI */
>>> +#undef HAVE_ARC_BE
>>> +
>>
>> Why do you need this define exactly? It is not used anywhere in the code
>> and for C code if is more straightforwar to use endian.h.
>
> It is used in build system as part of "formal" BE ABI support as pointed to
> in v4
> series review. This specific thing helps choose the right dynamic linker name
> for
> BE case.
Ack.
>
> $ git grep HAVE_ARC_BE
> config.h.in:113:#undef HAVE_ARC_BE
> sysdeps/arc/configure:175: $as_echo "#define HAVE_ARC_BE 1" >>confdefs.h
> sysdeps/arc/configure.ac:22: AC_DEFINE(HAVE_ARC_BE)
> sysdeps/unix/sysv/linux/arc/shlib-versions:3:%ifdef HAVE_ARC_BE
>
> I looked at other ports and they seem to follow similar patters: csky for
> CSKYABI,
> riscv for RISCV_ABI_XLEN etc.
Right, it is the usual way indeed. This is fine.
>
> But I can rework if there's a simpler/better way.
>
>>> +++ b/sysdeps/arc/Versions
>>> @@ -0,0 +1,8 @@
>>> +libc {
>>> + GLIBC_2.32 {
>>> +__mcount;
>>> + }
>>
>> Hum, does ARC require a different symbol name than the one provided
>> by gmon/Versions?
>
> ARC gcc generates __mcount and _mcount with different ABIs and we use the
> newer
> __mcount.
Ack.
>
>>> +AC_DEFINE(PI_STATIC_AND_HIDDEN)
>>> +libc_cv_have_sdata_section=no
>>
>> The libc_cv_have_sdata_section is done by configure.ac, why do you need
>> to explicit set it here?
>
> We inhibit small data explicitly which by default kicks in.
Ok, is it some limitation for loader bootstrap or something else?
>
>>> +if test $libc_cv_arc_be = yes; then
>>> + # For shlib-versions.
>>> + AC_DEFINE(HAVE_ARC_BE)
>>> + LIBC_CONFIG_VAR([default-abi], [ilp32_be])
>>> +else
>>> + LIBC_CONFIG_VAR([default-abi], [ilp32])
>>> +fi
>>
>> The ilp32 naming is usually set for ILP32 architectures that uses
>> 64-bit registers type on 32 bit VMA (for instance mips64n32, x32,
>> or aarch64_ilp32). I don't think this is the case for ARC, so I think
>> this naming might be confusing.
>>> +abi-variants := ilp32 ilp32_be
>
> arcle arcbe ?
LGTM.
>
>>> +
>>> +ifeq (,$(filter $(default-abi),$(abi-variants)))
>>> +$(error Unknown ABI $(default-abi), must be one of $(abi-variants))
>>> +endif
>>> +
>>> +abi-ilp32-condition:= !defined __BIG_ENDIAN__
>>> +abi-ilp32_be-condition := defined __BIG_ENDIAN__
>>
>> Ok with the 'ilp32' naming module described above.
>
>
>>> diff --git a/sysdeps/unix/sysv/linux/arc/Versions
>>> b/sysdeps/unix/sysv/linux/arc/Versions
>>> new file mode 100644
>>> index ..292f1974b02a
>>> --- /dev/null
>>> +++ b/sysdeps/unix/sysv/linux/arc/Versions
>>> @@ -0,0 +1,16 @@
>>> +ld {
>>> + GLIBC_PRIVATE {
>>> +# used for loading by static libraries
>>> +_dl_var_init;
>>> + }
>>> +}
>>> +libc {
>>> + GLIBC_2.32 {
>>> +_flush_cache;
>>> +cacheflush;
>>> + }
>>> + GLIBC_PRIVATE {
>>> +# A copy of sigaction lives in libpthread, and needs these.
>>> +__default_rt_sa_restorer;
>>> + }
>>> +}
>>
>> Afaik all other ABIs that requires the sa_restores uses a local symbol in
>> libpthread. I don't have a strong preference here.
>
> Do you mean add following to sysdeps/unix/sysv/linux/arc/Makefile
>
> ifeq ($(subdir),nptl)
> libpthread-routines += sigrestorer
> libpthread-shared-only-routines += sigrestorer
> endif
Yeap.
>
> And that is to optimize the reference to restorer as a direct PC relative
> access
> vs a got reference ?
My understanding is this specific optimization does not really matter:
sigaction is hardly a hotspot and the symbol will be issue by the
kernel itself. AFAIU is more a way to optimize the exported symbols
and simplify the GLIBC_PRIVATE namespace (since the sa_restore usually
has small text size).
>
> It seems even in libc, this is currently not optimal. It seems we need
> libc_hidden_* on restorer.
>
> 0002b020 <__GI___libc_sigaction>:
> 2b020: std.awr14r15,[sp,-8]
> 2b024: push_sr13
> 2b026: sub_s sp,sp,0x28
> ...
> 2b02e: mov_s r3,r1
> 2b030: ld r13,[pcl,0xd4e9c] <__default_rt_sa_restorer@@GLIBC_PRIVATE+0xd4558>
>
If you define it as attribute_hidden and add on both libc and libpthread it
should not require the libc_hidden_{proto,def}.
>
>
>>> diff --git a/sysdeps/unix/sysv/linux/arc/shlib-versions
>>> b/sysdeps/unix/sysv/linux/arc/shlib-versions
>>> new file mode 100644
>>> index ..343c0a04500e
>>> --- /dev/null
>>> +++ b/sysdeps/unix/sysv/linux/arc/shlib-versions
>>> @@ -0,0 +1,7 @@
>>> +DEFAULT GLIBC_2.32
>>> +
>>> +%ifdef HAVE_ARC_BE
>
> This is where the BE define is used.
>
>>> +ld=ld-linux-arceb.so.2
>>> +%else
>>> +ld=ld-linux-arc.so.2
>>> +%endif
>
Re: [PATCH v6 11/13] ARC: Build Infrastructure
On 6/3/20 12:58 PM, Adhemerval Zanella via Libc-alpha wrote:
>
>>
>> diff --git a/config.h.in b/config.h.in
>> index dea43df438f6..08962dfed075 100644
>> --- a/config.h.in
>> +++ b/config.h.in
>> @@ -109,6 +109,9 @@
>> /* AArch64 big endian ABI */
>> #undef HAVE_AARCH64_BE
>>
>> +/* ARC big endian ABI */
>> +#undef HAVE_ARC_BE
>> +
>
> Why do you need this define exactly? It is not used anywhere in the code
> and for C code if is more straightforwar to use endian.h.
It is used in build system as part of "formal" BE ABI support as pointed to in
v4
series review. This specific thing helps choose the right dynamic linker name
for
BE case.
$ git grep HAVE_ARC_BE
config.h.in:113:#undef HAVE_ARC_BE
sysdeps/arc/configure:175: $as_echo "#define HAVE_ARC_BE 1" >>confdefs.h
sysdeps/arc/configure.ac:22: AC_DEFINE(HAVE_ARC_BE)
sysdeps/unix/sysv/linux/arc/shlib-versions:3:%ifdef HAVE_ARC_BE
I looked at other ports and they seem to follow similar patters: csky for
CSKYABI,
riscv for RISCV_ABI_XLEN etc.
But I can rework if there's a simpler/better way.
>> +++ b/sysdeps/arc/Versions
>> @@ -0,0 +1,8 @@
>> +libc {
>> + GLIBC_2.32 {
>> +__mcount;
>> + }
>
> Hum, does ARC require a different symbol name than the one provided
> by gmon/Versions?
ARC gcc generates __mcount and _mcount with different ABIs and we use the newer
__mcount.
>> +AC_DEFINE(PI_STATIC_AND_HIDDEN)
>> +libc_cv_have_sdata_section=no
>
> The libc_cv_have_sdata_section is done by configure.ac, why do you need
> to explicit set it here?
We inhibit small data explicitly which by default kicks in.
>> +if test $libc_cv_arc_be = yes; then
>> + # For shlib-versions.
>> + AC_DEFINE(HAVE_ARC_BE)
>> + LIBC_CONFIG_VAR([default-abi], [ilp32_be])
>> +else
>> + LIBC_CONFIG_VAR([default-abi], [ilp32])
>> +fi
>
> The ilp32 naming is usually set for ILP32 architectures that uses
> 64-bit registers type on 32 bit VMA (for instance mips64n32, x32,
> or aarch64_ilp32). I don't think this is the case for ARC, so I think
> this naming might be confusing.
>> +abi-variants := ilp32 ilp32_be
arcle arcbe ?
>> +
>> +ifeq (,$(filter $(default-abi),$(abi-variants)))
>> +$(error Unknown ABI $(default-abi), must be one of $(abi-variants))
>> +endif
>> +
>> +abi-ilp32-condition := !defined __BIG_ENDIAN__
>> +abi-ilp32_be-condition := defined __BIG_ENDIAN__
>
> Ok with the 'ilp32' naming module described above.
>> diff --git a/sysdeps/unix/sysv/linux/arc/Versions
>> b/sysdeps/unix/sysv/linux/arc/Versions
>> new file mode 100644
>> index ..292f1974b02a
>> --- /dev/null
>> +++ b/sysdeps/unix/sysv/linux/arc/Versions
>> @@ -0,0 +1,16 @@
>> +ld {
>> + GLIBC_PRIVATE {
>> +# used for loading by static libraries
>> +_dl_var_init;
>> + }
>> +}
>> +libc {
>> + GLIBC_2.32 {
>> +_flush_cache;
>> +cacheflush;
>> + }
>> + GLIBC_PRIVATE {
>> +# A copy of sigaction lives in libpthread, and needs these.
>> +__default_rt_sa_restorer;
>> + }
>> +}
>
> Afaik all other ABIs that requires the sa_restores uses a local symbol in
> libpthread. I don't have a strong preference here.
Do you mean add following to sysdeps/unix/sysv/linux/arc/Makefile
ifeq ($(subdir),nptl)
libpthread-routines += sigrestorer
libpthread-shared-only-routines += sigrestorer
endif
And that is to optimize the reference to restorer as a direct PC relative access
vs a got reference ?
It seems even in libc, this is currently not optimal. It seems we need
libc_hidden_* on restorer.
0002b020 <__GI___libc_sigaction>:
2b020: std.aw r14r15,[sp,-8]
2b024: push_s r13
2b026: sub_s sp,sp,0x28
...
2b02e: mov_s r3,r1
2b030: ld r13,[pcl,0xd4e9c] <__default_rt_sa_restorer@@GLIBC_PRIVATE+0xd4558>
>> diff --git a/sysdeps/unix/sysv/linux/arc/shlib-versions
>> b/sysdeps/unix/sysv/linux/arc/shlib-versions
>> new file mode 100644
>> index ..343c0a04500e
>> --- /dev/null
>> +++ b/sysdeps/unix/sysv/linux/arc/shlib-versions
>> @@ -0,0 +1,7 @@
>> +DEFAULT GLIBC_2.32
>> +
>> +%ifdef HAVE_ARC_BE
This is where the BE define is used.
>> +ld=ld-linux-arceb.so.2
>> +%else
>> +ld=ld-linux-arc.so.2
>> +%endif
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 07/13] ARC: Linux Syscall Interface
On 03/06/2020 17:17, Vineet Gupta wrote: > On 6/3/20 1:04 PM, Adhemerval Zanella via Libc-alpha wrote: >> >> >> On 03/06/2020 16:46, Vineet Gupta wrote: >>> On 5/29/20 9:49 AM, Adhemerval Zanella via Libc-alpha wrote: > + ; - child starts here - > + > + ; Setup TP register (only recent kernels v4.19+ do that) > + and.f 0, r12, CLONE_SETTLS > + mov.nz r25, r9 Do you still need to set it since the minimum supported kernel for ARC is 5.1 ? >>> >>> Right. >>> It should be safe for internal glibc usage, since for both pthread and posix_spawn it blocks all signals including SIGCANCEL and SIGXID. However this is still small race window if this is called directly with pthread cancellation or g*uid in multithread. >>> >>> I'm not sure what you mean above. Do you mean not doing this in glibc and >>> even if >>> kernel support didn't exist should be safe internally ? >> >> At least for internal clone usage with CLONE_VM within glibc we explicit >> disable all signals (posix_spawn and pthread_create). >> >>> >>> fwiw as mentioned above kernel sets up TP for clone (SETTLS). I detested >>> doing >>> that for a long time, give ABI implications but ended up doing it anyways >>> due to >>> an actual race hit when running uClibc tst-kill6 [1] >> >> We explicit disable all signals during the create_thread call in >> pthread_create >> (b3cae39dcbfa2432b3f3aa28854d8ac57f0de1b8), so it should not happen on glibc >> anymore. However it is still an issue if application calls clone itself. > > The scenario there was pthread_create() and parent getting scheduled before > child > and immediately doing pthread_kill() causing child signal handler to be > invoked > and signal handler doing pthread_self() which was broken as TP was not setup. > > With commit above, parent pthread_kill() will block and will only run when > child > is scheduled and unblocks the signals ! It could happen with other scenarios when signal plus tp accesses were involved as well: pthread_cancel the thread (since the sigcancel_handler acesses the tp with THREAD_GETMEM macro), setg* functions (since sighandler_setxid), or any functions with a syscall failure that sets the errno. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote:
>
> sparc32 smp images in next-20200603 still crash for me with a spinlock
> recursion. s390 images hang early in boot. Several others (alpha, arm64,
> various ppc) don't even compile. I can run some more bisects over time,
> but this is becoming a full-time job :-(.
I've been able to bisect s390 hang to commit b614345f52bc ("x86/entry:
Clarify irq_{enter,exit}_rcu()").
After this commit, lockdep_hardirq_exit() is called twice on s390 (and
others) - one time in irq_exit_rcu() and another one in irq_exit():
/**
* irq_exit_rcu() - Exit an interrupt context without updating RCU
*
* Also processes softirqs if needed and possible.
*/
void irq_exit_rcu(void)
{
__irq_exit_rcu();
/* must be last! */
lockdep_hardirq_exit();
}
/**
* irq_exit - Exit an interrupt context, update RCU and lockdep
*
* Also processes softirqs if needed and possible.
*/
void irq_exit(void)
{
irq_exit_rcu();
rcu_irq_exit();
/* must be last! */
lockdep_hardirq_exit();
}
Removing the call in irq_exit() make s390 boot again, and judgung by the
x86 entry code, the comment /* must be last! */ is stale...
@Peter, @Thomas, can you comment please?
>From e51d50ee6f4d1f446decf91c2c67230da14ff82c Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Thu, 4 Jun 2020 12:37:03 +0300
Subject: [PATCH] softirq: don't call lockdep_hardirq_exit() twice
After commit b614345f52bc ("x86/entry: Clarify irq_{enter,exit}_rcu()")
lockdep_hardirq_exit() is called twice on every architecture that uses
irq_exit(): one time in irq_exit_rcu() and another one in irq_exit().
Remove the extra call in irq_exit().
Signed-off-by: Mike Rapoport
---
kernel/softirq.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/softirq.c b/kernel/softirq.c
index a3eb6eba8c41..7523f4ce4c1d 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -427,7 +427,6 @@ static inline void __irq_exit_rcu(void)
void irq_exit_rcu(void)
{
__irq_exit_rcu();
-/* must be last! */
lockdep_hardirq_exit();
}
@@ -440,8 +439,6 @@ void irq_exit(void)
{
irq_exit_rcu();
rcu_irq_exit();
-/* must be last! */
- lockdep_hardirq_exit();
}
/*
--
2.26.2
> Guenter
--
Sincerely yours,
Mike.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On 6/3/20 11:22 PM, Ira Weiny wrote:
[ ... ]
>
> s390: (does not compile)
>
> :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp]
> In file included from ./arch/sparc/include/asm/bug.h:6:0,
> from ./include/linux/bug.h:5,
> from ./include/linux/mmdebug.h:5,
> from ./include/linux/mm.h:9,
> from mm/huge_memory.c:8:
> mm/huge_memory.c: In function 'hugepage_init':
> ./include/linux/compiler.h:403:38: error: call to '__compiletime_assert_127'
> declared with attribute error: BUILD_BUG_ON failed: ((13 + (13-3))-13) >= 9
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^
> ./include/linux/compiler.h:384:4: note: in definition of macro
> '__compiletime_assert'
> prefix ## suffix();\
> ^~
> ./include/linux/compiler.h:403:2: note: in expansion of macro
> '_compiletime_assert'
> _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
> ^~~
> ./include/linux/build_bug.h:39:37: note: in expansion of macro
> 'compiletime_assert'
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^~
> ./include/linux/build_bug.h:50:2: note: in expansion of macro
> 'BUILD_BUG_ON_MSG'
> BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> ^~~~
> ./include/linux/bug.h:24:4: note: in expansion of macro 'BUILD_BUG_ON'
> BUILD_BUG_ON(cond); \
> ^~~~
> mm/huge_memory.c:403:2: note: in expansion of macro 'MAYBE_BUILD_BUG_ON'
> MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER);
> ^~
> make[1]: *** [scripts/Makefile.build:267: mm/huge_memory.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make: *** [Makefile:1735: mm] Error 2
> make: *** Waiting for unfinished jobs
>
>
>
> The s390 error is the same on Linus' master and linux-next. So whatever is
> causing that has slipped into mainline and/or is something I've broken in the
> test scripts.
>
Compiler version related. gcc version 8.x and later no longer work.
Bisect points to commit a148866489f ("sched: Replace rq::wake_list").
Oddly enough x86 images are broken as well. You'll have to use an
older version of gcc (or presumably clang) until this is fixed.
Guenter
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Thu, Jun 04, 2020 at 09:37:45AM +0300, Mike Rapoport wrote: > On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote: > > On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > > > > With linux-next on sparc I too see the spinlock issue; something like: > > > > ... > > Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139 > > lock: 0xf53ef350, .magic: dead4ead, .owner: S01syslogd/139, .owner_cpu: 0 > > CPU: 0 PID: 139 Comm: S01syslogd Not tainted 5.7.0-next-20200603 #1 > > [f0067d00 : > > do_raw_spin_lock+0xa8/0xd8 ] > > [f00d598c : > > copy_page_range+0x328/0x804 ] > > [f0025c34 : > > dup_mm+0x334/0x434 ] > > [f0027198 : > > copy_process+0x1248/0x12d4 ] > > [f00273b8 : > > _do_fork+0x54/0x30c ] > > [f00276e4 : > > do_fork+0x5c/0x6c ] > > [f000de44 : > > sparc_do_fork+0x18/0x38 ] > > [f000b7f4 : > > do_syscall+0x34/0x40 ] > > [5010cd4c : > > 0x5010cd4c ] > > > > > > I'm going to bisect between there and HEAD. > > The sparc issue should be fixed by > > https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org Saw your other email. And yes they are! Thanks! Ira > > > Ira > > -- > Sincerely yours, > Mike. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Thu, Jun 04, 2020 at 09:18:05AM +0300, Mike Rapoport wrote: > On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > > On 6/3/20 2:14 PM, Ira Weiny wrote: > > > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote: > > >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > > >> > > > > > > Actually it occurs to me that the patch consolidating kmap_prot is > > > odd for > > > sparc 32 bit... > > > > > > Its a long shot but could you try reverting this patch? > > > > > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions > > > > > > > That is not easy to revert, unfortunately, due to several follow-up > > patches. > > >>> > > >>> I have gotten your sparc tests to run and they all pass... > > >>> > > >>> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh > > >>> Build reference: v5.7-rc4-17-g852b6f2edc0f > > >>> > > >>> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed > > >>> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed > > >>> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed > > >>> Building sparc32:SS-4:nosmp:initrd ... running . passed > > >>> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed > > >>> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed > > >>> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed > > >>> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed > > >>> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . > > >>> passed > > >>> Building sparc32:SS-4:smp:scsi:hd ... running . passed > > >>> Building sparc32:SS-5:smp:scsi:cd ... running . passed > > >>> Building sparc32:SS-10:smp:scsi:hd ... running . passed > > >>> Building sparc32:SS-20:smp:scsi:hd ... running . passed > > >>> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed > > >>> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed > > >>> > > >>> Is there another test I need to run? > > >> > > >> This all petered out, but as I understand it, this patchset still might > > >> have issues on various architectures. > > >> > > >> Can folks please provide an update on the testing status? > > > > > > I believe the tests were failing for Guenter due to another patch > > > set...[1] > > > > > > My tests with just this series are working. > > > > > >>From my understanding the other failures were unrelated.[2] > > > > > > > > > I've checked the patch above on top of the mmots which already has > > > Ira's patches and it booted fine. I've used sparc32_defconfig to build > > > the kernel and qemu-system-sparc with default machine and CPU. > > > > > > > > > Mike, am I wrong? Do you think the kmap() patches are still causing > > > issues? > > sparc32 UP and microblaze work for me with next-20200603, but I didn't > test other architectures. > > > For my part, all I can say is that -next is in pretty bad shape right now. > > The summary of my tests says: > > > > Build results: > > total: 151 pass: 130 fail: 21 > > Qemu test results: > > total: 430 pass: 375 fail: 55 > > > > sparc32 smp images in next-20200603 still crash for me with a spinlock > > recursion. > > I think this is because Will's fixes [1] are not yet in -next. > > > s390 images hang early in boot. Several others (alpha, arm64, > > various ppc) don't even compile. I can run some more bisects over time, > > but this is becoming a full-time job :-(. > > > > Guenter > > [1] https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org I abandoned the bisect and tested with this fix.[1] It passes. Guenter, on the original thread we had microblaze and ppc working with my fix. https://lore.kernel.org/lkml/20200519194215.ga71...@roeck-us.net/ Sounds like the current failures above are from something much newer in the tree. Ira [1] 23:26:24 > /home/iweiny/dev/linux-build-test/rootfs/sparc/run-qemu-sparc.sh Build reference: next-20200603-3-gf5afe92a2135 Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed Building sparc32:SS-4:nosmp:initrd ... running . passed Building sparc32:SS-5:nosmp:scsi:hd ... running . passed Building sparc32:SS-10:nosmp:scsi:cd ... running . passed Building sparc32:SS-20:nosmp:scsi:hd ... running . passed Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed Building sparc32:SS-4:smp:scsi:hd ... running . passed Building sparc32:SS-5:smp:scsi:cd ... running . passed Building sparc32:SS-10:smp:scsi:hd ... running . passed Building sparc32:SS-20:smp:scsi:hd ... running . passed Building
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Wed, Jun 03, 2020 at 11:22:26PM -0700, Ira Weiny wrote: > On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > > With linux-next on sparc I too see the spinlock issue; something like: > > ... > Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139 > lock: 0xf53ef350, .magic: dead4ead, .owner: S01syslogd/139, .owner_cpu: 0 > CPU: 0 PID: 139 Comm: S01syslogd Not tainted 5.7.0-next-20200603 #1 > [f0067d00 : > do_raw_spin_lock+0xa8/0xd8 ] > [f00d598c : > copy_page_range+0x328/0x804 ] > [f0025c34 : > dup_mm+0x334/0x434 ] > [f0027198 : > copy_process+0x1248/0x12d4 ] > [f00273b8 : > _do_fork+0x54/0x30c ] > [f00276e4 : > do_fork+0x5c/0x6c ] > [f000de44 : > sparc_do_fork+0x18/0x38 ] > [f000b7f4 : > do_syscall+0x34/0x40 ] > [5010cd4c : > 0x5010cd4c ] > > > I'm going to bisect between there and HEAD. The sparc issue should be fixed by https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org > Ira -- Sincerely yours, Mike. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > On 6/3/20 2:14 PM, Ira Weiny wrote: > > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote: > >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > >> ... > >> > >> This all petered out, but as I understand it, this patchset still might > >> have issues on various architectures. > >> > >> Can folks please provide an update on the testing status? > > > > I believe the tests were failing for Guenter due to another patch set...[1] > > > > My tests with just this series are working. > > > >>From my understanding the other failures were unrelated.[2] > > > > > > I've checked the patch above on top of the mmots which already has > > Ira's patches and it booted fine. I've used sparc32_defconfig to build > > the kernel and qemu-system-sparc with default machine and CPU. > > > > > > Mike, am I wrong? Do you think the kmap() patches are still causing issues? > > > > For my part, all I can say is that -next is in pretty bad shape right now. > The summary of my tests says: > > Build results: > total: 151 pass: 130 fail: 21 > Qemu test results: > total: 430 pass: 375 fail: 55 > > sparc32 smp images in next-20200603 still crash for me with a spinlock > recursion. s390 images hang early in boot. Several others (alpha, arm64, > various ppc) don't even compile. I can run some more bisects over time, > but this is becoming a full-time job :-(. > I'm not sure what the process here is. I just applied my series[1] on Linus' Master branch[2] and ran sparc32 and s290 from your tests. sparc32: (passes) 21:43:49 > /home/iweiny/dev/linux-build-test/rootfs/sparc/run-qemu-sparc.sh Build reference: v5.7-7188-g67a7a97e8a0f Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed Building sparc32:SS-4:nosmp:initrd ... running . passed Building sparc32:SS-5:nosmp:scsi:hd ... running . passed Building sparc32:SS-10:nosmp:scsi:cd ... running . passed Building sparc32:SS-20:nosmp:scsi:hd ... running . passed Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running .. passed Building sparc32:SS-4:smp:scsi:hd ... running . passed Building sparc32:SS-5:smp:scsi:cd ... running . passed Building sparc32:SS-10:smp:scsi:hd ... running . passed Building sparc32:SS-20:smp:scsi:hd ... running . passed Building sparc32:SS-600MP:smp:scsi:hd ... running . passed Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed s390: (does not compile) :1511:2: warning: #warning syscall clone3 not implemented [-Wcpp] In file included from ./arch/sparc/include/asm/bug.h:6:0, from ./include/linux/bug.h:5, from ./include/linux/mmdebug.h:5, from ./include/linux/mm.h:9, from mm/huge_memory.c:8: mm/huge_memory.c: In function 'hugepage_init': ./include/linux/compiler.h:403:38: error: call to '__compiletime_assert_127' declared with attribute error: BUILD_BUG_ON failed: ((13 + (13-3))-13) >= 9 _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ./include/linux/compiler.h:384:4: note: in definition of macro '__compiletime_assert' prefix ## suffix();\ ^~ ./include/linux/compiler.h:403:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) ^~~~ ./include/linux/bug.h:24:4: note: in expansion of macro 'BUILD_BUG_ON' BUILD_BUG_ON(cond); \ ^~~~ mm/huge_memory.c:403:2: note: in expansion of macro 'MAYBE_BUILD_BUG_ON' MAYBE_BUILD_BUG_ON(HPAGE_PMD_ORDER >= MAX_ORDER); ^~ make[1]: *** [scripts/Makefile.build:267: mm/huge_memory.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1735: mm] Error 2 make: *** Waiting for unfinished jobs The s390 error is the same on Linus' master and linux-next. So whatever is causing that has slipped into mainline and/or is something I've broken in the test scripts. With linux-next on sparc I too see the spinlock issue; something like: ... Starting syslogd: BUG: spinlock recursion on CPU#0, S01syslogd/139 lock: 0xf53ef350, .magic: dead4ead, .owner: S01syslogd/139, .owner_cpu: 0 CPU: 0 PID: 139 Comm:
Re: [PATCH] arch/{mips,sparc,microblaze,powerpc}: Don't enable pagefault/preempt twice
On Wed, Jun 03, 2020 at 04:44:17PM -0700, Guenter Roeck wrote: > On 6/3/20 2:14 PM, Ira Weiny wrote: > > On Wed, Jun 03, 2020 at 01:57:36PM -0700, Andrew Morton wrote: > >> On Thu, 21 May 2020 10:42:50 -0700 Ira Weiny wrote: > >> > > > > Actually it occurs to me that the patch consolidating kmap_prot is odd > > for > > sparc 32 bit... > > > > Its a long shot but could you try reverting this patch? > > > > 4ea7d2419e3f kmap: consolidate kmap_prot definitions > > > > That is not easy to revert, unfortunately, due to several follow-up > patches. > >>> > >>> I have gotten your sparc tests to run and they all pass... > >>> > >>> 08:10:34 > ../linux-build-test/rootfs/sparc/run-qemu-sparc.sh > >>> Build reference: v5.7-rc4-17-g852b6f2edc0f > >>> > >>> Building sparc32:SPARCClassic:nosmp:scsi:hd ... running . passed > >>> Building sparc32:SPARCbook:nosmp:scsi:cd ... running . passed > >>> Building sparc32:LX:nosmp:noapc:scsi:hd ... running . passed > >>> Building sparc32:SS-4:nosmp:initrd ... running . passed > >>> Building sparc32:SS-5:nosmp:scsi:hd ... running . passed > >>> Building sparc32:SS-10:nosmp:scsi:cd ... running . passed > >>> Building sparc32:SS-20:nosmp:scsi:hd ... running . passed > >>> Building sparc32:SS-600MP:nosmp:scsi:hd ... running . passed > >>> Building sparc32:Voyager:nosmp:noapc:scsi:hd ... running . passed > >>> Building sparc32:SS-4:smp:scsi:hd ... running . passed > >>> Building sparc32:SS-5:smp:scsi:cd ... running . passed > >>> Building sparc32:SS-10:smp:scsi:hd ... running . passed > >>> Building sparc32:SS-20:smp:scsi:hd ... running . passed > >>> Building sparc32:SS-600MP:smp:scsi:hd ... running . passed > >>> Building sparc32:Voyager:smp:noapc:scsi:hd ... running . passed > >>> > >>> Is there another test I need to run? > >> > >> This all petered out, but as I understand it, this patchset still might > >> have issues on various architectures. > >> > >> Can folks please provide an update on the testing status? > > > > I believe the tests were failing for Guenter due to another patch set...[1] > > > > My tests with just this series are working. > > > >>From my understanding the other failures were unrelated.[2] > > > > > > I've checked the patch above on top of the mmots which already has > > Ira's patches and it booted fine. I've used sparc32_defconfig to build > > the kernel and qemu-system-sparc with default machine and CPU. > > > > > > Mike, am I wrong? Do you think the kmap() patches are still causing issues? sparc32 UP and microblaze work for me with next-20200603, but I didn't test other architectures. > For my part, all I can say is that -next is in pretty bad shape right now. > The summary of my tests says: > > Build results: > total: 151 pass: 130 fail: 21 > Qemu test results: > total: 430 pass: 375 fail: 55 > > sparc32 smp images in next-20200603 still crash for me with a spinlock > recursion. I think this is because Will's fixes [1] are not yet in -next. > s390 images hang early in boot. Several others (alpha, arm64, > various ppc) don't even compile. I can run some more bisects over time, > but this is becoming a full-time job :-(. > > Guenter [1] https://lore.kernel.org/lkml/20200526173302.377-1-w...@kernel.org -- Sincerely yours, Mike. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
