December 2024 - Linux-stable-mirror

[PATCH] HID: wacom: Initialize brightness of LED trigger

by Gerecke, Jason

From: Jason Gerecke <jason.gerecke(a)wacom.com> If an LED has a default_trigger set prior to being registered with the subsystem, that trigger will be executed with a brightness value defined by `trigger->brightness`. Our driver was not setting this value, which was causing problems. It would cause the selected LED to be turned off, as well as corrupt the hlv/llv values assigned to other LEDs (since calling `wacom_led_brightness_set` will overite these values). This patch sets the value of `trigger->brightness` to an appropriate value. We use `wacom_leds_brightness_get` to transform the llv/hlv values into a brightness that is understood by the rest of the LED subsystem. Fixes: 822c91e72eac ("leds: trigger: Store brightness set by led_trigger_event()") Cc: stable(a)vger.kernel.org # v6.10+ Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com> --- drivers/hid/wacom_sys.c | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c index 2bc45b24075c3..e60ca39ac7adc 100644 --- a/drivers/hid/wacom_sys.c +++ b/drivers/hid/wacom_sys.c @@ -1370,17 +1370,6 @@ static int wacom_led_register_one(struct device *dev, struct wacom *wacom, if (!name) return -ENOMEM; - if (!read_only) { - led->trigger.name = name; - error = devm_led_trigger_register(dev, &led->trigger); - if (error) { - hid_err(wacom->hdev, - "failed to register LED trigger %s: %d\n", - led->cdev.name, error); - return error; - } - } - led->group = group; led->id = id; led->wacom = wacom; @@ -1397,6 +1386,19 @@ static int wacom_led_register_one(struct device *dev, struct wacom *wacom, led->cdev.brightness_set = wacom_led_readonly_brightness_set; } + if (!read_only) { + led->trigger.name = name; + if (id == wacom->led.groups[group].select) + led->trigger.brightness = wacom_leds_brightness_get(led); + error = devm_led_trigger_register(dev, &led->trigger); + if (error) { + hid_err(wacom->hdev, + "failed to register LED trigger %s: %d\n", + led->cdev.name, error); + return error; + } + } + error = devm_led_classdev_register(dev, &led->cdev); if (error) { hid_err(wacom->hdev, -- 2.47.1

10 months, 1 week

2
1
0 0

[PATCH] spi: spi-mem: check the dummy buswidth only for rx mode

by haibo.chen＠nxp.com

