Oops. + Cc stable(a)vger.kernel.org
On 2024/03/18 10:52, GONG, Ruiqi wrote:
> From: Hugo Villeneuve <hvilleneuve(a)dimonoff.com>
>
> commit dbf4ab821804df071c8b566d9813083125e6d97b upstream.
>
> The SC16IS7XX IC supports a burst mode to access the FIFOs where the
> initial register address is sent ($00), followed by all the FIFO data
> without having to resend the register address each time. In this mode, the
> IC doesn't increment the register address for each R/W byte.
>
> The regmap_raw_read() and regmap_raw_write() are functions which can
> perform IO over multiple registers. They are currently used to read/write
> from/to the FIFO, and although they operate correctly in this burst mode on
> the SPI bus, they would corrupt the regmap cache if it was not disabled
> manually. The reason is that when the R/W size is more than 1 byte, these
> functions assume that the register address is incremented and handle the
> cache accordingly.
>
> Convert FIFO R/W functions to use the regmap _noinc_ versions in order to
> remove the manual cache control which was a workaround when using the
> _raw_ versions. FIFO registers are properly declared as volatile so
> cache will not be used/updated for FIFO accesses.
>
> Fixes: dfeae619d781 ("serial: sc16is7xx")
> Cc: <stable(a)vger.kernel.org>
> Signed-off-by: Hugo Villeneuve <hvilleneuve(a)dimonoff.com>
> Link: https://lore.kernel.org/r/20231211171353.2901416-6-hugo@hugovil.com
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> Cc: Hugo Villeneuve <hvilleneuve(a)dimonoff.com>
> Signed-off-by: GONG, Ruiqi <gongruiqi1(a)huawei.com>
> ---
>
> The mainline commit dbf4ab821804 ("serial: sc16is7xx: convert from _raw_
> to _noinc_ regmap functions for FIFO") by Hugo has been assigned to be
> CVE-2023-52488, but for stable branches lower than 6.1 there's no
> official backport.
>
> I made up this backport patch for 5.10, and its correctness has been
> confirmed in previous communication with Hugo. Let's publicize it and
> merge it into upstream.
>
> drivers/tty/serial/sc16is7xx.c | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/tty/serial/sc16is7xx.c b/drivers/tty/serial/sc16is7xx.c
> index 31e0c5c3ddea..29f05db0d49b 100644
> --- a/drivers/tty/serial/sc16is7xx.c
> +++ b/drivers/tty/serial/sc16is7xx.c
> @@ -376,9 +376,7 @@ static void sc16is7xx_fifo_read(struct uart_port *port, unsigned int rxlen)
> const u8 line = sc16is7xx_line(port);
> u8 addr = (SC16IS7XX_RHR_REG << SC16IS7XX_REG_SHIFT) | line;
>
> - regcache_cache_bypass(s->regmap, true);
> - regmap_raw_read(s->regmap, addr, s->buf, rxlen);
> - regcache_cache_bypass(s->regmap, false);
> + regmap_noinc_read(s->regmap, addr, s->buf, rxlen);
> }
>
> static void sc16is7xx_fifo_write(struct uart_port *port, u8 to_send)
> @@ -394,9 +392,7 @@ static void sc16is7xx_fifo_write(struct uart_port *port, u8 to_send)
> if (unlikely(!to_send))
> return;
>
> - regcache_cache_bypass(s->regmap, true);
> - regmap_raw_write(s->regmap, addr, s->buf, to_send);
> - regcache_cache_bypass(s->regmap, false);
> + regmap_noinc_write(s->regmap, addr, s->buf, to_send);
> }
>
> static void sc16is7xx_port_update(struct uart_port *port, u8 reg,
> @@ -489,6 +485,11 @@ static bool sc16is7xx_regmap_precious(struct device *dev, unsigned int reg)
> return false;
> }
>
> +static bool sc16is7xx_regmap_noinc(struct device *dev, unsigned int reg)
> +{
> + return reg == SC16IS7XX_RHR_REG;
> +}
> +
> static int sc16is7xx_set_baud(struct uart_port *port, int baud)
> {
> struct sc16is7xx_port *s = dev_get_drvdata(port->dev);
> @@ -1439,6 +1440,8 @@ static struct regmap_config regcfg = {
> .cache_type = REGCACHE_RBTREE,
> .volatile_reg = sc16is7xx_regmap_volatile,
> .precious_reg = sc16is7xx_regmap_precious,
> + .writeable_noinc_reg = sc16is7xx_regmap_noinc,
> + .readable_noinc_reg = sc16is7xx_regmap_noinc,
> };
>
> #ifdef CONFIG_SERIAL_SC16IS7XX_SPI
From: Bitterblue Smith <rtl8821cerfe2(a)gmail.com>
[ Upstream commit 605d7c0b05eecb985273b1647070497142c470d3 ]
Clear bit 8 of REG_SYS_STATUS1 after MAC power on.
Without this, some RTL8821CU and RTL8811CU cannot connect to any
network:
Feb 19 13:33:11 ideapad2 kernel: wlp3s0f3u2: send auth to
90:55:de:__:__:__ (try 1/3)
Feb 19 13:33:13 ideapad2 kernel: wlp3s0f3u2: send auth to
90:55:de:__:__:__ (try 2/3)
Feb 19 13:33:14 ideapad2 kernel: wlp3s0f3u2: send auth to
90:55:de:__:__:__ (try 3/3)
Feb 19 13:33:15 ideapad2 kernel: wlp3s0f3u2: authentication with
90:55:de:__:__:__ timed out
The RTL8822CU and RTL8822BU out-of-tree drivers do this as well, so do
it for all three types of chips.
Tested with RTL8811CU (Tenda U9 V2.0).
Signed-off-by: Bitterblue Smith <rtl8821cerfe2(a)gmail.com>
Acked-by: Ping-Ke Shih <pkshih(a)realtek.com>
Signed-off-by: Kalle Valo <kvalo(a)kernel.org>
Link: https://msgid.link/aeeefad9-27c8-4506-a510-ef9a9a8731a4@gmail.com
---
drivers/net/wireless/realtek/rtw88/mac.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/mac.c b/drivers/net/wireless/realtek/rtw88/mac.c
index 298663b03580..0c1c1ff31085 100644
--- a/drivers/net/wireless/realtek/rtw88/mac.c
+++ b/drivers/net/wireless/realtek/rtw88/mac.c
@@ -309,6 +309,13 @@ static int rtw_mac_power_switch(struct rtw_dev *rtwdev, bool pwr_on)
pwr_seq = pwr_on ? chip->pwr_on_seq : chip->pwr_off_seq;
ret = rtw_pwr_seq_parser(rtwdev, pwr_seq);
+ if (pwr_on && rtw_hci_type(rtwdev) == RTW_HCI_TYPE_USB) {
+ if (chip->id == RTW_CHIP_TYPE_8822C ||
+ chip->id == RTW_CHIP_TYPE_8822B ||
+ chip->id == RTW_CHIP_TYPE_8821C)
+ rtw_write8_clr(rtwdev, REG_SYS_STATUS1 + 1, BIT(0));
+ }
+
if (rtw_hci_type(rtwdev) == RTW_HCI_TYPE_SDIO)
rtw_write32(rtwdev, REG_SDIO_HIMR, imr);
--
2.43.2
Hey stable folks,
Can the following patches found in mainline
[PATCH] ASoC: amd: yc: Revert "Fix non-functional mic on Lenovo 21J2"
(861b341)
[PATCH] ASoC: amd: yc: Revert "add new YC platform variant (0x63)
support" (37bee18)
be backported to linux-6.8.y?
They're improperly assuming the 0x63 variant is part of the Yellow Carp
family. This causes the microphone input device to not being properly
probed on the device.
Known broken devices: ThinkPad P16s Gen 2 (21K9CTO1WW)
Thanks, Luca.
Hello everyone,
Can those changes be pulled in stable? They're currently breaking mic
input on my 21K9CTO1WW, ThinkPad P16s Gen 2, and probably more devices
in the wild.
Thanks, Luca.
On 12/03/24 03:33, Jiawei Wang wrote:
> Please revert my previous two commits:
>
> ASoC: amd: yc: add new YC platform variant (0x63) support
> [ Upstream commit 316a784839b21b122e1761cdca54677bb19a47fa ]
>
> ASoC: amd: yc: Fix non-functional mic on Lenovo 21J2
> [ Upstream commit ed00a6945dc32462c2d3744a3518d2316da66fcc ]
>
> PCI revision id 0x63 is the Pink Sardine (PS) platform, not Yellow
> Carp (YC). Thanks to Mukunda Vijendar [1] for pointing out that.
>
> The mic on Lenovo 21J2 works after enabling the CONFIG_SND_SOC_AMD_PS
> flag, which I had not enabled when I was writing these patches. 21J2
> does not need to be in this quirk table.
>
> I apologize for the inconvenience caused.
>
> Link: https://lore.kernel.org/linux-sound/023092e1-689c-4b00-b93f-4092c3724fb6@am… [1]
>
> Signed-off-by: Jiawei Wang <me(a)jwang.link>
>
> Jiawei Wang (2):
> Revert "ASoC: amd: yc: Fix non-functional mic on Lenovo 21J2"
> Revert "ASoC: amd: yc: add new YC platform variant (0x63) support"
>
> sound/soc/amd/yc/acp6x-mach.c | 7 -------
> sound/soc/amd/yc/pci-acp6x.c | 1 -
> 2 files changed, 8 deletions(-)
>
The patch below does not apply to the 6.8-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
Thanks,
Sasha
------------------ original commit in Linus's tree ------------------
From cefcd4fe2e3aaf792c14c9e56dab89e3d7a65d02 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb(a)kernel.org>
Date: Fri, 22 Mar 2024 17:03:58 +0200
Subject: [PATCH] x86/efistub: Call mixed mode boot services on the firmware's
stack
Normally, the EFI stub calls into the EFI boot services using the stack
that was live when the stub was entered. According to the UEFI spec,
this stack needs to be at least 128k in size - this might seem large but
all asynchronous processing and event handling in EFI runs from the same
stack and so quite a lot of space may be used in practice.
In mixed mode, the situation is a bit different: the bootloader calls
the 32-bit EFI stub entry point, which calls the decompressor's 32-bit
entry point, where the boot stack is set up, using a fixed allocation
of 16k. This stack is still in use when the EFI stub is started in
64-bit mode, and so all calls back into the EFI firmware will be using
the decompressor's limited boot stack.
Due to the placement of the boot stack right after the boot heap, any
stack overruns have gone unnoticed. However, commit
5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code")
moved the definition of the boot heap into C code, and now the boot
stack is placed right at the base of BSS, where any overruns will
corrupt the end of the .data section.
While it would be possible to work around this by increasing the size of
the boot stack, doing so would affect all x86 systems, and mixed mode
systems are a tiny (and shrinking) fraction of the x86 installed base.
So instead, record the firmware stack pointer value when entering from
the 32-bit firmware, and switch to this stack every time a EFI boot
service call is made.
Cc: <stable(a)kernel.org> # v6.1+
Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org>
---
arch/x86/boot/compressed/efi_mixed.S | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/x86/boot/compressed/efi_mixed.S b/arch/x86/boot/compressed/efi_mixed.S
index f4e22ef774ab6..719e939050cbf 100644
--- a/arch/x86/boot/compressed/efi_mixed.S
+++ b/arch/x86/boot/compressed/efi_mixed.S
@@ -49,6 +49,11 @@ SYM_FUNC_START(startup_64_mixed_mode)
lea efi32_boot_args(%rip), %rdx
mov 0(%rdx), %edi
mov 4(%rdx), %esi
+
+ /* Switch to the firmware's stack */
+ movl efi32_boot_sp(%rip), %esp
+ andl $~7, %esp
+
#ifdef CONFIG_EFI_HANDOVER_PROTOCOL
mov 8(%rdx), %edx // saved bootparams pointer
test %edx, %edx
@@ -254,6 +259,9 @@ SYM_FUNC_START_LOCAL(efi32_entry)
/* Store firmware IDT descriptor */
sidtl (efi32_boot_idt - 1b)(%ebx)
+ /* Store firmware stack pointer */
+ movl %esp, (efi32_boot_sp - 1b)(%ebx)
+
/* Store boot arguments */
leal (efi32_boot_args - 1b)(%ebx), %ebx
movl %ecx, 0(%ebx)
@@ -318,5 +326,6 @@ SYM_DATA_END(efi32_boot_idt)
SYM_DATA_LOCAL(efi32_boot_cs, .word 0)
SYM_DATA_LOCAL(efi32_boot_ds, .word 0)
+SYM_DATA_LOCAL(efi32_boot_sp, .long 0)
SYM_DATA_LOCAL(efi32_boot_args, .long 0, 0, 0)
SYM_DATA(efi_is64, .byte 1)
--
2.43.0
Commit e79c6a4fc923 ("net: make net namespace sysctls belong to container's owner")
added default values for i_uid/i_gid.
These however are only used when ctl_table_root->set_ownership is not
implemented.
But the callbacks themselves could fail to compute i_uid/i_gid and they
all need to have the same fallback logic for this case.
This is unnecessary code duplication and prone to errors.
For example net_ctl_set_ownership() missed the fallback.
Instead always initialize i_uid/i_gid inside the sysfs core so
set_ownership() can safely skip setting them.
Fixes: e79c6a4fc923 ("net: make net namespace sysctls belong to container's owner")
Cc: stable(a)vger.kernel.org
Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net>
---
Changes in v2:
- Move the fallback logic to the sysctl core
- Link to v1: https://lore.kernel.org/r/20240315-sysctl-net-ownership-v1-1-2b465555a292@w…
---
fs/proc/proc_sysctl.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index 37cde0efee57..9e34ab9c21e4 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -479,12 +479,10 @@ static struct inode *proc_sys_make_inode(struct super_block *sb,
make_empty_dir_inode(inode);
}
+ inode->i_uid = GLOBAL_ROOT_UID;
+ inode->i_gid = GLOBAL_ROOT_GID;
if (root->set_ownership)
root->set_ownership(head, table, &inode->i_uid, &inode->i_gid);
- else {
- inode->i_uid = GLOBAL_ROOT_UID;
- inode->i_gid = GLOBAL_ROOT_GID;
- }
return inode;
}
---
base-commit: ff9c18e435b042596c9d48badac7488e3fa76a55
change-id: 20240315-sysctl-net-ownership-bc4e17eaeea6
Best regards,
--
Thomas Weißschuh <linux(a)weissschuh.net>