February 2025 - Linux-stable-mirror

by Lorenz Brun

Am Mo., 17. Feb. 2025 um 16:00 Uhr schrieb Lorenz Brun <lorenz(a)monogon.tech>: > > Hi everyone, > > Linux 6.12.14 (released today) contains a regression for XFS, causing > a kernel panic after just a few seconds of working with a > freshly-created (xfsprogs 6.9) XFS filesystem. I have not yet bisected > this because I wanted to get this report out ASAP but I'm going to do > that now. There are multiple associated stack traces, but all of them > have xfs_buf_offset as the faulting function. > > Example backtrace: > [ 31.745932] BUG: kernel NULL pointer dereference, address: 0000000000000098 > [ 31.746590] #PF: supervisor read access in kernel mode > [ 31.747072] #PF: error_code(0x0000) - not-present page > [ 31.747537] PGD 5bee067 P4D 5bee067 PUD 5bef067 PMD 0 > [ 31.748016] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI > [ 31.748459] CPU: 0 UID: 0 PID: 116 Comm: xfsaild/vda4 Not tainted > 6.12.14-metropolis #1 9b2470be3d7713b818a3236e4a2804dd9cbef735 > [ 31.749490] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), > BIOS 0.0.0 02/06/2015 > [ 31.750340] RIP: 0010:xfs_buf_offset+0x9/0x50 > [ 31.750823] Code: 08 5b e9 8a 2c c4 00 66 2e 0f 1f 84 00 00 00 00 > 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f > 44 00 00 <48> 8b 87 98 00 00 00 48 85 c0 75 2e 48 8b 87 00 01 00 00 48 > 89 f2 > [ 31.752775] RSP: 0018:ffffbf50c07abdb8 EFLAGS: 00010246 > [ 31.753343] RAX: 0000000000000002 RBX: ffff9c0985817d58 RCX: 0000000000000016 > [ 31.754103] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > [ 31.754734] RBP: 0000000000000000 R08: ffff9c09fb704000 R09: 00000000e0be9fc4 > [ 31.755396] R10: 0000000000000000 R11: ffff9c0985827df8 R12: ffff9c09fb57ff58 > [ 31.756078] R13: ffff9c0985817eb0 R14: ffff9c09fb704000 R15: ffff9c0985817f00 > [ 31.756764] FS: 0000000000000000(0000) GS:ffff9c09fc000000(0000) > knlGS:0000000000000000 > [ 31.757529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 31.758041] CR2: 0000000000000098 CR3: 0000000005b70000 CR4: 0000000000350ef0 > [ 31.758696] Call Trace: > [ 31.758940] <TASK> > [ 31.759172] ? __die+0x56/0x97 > [ 31.759473] ? page_fault_oops+0x15c/0x2d0 > [ 31.759853] ? exc_page_fault+0x4c5/0x790 > [ 31.760237] ? asm_exc_page_fault+0x26/0x30 > [ 31.760637] ? xfs_buf_offset+0x9/0x50 > [ 31.761002] ? srso_return_thunk+0x5/0x5f > [ 31.761409] xfs_qm_dqflush+0xd0/0x350 > [ 31.761799] xfs_qm_dquot_logitem_push+0xe9/0x140 > [ 31.762253] xfsaild+0x347/0xa10 > [ 31.762567] ? srso_return_thunk+0x5/0x5f > [ 31.762952] ? srso_return_thunk+0x5/0x5f > [ 31.763325] ? __pfx_xfsaild+0x10/0x10 > [ 31.763665] kthread+0xd2/0x100 > [ 31.763985] ? __pfx_kthread+0x10/0x10 > [ 31.764342] ret_from_fork+0x34/0x50 > [ 31.764675] ? __pfx_kthread+0x10/0x10 > [ 31.765029] ret_from_fork_asm+0x1a/0x30 > [ 31.765408] </TASK> > [ 31.765618] Modules linked in: kvm_amd > [ 31.765978] CR2: 0000000000000098 > [ 31.766297] ---[ end trace 0000000000000000 ]--- > [ 32.371004] RIP: 0010:xfs_buf_offset+0x9/0x50 > [ 32.371453] Code: 08 5b e9 8a 2c c4 00 66 2e 0f 1f 84 00 00 00 00 > 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f > 44 00 00 <48> 8b 87 98 00 00 00 48 85 c0 75 2e 48 8b 87 00 01 00 00 48 > 89 f2 > [ 32.373133] RSP: 0018:ffffbf50c07abdb8 EFLAGS: 00010246 > [ 32.373611] RAX: 0000000000000002 RBX: ffff9c0985817d58 RCX: 0000000000000016 > [ 32.374275] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 > [ 32.374921] RBP: 0000000000000000 R08: ffff9c09fb704000 R09: 00000000e0be9fc4 > [ 32.375720] R10: 0000000000000000 R11: ffff9c0985827df8 R12: ffff9c09fb57ff58 > [ 32.376376] R13: ffff9c0985817eb0 R14: ffff9c09fb704000 R15: ffff9c0985817f00 > [ 32.377027] FS: 0000000000000000(0000) GS:ffff9c09fc000000(0000) > knlGS:0000000000000000 > [ 32.377761] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 32.378292] CR2: 0000000000000098 CR3: 0000000005b70000 CR4: 0000000000350ef0 > [ 32.378940] Kernel panic - not syncing: Fatal exception > [ 32.379492] Kernel Offset: 0x2a600000 from 0xffffffff81000000 > (relocation range: 0xffffffff80000000-0xffffffffbfffffff) > > #regzbot introduced: v6.12.13..v6.12.14 > > Regards, > Lorenz Hi everyone, I root-caused this to 5808d420 ("xfs: attach dquot buffer to dquot log item buffer"), but needs reverting of the 3 follow-up commits (d331fc15, ee6984a2 and 84307caf) as well as they depend on the broken one. With that 6.12.14 passes our test suite again. Reproduction should be rather easy by just creating a fresh filesystem, mounting with "prjquota" and performing I/O. Regards, Lorenz

