This is the start of the stable review cycle for the 5.4.203 release.
There are 16 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.203-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 5.4.203-rc1
Stefan Agner <[email protected]>
crypto: arm/ghash-ce - define fpu before fpu registers are referenced
Ard Biesheuvel <[email protected]>
crypto: arm - use Kconfig based compiler checks for crypto opcodes
Jian Cai <[email protected]>
ARM: 9029/1: Make iwmmxt.S support Clang's integrated assembler
Stefan Agner <[email protected]>
ARM: OMAP2+: drop unnecessary adrl
Stefan Agner <[email protected]>
ARM: 8929/1: use APSR_nzcv instead of r15 as mrc operand
Nick Desaulniers <[email protected]>
ARM: 8933/1: replace Sun/Solaris style flag on section directive
Ard Biesheuvel <[email protected]>
crypto: arm/sha512-neon - avoid ADRL pseudo instruction
Ard Biesheuvel <[email protected]>
crypto: arm/sha256-neon - avoid ADRL pseudo instruction
Jian Cai <[email protected]>
ARM: 8971/1: replace the sole use of a symbol with its definition
Stefan Agner <[email protected]>
ARM: 8990/1: use VFP assembler mnemonics in register load/store macros
Stefan Agner <[email protected]>
ARM: 8989/1: use .fpu assembler directives instead of assembler arguments
Vladimir Oltean <[email protected]>
net: mscc: ocelot: allow unregistered IP multicast flooding
Naveen N. Rao <[email protected]>
kexec_file: drop weak attribute from arch_kexec_apply_relocations[_add]
Naveen N. Rao <[email protected]>
powerpc/ftrace: Remove ftrace init tramp once kernel init is complete
Greg Kroah-Hartman <[email protected]>
clocksource/drivers/ixp4xx: remove __init from ixp4xx_timer_setup()
Christoph Hellwig <[email protected]>
drm: remove drm_fb_helper_modinit
-------------
Diffstat:
Makefile | 4 +-
arch/arm/boot/bootp/init.S | 2 +-
arch/arm/boot/compressed/big-endian.S | 2 +-
arch/arm/boot/compressed/head.S | 4 +-
arch/arm/boot/compressed/piggy.S | 2 +-
arch/arm/crypto/Kconfig | 14 +++--
arch/arm/crypto/Makefile | 32 ++---------
arch/arm/crypto/crct10dif-ce-core.S | 2 +-
arch/arm/crypto/ghash-ce-core.S | 4 +-
arch/arm/crypto/sha1-ce-core.S | 1 +
arch/arm/crypto/sha2-ce-core.S | 1 +
arch/arm/crypto/sha256-armv4.pl | 4 +-
arch/arm/crypto/sha256-core.S_shipped | 4 +-
arch/arm/crypto/sha512-armv4.pl | 4 +-
arch/arm/crypto/sha512-core.S_shipped | 4 +-
arch/arm/include/asm/assembler.h | 3 +-
arch/arm/include/asm/vfpmacros.h | 19 ++++---
arch/arm/kernel/iwmmxt.S | 89 +++++++++++++++---------------
arch/arm/kernel/iwmmxt.h | 47 ++++++++++++++++
arch/arm/mach-omap2/sleep34xx.S | 2 +-
arch/arm/mm/proc-arm1020.S | 2 +-
arch/arm/mm/proc-arm1020e.S | 2 +-
arch/arm/mm/proc-arm1022.S | 2 +-
arch/arm/mm/proc-arm1026.S | 6 +-
arch/arm/mm/proc-arm720.S | 2 +-
arch/arm/mm/proc-arm740.S | 2 +-
arch/arm/mm/proc-arm7tdmi.S | 2 +-
arch/arm/mm/proc-arm920.S | 2 +-
arch/arm/mm/proc-arm922.S | 2 +-
arch/arm/mm/proc-arm925.S | 2 +-
arch/arm/mm/proc-arm926.S | 6 +-
arch/arm/mm/proc-arm940.S | 2 +-
arch/arm/mm/proc-arm946.S | 2 +-
arch/arm/mm/proc-arm9tdmi.S | 2 +-
arch/arm/mm/proc-fa526.S | 2 +-
arch/arm/mm/proc-feroceon.S | 2 +-
arch/arm/mm/proc-mohawk.S | 2 +-
arch/arm/mm/proc-sa110.S | 2 +-
arch/arm/mm/proc-sa1100.S | 2 +-
arch/arm/mm/proc-v6.S | 2 +-
arch/arm/mm/proc-v7.S | 2 +-
arch/arm/mm/proc-v7m.S | 4 +-
arch/arm/mm/proc-xsc3.S | 2 +-
arch/arm/mm/proc-xscale.S | 2 +-
arch/arm/vfp/Makefile | 2 -
arch/arm/vfp/vfphw.S | 30 ++++++----
arch/powerpc/include/asm/ftrace.h | 5 +-
arch/powerpc/kernel/trace/ftrace.c | 15 ++++-
arch/powerpc/mm/mem.c | 2 +
arch/s390/include/asm/kexec.h | 10 ++++
arch/x86/include/asm/kexec.h | 9 +++
drivers/clocksource/mmio.c | 2 +-
drivers/clocksource/timer-ixp4xx.c | 10 ++--
drivers/gpu/drm/drm_crtc_helper_internal.h | 10 ----
drivers/gpu/drm/drm_fb_helper.c | 21 -------
drivers/gpu/drm/drm_kms_helper_common.c | 25 ++++-----
drivers/net/ethernet/mscc/ocelot.c | 8 ++-
include/linux/kexec.h | 46 ++++++++++++---
include/linux/platform_data/timer-ixp4xx.h | 5 +-
kernel/kexec_file.c | 34 ------------
60 files changed, 289 insertions(+), 247 deletions(-)
From: Greg Kroah-Hartman <[email protected]>
ixp4xx_timer_setup is exported, and so can not be an __init function.
Remove the __init marking as the build system is rightfully claiming
this is an error in older kernels.
This is fixed "properly" in commit 41929c9f628b
("clocksource/drivers/ixp4xx: Drop boardfile probe path") but that can
not be backported to older kernels as the reworking of the IXP4xx
codebase is not suitable for stable releases.
Cc: Linus Walleij <[email protected]>
Cc: Daniel Lezcano <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clocksource/mmio.c | 2 +-
drivers/clocksource/timer-ixp4xx.c | 10 ++++------
include/linux/platform_data/timer-ixp4xx.h | 5 ++---
3 files changed, 7 insertions(+), 10 deletions(-)
--- a/drivers/clocksource/mmio.c
+++ b/drivers/clocksource/mmio.c
@@ -46,7 +46,7 @@ u64 clocksource_mmio_readw_down(struct c
* @bits: Number of valid bits
* @read: One of clocksource_mmio_read*() above
*/
-int __init clocksource_mmio_init(void __iomem *base, const char *name,
+int clocksource_mmio_init(void __iomem *base, const char *name,
unsigned long hz, int rating, unsigned bits,
u64 (*read)(struct clocksource *))
{
--- a/drivers/clocksource/timer-ixp4xx.c
+++ b/drivers/clocksource/timer-ixp4xx.c
@@ -170,9 +170,8 @@ static int ixp4xx_resume(struct clock_ev
* We use OS timer1 on the CPU for the timer tick and the timestamp
* counter as a source of real clock ticks to account for missed jiffies.
*/
-static __init int ixp4xx_timer_register(void __iomem *base,
- int timer_irq,
- unsigned int timer_freq)
+static int ixp4xx_timer_register(void __iomem *base, int timer_irq,
+ unsigned int timer_freq)
{
struct ixp4xx_timer *tmr;
int ret;
@@ -245,9 +244,8 @@ static __init int ixp4xx_timer_register(
* @timer_irq: Linux IRQ number for the timer
* @timer_freq: Fixed frequency of the timer
*/
-void __init ixp4xx_timer_setup(resource_size_t timerbase,
- int timer_irq,
- unsigned int timer_freq)
+void ixp4xx_timer_setup(resource_size_t timerbase, int timer_irq,
+ unsigned int timer_freq)
{
void __iomem *base;
--- a/include/linux/platform_data/timer-ixp4xx.h
+++ b/include/linux/platform_data/timer-ixp4xx.h
@@ -4,8 +4,7 @@
#include <linux/ioport.h>
-void __init ixp4xx_timer_setup(resource_size_t timerbase,
- int timer_irq,
- unsigned int timer_freq);
+void ixp4xx_timer_setup(resource_size_t timerbase, int timer_irq,
+ unsigned int timer_freq);
#endif
From: Ard Biesheuvel <[email protected]>
commit 54781938ec342cadbe2d76669ef8d3294d909974 upstream
The ADRL pseudo instruction is not an architectural construct, but a
convenience macro that was supported by the ARM proprietary assembler
and adopted by binutils GAS as well, but only when assembling in 32-bit
ARM mode. Therefore, it can only be used in assembler code that is known
to assemble in ARM mode only, but as it turns out, the Clang assembler
does not implement ADRL at all, and so it is better to get rid of it
entirely.
So replace the ADRL instruction with a ADR instruction that refers to
a nearer symbol, and apply the delta explicitly using an additional
instruction.
Signed-off-by: Ard Biesheuvel <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/crypto/sha256-armv4.pl | 4 ++--
arch/arm/crypto/sha256-core.S_shipped | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/arch/arm/crypto/sha256-armv4.pl
+++ b/arch/arm/crypto/sha256-armv4.pl
@@ -175,7 +175,6 @@ $code=<<___;
#else
.syntax unified
# ifdef __thumb2__
-# define adrl adr
.thumb
# else
.code 32
@@ -471,7 +470,8 @@ sha256_block_data_order_neon:
stmdb sp!,{r4-r12,lr}
sub $H,sp,#16*4+16
- adrl $Ktbl,K256
+ adr $Ktbl,.Lsha256_block_data_order
+ sub $Ktbl,$Ktbl,#.Lsha256_block_data_order-K256
bic $H,$H,#15 @ align for 128-bit stores
mov $t2,sp
mov sp,$H @ alloca
--- a/arch/arm/crypto/sha256-core.S_shipped
+++ b/arch/arm/crypto/sha256-core.S_shipped
@@ -56,7 +56,6 @@
#else
.syntax unified
# ifdef __thumb2__
-# define adrl adr
.thumb
# else
.code 32
@@ -1885,7 +1884,8 @@ sha256_block_data_order_neon:
stmdb sp!,{r4-r12,lr}
sub r11,sp,#16*4+16
- adrl r14,K256
+ adr r14,.Lsha256_block_data_order
+ sub r14,r14,#.Lsha256_block_data_order-K256
bic r11,r11,#15 @ align for 128-bit stores
mov r12,sp
mov sp,r11 @ alloca
From: Jian Cai <[email protected]>
commit a780e485b5768e78aef087502499714901b68cc4 upstream
ALT_UP_B macro sets symbol up_b_offset via .equ to an expression
involving another symbol. The macro gets expanded twice when
arch/arm/kernel/sleep.S is assembled, creating a scenario where
up_b_offset is set to another expression involving symbols while its
current value is based on symbols. LLVM integrated assembler does not
allow such cases, and based on the documentation of binutils, "Values
that are based on expressions involving other symbols are allowed, but
some targets may restrict this to only being done once per assembly", so
it may be better to avoid such cases as it is not clearly stated which
targets should support or disallow them. The fix in this case is simple,
as up_b_offset has only one use, so we can replace the use with the
definition and get rid of up_b_offset.
Link:https://github.com/ClangBuiltLinux/linux/issues/920
Reviewed-by: Stefan Agner <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Jian Cai <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/include/asm/assembler.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -279,10 +279,9 @@
.endif ;\
.popsection
#define ALT_UP_B(label) \
- .equ up_b_offset, label - 9998b ;\
.pushsection ".alt.smp.init", "a" ;\
.long 9998b ;\
- W(b) . + up_b_offset ;\
+ W(b) . + (label - 9998b) ;\
.popsection
#else
#define ALT_SMP(instr...)
From: Stefan Agner <[email protected]>
commit a6c30873ee4a5cc0549c1973668156381ab2c1c4 upstream
Explicit FPU selection has been introduced in commit 1a6be26d5b1a
("[ARM] Enable VFP to be built when non-VFP capable CPUs are selected")
to make use of assembler mnemonics for VFP instructions.
However, clang currently does not support passing assembler flags
like this and errors out with:
clang-10: error: the clang compiler does not support '-Wa,-mfpu=softvfp+vfp'
Make use of the .fpu assembler directives to select the floating point
hardware selectively. Also use the new unified assembler language
mnemonics. This allows to build these procedures with Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/762
Signed-off-by: Stefan Agner <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/vfp/Makefile | 2 --
arch/arm/vfp/vfphw.S | 30 ++++++++++++++++++++----------
2 files changed, 20 insertions(+), 12 deletions(-)
--- a/arch/arm/vfp/Makefile
+++ b/arch/arm/vfp/Makefile
@@ -8,6 +8,4 @@
# ccflags-y := -DDEBUG
# asflags-y := -DDEBUG
-KBUILD_AFLAGS :=$(KBUILD_AFLAGS:-msoft-float=-Wa,-mfpu=softvfp+vfp -mfloat-abi=soft)
-
obj-y += vfpmodule.o entry.o vfphw.o vfpsingle.o vfpdouble.o
--- a/arch/arm/vfp/vfphw.S
+++ b/arch/arm/vfp/vfphw.S
@@ -253,11 +253,14 @@ vfp_current_hw_state_address:
ENTRY(vfp_get_float)
tbl_branch r0, r3, #3
+ .fpu vfpv2
.irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
-1: mrc p10, 0, r0, c\dr, c0, 0 @ fmrs r0, s0
+1: vmov r0, s\dr
ret lr
.org 1b + 8
-1: mrc p10, 0, r0, c\dr, c0, 4 @ fmrs r0, s1
+ .endr
+ .irp dr,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
+1: vmov r0, s\dr
ret lr
.org 1b + 8
.endr
@@ -265,11 +268,14 @@ ENDPROC(vfp_get_float)
ENTRY(vfp_put_float)
tbl_branch r1, r3, #3
+ .fpu vfpv2
.irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
-1: mcr p10, 0, r0, c\dr, c0, 0 @ fmsr r0, s0
+1: vmov s\dr, r0
ret lr
.org 1b + 8
-1: mcr p10, 0, r0, c\dr, c0, 4 @ fmsr r0, s1
+ .endr
+ .irp dr,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
+1: vmov s\dr, r0
ret lr
.org 1b + 8
.endr
@@ -277,15 +283,17 @@ ENDPROC(vfp_put_float)
ENTRY(vfp_get_double)
tbl_branch r0, r3, #3
+ .fpu vfpv2
.irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
-1: fmrrd r0, r1, d\dr
+1: vmov r0, r1, d\dr
ret lr
.org 1b + 8
.endr
#ifdef CONFIG_VFPv3
@ d16 - d31 registers
- .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
-1: mrrc p11, 3, r0, r1, c\dr @ fmrrd r0, r1, d\dr
+ .fpu vfpv3
+ .irp dr,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
+1: vmov r0, r1, d\dr
ret lr
.org 1b + 8
.endr
@@ -299,15 +307,17 @@ ENDPROC(vfp_get_double)
ENTRY(vfp_put_double)
tbl_branch r2, r3, #3
+ .fpu vfpv2
.irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
-1: fmdrr d\dr, r0, r1
+1: vmov d\dr, r0, r1
ret lr
.org 1b + 8
.endr
#ifdef CONFIG_VFPv3
+ .fpu vfpv3
@ d16 - d31 registers
- .irp dr,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15
-1: mcrr p11, 3, r0, r1, c\dr @ fmdrr r0, r1, d\dr
+ .irp dr,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
+1: vmov d\dr, r0, r1
ret lr
.org 1b + 8
.endr
From: Ard Biesheuvel <[email protected]>
commit 0f5e8323777bfc1c1d2cba71242db6a361de03b6 upstream
The ADRL pseudo instruction is not an architectural construct, but a
convenience macro that was supported by the ARM proprietary assembler
and adopted by binutils GAS as well, but only when assembling in 32-bit
ARM mode. Therefore, it can only be used in assembler code that is known
to assemble in ARM mode only, but as it turns out, the Clang assembler
does not implement ADRL at all, and so it is better to get rid of it
entirely.
So replace the ADRL instruction with a ADR instruction that refers to
a nearer symbol, and apply the delta explicitly using an additional
instruction.
Signed-off-by: Ard Biesheuvel <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/crypto/sha512-armv4.pl | 4 ++--
arch/arm/crypto/sha512-core.S_shipped | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
--- a/arch/arm/crypto/sha512-armv4.pl
+++ b/arch/arm/crypto/sha512-armv4.pl
@@ -212,7 +212,6 @@ $code=<<___;
#else
.syntax unified
# ifdef __thumb2__
-# define adrl adr
.thumb
# else
.code 32
@@ -602,7 +601,8 @@ sha512_block_data_order_neon:
dmb @ errata #451034 on early Cortex A8
add $len,$inp,$len,lsl#7 @ len to point at the end of inp
VFP_ABI_PUSH
- adrl $Ktbl,K512
+ adr $Ktbl,.Lsha512_block_data_order
+ sub $Ktbl,$Ktbl,.Lsha512_block_data_order-K512
vldmia $ctx,{$A-$H} @ load context
.Loop_neon:
___
--- a/arch/arm/crypto/sha512-core.S_shipped
+++ b/arch/arm/crypto/sha512-core.S_shipped
@@ -79,7 +79,6 @@
#else
.syntax unified
# ifdef __thumb2__
-# define adrl adr
.thumb
# else
.code 32
@@ -543,7 +542,8 @@ sha512_block_data_order_neon:
dmb @ errata #451034 on early Cortex A8
add r2,r1,r2,lsl#7 @ len to point at the end of inp
VFP_ABI_PUSH
- adrl r3,K512
+ adr r3,.Lsha512_block_data_order
+ sub r3,r3,.Lsha512_block_data_order-K512
vldmia r0,{d16-d23} @ load context
.Loop_neon:
vshr.u64 d24,d20,#14 @ 0
From: Jian Cai <[email protected]>
commit 3c9f5708b7aed6a963e2aefccbd1854802de163e upstream
This patch replaces 6 IWMMXT instructions Clang's integrated assembler
does not support in iwmmxt.S using macros, while making sure GNU
assembler still emit the same instructions. This should be easier than
providing full IWMMXT support in Clang. This is one of the last bits of
kernel code that could be compiled but not assembled with clang. Once
all of it works with IAS, we no longer need to special-case 32-bit Arm
in Kbuild, or turn off CONFIG_IWMMXT when build-testing.
"Intel Wireless MMX Technology - Developer Guide - August, 2002" should
be referenced for the encoding schemes of these extensions.
Link: https://github.com/ClangBuiltLinux/linux/issues/975
Suggested-by: Nick Desaulniers <[email protected]>
Suggested-by: Ard Biesheuvel <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Signed-off-by: Jian Cai <[email protected]>
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/arm/kernel/iwmmxt.S | 89 +++++++++++++++++++++++------------------------
arch/arm/kernel/iwmmxt.h | 47 ++++++++++++++++++++++++
2 files changed, 92 insertions(+), 44 deletions(-)
create mode 100644 arch/arm/kernel/iwmmxt.h
--- a/arch/arm/kernel/iwmmxt.S
+++ b/arch/arm/kernel/iwmmxt.S
@@ -16,6 +16,7 @@
#include <asm/thread_info.h>
#include <asm/asm-offsets.h>
#include <asm/assembler.h>
+#include "iwmmxt.h"
#if defined(CONFIG_CPU_PJ4) || defined(CONFIG_CPU_PJ4B)
#define PJ4(code...) code
@@ -113,33 +114,33 @@ concan_save:
concan_dump:
- wstrw wCSSF, [r1, #MMX_WCSSF]
- wstrw wCASF, [r1, #MMX_WCASF]
- wstrw wCGR0, [r1, #MMX_WCGR0]
- wstrw wCGR1, [r1, #MMX_WCGR1]
- wstrw wCGR2, [r1, #MMX_WCGR2]
- wstrw wCGR3, [r1, #MMX_WCGR3]
+ wstrw wCSSF, r1, MMX_WCSSF
+ wstrw wCASF, r1, MMX_WCASF
+ wstrw wCGR0, r1, MMX_WCGR0
+ wstrw wCGR1, r1, MMX_WCGR1
+ wstrw wCGR2, r1, MMX_WCGR2
+ wstrw wCGR3, r1, MMX_WCGR3
1: @ MUP? wRn
tst r2, #0x2
beq 2f
- wstrd wR0, [r1, #MMX_WR0]
- wstrd wR1, [r1, #MMX_WR1]
- wstrd wR2, [r1, #MMX_WR2]
- wstrd wR3, [r1, #MMX_WR3]
- wstrd wR4, [r1, #MMX_WR4]
- wstrd wR5, [r1, #MMX_WR5]
- wstrd wR6, [r1, #MMX_WR6]
- wstrd wR7, [r1, #MMX_WR7]
- wstrd wR8, [r1, #MMX_WR8]
- wstrd wR9, [r1, #MMX_WR9]
- wstrd wR10, [r1, #MMX_WR10]
- wstrd wR11, [r1, #MMX_WR11]
- wstrd wR12, [r1, #MMX_WR12]
- wstrd wR13, [r1, #MMX_WR13]
- wstrd wR14, [r1, #MMX_WR14]
- wstrd wR15, [r1, #MMX_WR15]
+ wstrd wR0, r1, MMX_WR0
+ wstrd wR1, r1, MMX_WR1
+ wstrd wR2, r1, MMX_WR2
+ wstrd wR3, r1, MMX_WR3
+ wstrd wR4, r1, MMX_WR4
+ wstrd wR5, r1, MMX_WR5
+ wstrd wR6, r1, MMX_WR6
+ wstrd wR7, r1, MMX_WR7
+ wstrd wR8, r1, MMX_WR8
+ wstrd wR9, r1, MMX_WR9
+ wstrd wR10, r1, MMX_WR10
+ wstrd wR11, r1, MMX_WR11
+ wstrd wR12, r1, MMX_WR12
+ wstrd wR13, r1, MMX_WR13
+ wstrd wR14, r1, MMX_WR14
+ wstrd wR15, r1, MMX_WR15
2: teq r0, #0 @ anything to load?
reteq lr @ if not, return
@@ -147,30 +148,30 @@ concan_dump:
concan_load:
@ Load wRn
- wldrd wR0, [r0, #MMX_WR0]
- wldrd wR1, [r0, #MMX_WR1]
- wldrd wR2, [r0, #MMX_WR2]
- wldrd wR3, [r0, #MMX_WR3]
- wldrd wR4, [r0, #MMX_WR4]
- wldrd wR5, [r0, #MMX_WR5]
- wldrd wR6, [r0, #MMX_WR6]
- wldrd wR7, [r0, #MMX_WR7]
- wldrd wR8, [r0, #MMX_WR8]
- wldrd wR9, [r0, #MMX_WR9]
- wldrd wR10, [r0, #MMX_WR10]
- wldrd wR11, [r0, #MMX_WR11]
- wldrd wR12, [r0, #MMX_WR12]
- wldrd wR13, [r0, #MMX_WR13]
- wldrd wR14, [r0, #MMX_WR14]
- wldrd wR15, [r0, #MMX_WR15]
+ wldrd wR0, r0, MMX_WR0
+ wldrd wR1, r0, MMX_WR1
+ wldrd wR2, r0, MMX_WR2
+ wldrd wR3, r0, MMX_WR3
+ wldrd wR4, r0, MMX_WR4
+ wldrd wR5, r0, MMX_WR5
+ wldrd wR6, r0, MMX_WR6
+ wldrd wR7, r0, MMX_WR7
+ wldrd wR8, r0, MMX_WR8
+ wldrd wR9, r0, MMX_WR9
+ wldrd wR10, r0, MMX_WR10
+ wldrd wR11, r0, MMX_WR11
+ wldrd wR12, r0, MMX_WR12
+ wldrd wR13, r0, MMX_WR13
+ wldrd wR14, r0, MMX_WR14
+ wldrd wR15, r0, MMX_WR15
@ Load wCx
- wldrw wCSSF, [r0, #MMX_WCSSF]
- wldrw wCASF, [r0, #MMX_WCASF]
- wldrw wCGR0, [r0, #MMX_WCGR0]
- wldrw wCGR1, [r0, #MMX_WCGR1]
- wldrw wCGR2, [r0, #MMX_WCGR2]
- wldrw wCGR3, [r0, #MMX_WCGR3]
+ wldrw wCSSF, r0, MMX_WCSSF
+ wldrw wCASF, r0, MMX_WCASF
+ wldrw wCGR0, r0, MMX_WCGR0
+ wldrw wCGR1, r0, MMX_WCGR1
+ wldrw wCGR2, r0, MMX_WCGR2
+ wldrw wCGR3, r0, MMX_WCGR3
@ clear CUP/MUP (only if r1 != 0)
teq r1, #0
--- /dev/null
+++ b/arch/arm/kernel/iwmmxt.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef __IWMMXT_H__
+#define __IWMMXT_H__
+
+.irp b, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
+.set .LwR\b, \b
+.set .Lr\b, \b
+.endr
+
+.set .LwCSSF, 0x2
+.set .LwCASF, 0x3
+.set .LwCGR0, 0x8
+.set .LwCGR1, 0x9
+.set .LwCGR2, 0xa
+.set .LwCGR3, 0xb
+
+.macro wldrd, reg:req, base:req, offset:req
+.inst 0xedd00100 | (.L\reg << 12) | (.L\base << 16) | (\offset >> 2)
+.endm
+
+.macro wldrw, reg:req, base:req, offset:req
+.inst 0xfd900100 | (.L\reg << 12) | (.L\base << 16) | (\offset >> 2)
+.endm
+
+.macro wstrd, reg:req, base:req, offset:req
+.inst 0xedc00100 | (.L\reg << 12) | (.L\base << 16) | (\offset >> 2)
+.endm
+
+.macro wstrw, reg:req, base:req, offset:req
+.inst 0xfd800100 | (.L\reg << 12) | (.L\base << 16) | (\offset >> 2)
+.endm
+
+#ifdef __clang__
+
+#define wCon c1
+
+.macro tmrc, dest:req, control:req
+mrc p1, 0, \dest, \control, c0, 0
+.endm
+
+.macro tmcr, control:req, src:req
+mcr p1, 0, \src, \control, c0, 0
+.endm
+#endif
+
+#endif
On 6/30/2022 6:46 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.203 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.203-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli <[email protected]>
--
Florian
On 6/30/22 7:46 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.203 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.203-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <[email protected]>
thanks,
-- Shuah
On Thu, Jun 30, 2022 at 03:46:54PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.203 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 161 pass: 161 fail: 0
Qemu test results:
total: 449 pass: 449 fail: 0
Tested-by: Guenter Roeck <[email protected]>
Guenter
On Thu, 30 Jun 2022 at 19:23, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This is the start of the stable review cycle for the 5.4.203 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.203-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <[email protected]>
## Build
* kernel: 5.4.203-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: 9e421f18b3874909b6cc412c2b93d30ed881c3c8
* git describe: v5.4.202-17-g9e421f18b387
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.202-17-g9e421f18b387
## Test Regressions (compared to v5.4.202)
No test regressions found.
## Metric Regressions (compared to v5.4.202)
No metric regressions found.
## Test Fixes (compared to v5.4.202)
No test fixes found.
## Metric Fixes (compared to v5.4.202)
No metric fixes found.
## Test result summary
total: 123566, pass: 110149, fail: 244, skip: 12178, xfail: 995
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 307 total, 307 passed, 0 failed
* arm64: 61 total, 59 passed, 2 failed
* i386: 28 total, 25 passed, 3 failed
* mips: 48 total, 48 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 54 total, 54 passed, 0 failed
* riscv: 27 total, 27 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 55 total, 54 passed, 1 failed
## Test suites summary
* fwts
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Hi Greg,
On Thu, Jun 30, 2022 at 03:46:54PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.203 release.
> There are 16 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000.
> Anything received after that time might be too late.
Build test (gcc version 11.3.1 20220627):
mips: 65 configs -> no failure
arm: 106 configs -> no failure
arm64: 2 configs -> no failure
x86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:
x86_64: Booted on my test laptop. No regression.
x86_64: Booted on qemu. No regression. [1]
[1]. https://openqa.qa.codethink.co.uk/tests/1422
Tested-by: Sudip Mukherjee <[email protected]>
--
Regards
Sudip