From: Haibo Chen <haibo.chen(a)nxp.com> Dummy usually used for rx, so combine the dummy buswidth check only for rx mode. Find issue after commit 98d1fb94ce75 ("mtd: spi-nor: core: replace dummy buswidth from addr to data") on imx8mn-ddr4-evk board. On this board, rx=4, tx=1, without the upper commit, chose SNOR_CMD_READ_1_1_4, after this commit, chose SNOR_CMD_READ(1_1_1). This is because when dummy buswidth = 4, spi_check_buswidth_req(mem, op->dummy.buswidth, true) do not return the expected result. Combine the cmd.buswidth and addr.buswidth check to tx is reasonable, but for dummy buswidth, need to check the rx mode. Fixes: c36ff266dc82 ("spi: Extend the core to ease integration of SPI memory controllers") Cc: stable(a)vger.kernel.org Signed-off-by: Haibo Chen <haibo.chen(a)nxp.com> --- drivers/spi/spi-mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index abc6792e738c..bc9f09a9e5a0 100644 --- a/drivers/spi/spi-mem.c +++ b/drivers/spi/spi-mem.c @@ -150,7 +150,7 @@ static bool spi_mem_check_buswidth(struct spi_mem *mem, return false; if (op->dummy.nbytes && - spi_check_buswidth_req(mem, op->dummy.buswidth, true)) + spi_check_buswidth_req(mem, op->dummy.buswidth, false)) return false; if (op->data.dir != SPI_MEM_NO_DATA && -- 2.34.1

10 months, 1 week

1
0
0 0

[PATCH] btrfs: output the reason for open_ctree() failure

by Qu Wenruo

There is a recent ML report that mounting a large fs backed by hardware RAID56 controller (with one device missing) took too much time, and systemd seems to kill the mount attempt. In that case, the only error message is: BTRFS error (device sdj): open_ctree failed There is no reason on why the failure happened, making it very hard to understand the reason. At least output the error number (in the particular case it should be -EINTR) to provide some clue. Link: https://lore.kernel.org/linux-btrfs/9b9c4d2810abcca2f9f76e32220ed9a90febb23… Reported-by: Christoph Anton Mitterer <calestyo(a)scientia.org> Cc: stable(a)vger.kernel.org Signed-off-by: Qu Wenruo <wqu(a)suse.com> --- fs/btrfs/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c index 7dfe5005129a..f6eaaf20229d 100644 --- a/fs/btrfs/super.c +++ b/fs/btrfs/super.c @@ -971,7 +971,7 @@ static int btrfs_fill_super(struct super_block *sb, err = open_ctree(sb, fs_devices); if (err) { - btrfs_err(fs_info, "open_ctree failed"); + btrfs_err(fs_info, "open_ctree failed: %d", err); return err; } -- 2.47.1

10 months, 1 week

2
1
0 0

[PATCH 0/8] of/irq: fix bugs

by Zijun Hu

This patch series is to fix bugs in drivers/of/irq.c Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- Zijun Hu (8): of/irq: Fix wrong value of variable @len in of_irq_parse_imap_parent() of/irq: Correct element count for array @dummy_imask in API of_irq_parse_raw() of/irq: Fix device node refcount leakage in API of_irq_parse_raw() of/irq: Fix using uninitialized variable @addr_len in API of_irq_parse_one() of/irq: Fix device node refcount leakage in API of_irq_parse_one() of/irq: Fix device node refcount leakages in of_irq_count() of/irq: Fix device node refcount leakages in of_irq_init() of/irq: Fix device node refcount leakage in API irq_of_parse_and_map() drivers/of/irq.c | 30 +++++++++++++++++++++++++----- 1 file changed, 25 insertions(+), 5 deletions(-) --- base-commit: 16ef9c9de0c48b836c5996c6e9792cb4f658c8f1 change-id: 20241208-of_irq_fix-659514bc9aa3 Best regards, -- Zijun Hu <quic_zijuhu(a)quicinc.com>

10 months, 1 week

2
12
0 0

[PATCH] drm/panic: remove spurious empty line to clean warning

by Miguel Ojeda

Clippy in the upcoming Rust 1.83.0 spots a spurious empty line since the `clippy::empty_line_after_doc_comments` warning is now enabled by default given it is part of the `suspicious` group [1]: error: empty line after doc comment --> drivers/gpu/drm/drm_panic_qr.rs:931:1 | 931 | / /// They must remain valid for the duration of the function call. 932 | | | |_ 933 | #[no_mangle] 934 | / pub unsafe extern "C" fn drm_panic_qr_generate( 935 | | url: *const i8, 936 | | data: *mut u8, 937 | | data_len: usize, ... | 940 | | tmp_size: usize, 941 | | ) -> u8 { | |_______- the comment documents this function | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#empty_line_after_… = note: `-D clippy::empty-line-after-doc-comments` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::empty_line_after_doc_comments)]` = help: if the empty line is unintentional remove it Thus remove the empty line. Cc: stable(a)vger.kernel.org Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Link: https://github.com/rust-lang/rust-clippy/pull/13091 [1] Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- I added the Fixes and stable tags since it would be nice to keep the 6.12 LTS Clippy-clean (since that one is the first that supports several Rust compilers). drivers/gpu/drm/drm_panic_qr.rs | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/drm_panic_qr.rs b/drivers/gpu/drm/drm_panic_qr.rs index 09500cddc009..ef2d490965ba 100644 --- a/drivers/gpu/drm/drm_panic_qr.rs +++ b/drivers/gpu/drm/drm_panic_qr.rs @@ -929,7 +929,6 @@ fn draw_all(&mut self, data: impl Iterator<Item = u8>) { /// * `tmp` must be valid for reading and writing for `tmp_size` bytes. /// /// They must remain valid for the duration of the function call. - #[no_mangle] pub unsafe extern "C" fn drm_panic_qr_generate( url: *const i8, base-commit: b7ed2b6f4e8d7f64649795e76ee9db67300de8eb -- 2.47.0

10 months, 1 week

4
6
0 0

FAILED: patch "[PATCH] x86/kexec: Restore GDT on return from ::preserve_context" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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-5.4.y git checkout FETCH_HEAD git cherry-pick -x 07fa619f2a40c221ea27747a3323cabc59ab25eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121049-attire-ramble-432b@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 07fa619f2a40c221ea27747a3323cabc59ab25eb Mon Sep 17 00:00:00 2001 From: David Woodhouse <dwmw(a)amazon.co.uk> Date: Thu, 5 Dec 2024 15:05:07 +0000 Subject: [PATCH] x86/kexec: Restore GDT on return from ::preserve_context kexec The restore_processor_state() function explicitly states that "the asm code that gets us here will have restored a usable GDT". That wasn't true in the case of returning from a ::preserve_context kexec. Make it so. Without this, the kernel was depending on the called function to reload a GDT which is appropriate for the kernel before returning. Test program: #include <unistd.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <linux/kexec.h> #include <linux/reboot.h> #include <sys/reboot.h> #include <sys/syscall.h> int main (void) { struct kexec_segment segment = {}; unsigned char purgatory[] = { 0x66, 0xba, 0xf8, 0x03, // mov $0x3f8, %dx 0xb0, 0x42, // mov $0x42, %al 0xee, // outb %al, (%dx) 0xc3, // ret }; int ret; segment.buf = &purgatory; segment.bufsz = sizeof(purgatory); segment.mem = (void *)0x400000; segment.memsz = 0x1000; ret = syscall(__NR_kexec_load, 0x400000, 1, &segment, KEXEC_PRESERVE_CONTEXT); if (ret) { perror("kexec_load"); exit(1); } ret = syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KEXEC); if (ret) { perror("kexec reboot"); exit(1); } printf("Success\n"); return 0; } Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20241205153343.3275139-2-dwmw2@infradead.org diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S index e9e88c342f75..1236f25fc8d1 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -242,6 +242,13 @@ SYM_CODE_START_LOCAL_NOALIGN(virtual_mapped) movq CR0(%r8), %r8 movq %rax, %cr3 movq %r8, %cr0 + +#ifdef CONFIG_KEXEC_JUMP + /* Saved in save_processor_state. */ + movq $saved_context, %rax + lgdt saved_context_gdt_desc(%rax) +#endif + movq %rbp, %rax popf

10 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] x86/kexec: Restore GDT on return from ::preserve_context" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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-5.10.y git checkout FETCH_HEAD git cherry-pick -x 07fa619f2a40c221ea27747a3323cabc59ab25eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121048-dreamlike-devourer-7135@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 07fa619f2a40c221ea27747a3323cabc59ab25eb Mon Sep 17 00:00:00 2001 From: David Woodhouse <dwmw(a)amazon.co.uk> Date: Thu, 5 Dec 2024 15:05:07 +0000 Subject: [PATCH] x86/kexec: Restore GDT on return from ::preserve_context kexec The restore_processor_state() function explicitly states that "the asm code that gets us here will have restored a usable GDT". That wasn't true in the case of returning from a ::preserve_context kexec. Make it so. Without this, the kernel was depending on the called function to reload a GDT which is appropriate for the kernel before returning. Test program: #include <unistd.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <linux/kexec.h> #include <linux/reboot.h> #include <sys/reboot.h> #include <sys/syscall.h> int main (void) { struct kexec_segment segment = {}; unsigned char purgatory[] = { 0x66, 0xba, 0xf8, 0x03, // mov $0x3f8, %dx 0xb0, 0x42, // mov $0x42, %al 0xee, // outb %al, (%dx) 0xc3, // ret }; int ret; segment.buf = &purgatory; segment.bufsz = sizeof(purgatory); segment.mem = (void *)0x400000; segment.memsz = 0x1000; ret = syscall(__NR_kexec_load, 0x400000, 1, &segment, KEXEC_PRESERVE_CONTEXT); if (ret) { perror("kexec_load"); exit(1); } ret = syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KEXEC); if (ret) { perror("kexec reboot"); exit(1); } printf("Success\n"); return 0; } Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20241205153343.3275139-2-dwmw2@infradead.org diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S index e9e88c342f75..1236f25fc8d1 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -242,6 +242,13 @@ SYM_CODE_START_LOCAL_NOALIGN(virtual_mapped) movq CR0(%r8), %r8 movq %rax, %cr3 movq %r8, %cr0 + +#ifdef CONFIG_KEXEC_JUMP + /* Saved in save_processor_state. */ + movq $saved_context, %rax + lgdt saved_context_gdt_desc(%rax) +#endif + movq %rbp, %rax popf

