From: Rob Herring robh@kernel.org
[ Upstream commit 2e9edc07df2ec6f835222151fa4e536e9e54856a ]
Based on 'ranges', the 'bus@4000000' node unit-address is off by 1 '0'.
Link: https://lore.kernel.org/r/20210819184239.1192395-5-robh@kernel.org Cc: Andre Przywara andre.przywara@arm.com Cc: Sudeep Holla sudeep.holla@arm.com Cc: Linus Walleij linus.walleij@linaro.org Reviewed-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Rob Herring robh@kernel.org Signed-off-by: Sudeep Holla sudeep.holla@arm.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm/boot/dts/vexpress-v2m.dtsi | 2 +- arch/arm/boot/dts/vexpress-v2p-ca9.dts | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi index 2ac41ed3a57c..659dcf4004b4 100644 --- a/arch/arm/boot/dts/vexpress-v2m.dtsi +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi @@ -19,7 +19,7 @@ */
/ { - bus@4000000 { + bus@40000000 { motherboard { model = "V2M-P1"; arm,hbi = <0x190>; diff --git a/arch/arm/boot/dts/vexpress-v2p-ca9.dts b/arch/arm/boot/dts/vexpress-v2p-ca9.dts index 4c5847955856..1317f0f58d53 100644 --- a/arch/arm/boot/dts/vexpress-v2p-ca9.dts +++ b/arch/arm/boot/dts/vexpress-v2p-ca9.dts @@ -295,7 +295,7 @@ power-vd10-s3 { }; };
- smb: bus@4000000 { + smb: bus@40000000 { compatible = "simple-bus";
#address-cells = <2>;
From: Joel Stanley joel@jms.id.au
[ Upstream commit 8c1768967e2733d55abf449d8abd6f1915ba3539 ]
DRM_FBDEV_EMULATION previously selected FB and was default y as long as DRM was enabled. In commit f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB") the select was replaced with a depends on FB, disabling the drivers that depended on it.
Renable FB so we get back FB_EFI, FB_WM8505, FB_SH_MOBILE_LCDC, FB_SIMPLE and VIDEO_VIVID.
It must be set to y and not a module as the test driver VIDEO_VIVID requires it to be built in.
Link: https://lore.kernel.org/r/CAK8P3a18EdBKQdGDOZc9cPKsf=hY8==v2cO0DBE_tyd82Uq-N... Signed-off-by: Joel Stanley joel@jms.id.au Reviewed-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index a611b0c1e540..b1073fb3a132 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -701,6 +701,7 @@ CONFIG_DRM_PL111=m CONFIG_DRM_LIMA=m CONFIG_DRM_PANFROST=m CONFIG_DRM_ASPEED_GFX=m +CONFIG_FB=y CONFIG_FB_EFI=y CONFIG_FB_WM8505=y CONFIG_FB_SH_MOBILE_LCDC=y
From: Eugen Hristev eugen.hristev@microchip.com
[ Upstream commit 4348cc10da6377a86940beb20ad357933b8f91bb ]
Without a sensor node, the ISC will simply fail to probe, as the corresponding port node is missing. It is then logical to disable the node in the devicetree. If we add a port with a connection to a sensor endpoint, ISC can be enabled.
Signed-off-by: Eugen Hristev eugen.hristev@microchip.com Signed-off-by: Nicolas Ferre nicolas.ferre@microchip.com Link: https://lore.kernel.org/r/20210902121358.503589-1-eugen.hristev@microchip.co... Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm/boot/dts/at91-sama5d27_som1_ek.dts | 1 - 1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts index 9a18453d7842..0a53f21a8903 100644 --- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts +++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts @@ -71,7 +71,6 @@ apb { isc: isc@f0008000 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_isc_base &pinctrl_isc_data_8bit &pinctrl_isc_data_9_10 &pinctrl_isc_data_11_12>; - status = "okay"; };
qspi1: spi@f0024000 {
From: Johannes Thumshirn johannes.thumshirn@wdc.com
[ Upstream commit 1dbdd99b511c966be9147ad72991a2856ac76f22 ]
While debugging an issue we've found that $DEBUGFS/block/$disk/state doesn't decode QUEUE_FLAG_HCTX_ACTIVE but only displays its numerical value.
Add QUEUE_FLAG(HCTX_ACTIVE) to the blk_queue_flag_name array so it'll get decoded properly.
Signed-off-by: Johannes Thumshirn johannes.thumshirn@wdc.com Link: https://lore.kernel.org/r/4351076388918075bd80ef07756f9d2ce63be12c.163333205... Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Sasha Levin sashal@kernel.org --- block/blk-mq-debugfs.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/block/blk-mq-debugfs.c b/block/blk-mq-debugfs.c index 4de03da9a624..b5f26082b959 100644 --- a/block/blk-mq-debugfs.c +++ b/block/blk-mq-debugfs.c @@ -129,6 +129,7 @@ static const char *const blk_queue_flag_name[] = { QUEUE_FLAG_NAME(PCI_P2PDMA), QUEUE_FLAG_NAME(ZONE_RESETALL), QUEUE_FLAG_NAME(RQ_ALLOC_TIME), + QUEUE_FLAG_NAME(HCTX_ACTIVE), QUEUE_FLAG_NAME(NOWAIT), }; #undef QUEUE_FLAG_NAME
From: Jan Beulich jbeulich@suse.com
[ Upstream commit 9172b5c4a778da1f855b2e3780b1afabb3cfd523 ]
Like xen_start_flags, xen_domain_type gets set before .bss gets cleared. Hence this variable also needs to be prevented from getting put in .bss, which is possible because XEN_NATIVE is an enumerator evaluating to zero. Any use prior to init_hvm_pv_info() setting the variable again would lead to wrong decisions; one such case is xenboot_console_setup() when called as a result of "earlyprintk=xen".
Use __ro_after_init as more applicable than either __section(".data") or __read_mostly.
Signed-off-by: Jan Beulich jbeulich@suse.com Reviewed-by: Juergen Gross jgross@suse.com
Link: https://lore.kernel.org/r/d301677b-6f22-5ae6-bd36-458e1f323d0b@suse.com Signed-off-by: Juergen Gross jgross@suse.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/x86/xen/enlighten.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index aa9f50fccc5d..0f68c6da7382 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -51,9 +51,6 @@ DEFINE_PER_CPU(struct vcpu_info, xen_vcpu_info); DEFINE_PER_CPU(uint32_t, xen_vcpu_id); EXPORT_PER_CPU_SYMBOL(xen_vcpu_id);
-enum xen_domain_type xen_domain_type = XEN_NATIVE; -EXPORT_SYMBOL_GPL(xen_domain_type); - unsigned long *machine_to_phys_mapping = (void *)MACH2PHYS_VIRT_START; EXPORT_SYMBOL(machine_to_phys_mapping); unsigned long machine_to_phys_nr; @@ -68,9 +65,11 @@ __read_mostly int xen_have_vector_callback; EXPORT_SYMBOL_GPL(xen_have_vector_callback);
/* - * NB: needs to live in .data because it's used by xen_prepare_pvh which runs - * before clearing the bss. + * NB: These need to live in .data or alike because they're used by + * xen_prepare_pvh() which runs before clearing the bss. */ +enum xen_domain_type __ro_after_init xen_domain_type = XEN_NATIVE; +EXPORT_SYMBOL_GPL(xen_domain_type); uint32_t xen_start_flags __section(".data") = 0; EXPORT_SYMBOL(xen_start_flags);
From: Alex Deucher alexander.deucher@amd.com
[ Upstream commit 4702b34d1de9582df9dfa0e583ea28fff7de29df ]
Depends on DRM_AMDGPU_SI and DRM_AMD_DC
Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/display/Kconfig | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/Kconfig b/drivers/gpu/drm/amd/display/Kconfig index 3c410d236c49..f3274eb6b341 100644 --- a/drivers/gpu/drm/amd/display/Kconfig +++ b/drivers/gpu/drm/amd/display/Kconfig @@ -33,6 +33,8 @@ config DRM_AMD_DC_HDCP
config DRM_AMD_DC_SI bool "AMD DC support for Southern Islands ASICs" + depends on DRM_AMDGPU_SI + depends on DRM_AMD_DC default n help Choose this option to enable new AMD DC support for SI asics
From: Max Filippov jcmvbkbc@gmail.com
[ Upstream commit f3d7c2cdf6dc0d5402ec29c3673893b3542c5ad1 ]
Use platform data to initialize xtfpga device drivers when CONFIG_USE_OF is not selected. This fixes xtfpga networking when CONFIG_USE_OF is not selected but CONFIG_OF is.
Signed-off-by: Max Filippov jcmvbkbc@gmail.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/xtensa/platforms/xtfpga/setup.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/xtensa/platforms/xtfpga/setup.c b/arch/xtensa/platforms/xtfpga/setup.c index 4f7d6142d41f..59b7f11f2a3e 100644 --- a/arch/xtensa/platforms/xtfpga/setup.c +++ b/arch/xtensa/platforms/xtfpga/setup.c @@ -66,7 +66,7 @@ void __init platform_calibrate_ccount(void)
#endif
-#ifdef CONFIG_OF +#ifdef CONFIG_USE_OF
static void __init xtfpga_clk_setup(struct device_node *np) { @@ -284,4 +284,4 @@ static int __init xtavnet_init(void) */ arch_initcall(xtavnet_init);
-#endif /* CONFIG_OF */ +#endif /* CONFIG_USE_OF */
From: Guenter Roeck linux@roeck-us.net
[ Upstream commit 012e974501a270d8dfd4ee2039e1fdf7579c907e ]
Rebooting xtensa images loaded with the '-kernel' option in qemu does not work. When executing a reboot command, the qemu session either hangs or experiences an endless sequence of error messages.
Kernel panic - not syncing: Unrecoverable error in exception handler
Reset code jumps to the CPU restart address, but Linux can not recover from there because code and data in the kernel init sections have been discarded and overwritten at this point.
XTFPGA platforms have a means to reset the CPU by writing 0xdead into a specific FPGA IO address. When used in QEMU the kernel image loaded with the '-kernel' option gets restored to its original state allowing the machine to boot successfully.
Use that mechanism to attempt a platform reset. If it does not work, fall back to the existing mechanism.
Signed-off-by: Guenter Roeck linux@roeck-us.net Signed-off-by: Max Filippov jcmvbkbc@gmail.com Signed-off-by: Sasha Levin sashal@kernel.org --- arch/xtensa/platforms/xtfpga/setup.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/xtensa/platforms/xtfpga/setup.c b/arch/xtensa/platforms/xtfpga/setup.c index 59b7f11f2a3e..538e6748e85a 100644 --- a/arch/xtensa/platforms/xtfpga/setup.c +++ b/arch/xtensa/platforms/xtfpga/setup.c @@ -51,8 +51,12 @@ void platform_power_off(void)
void platform_restart(void) { - /* Flush and reset the mmu, simulate a processor reset, and - * jump to the reset vector. */ + /* Try software reset first. */ + WRITE_ONCE(*(u32 *)XTFPGA_SWRST_VADDR, 0xdead); + + /* If software reset did not work, flush and reset the mmu, + * simulate a processor reset, and jump to the reset vector. + */ cpu_reset(); /* control never gets here */ }
From: Benjamin Coddington bcodding@redhat.com
[ Upstream commit c20106944eb679fa3ab7e686fe5f6ba30fbc51e5 ]
If nfsd has existing listening sockets without any processes, then an error returned from svc_create_xprt() for an additional transport will remove those existing listeners. We're seeing this in practice when userspace attempts to create rpcrdma transports without having the rpcrdma modules present before creating nfsd kernel processes. Fix this by checking for existing sockets before calling nfsd_destroy().
Signed-off-by: Benjamin Coddington bcodding@redhat.com Signed-off-by: Chuck Lever chuck.lever@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/nfsd/nfsctl.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/nfsd/nfsctl.c b/fs/nfsd/nfsctl.c index 0759e589ab52..506da1c77bea 100644 --- a/fs/nfsd/nfsctl.c +++ b/fs/nfsd/nfsctl.c @@ -792,7 +792,10 @@ static ssize_t __write_ports_addxprt(char *buf, struct net *net, const struct cr svc_xprt_put(xprt); } out_err: - nfsd_destroy(net); + if (!list_empty(&nn->nfsd_serv->sv_permsocks)) + nn->nfsd_serv->sv_nrthreads--; + else + nfsd_destroy(net); return err; }
From: "Naveen N. Rao" naveen.n.rao@linux.vnet.ibm.com
[ Upstream commit 030905920f32e91a52794937f67434ac0b3ea41a ]
Add a helper to return the stf_barrier type for the current processor.
Signed-off-by: Naveen N. Rao naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Michael Ellerman mpe@ellerman.id.au Link: https://lore.kernel.org/r/3bd5d7f96ea1547991ac2ce3137dc2b220bae285.163346414... Signed-off-by: Sasha Levin sashal@kernel.org --- arch/powerpc/include/asm/security_features.h | 5 +++++ arch/powerpc/kernel/security.c | 5 +++++ 2 files changed, 10 insertions(+)
diff --git a/arch/powerpc/include/asm/security_features.h b/arch/powerpc/include/asm/security_features.h index b774a4477d5f..e380acc6e413 100644 --- a/arch/powerpc/include/asm/security_features.h +++ b/arch/powerpc/include/asm/security_features.h @@ -39,6 +39,11 @@ static inline bool security_ftr_enabled(u64 feature) return !!(powerpc_security_features & feature); }
+#ifdef CONFIG_PPC_BOOK3S_64 +enum stf_barrier_type stf_barrier_type_get(void); +#else +static inline enum stf_barrier_type stf_barrier_type_get(void) { return STF_BARRIER_NONE; } +#endif
// Features indicating support for Spectre/Meltdown mitigations
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c index e4e1a94ccf6a..3f510c911b10 100644 --- a/arch/powerpc/kernel/security.c +++ b/arch/powerpc/kernel/security.c @@ -261,6 +261,11 @@ static int __init handle_no_stf_barrier(char *p)
early_param("no_stf_barrier", handle_no_stf_barrier);
+enum stf_barrier_type stf_barrier_type_get(void) +{ + return stf_enabled_flush_types; +} + /* This is the generic flag used by other architectures */ static int __init handle_ssbd(char *p) {
From: Arnd Bergmann arnd@arndb.de
[ Upstream commit 951cd3a0866d29cb9c01ebc1d9c17590e598226e ]
Compile-testing drivers that require access to a firmware layer fails when that firmware symbol is unavailable. This happened twice this week:
- My proposed to change to rework the QCOM_SCM firmware symbol broke on ppc64 and others.
- The cs_dsp firmware patch added device specific firmware loader into drivers/firmware, which broke on the same set of architectures.
We should probably do the same thing for other subsystems as well, but fix this one first as this is a dependency for other patches getting merged.
Reviewed-by: Bjorn Andersson bjorn.andersson@linaro.org Reviewed-by: Charles Keepax ckeepax@opensource.cirrus.com Acked-by: Will Deacon will@kernel.org Acked-by: Bjorn Andersson bjorn.andersson@linaro.org Cc: Mark Brown broonie@kernel.org Cc: Liam Girdwood lgirdwood@gmail.com Cc: Charles Keepax ckeepax@opensource.cirrus.com Cc: Simon Trimmer simont@opensource.cirrus.com Cc: Michael Ellerman mpe@ellerman.id.au Reviewed-by: Mark Brown broonie@kernel.org Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm/Kconfig | 2 -- arch/arm64/Kconfig | 2 -- arch/ia64/Kconfig | 2 -- arch/mips/Kconfig | 2 -- arch/parisc/Kconfig | 2 -- arch/riscv/Kconfig | 2 -- arch/x86/Kconfig | 2 -- drivers/Kconfig | 2 ++ 8 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 002e0cf025f5..d4c6b95b24d7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2043,8 +2043,6 @@ config ARCH_HIBERNATION_POSSIBLE
endmenu
-source "drivers/firmware/Kconfig" - if CRYPTO source "arch/arm/crypto/Kconfig" endif diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 5e5cf3af6351..f4809760a806 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1933,8 +1933,6 @@ source "drivers/cpufreq/Kconfig"
endmenu
-source "drivers/firmware/Kconfig" - source "drivers/acpi/Kconfig"
source "arch/arm64/kvm/Kconfig" diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 39b25a5a591b..e8014d2e36c0 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -426,8 +426,6 @@ config CRASH_DUMP help Generate crash dump after being started by kexec.
-source "drivers/firmware/Kconfig" - endmenu
menu "Power management and ACPI options" diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 1a63f592034e..3bd3a01a2a2b 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -3328,8 +3328,6 @@ source "drivers/cpuidle/Kconfig"
endmenu
-source "drivers/firmware/Kconfig" - source "arch/mips/kvm/Kconfig"
source "arch/mips/vdso/Kconfig" diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 14f3252f2da0..ad13477fb40c 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -378,6 +378,4 @@ config KEXEC_FILE
endmenu
-source "drivers/firmware/Kconfig" - source "drivers/parisc/Kconfig" diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index f7abd118d23d..fcb8e5da148e 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -428,5 +428,3 @@ menu "Power management options" source "kernel/power/Kconfig"
endmenu - -source "drivers/firmware/Kconfig" diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f3c8a8110f60..499f3cc1e62f 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2899,8 +2899,6 @@ config HAVE_ATOMIC_IOMAP def_bool y depends on X86_32
-source "drivers/firmware/Kconfig" - source "arch/x86/kvm/Kconfig"
source "arch/x86/Kconfig.assembler" diff --git a/drivers/Kconfig b/drivers/Kconfig index dcecc9f6e33f..493ac7ffd8d0 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -16,6 +16,8 @@ source "drivers/bus/Kconfig"
source "drivers/connector/Kconfig"
+source "drivers/firmware/Kconfig" + source "drivers/gnss/Kconfig"
source "drivers/mtd/Kconfig"
On Tue, Oct 12, 2021 at 08:55:31PM -0400, Sasha Levin wrote:
From: Arnd Bergmann arnd@arndb.de
[ Upstream commit 951cd3a0866d29cb9c01ebc1d9c17590e598226e ]
Compile-testing drivers that require access to a firmware layer fails when that firmware symbol is unavailable. This happened twice this week:
My proposed to change to rework the QCOM_SCM firmware symbol broke on ppc64 and others.
The cs_dsp firmware patch added device specific firmware loader into drivers/firmware, which broke on the same set of architectures.
We should probably do the same thing for other subsystems as well, but fix this one first as this is a dependency for other patches getting merged.
Reviewed-by: Bjorn Andersson bjorn.andersson@linaro.org Reviewed-by: Charles Keepax ckeepax@opensource.cirrus.com Acked-by: Will Deacon will@kernel.org Acked-by: Bjorn Andersson bjorn.andersson@linaro.org Cc: Mark Brown broonie@kernel.org Cc: Liam Girdwood lgirdwood@gmail.com Cc: Charles Keepax ckeepax@opensource.cirrus.com Cc: Simon Trimmer simont@opensource.cirrus.com Cc: Michael Ellerman mpe@ellerman.id.au Reviewed-by: Mark Brown broonie@kernel.org Signed-off-by: Arnd Bergmann arnd@arndb.de Signed-off-by: Sasha Levin sashal@kernel.org
arch/arm/Kconfig | 2 -- arch/arm64/Kconfig | 2 -- arch/ia64/Kconfig | 2 -- arch/mips/Kconfig | 2 -- arch/parisc/Kconfig | 2 -- arch/riscv/Kconfig | 2 -- arch/x86/Kconfig | 2 -- drivers/Kconfig | 2 ++ 8 files changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 002e0cf025f5..d4c6b95b24d7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -2043,8 +2043,6 @@ config ARCH_HIBERNATION_POSSIBLE endmenu -source "drivers/firmware/Kconfig"
if CRYPTO source "arch/arm/crypto/Kconfig" endif diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 5e5cf3af6351..f4809760a806 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1933,8 +1933,6 @@ source "drivers/cpufreq/Kconfig" endmenu -source "drivers/firmware/Kconfig"
source "drivers/acpi/Kconfig" source "arch/arm64/kvm/Kconfig" diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 39b25a5a591b..e8014d2e36c0 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -426,8 +426,6 @@ config CRASH_DUMP help Generate crash dump after being started by kexec. -source "drivers/firmware/Kconfig"
endmenu menu "Power management and ACPI options" diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 1a63f592034e..3bd3a01a2a2b 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -3328,8 +3328,6 @@ source "drivers/cpuidle/Kconfig" endmenu -source "drivers/firmware/Kconfig"
source "arch/mips/kvm/Kconfig" source "arch/mips/vdso/Kconfig" diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig index 14f3252f2da0..ad13477fb40c 100644 --- a/arch/parisc/Kconfig +++ b/arch/parisc/Kconfig @@ -378,6 +378,4 @@ config KEXEC_FILE endmenu -source "drivers/firmware/Kconfig"
source "drivers/parisc/Kconfig" diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index f7abd118d23d..fcb8e5da148e 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -428,5 +428,3 @@ menu "Power management options" source "kernel/power/Kconfig" endmenu
-source "drivers/firmware/Kconfig" diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index f3c8a8110f60..499f3cc1e62f 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2899,8 +2899,6 @@ config HAVE_ATOMIC_IOMAP def_bool y depends on X86_32 -source "drivers/firmware/Kconfig"
source "arch/x86/kvm/Kconfig" source "arch/x86/Kconfig.assembler" diff --git a/drivers/Kconfig b/drivers/Kconfig index dcecc9f6e33f..493ac7ffd8d0 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -16,6 +16,8 @@ source "drivers/bus/Kconfig" source "drivers/connector/Kconfig" +source "drivers/firmware/Kconfig"
source "drivers/gnss/Kconfig" source "drivers/mtd/Kconfig" -- 2.33.0
This isn't for stable kernels, it should be dropped from all of your AUTOSEL queues.
thanks,
greg k-h
On Wed, Oct 13, 2021 at 7:58 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Oct 12, 2021 at 08:55:31PM -0400, Sasha Levin wrote:
This isn't for stable kernels, it should be dropped from all of your AUTOSEL queues.
Agreed. The second patch that depends on this does fix a (randconfig) build issue in stable kernels as well, but that patch is currently broken, and the two patches combined do feel a little too invasive for addressing such a minor issue in the stable kernels.
If anyone runs into the QCOM_SCM link failures on stable kernels, I can come up with a more localized fix.
Arnd
On Wed, Oct 13, 2021 at 10:38:01AM +0200, Arnd Bergmann wrote:
On Wed, Oct 13, 2021 at 7:58 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Oct 12, 2021 at 08:55:31PM -0400, Sasha Levin wrote:
This isn't for stable kernels, it should be dropped from all of your AUTOSEL queues.
Agreed. The second patch that depends on this does fix a (randconfig) build issue in stable kernels as well, but that patch is currently broken,
Fixing randconfig issues isn't important for stable, is it? The target audience for 5.10.74 are people running a kernel between 5.10 and 5.10.73, and those don't suffer from this type of build problem, right?
Best regards Uwe
On Wed, Oct 13, 2021 at 10:45 AM Uwe Kleine-König u.kleine-koenig@pengutronix.de wrote:
On Wed, Oct 13, 2021 at 10:38:01AM +0200, Arnd Bergmann wrote:
On Wed, Oct 13, 2021 at 7:58 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Oct 12, 2021 at 08:55:31PM -0400, Sasha Levin wrote:
This isn't for stable kernels, it should be dropped from all of your AUTOSEL queues.
Agreed. The second patch that depends on this does fix a (randconfig) build issue in stable kernels as well, but that patch is currently broken,
Fixing randconfig issues isn't important for stable, is it? The target audience for 5.10.74 are people running a kernel between 5.10 and 5.10.73, and those don't suffer from this type of build problem, right?
In general, I think randconfig build testing is useful for validating stable kernels, to help avoid regressions, but there are a number of known randconfig problems that you hit much more frequently than this one, which only breaks once every few hundred kernel builds.
Arnd
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Greg KH -
Sasha Levin -
Uwe Kleine-König