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 e4c8def9a0a5..32dfc736a4b1 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -677,6 +677,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 89f0c9979b89..4f63158d6b9b 100644 --- a/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts +++ b/arch/arm/boot/dts/at91-sama5d27_som1_ek.dts @@ -69,7 +69,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: 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 829115bb381f..61c5e2c45439 100644 --- a/arch/xtensa/platforms/xtfpga/setup.c +++ b/arch/xtensa/platforms/xtfpga/setup.c @@ -81,7 +81,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) { @@ -299,4 +299,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 61c5e2c45439..4edccb4d4a5f 100644 --- a/arch/xtensa/platforms/xtfpga/setup.c +++ b/arch/xtensa/platforms/xtfpga/setup.c @@ -50,8 +50,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 7f39d6091dfa..b1da4535733d 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 e9e3f85134e5..316a9c8d1929 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 1740a66cea84..ff022e725693 100644 --- a/arch/powerpc/kernel/security.c +++ b/arch/powerpc/kernel/security.c @@ -256,6 +256,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) {
On Wed, Oct 13, 2021 at 2:55 AM Sasha Levin sashal@kernel.org wrote:
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
This is only needed to fix regressions from f611b1e7624c, which made it into v5.14. I don't think that patch should be backported, so neither should this one.
Arnd
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Sasha Levin