10 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] x86/kexec: Restore GDT on return from ::preserve_context" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-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-5.15.y git checkout FETCH_HEAD git cherry-pick -x 07fa619f2a40c221ea27747a3323cabc59ab25eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121047-pushing-trouble-cc13@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 07fa619f2a40c221ea27747a3323cabc59ab25eb Mon Sep 17 00:00:00 2001 From: David Woodhouse <dwmw(a)amazon.co.uk> Date: Thu, 5 Dec 2024 15:05:07 +0000 Subject: [PATCH] x86/kexec: Restore GDT on return from ::preserve_context kexec The restore_processor_state() function explicitly states that "the asm code that gets us here will have restored a usable GDT". That wasn't true in the case of returning from a ::preserve_context kexec. Make it so. Without this, the kernel was depending on the called function to reload a GDT which is appropriate for the kernel before returning. Test program: #include <unistd.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <linux/kexec.h> #include <linux/reboot.h> #include <sys/reboot.h> #include <sys/syscall.h> int main (void) { struct kexec_segment segment = {}; unsigned char purgatory[] = { 0x66, 0xba, 0xf8, 0x03, // mov $0x3f8, %dx 0xb0, 0x42, // mov $0x42, %al 0xee, // outb %al, (%dx) 0xc3, // ret }; int ret; segment.buf = &purgatory; segment.bufsz = sizeof(purgatory); segment.mem = (void *)0x400000; segment.memsz = 0x1000; ret = syscall(__NR_kexec_load, 0x400000, 1, &segment, KEXEC_PRESERVE_CONTEXT); if (ret) { perror("kexec_load"); exit(1); } ret = syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KEXEC); if (ret) { perror("kexec reboot"); exit(1); } printf("Success\n"); return 0; } Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20241205153343.3275139-2-dwmw2@infradead.org diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S index e9e88c342f75..1236f25fc8d1 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -242,6 +242,13 @@ SYM_CODE_START_LOCAL_NOALIGN(virtual_mapped) movq CR0(%r8), %r8 movq %rax, %cr3 movq %r8, %cr0 + +#ifdef CONFIG_KEXEC_JUMP + /* Saved in save_processor_state. */ + movq $saved_context, %rax + lgdt saved_context_gdt_desc(%rax) +#endif + movq %rbp, %rax popf

