WTF: patch "[PATCH] ARC: enable uboot support unconditionally" was seriously submitted to be applied to the 4.20-stable tree?
The patch below was submitted to be applied to the 4.20-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 493a2f812446e92bcb1e69a77381b4d39808d730 Mon Sep 17 00:00:00 2001
From: Eugeniy Paltsev Eugeniy.Paltsev@synopsys.com Date: Thu, 14 Feb 2019 18:07:45 +0300 Subject: [PATCH] ARC: enable uboot support unconditionally
After reworking U-boot args handling code and adding paranoid arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and enable uboot support unconditionally.
For JTAG case we can assume that core registers will come up reset value of 0 or in worst case we rely on user passing '-on=clear_regs' to Metaware debugger.
Cc: stable@vger.kernel.org Tested-by: Corentin LABBE clabbe@baylibre.com Signed-off-by: Eugeniy Paltsev Eugeniy.Paltsev@synopsys.com Signed-off-by: Vineet Gupta vgupta@synopsys.com
diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 7215f52b3413..d750b302d5ab 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -191,7 +191,6 @@ config NR_CPUS
config ARC_SMP_HALT_ON_RESET bool "Enable Halt-on-reset boot mode" - default y if ARC_UBOOT_SUPPORT help In SMP configuration cores can be configured as Halt-on-reset or they could all start at same time. For Halt-on-reset, non @@ -523,17 +522,6 @@ config ARC_DBG_TLB_PARANOIA
endif
-config ARC_UBOOT_SUPPORT - bool "Support uboot arg Handling" - help - ARC Linux by default checks for uboot provided args as pointers to - external cmdline or DTB. This however breaks in absence of uboot, - when booting from Metaware debugger directly, as the registers are - not zeroed out on reset by mdb and/or ARCv2 based cores. The bogus - registers look like uboot args to kernel which then chokes. - So only enable the uboot arg checking/processing if users are sure - of uboot being in play. - config ARC_BUILTIN_DTB_NAME string "Built in DTB" help diff --git a/arch/arc/configs/nps_defconfig b/arch/arc/configs/nps_defconfig index 6e84060e7c90..621f59407d76 100644 --- a/arch/arc/configs/nps_defconfig +++ b/arch/arc/configs/nps_defconfig @@ -31,7 +31,6 @@ CONFIG_ARC_CACHE_LINE_SHIFT=5 # CONFIG_ARC_HAS_LLSC is not set CONFIG_ARC_KVADDR_SIZE=402 CONFIG_ARC_EMUL_UNALIGNED=y -CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_PREEMPT=y CONFIG_NET=y CONFIG_UNIX=y diff --git a/arch/arc/configs/vdk_hs38_defconfig b/arch/arc/configs/vdk_hs38_defconfig index 1e59a2e9c602..e447ace6fa1c 100644 --- a/arch/arc/configs/vdk_hs38_defconfig +++ b/arch/arc/configs/vdk_hs38_defconfig @@ -13,7 +13,6 @@ CONFIG_PARTITION_ADVANCED=y CONFIG_ARC_PLAT_AXS10X=y CONFIG_AXS103=y CONFIG_ISA_ARCV2=y -CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38" CONFIG_PREEMPT=y CONFIG_NET=y diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig b/arch/arc/configs/vdk_hs38_smp_defconfig index b5c3f6c54b03..c82cdb10aaf4 100644 --- a/arch/arc/configs/vdk_hs38_smp_defconfig +++ b/arch/arc/configs/vdk_hs38_smp_defconfig @@ -15,8 +15,6 @@ CONFIG_AXS103=y CONFIG_ISA_ARCV2=y CONFIG_SMP=y # CONFIG_ARC_TIMERS_64BIT is not set -# CONFIG_ARC_SMP_HALT_ON_RESET is not set -CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38_smp" CONFIG_PREEMPT=y CONFIG_NET=y diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S index 1f945d0f40da..30e090625916 100644 --- a/arch/arc/kernel/head.S +++ b/arch/arc/kernel/head.S @@ -100,7 +100,6 @@ ENTRY(stext) st.ab 0, [r5, 4] 1:
-#ifdef CONFIG_ARC_UBOOT_SUPPORT ; Uboot - kernel ABI ; r0 = [0] No uboot interaction, [1] cmdline in r2, [2] DTB in r2 ; r1 = magic number (always zero as of now) @@ -108,7 +107,6 @@ ENTRY(stext) ; These are handled later in handle_uboot_args() st r0, [@uboot_tag] st r2, [@uboot_arg] -#endif
; setup "current" tsk and optionally cache it in dedicated r25 mov r9, @init_task diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c index 8bb156164556..93d4d6639873 100644 --- a/arch/arc/kernel/setup.c +++ b/arch/arc/kernel/setup.c @@ -487,7 +487,6 @@ void __init handle_uboot_args(void) bool use_embedded_dtb = true; bool append_cmdline = false;
-#ifdef CONFIG_ARC_UBOOT_SUPPORT /* check that we know this tag */ if (uboot_tag != UBOOT_TAG_NONE && uboot_tag != UBOOT_TAG_CMDLINE && @@ -514,7 +513,6 @@ void __init handle_uboot_args(void) append_cmdline = true;
ignore_uboot_args: -#endif
if (use_embedded_dtb) { machine_desc = setup_machine_fdt(__dtb_start);
On Sun, Feb 24, 2019 at 02:54:28PM +0100, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.20-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
Hello
Without this patch, we cannot boot a defconfig on ARC, and this is critical for testing ARC devices in kernelCI. Why this patch is not a real stable patch, it is a strong requirement for testing all future stable release on kernelCI. Note that another patch (touching defconfig) for booting defconfig is still missing and need to be also added to stable. (I will resend it today)
Regards
On Mon, Feb 25, 2019 at 10:43:47AM +0100, LABBE Corentin wrote:
On Sun, Feb 24, 2019 at 02:54:28PM +0100, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.20-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
Hello
Without this patch, we cannot boot a defconfig on ARC, and this is critical for testing ARC devices in kernelCI.
But this means you have never been able to boot a defconfig on ARC, right? So this is a new "feature" you are adding :)
If you wait one more week, all is good, you can do this for 5.0, and when I drop 4.20 in another few weeks, all is fine.
Why this patch is not a real stable patch, it is a strong requirement for testing all future stable release on kernelCI.
Only for 4.20.
And normally kernelci uses a specific configuration for the board it is testing, not defconfig. Or am I mistaken?
This is a fine patch to have upstream, it just really doesn't fit the stable rules.
Note that another patch (touching defconfig) for booting defconfig is still missing and need to be also added to stable. (I will resend it today)
Again, looks like a new feature. Just wait a week and all will be fine for you :)
thanks,
greg k-h
On Mon, Feb 25, 2019 at 02:54:00PM +0100, Greg KH wrote:
On Mon, Feb 25, 2019 at 10:43:47AM +0100, LABBE Corentin wrote:
On Sun, Feb 24, 2019 at 02:54:28PM +0100, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.20-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
Hello
Without this patch, we cannot boot a defconfig on ARC, and this is critical for testing ARC devices in kernelCI.
But this means you have never been able to boot a defconfig on ARC, right? So this is a new "feature" you are adding :)
No I was able to boot them, but by adding CONFIG_ARC_UBOOT_SUPPORT. This patch remove the assertion that ARC devices will be booted by default for debugging purpose.
If you wait one more week, all is good, you can do this for 5.0, and when I drop 4.20 in another few weeks, all is fine.
Why this patch is not a real stable patch, it is a strong requirement for testing all future stable release on kernelCI.
Only for 4.20.
And normally kernelci uses a specific configuration for the board it is testing, not defconfig. Or am I mistaken?
No, kernelci only build defconfig without touching them.
This is a fine patch to have upstream, it just really doesn't fit the stable rules.
Note that another patch (touching defconfig) for booting defconfig is still missing and need to be also added to stable. (I will resend it today)
Again, looks like a new feature. Just wait a week and all will be fine for you :)
Greg KH gregkh@linuxfoundation.org writes:
On Mon, Feb 25, 2019 at 10:43:47AM +0100, LABBE Corentin wrote:
On Sun, Feb 24, 2019 at 02:54:28PM +0100, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.20-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
Hello
Without this patch, we cannot boot a defconfig on ARC, and this is critical for testing ARC devices in kernelCI.
But this means you have never been able to boot a defconfig on ARC, right? So this is a new "feature" you are adding :)
Correct, we've never been able to boot an *upstream* defconfig in kernelCI for ARC.
If you wait one more week, all is good, you can do this for 5.0, and when I drop 4.20 in another few weeks, all is fine.
Why this patch is not a real stable patch, it is a strong requirement for testing all future stable release on kernelCI.
Only for 4.20.
And normally kernelci uses a specific configuration for the board it is testing, not defconfig. Or am I mistaken?
We only boot upstream defconfigs, hence the backport request I guess.
Without it, we'll survive. It just means we can only boot v5.1+ on ARC in kernelCI.
Kevin
On Mon, Feb 25, 2019 at 03:11:07PM -0800, Kevin Hilman wrote:
Greg KH gregkh@linuxfoundation.org writes:
On Mon, Feb 25, 2019 at 10:43:47AM +0100, LABBE Corentin wrote:
On Sun, Feb 24, 2019 at 02:54:28PM +0100, gregkh@linuxfoundation.org wrote:
The patch below was submitted to be applied to the 4.20-stable tree.
I fail to see how this patch meets the stable kernel rules as found at Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to stable@vger.kernel.org and let me know why this patch should be applied. Otherwise, it is now dropped from my patch queues, never to be seen again.
thanks,
greg k-h
Hello
Without this patch, we cannot boot a defconfig on ARC, and this is critical for testing ARC devices in kernelCI.
But this means you have never been able to boot a defconfig on ARC, right? So this is a new "feature" you are adding :)
Correct, we've never been able to boot an *upstream* defconfig in kernelCI for ARC.
If you wait one more week, all is good, you can do this for 5.0, and when I drop 4.20 in another few weeks, all is fine.
Why this patch is not a real stable patch, it is a strong requirement for testing all future stable release on kernelCI.
Only for 4.20.
And normally kernelci uses a specific configuration for the board it is testing, not defconfig. Or am I mistaken?
We only boot upstream defconfigs, hence the backport request I guess.
Without it, we'll survive. It just means we can only boot v5.1+ on ARC in kernelCI.
5.0+ in kernelCI, this was for a stable patch in 4.20 only, it's already in Linus's tree for 5.0 :)
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
gregkh＠linuxfoundation.org
-
Kevin Hilman -
LABBE Corentin