Greetings!
I've run into a problem with an external microphone (3.5 jack headset) and
fresh kernels (6.9, 6.10)
When using the 6.9 or the 6.10 kernel system doesn't see an external mic
from the headset (3.5 jack). Instead, there's only an internal mic
plugged/available in the system.
When using the 6.8 kernel or less it's okay, I can use mic from the
headset. So currently I'm on 6.8.12.
Also opened a bug on bugzilla (
https://bugzilla.kernel.org/show_bug.cgi?id=219158)
Laptop Model: Asus ROG G14 GA402XY
Codec: Realtek ALC285 + Cirrus logic cs35l41
OS: Debian Testing
Kernel: 6.9.x, 6.10 represents the issue, 6.8.x no
DE: Gnome 46, wayland
What I've tried:
- Play with snd_hda_intel model parameters from here:
https://www.kernel.org/doc/html/latest/sound/hd-audio/models.html?highlight…
ex: options snd_hda_intel model=dell-headset-mic
- Retask jack with hdajackretask
- Install a fresh system on another ssd (latest PopOS) - after kernel
update to 6.9.x (from the repository) it's the same issue.
On Mon, Aug 19, 2024 at 10:25:08AM -0400, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> Input: bcm5974 - check endpoint type before starting traffic
>
> to the 6.1-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> input-bcm5974-check-endpoint-type-before-starting-tr.patch
> and it can be found in the queue-6.1 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
Please drop it, it was reverted.
Thanks.
--
Dmitry
[Public]
> -----Original Message-----
> From: Sasha Levin <sashal(a)kernel.org>
> Sent: Wednesday, August 21, 2024 9:33 AM
> To: stable-commits(a)vger.kernel.org; Xiao, Jack <Jack.Xiao(a)amd.com>
> Cc: Deucher, Alexander <Alexander.Deucher(a)amd.com>; Koenig, Christian
> <Christian.Koenig(a)amd.com>; Pan, Xinhui <Xinhui.Pan(a)amd.com>; David
> Airlie <airlied(a)gmail.com>; Daniel Vetter <daniel(a)ffwll.ch>
> Subject: Patch "drm/amdgpu/gfx11: need acquire mutex before access
> CP_VMID_RESET v2" has been added to the 6.6-stable tree
>
> This is a note to let you know that I've just added the patch titled
>
> drm/amdgpu/gfx11: need acquire mutex before access CP_VMID_RESET v2
>
> to the 6.6-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-
> queue.git;a=summary
>
> The filename of the patch is:
> drm-amdgpu-gfx11-need-acquire-mutex-before-access-cp.patch
> and it can be found in the queue-6.6 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree, please let
> <stable(a)vger.kernel.org> know about it.
>
This patch is not stable material. Please drop for stable.
Thanks,
Alex
>
>
> commit 72516630230bee2668c491fdafcac27c565a5ad5
> Author: Jack Xiao <Jack.Xiao(a)amd.com>
> Date: Tue Dec 19 17:10:34 2023 +0800
>
> drm/amdgpu/gfx11: need acquire mutex before access CP_VMID_RESET v2
>
> [ Upstream commit 4b5c5f5ad38b9435518730cc7f8f1e8de9c5cb2f ]
>
> It's required to take the gfx mutex before access to CP_VMID_RESET,
> for there is a race condition with CP firmware to write the register.
>
> v2: add extra code to ensure the mutex releasing is successful.
>
> Signed-off-by: Jack Xiao <Jack.Xiao(a)amd.com>
> Reviewed-by: Hawking Zhang <Hawking.Zhang(a)amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> index c81e98f0d17ff..17a09e96b30fc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
> @@ -4430,11 +4430,43 @@ static int gfx_v11_0_wait_for_idle(void *handle)
> return -ETIMEDOUT;
> }
>
> +static int gfx_v11_0_request_gfx_index_mutex(struct amdgpu_device *adev,
> + int req)
> +{
> + u32 i, tmp, val;
> +
> + for (i = 0; i < adev->usec_timeout; i++) {
> + /* Request with MeId=2, PipeId=0 */
> + tmp = REG_SET_FIELD(0, CP_GFX_INDEX_MUTEX, REQUEST,
> req);
> + tmp = REG_SET_FIELD(tmp, CP_GFX_INDEX_MUTEX,
> CLIENTID, 4);
> + WREG32_SOC15(GC, 0, regCP_GFX_INDEX_MUTEX, tmp);
> +
> + val = RREG32_SOC15(GC, 0, regCP_GFX_INDEX_MUTEX);
> + if (req) {
> + if (val == tmp)
> + break;
> + } else {
> + tmp = REG_SET_FIELD(tmp, CP_GFX_INDEX_MUTEX,
> + REQUEST, 1);
> +
> + /* unlocked or locked by firmware */
> + if (val != tmp)
> + break;
> + }
> + udelay(1);
> + }
> +
> + if (i >= adev->usec_timeout)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> static int gfx_v11_0_soft_reset(void *handle) {
> u32 grbm_soft_reset = 0;
> u32 tmp;
> - int i, j, k;
> + int r, i, j, k;
> struct amdgpu_device *adev = (struct amdgpu_device *)handle;
>
> tmp = RREG32_SOC15(GC, 0, regCP_INT_CNTL); @@ -4474,6
> +4506,13 @@ static int gfx_v11_0_soft_reset(void *handle)
> }
> }
>
> + /* Try to acquire the gfx mutex before access to CP_VMID_RESET */
> + r = gfx_v11_0_request_gfx_index_mutex(adev, 1);
> + if (r) {
> + DRM_ERROR("Failed to acquire the gfx mutex during soft
> reset\n");
> + return r;
> + }
> +
> WREG32_SOC15(GC, 0, regCP_VMID_RESET, 0xfffffffe);
>
> // Read CP_VMID_RESET register three times.
> @@ -4482,6 +4521,13 @@ static int gfx_v11_0_soft_reset(void *handle)
> RREG32_SOC15(GC, 0, regCP_VMID_RESET);
> RREG32_SOC15(GC, 0, regCP_VMID_RESET);
>
> + /* release the gfx mutex */
> + r = gfx_v11_0_request_gfx_index_mutex(adev, 0);
> + if (r) {
> + DRM_ERROR("Failed to release the gfx mutex during soft
> reset\n");
> + return r;
> + }
> +
> for (i = 0; i < adev->usec_timeout; i++) {
> if (!RREG32_SOC15(GC, 0, regCP_HQD_ACTIVE) &&
> !RREG32_SOC15(GC, 0, regCP_GFX_HQD_ACTIVE))
On 21. 08. 24, 15:37, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> serial: pch: Don't disable interrupts while acquiring lock in ISR.
>
> to the 6.1-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> serial-pch-don-t-disable-interrupts-while-acquiring-.patch
> and it can be found in the queue-6.1 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
I feel so. It does not fix anything real. It is a prep for
d47dd323bf959. So unless you take that too, this one does not make sense
on its own.
> commit 2e7194802a740ab6ef47e19e56bd1b06c03610d3
> Author: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
> Date: Fri Mar 1 22:45:28 2024 +0100
>
> serial: pch: Don't disable interrupts while acquiring lock in ISR.
>
> [ Upstream commit f8ff23ebce8c305383c8070e1ea3b08a69eb1e8d ]
>
> The interrupt service routine is always invoked with disabled
> interrupts.
>
> Remove the _irqsave() from the locking functions in the interrupts
> service routine/ pch_uart_interrupt().
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
> Link: https://lore.kernel.org/r/20240301215246.891055-16-bigeasy@linutronix.de
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/drivers/tty/serial/pch_uart.c b/drivers/tty/serial/pch_uart.c
> index abff1c6470f6a..d638e890ef6f0 100644
> --- a/drivers/tty/serial/pch_uart.c
> +++ b/drivers/tty/serial/pch_uart.c
> @@ -1023,11 +1023,10 @@ static irqreturn_t pch_uart_interrupt(int irq, void *dev_id)
> u8 lsr;
> int ret = 0;
> unsigned char iid;
> - unsigned long flags;
> int next = 1;
> u8 msr;
>
> - spin_lock_irqsave(&priv->lock, flags);
> + spin_lock(&priv->lock);
> handled = 0;
> while (next) {
> iid = pch_uart_hal_get_iid(priv);
> @@ -1087,7 +1086,7 @@ static irqreturn_t pch_uart_interrupt(int irq, void *dev_id)
> handled |= (unsigned int)ret;
> }
>
> - spin_unlock_irqrestore(&priv->lock, flags);
> + spin_unlock(&priv->lock);
> return IRQ_RETVAL(handled);
> }
>
--
js
suse labs
From: Zijun Hu <quic_zijuhu(a)quicinc.com>
An uninitialized variable @data.have_async may be used as analyzed
by the following inline comments:
static int __device_attach(struct device *dev, bool allow_async)
{
// if @allow_async is true.
...
struct device_attach_data data = {
.dev = dev,
.check_async = allow_async,
.want_async = false,
};
// @data.have_async is not initialized.
...
ret = bus_for_each_drv(dev->bus, NULL, &data,
__device_attach_driver);
// @data.have_async must not be set by __device_attach_driver() if
// @dev->bus does not have driver which allows probe asynchronously
if (!ret && allow_async && data.have_async) {
// Above @data.have_async is not uninitialized but used.
...
}
...
}
It may be unnecessary to trigger the second pass probing asynchronous
drivers for the device @dev.
Fixed by initializing @data.have_async to false.
Fixes: 765230b5f084 ("driver-core: add asynchronous probing support for drivers")
Cc: stable(a)vger.kernel.org
Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com>
---
drivers/base/dd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9b745ba54de1..b0c44b0846aa 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -1021,6 +1021,7 @@ static int __device_attach(struct device *dev, bool allow_async)
.dev = dev,
.check_async = allow_async,
.want_async = false,
+ .have_async = false,
};
if (dev->parent)
---
base-commit: 87ee9981d1f86ee9b1623a46c7f9e4ac24461fe4
change-id: 20240823-fix_have_async-3a135618d91b
Best regards,
--
Zijun Hu <quic_zijuhu(a)quicinc.com>
The following commit has been merged into the irq/urgent branch of tip:
Commit-ID: 71c8e2a7c822ee557b07d9bb49028dd269c87b2e
Gitweb: https://git.kernel.org/tip/71c8e2a7c822ee557b07d9bb49028dd269c87b2e
Author: Mark Rutland <mark.rutland(a)arm.com>
AuthorDate: Thu, 22 Aug 2024 11:23:08 +01:00
Committer: Thomas Gleixner <tglx(a)linutronix.de>
CommitterDate: Fri, 23 Aug 2024 12:45:45 +02:00
irqchip/gic-v3: Init SRE before poking sysregs
The GICv3 driver pokes GICv3 system registers in gic_prio_init() before
gic_cpu_sys_reg_init() ensures that GICv3 system registers have been
enabled by writing to ICC_SRE_EL1.SRE.
On arm64 this is benign as has_useable_gicv3_cpuif() runs earlier during
cpufeature detection, and this enables the GICv3 system registers.
On 32-bit arm when booting on an FVP using the boot-wrapper, the accesses
in gic_prio_init() end up being UNDEFINED and crashes the kernel during
boot.
This is a regression introduced by the addition of gic_prio_init().
Fix this by factoring out the SRE initialization into a new function and
calling it early in the three paths where SRE may not have been
initialized:
(1) gic_init_bases(), before the primary CPU pokes GICv3 sysregs in
gic_prio_init().
(2) gic_starting_cpu(), before secondary CPUs initialize GICv3 sysregs
in gic_cpu_init().
(3) gic_cpu_pm_notifier(), before CPUs re-initialize GICv3 sysregs in
gic_cpu_sys_reg_init().
Fixes: d447bf09a4013541 ("irqchip/gic-v3: Detect GICD_CTRL.DS and SCR_EL3.FIQ earlier")
Signed-off-by: Mark Rutland <mark.rutland(a)arm.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Reviewed-by: Marc Zyngier <maz(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/irqchip/irq-gic-v3.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index c19083b..74f21e0 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -1154,14 +1154,8 @@ static void gic_update_rdist_properties(void)
gic_data.rdists.has_vpend_valid_dirty ? "Valid+Dirty " : "");
}
-static void gic_cpu_sys_reg_init(void)
+static void gic_cpu_sys_reg_enable(void)
{
- int i, cpu = smp_processor_id();
- u64 mpidr = gic_cpu_to_affinity(cpu);
- u64 need_rss = MPIDR_RS(mpidr);
- bool group0;
- u32 pribits;
-
/*
* Need to check that the SRE bit has actually been set. If
* not, it means that SRE is disabled at EL2. We're going to
@@ -1172,6 +1166,16 @@ static void gic_cpu_sys_reg_init(void)
if (!gic_enable_sre())
pr_err("GIC: unable to set SRE (disabled at EL2), panic ahead\n");
+}
+
+static void gic_cpu_sys_reg_init(void)
+{
+ int i, cpu = smp_processor_id();
+ u64 mpidr = gic_cpu_to_affinity(cpu);
+ u64 need_rss = MPIDR_RS(mpidr);
+ bool group0;
+ u32 pribits;
+
pribits = gic_get_pribits();
group0 = gic_has_group0();
@@ -1333,6 +1337,7 @@ static int gic_check_rdist(unsigned int cpu)
static int gic_starting_cpu(unsigned int cpu)
{
+ gic_cpu_sys_reg_enable();
gic_cpu_init();
if (gic_dist_supports_lpis())
@@ -1498,6 +1503,7 @@ static int gic_cpu_pm_notifier(struct notifier_block *self,
if (cmd == CPU_PM_EXIT) {
if (gic_dist_security_disabled())
gic_enable_redist(true);
+ gic_cpu_sys_reg_enable();
gic_cpu_sys_reg_init();
} else if (cmd == CPU_PM_ENTER && gic_dist_security_disabled()) {
gic_write_grpen1(0);
@@ -2070,6 +2076,7 @@ static int __init gic_init_bases(phys_addr_t dist_phys_base,
gic_update_rdist_properties();
+ gic_cpu_sys_reg_enable();
gic_prio_init();
gic_dist_init();
gic_cpu_init();
The patch below does not apply to the 6.1-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>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y
git checkout FETCH_HEAD
git cherry-pick -x 14d069d92951a3e150c0a81f2ca3b93e54da913b
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024081950-amaze-wriggle-3057@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^..
Possible dependencies:
14d069d92951 ("i2c: tegra: Do not mark ACPI devices as irq safe")
4f5d68c85914 ("i2c: tegra: allow VI support to be compiled out")
a55efa7edf37 ("i2c: tegra: allow DVC support to be compiled out")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 14d069d92951a3e150c0a81f2ca3b93e54da913b Mon Sep 17 00:00:00 2001
From: Breno Leitao <leitao(a)debian.org>
Date: Tue, 13 Aug 2024 09:12:53 -0700
Subject: [PATCH] i2c: tegra: Do not mark ACPI devices as irq safe
On ACPI machines, the tegra i2c module encounters an issue due to a
mutex being called inside a spinlock. This leads to the following bug:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585
...
Call trace:
__might_sleep
__mutex_lock_common
mutex_lock_nested
acpi_subsys_runtime_resume
rpm_resume
tegra_i2c_xfer
The problem arises because during __pm_runtime_resume(), the spinlock
&dev->power.lock is acquired before rpm_resume() is called. Later,
rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on
mutexes, triggering the error.
To address this issue, devices on ACPI are now marked as not IRQ-safe,
considering the dependency of acpi_subsys_runtime_resume() on mutexes.
Fixes: bd2fdedbf2ba ("i2c: tegra: Add the ACPI support")
Cc: <stable(a)vger.kernel.org> # v5.17+
Co-developed-by: Michael van der Westhuizen <rmikey(a)meta.com>
Signed-off-by: Michael van der Westhuizen <rmikey(a)meta.com>
Signed-off-by: Breno Leitao <leitao(a)debian.org>
Reviewed-by: Dmitry Osipenko <digetx(a)gmail.com>
Reviewed-by: Andy Shevchenko <andy(a)kernel.org>
Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org>
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 85b31edc558d..1df5b4204142 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1802,9 +1802,9 @@ static int tegra_i2c_probe(struct platform_device *pdev)
* domain.
*
* VI I2C device shouldn't be marked as IRQ-safe because VI I2C won't
- * be used for atomic transfers.
+ * be used for atomic transfers. ACPI device is not IRQ safe also.
*/
- if (!IS_VI(i2c_dev))
+ if (!IS_VI(i2c_dev) && !has_acpi_companion(i2c_dev->dev))
pm_runtime_irq_safe(i2c_dev->dev);
pm_runtime_enable(i2c_dev->dev);