10 months, 1 week

1
0
0 0

FAILED: patch "[PATCH] x86/kexec: Restore GDT on return from ::preserve_context" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

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 07fa619f2a40c221ea27747a3323cabc59ab25eb # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024121045-limelight-gainfully-7197@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 07fa619f2a40c221ea27747a3323cabc59ab25eb Mon Sep 17 00:00:00 2001 From: David Woodhouse <dwmw(a)amazon.co.uk> Date: Thu, 5 Dec 2024 15:05:07 +0000 Subject: [PATCH] x86/kexec: Restore GDT on return from ::preserve_context kexec The restore_processor_state() function explicitly states that "the asm code that gets us here will have restored a usable GDT". That wasn't true in the case of returning from a ::preserve_context kexec. Make it so. Without this, the kernel was depending on the called function to reload a GDT which is appropriate for the kernel before returning. Test program: #include <unistd.h> #include <errno.h> #include <stdio.h> #include <stdlib.h> #include <linux/kexec.h> #include <linux/reboot.h> #include <sys/reboot.h> #include <sys/syscall.h> int main (void) { struct kexec_segment segment = {}; unsigned char purgatory[] = { 0x66, 0xba, 0xf8, 0x03, // mov $0x3f8, %dx 0xb0, 0x42, // mov $0x42, %al 0xee, // outb %al, (%dx) 0xc3, // ret }; int ret; segment.buf = &purgatory; segment.bufsz = sizeof(purgatory); segment.mem = (void *)0x400000; segment.memsz = 0x1000; ret = syscall(__NR_kexec_load, 0x400000, 1, &segment, KEXEC_PRESERVE_CONTEXT); if (ret) { perror("kexec_load"); exit(1); } ret = syscall(__NR_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_KEXEC); if (ret) { perror("kexec reboot"); exit(1); } printf("Success\n"); return 0; } Signed-off-by: David Woodhouse <dwmw(a)amazon.co.uk> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20241205153343.3275139-2-dwmw2@infradead.org diff --git a/arch/x86/kernel/relocate_kernel_64.S b/arch/x86/kernel/relocate_kernel_64.S index e9e88c342f75..1236f25fc8d1 100644 --- a/arch/x86/kernel/relocate_kernel_64.S +++ b/arch/x86/kernel/relocate_kernel_64.S @@ -242,6 +242,13 @@ SYM_CODE_START_LOCAL_NOALIGN(virtual_mapped) movq CR0(%r8), %r8 movq %rax, %cr3 movq %r8, %cr0 + +#ifdef CONFIG_KEXEC_JUMP + /* Saved in save_processor_state. */ + movq $saved_context, %rax + lgdt saved_context_gdt_desc(%rax) +#endif + movq %rbp, %rax popf

10 months, 1 week

1
0
0 0

Apply c95bbb59a9b2 to 6.12.y

by Miguel Ojeda

Hi Greg, Sasha, Please consider applying commit c95bbb59a9b2 ("rust: enable arbitrary_self_types and remove `Receiver`") to 6.12.y. It is meant to support the upcoming Rust 1.84.0 compiler (to be released in a month), since 6.12 LTS is the first stable kernel that supports a minimum Rust version, thus users may use newer compilers. Older LTSs do not need it, for that reason. It applies almost cleanly (there is a simple conflict). Thanks! Cheers, Miguel

10 months, 1 week

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024