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>
If drm_gem_handle_create() fails in vkms_gem_create(), then the
vkms_gem_object is not freed.
Fix it by adding a call to vkms_gem_free_object().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Fixes: 0ea2ea42b31a ("drm/vkms: Hold gem object while still in-use")
Cc: stable(a)vger.kernel.org#v5.10.212
#Co-developed-by: Fedor Pchelkin <pchelkin(a)ispras.ru>
Signed-off-by: Salomatkina Elena <elena.salomatkina.cmc(a)gmail.com>
---
drivers/gpu/drm/vkms/vkms_gem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_gem.c b/drivers/gpu/drm/vkms/vkms_gem.c
index a017fc59905e..cc6584767a1b 100644
--- a/drivers/gpu/drm/vkms/vkms_gem.c
+++ b/drivers/gpu/drm/vkms/vkms_gem.c
@@ -113,9 +113,10 @@ static struct drm_gem_object *vkms_gem_create(struct drm_device *dev,
return ERR_CAST(obj);
ret = drm_gem_handle_create(file, &obj->gem, handle);
- if (ret)
+ if (ret) {
+ vkms_gem_free_object(&obj->gem);
return ERR_PTR(ret);
-
+ }
return &obj->gem;
}
--
2.34.1
The ISRs of the tps25750 and tps6598x do not handle generated events
properly under all circumstances.
The tps6598x ISR does not read all bits of the INT_EVENTX registers,
leaving events signaled with bits above 64 unattended. Moreover, these
events are not cleared, leaving the interrupt enabled.
The tps25750 reads all bits of the INT_EVENT1 register, but the event
checking is not right because the same event is checked in two different
regions of the same register by means of an OR operation.
This series aims to fix both issues by reading all bits of the
INT_EVENTX registers, and limiting the event checking to the region
where the supported events are defined (currently they are limited to
the first 64 bits of the registers, as the are defined as BIT_ULL()).
If the need for events above the first 64 bits of the INT_EVENTX
registers arises, a different mechanism might be required. But for the
current needs, all definitions can be left as they are.
Note: resend to add 'stable' mailing list (fixes in the series).
Signed-off-by: Javier Carrasco <javier.carrasco(a)wolfvision.net>
---
Javier Carrasco (2):
usb: typec: tipd: fix event checking for tps25750
usb: typec: tipd: fix event checking for tps6598x
drivers/usb/typec/tipd/core.c | 37 +++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240328-tps6598x_fix_event_handling-8fff3a6018d9
Best regards,
--
Javier Carrasco <javier.carrasco(a)wolfvision.net>
From: Fabio Estevam <festevam(a)denx.de>
Since commit 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint
property verification") even when the correct 'link-frequencies'
property is passed in the devicetree, the driver fails to probe:
ov2680 1-0036: probe with driver ov2680 failed with error -22
The reason is that the variable 'ret' may contain the -EINVAL value
from a previous assignment:
ret = fwnode_property_read_u32(dev_fwnode(dev), "clock-frequency",
&rate);
Fix the problem by clearing 'ret' on the successful path.
Tested on imx7s-warp board with the following devicetree:
port {
ov2680_to_mipi: endpoint {
remote-endpoint = <&mipi_from_sensor>;
clock-lanes = <0>;
data-lanes = <1>;
link-frequencies = /bits/ 64 <330000000>;
};
};
Cc: stable(a)vger.kernel.org
Fixes: 63b0cd30b78e ("media: ov2680: Add bus-cfg / endpoint property verification")
Suggested-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Fabio Estevam <festevam(a)denx.de>
---
Changes since v1:
- Use Hans' suggestion to clear 'ret'.
drivers/media/i2c/ov2680.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/i2c/ov2680.c b/drivers/media/i2c/ov2680.c
index 39d321e2b7f9..3e3b7c2b492c 100644
--- a/drivers/media/i2c/ov2680.c
+++ b/drivers/media/i2c/ov2680.c
@@ -1135,6 +1135,7 @@ static int ov2680_parse_dt(struct ov2680_dev *sensor)
goto out_free_bus_cfg;
}
+ ret = 0;
out_free_bus_cfg:
v4l2_fwnode_endpoint_free(&bus_cfg);
return ret;
--
2.34.1
Dear Linux folks,
Please apply commit 13e3a512a290 (i2c: smbus: Support up to 8 SPD
EEPROMs) [1] to the stable series to get rid of a warning and to support
more SPDs. That commit is present since v6.8-rc1.
Kind regards,
Paul
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
misc_cmd_type in exec_op have multiple problems. With commit a82990c8a409
("mtd: rawnand: qcom: Add read/read_start ops in exec_op path") it was
reworked and generalized but actually broke the handling of the
ERASE_BLOCK command.
Additional logic was added to the erase command cycle without clear
explaination causing the erase command to be broken on testing it on
a ipq806x nandc.
Fix the erase command by reverting the additional logic and only adding
the NAND_DEV0_CFG0 additional call (required for erase command).
Fixes: a82990c8a409 ("mtd: rawnand: qcom: Add read/read_start ops in exec_op path")
Cc: stable(a)vger.kernel.org
Signed-off-by: Christian Marangi <ansuelsmth(a)gmail.com>
---
Changes v2:
- Split this and rework commit description and title
drivers/mtd/nand/raw/qcom_nandc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c
index b079605c84d3..19d76e345a49 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -2830,9 +2830,8 @@ static int qcom_misc_cmd_type_exec(struct nand_chip *chip, const struct nand_sub
nandc_set_reg(chip, NAND_EXEC_CMD, 1);
write_reg_dma(nandc, NAND_FLASH_CMD, instrs, NAND_BAM_NEXT_SGL);
- (q_op.cmd_reg == OP_BLOCK_ERASE) ? write_reg_dma(nandc, NAND_DEV0_CFG0,
- 2, NAND_BAM_NEXT_SGL) : read_reg_dma(nandc,
- NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
+ if (q_op.cmd_reg == OP_BLOCK_ERASE)
+ write_reg_dma(nandc, NAND_DEV0_CFG0, 2, NAND_BAM_NEXT_SGL);
write_reg_dma(nandc, NAND_EXEC_CMD, 1, NAND_BAM_NEXT_SGL);
read_reg_dma(nandc, NAND_FLASH_STATUS, 1, NAND_BAM_NEXT_SGL);
--
2.43.0