8 months, 1 week

3
4
0 0

[PATCH AUTOSEL 5.4 1/3] HID: intel-ish-hid: fix the length of MNG_SYNC_FW_CLOCK in doorbell

by Sasha Levin

From: Zhang Lixu <lixu.zhang(a)intel.com> [ Upstream commit 4b54ae69197b9f416baa0fceadff7e89075f8454 ] The timestamps in the Firmware log and HID sensor samples are incorrect. They show 1970-01-01 because the current IPC driver only uses the first 8 bytes of bootup time when synchronizing time with the firmware. The firmware converts the bootup time to UTC time, which results in the display of 1970-01-01. In write_ipc_from_queue(), when sending the MNG_SYNC_FW_CLOCK message, the clock is updated according to the definition of ipc_time_update_msg. However, in _ish_sync_fw_clock(), the message length is specified as the size of uint64_t when building the doorbell. As a result, the firmware only receives the first 8 bytes of struct ipc_time_update_msg. This patch corrects the length in the doorbell to ensure the entire ipc_time_update_msg is sent, fixing the timestamp issue. Signed-off-by: Zhang Lixu <lixu.zhang(a)intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/intel-ish-hid/ipc/ipc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c index 8f8dfdf64833e..871f043eeba1e 100644 --- a/drivers/hid/intel-ish-hid/ipc/ipc.c +++ b/drivers/hid/intel-ish-hid/ipc/ipc.c @@ -549,14 +549,14 @@ static void fw_reset_work_fn(struct work_struct *unused) static void _ish_sync_fw_clock(struct ishtp_device *dev) { static unsigned long prev_sync; - uint64_t usec; + struct ipc_time_update_msg time = {}; if (prev_sync && jiffies - prev_sync < 20 * HZ) return; prev_sync = jiffies; - usec = ktime_to_us(ktime_get_boottime()); - ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &usec, sizeof(uint64_t)); + /* The fields of time would be updated while sending message */ + ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &time, sizeof(time)); } /** -- 2.39.5

8 months, 1 week

1
2
0 0

[PATCH AUTOSEL 5.10 1/4] HID: intel-ish-hid: fix the length of MNG_SYNC_FW_CLOCK in doorbell

by Sasha Levin

From: Zhang Lixu <lixu.zhang(a)intel.com> [ Upstream commit 4b54ae69197b9f416baa0fceadff7e89075f8454 ] The timestamps in the Firmware log and HID sensor samples are incorrect. They show 1970-01-01 because the current IPC driver only uses the first 8 bytes of bootup time when synchronizing time with the firmware. The firmware converts the bootup time to UTC time, which results in the display of 1970-01-01. In write_ipc_from_queue(), when sending the MNG_SYNC_FW_CLOCK message, the clock is updated according to the definition of ipc_time_update_msg. However, in _ish_sync_fw_clock(), the message length is specified as the size of uint64_t when building the doorbell. As a result, the firmware only receives the first 8 bytes of struct ipc_time_update_msg. This patch corrects the length in the doorbell to ensure the entire ipc_time_update_msg is sent, fixing the timestamp issue. Signed-off-by: Zhang Lixu <lixu.zhang(a)intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/intel-ish-hid/ipc/ipc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c index a45ac7fa417b9..da896f5c74424 100644 --- a/drivers/hid/intel-ish-hid/ipc/ipc.c +++ b/drivers/hid/intel-ish-hid/ipc/ipc.c @@ -549,14 +549,14 @@ static void fw_reset_work_fn(struct work_struct *unused) static void _ish_sync_fw_clock(struct ishtp_device *dev) { static unsigned long prev_sync; - uint64_t usec; + struct ipc_time_update_msg time = {}; if (prev_sync && jiffies - prev_sync < 20 * HZ) return; prev_sync = jiffies; - usec = ktime_to_us(ktime_get_boottime()); - ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &usec, sizeof(uint64_t)); + /* The fields of time would be updated while sending message */ + ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &time, sizeof(time)); } /** -- 2.39.5

8 months, 1 week

1
3
0 0

[PATCH AUTOSEL 5.15 1/6] HID: intel-ish-hid: fix the length of MNG_SYNC_FW_CLOCK in doorbell

by Sasha Levin

From: Zhang Lixu <lixu.zhang(a)intel.com> [ Upstream commit 4b54ae69197b9f416baa0fceadff7e89075f8454 ] The timestamps in the Firmware log and HID sensor samples are incorrect. They show 1970-01-01 because the current IPC driver only uses the first 8 bytes of bootup time when synchronizing time with the firmware. The firmware converts the bootup time to UTC time, which results in the display of 1970-01-01. In write_ipc_from_queue(), when sending the MNG_SYNC_FW_CLOCK message, the clock is updated according to the definition of ipc_time_update_msg. However, in _ish_sync_fw_clock(), the message length is specified as the size of uint64_t when building the doorbell. As a result, the firmware only receives the first 8 bytes of struct ipc_time_update_msg. This patch corrects the length in the doorbell to ensure the entire ipc_time_update_msg is sent, fixing the timestamp issue. Signed-off-by: Zhang Lixu <lixu.zhang(a)intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/intel-ish-hid/ipc/ipc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c index ba45605fc6b52..a48f7cd514b0f 100644 --- a/drivers/hid/intel-ish-hid/ipc/ipc.c +++ b/drivers/hid/intel-ish-hid/ipc/ipc.c @@ -577,14 +577,14 @@ static void fw_reset_work_fn(struct work_struct *unused) static void _ish_sync_fw_clock(struct ishtp_device *dev) { static unsigned long prev_sync; - uint64_t usec; + struct ipc_time_update_msg time = {}; if (prev_sync && jiffies - prev_sync < 20 * HZ) return; prev_sync = jiffies; - usec = ktime_to_us(ktime_get_boottime()); - ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &usec, sizeof(uint64_t)); + /* The fields of time would be updated while sending message */ + ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &time, sizeof(time)); } /** -- 2.39.5

8 months, 1 week

1
5
0 0

[PATCH AUTOSEL 6.1 01/13] HID: intel-ish-hid: fix the length of MNG_SYNC_FW_CLOCK in doorbell

by Sasha Levin

From: Zhang Lixu <lixu.zhang(a)intel.com> [ Upstream commit 4b54ae69197b9f416baa0fceadff7e89075f8454 ] The timestamps in the Firmware log and HID sensor samples are incorrect. They show 1970-01-01 because the current IPC driver only uses the first 8 bytes of bootup time when synchronizing time with the firmware. The firmware converts the bootup time to UTC time, which results in the display of 1970-01-01. In write_ipc_from_queue(), when sending the MNG_SYNC_FW_CLOCK message, the clock is updated according to the definition of ipc_time_update_msg. However, in _ish_sync_fw_clock(), the message length is specified as the size of uint64_t when building the doorbell. As a result, the firmware only receives the first 8 bytes of struct ipc_time_update_msg. This patch corrects the length in the doorbell to ensure the entire ipc_time_update_msg is sent, fixing the timestamp issue. Signed-off-by: Zhang Lixu <lixu.zhang(a)intel.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/hid/intel-ish-hid/ipc/ipc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c b/drivers/hid/intel-ish-hid/ipc/ipc.c index dd5fc60874ba1..b1a41c90c5741 100644 --- a/drivers/hid/intel-ish-hid/ipc/ipc.c +++ b/drivers/hid/intel-ish-hid/ipc/ipc.c @@ -577,14 +577,14 @@ static void fw_reset_work_fn(struct work_struct *unused) static void _ish_sync_fw_clock(struct ishtp_device *dev) { static unsigned long prev_sync; - uint64_t usec; + struct ipc_time_update_msg time = {}; if (prev_sync && time_before(jiffies, prev_sync + 20 * HZ)) return; prev_sync = jiffies; - usec = ktime_to_us(ktime_get_boottime()); - ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &usec, sizeof(uint64_t)); + /* The fields of time would be updated while sending message */ + ipc_send_mng_msg(dev, MNG_SYNC_FW_CLOCK, &time, sizeof(time)); } /** -- 2.39.5

8 months, 1 week

1
12
0 0

[PATCH AUTOSEL 6.12 01/31] sched_ext: selftests/dsp_local_on: Fix sporadic failures

by Sasha Levin

From: Tejun Heo <tj(a)kernel.org> [ Upstream commit e9fe182772dcb2630964724fd93e9c90b68ea0fd ] dsp_local_on has several incorrect assumptions, one of which is that p->nr_cpus_allowed always tracks p->cpus_ptr. This is not true when a task is scheduled out while migration is disabled - p->cpus_ptr is temporarily overridden to the previous CPU while p->nr_cpus_allowed remains unchanged. This led to sporadic test faliures when dsp_local_on_dispatch() tries to put a migration disabled task to a different CPU. Fix it by keeping the previous CPU when migration is disabled. There are SCX schedulers that make use of p->nr_cpus_allowed. They should also implement explicit handling for p->migration_disabled. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Ihor Solodrai <ihor.solodrai(a)pm.me> Cc: Andrea Righi <arighi(a)nvidia.com> Cc: Changwoo Min <changwoo(a)igalia.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/sched_ext/dsp_local_on.bpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c b/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c index c9a2da0575a0f..eea06decb6f59 100644 --- a/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c +++ b/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c @@ -43,7 +43,7 @@ void BPF_STRUCT_OPS(dsp_local_on_dispatch, s32 cpu, struct task_struct *prev) if (!p) return; - if (p->nr_cpus_allowed == nr_cpus) + if (p->nr_cpus_allowed == nr_cpus && !p->migration_disabled) target = bpf_get_prandom_u32() % nr_cpus; else target = scx_bpf_task_cpu(p); -- 2.39.5

8 months, 1 week

1
30
0 0

[PATCH AUTOSEL 6.13 01/31] sched_ext: selftests/dsp_local_on: Fix sporadic failures

by Sasha Levin

From: Tejun Heo <tj(a)kernel.org> [ Upstream commit e9fe182772dcb2630964724fd93e9c90b68ea0fd ] dsp_local_on has several incorrect assumptions, one of which is that p->nr_cpus_allowed always tracks p->cpus_ptr. This is not true when a task is scheduled out while migration is disabled - p->cpus_ptr is temporarily overridden to the previous CPU while p->nr_cpus_allowed remains unchanged. This led to sporadic test faliures when dsp_local_on_dispatch() tries to put a migration disabled task to a different CPU. Fix it by keeping the previous CPU when migration is disabled. There are SCX schedulers that make use of p->nr_cpus_allowed. They should also implement explicit handling for p->migration_disabled. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Ihor Solodrai <ihor.solodrai(a)pm.me> Cc: Andrea Righi <arighi(a)nvidia.com> Cc: Changwoo Min <changwoo(a)igalia.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/sched_ext/dsp_local_on.bpf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c b/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c index fbda6bf546712..758b479bd1ee1 100644 --- a/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c +++ b/tools/testing/selftests/sched_ext/dsp_local_on.bpf.c @@ -43,7 +43,7 @@ void BPF_STRUCT_OPS(dsp_local_on_dispatch, s32 cpu, struct task_struct *prev) if (!p) return; - if (p->nr_cpus_allowed == nr_cpus) + if (p->nr_cpus_allowed == nr_cpus && !p->migration_disabled) target = bpf_get_prandom_u32() % nr_cpus; else target = scx_bpf_task_cpu(p); -- 2.39.5

8 months, 1 week

1
30
0 0

[PATCH v3] HID: corsair-void: Update power supply values with a unified work handler

by Stuart Hayhurst

corsair_void_process_receiver can be called from an interrupt context, locking battery_mutex in it was causing a kernel panic. Fix it by moving the critical section into its own work, sharing this work with battery_add_work and battery_remove_work to remove the need for any locking Closes: https://bugzilla.suse.com/show_bug.cgi?id=1236843 Fixes: 6ea2a6fd3872 ("HID: corsair-void: Add Corsair Void headset family driver") Cc: stable(a)vger.kernel.org Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst(a)gmail.com> --- v2 -> v3: - Use an enum instead of a define for battery flag values - Use an integer instead of BIT() for the bit index - Drop unhelpful comments - Simplify corsair_void_battery_work_handler logic - Remove extra newline in commit message v1 -> v2: - Actually remove the mutex --- drivers/hid/hid-corsair-void.c | 83 ++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 40 deletions(-) diff --git a/drivers/hid/hid-corsair-void.c b/drivers/hid/hid-corsair-void.c index 56e858066c3c..afbd67aa9719 100644 --- a/drivers/hid/hid-corsair-void.c +++ b/drivers/hid/hid-corsair-void.c @@ -71,11 +71,9 @@ #include <linux/bitfield.h> #include <linux/bitops.h> -#include <linux/cleanup.h> #include <linux/device.h> #include <linux/hid.h> #include <linux/module.h> -#include <linux/mutex.h> #include <linux/power_supply.h> #include <linux/usb.h> #include <linux/workqueue.h> @@ -120,6 +118,12 @@ enum { CORSAIR_VOID_BATTERY_CHARGING = 5, }; +enum { + CORSAIR_VOID_ADD_BATTERY = 0, + CORSAIR_VOID_REMOVE_BATTERY = 1, + CORSAIR_VOID_UPDATE_BATTERY = 2, +}; + static enum power_supply_property corsair_void_battery_props[] = { POWER_SUPPLY_PROP_STATUS, POWER_SUPPLY_PROP_PRESENT, @@ -155,12 +159,12 @@ struct corsair_void_drvdata { struct power_supply *battery; struct power_supply_desc battery_desc; - struct mutex battery_mutex; struct delayed_work delayed_status_work; struct delayed_work delayed_firmware_work; - struct work_struct battery_remove_work; - struct work_struct battery_add_work; + + unsigned long battery_work_flags; + struct work_struct battery_work; }; /* @@ -260,11 +264,9 @@ static void corsair_void_process_receiver(struct corsair_void_drvdata *drvdata, /* Inform power supply if battery values changed */ if (memcmp(&orig_battery_data, battery_data, sizeof(*battery_data))) { - scoped_guard(mutex, &drvdata->battery_mutex) { - if (drvdata->battery) { - power_supply_changed(drvdata->battery); - } - } + set_bit(CORSAIR_VOID_UPDATE_BATTERY, + &drvdata->battery_work_flags); + schedule_work(&drvdata->battery_work); } } @@ -536,29 +538,11 @@ static void corsair_void_firmware_work_handler(struct work_struct *work) } -static void corsair_void_battery_remove_work_handler(struct work_struct *work) -{ - struct corsair_void_drvdata *drvdata; - - drvdata = container_of(work, struct corsair_void_drvdata, - battery_remove_work); - scoped_guard(mutex, &drvdata->battery_mutex) { - if (drvdata->battery) { - power_supply_unregister(drvdata->battery); - drvdata->battery = NULL; - } - } -} - -static void corsair_void_battery_add_work_handler(struct work_struct *work) +static void corsair_void_add_battery(struct corsair_void_drvdata *drvdata) { - struct corsair_void_drvdata *drvdata; struct power_supply_config psy_cfg = {}; struct power_supply *new_supply; - drvdata = container_of(work, struct corsair_void_drvdata, - battery_add_work); - guard(mutex)(&drvdata->battery_mutex); if (drvdata->battery) return; @@ -583,16 +567,42 @@ static void corsair_void_battery_add_work_handler(struct work_struct *work) drvdata->battery = new_supply; } +static void corsair_void_battery_work_handler(struct work_struct *work) +{ + struct corsair_void_drvdata *drvdata = container_of(work, + struct corsair_void_drvdata, battery_work); + + bool add_battery = test_and_clear_bit(CORSAIR_VOID_ADD_BATTERY, + &drvdata->battery_work_flags); + bool remove_battery = test_and_clear_bit(CORSAIR_VOID_REMOVE_BATTERY, + &drvdata->battery_work_flags); + bool update_battery = test_and_clear_bit(CORSAIR_VOID_UPDATE_BATTERY, + &drvdata->battery_work_flags); + + if (add_battery && !remove_battery) { + corsair_void_add_battery(drvdata); + } else if (remove_battery && !add_battery && drvdata->battery) { + power_supply_unregister(drvdata->battery); + drvdata->battery = NULL; + } + + if (update_battery && drvdata->battery) + power_supply_changed(drvdata->battery); + +} + static void corsair_void_headset_connected(struct corsair_void_drvdata *drvdata) { - schedule_work(&drvdata->battery_add_work); + set_bit(CORSAIR_VOID_ADD_BATTERY, &drvdata->battery_work_flags); + schedule_work(&drvdata->battery_work); schedule_delayed_work(&drvdata->delayed_firmware_work, msecs_to_jiffies(100)); } static void corsair_void_headset_disconnected(struct corsair_void_drvdata *drvdata) { - schedule_work(&drvdata->battery_remove_work); + set_bit(CORSAIR_VOID_REMOVE_BATTERY, &drvdata->battery_work_flags); + schedule_work(&drvdata->battery_work); corsair_void_set_unknown_wireless_data(drvdata); corsair_void_set_unknown_batt(drvdata); @@ -678,13 +688,7 @@ static int corsair_void_probe(struct hid_device *hid_dev, drvdata->battery_desc.get_property = corsair_void_battery_get_property; drvdata->battery = NULL; - INIT_WORK(&drvdata->battery_remove_work, - corsair_void_battery_remove_work_handler); - INIT_WORK(&drvdata->battery_add_work, - corsair_void_battery_add_work_handler); - ret = devm_mutex_init(drvdata->dev, &drvdata->battery_mutex); - if (ret) - return ret; + INIT_WORK(&drvdata->battery_work, corsair_void_battery_work_handler); ret = sysfs_create_group(&hid_dev->dev.kobj, &corsair_void_attr_group); if (ret) @@ -721,8 +725,7 @@ static void corsair_void_remove(struct hid_device *hid_dev) struct corsair_void_drvdata *drvdata = hid_get_drvdata(hid_dev); hid_hw_stop(hid_dev); - cancel_work_sync(&drvdata->battery_remove_work); - cancel_work_sync(&drvdata->battery_add_work); + cancel_work_sync(&drvdata->battery_work); if (drvdata->battery) power_supply_unregister(drvdata->battery); -- 2.47.2

8 months, 1 week

4
4
0 0

[PATCH RFC 2/2] usb: typec: ucsi: increase timeout for PPM reset operations

by Fedor Pchelkin

It is observed that on some systems an initial PPM reset during the boot phase can trigger a timeout: [ 6.482546] ucsi_acpi USBC000:00: failed to reset PPM! [ 6.482551] ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed Still, increasing the timeout value, albeit being the most straightforward solution, eliminates the problem: the initial PPM reset may take up to ~8000-10000ms on some Lenovo laptops. When it is reset after the above period of time (or even if ucsi_reset_ppm() is not called overall), UCSI works as expected. Moreover, if the ucsi_acpi module is loaded/unloaded manually after the system has booted, reading the CCI values and resetting the PPM works perfectly, without any timeout. Thus it's only a boot-time issue. The reason for this behavior is not clear but it may be the consequence of some tricks that the firmware performs or be an actual firmware bug. As a workaround, increase the timeout to avoid failing the UCSI initialization prematurely. Fixes: b1b59e16075f ("usb: typec: ucsi: Increase command completion timeout value") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <boddah8794(a)gmail.com> --- drivers/usb/typec/ucsi/ucsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c index 0fe1476f4c29..7a56d3f840d7 100644 --- a/drivers/usb/typec/ucsi/ucsi.c +++ b/drivers/usb/typec/ucsi/ucsi.c @@ -25,7 +25,7 @@ * difficult to estimate the time it takes for the system to process the command * before it is actually passed to the PPM. */ -#define UCSI_TIMEOUT_MS 5000 +#define UCSI_TIMEOUT_MS 10000 /* * UCSI_SWAP_TIMEOUT_MS - Timeout for role swap requests -- 2.48.1

8 months, 1 week

4
5
0 0

[PATCH vhost] vdpa/mlx5: Fix oversized null mkey longer than 32bit

by Dragos Tatulea

From: Si-Wei Liu <si-wei.liu(a)oracle.com> create_user_mr() has correct code to count the number of null keys used to fill in a hole for the memory map. However, fill_indir() does not follow the same to cap the range up to the 1GB limit correspondinly. Fill in more null keys for the gaps in between, so that null keys are correctly populated. Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code") Cc: stable(a)vger.kernel.org Signed-off-by: Si-Wei Liu <si-wei.liu(a)oracle.com> Signed-off-by: Dragos Tatulea <dtatulea(a)nvidia.com> --- drivers/vdpa/mlx5/core/mr.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c index 8455f08f5d40..61424342c096 100644 --- a/drivers/vdpa/mlx5/core/mr.c +++ b/drivers/vdpa/mlx5/core/mr.c @@ -190,9 +190,12 @@ static void fill_indir(struct mlx5_vdpa_dev *mvdev, struct mlx5_vdpa_mr *mkey, v klm->bcount = cpu_to_be32(klm_bcount(dmr->end - dmr->start)); preve = dmr->end; } else { + u64 bcount = min_t(u64, dmr->start - preve, MAX_KLM_SIZE); + klm->key = cpu_to_be32(mvdev->res.null_mkey); - klm->bcount = cpu_to_be32(klm_bcount(dmr->start - preve)); - preve = dmr->start; + klm->bcount = cpu_to_be32(klm_bcount(bcount)); + preve += bcount; + goto again; } } -- 2.43.0

8 months, 1 week

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025