October 2024 - Linux-stable-mirror

+ mm-gup-stop-leaking-pinned-pages-in-low-memory-conditions.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/gup: stop leaking pinned pages in low memory conditions has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-gup-stop-leaking-pinned-pages-in-low-memory-conditions.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: John Hubbard <jhubbard(a)nvidia.com> Subject: mm/gup: stop leaking pinned pages in low memory conditions Date: Wed, 16 Oct 2024 13:22:42 -0700 If a driver tries to call any of the pin_user_pages*(FOLL_LONGTERM) family of functions, and requests "too many" pages, then the call will erroneously leave pages pinned. This is visible in user space as an actual memory leak. Repro is trivial: just make enough pin_user_pages(FOLL_LONGTERM) calls to exhaust memory. The root cause of the problem is this sequence, within __gup_longterm_locked(): __get_user_pages_locked() rc = check_and_migrate_movable_pages() ...which gets retried in a loop. The loop error handling is incomplete, clearly due to a somewhat unusual and complicated tri-state error API. But anyway, if -ENOMEM, or in fact, any unexpected error is returned from check_and_migrate_movable_pages(), then __gup_longterm_locked() happily returns the error, while leaving the pages pinned. In the failed case, which is an app that requests (via a device driver) 30720000000 bytes to be pinned, and then exits, I see this: $ grep foll /proc/vmstat nr_foll_pin_acquired 7502048 nr_foll_pin_released 2048 And after applying this patch, it returns to balanced pins: $ grep foll /proc/vmstat nr_foll_pin_acquired 7502048 nr_foll_pin_released 7502048 Fix this by unpinning the pages that __get_user_pages_locked() has pinned, in such error cases. Link: https://lkml.kernel.org/r/20241016202242.456953-1-jhubbard@nvidia.com Fixes: 24a95998e9ba ("mm/gup.c: simplify and fix check_and_migrate_movable_pages() return codes") Signed-off-by: John Hubbard <jhubbard(a)nvidia.com> Cc: Alistair Popple <apopple(a)nvidia.com> Cc: Shigeru Yoshida <syoshida(a)redhat.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: Jason Gunthorpe <jgg(a)nvidia.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/gup.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/mm/gup.c~mm-gup-stop-leaking-pinned-pages-in-low-memory-conditions +++ a/mm/gup.c @@ -2492,6 +2492,17 @@ static long __gup_longterm_locked(struct /* FOLL_LONGTERM implies FOLL_PIN */ rc = check_and_migrate_movable_pages(nr_pinned_pages, pages); + + /* + * The __get_user_pages_locked() call happens before we know + * that whether it's possible to successfully complete the whole + * operation. To compensate for this, if we get an unexpected + * error (such as -ENOMEM) then we must unpin everything, before + * erroring out. + */ + if (rc != -EAGAIN && rc != 0) + unpin_user_pages(pages, nr_pinned_pages); + } while (rc == -EAGAIN); memalloc_pin_restore(flags); return rc ? rc : nr_pinned_pages; _ Patches currently in -mm which might be from jhubbard(a)nvidia.com are mm-gup-stop-leaking-pinned-pages-in-low-memory-conditions.patch kaslr-rename-physmem_end-and-physmem_end-to-direct_map_physmem_end.patch

2 months, 3 weeks

1
0
0 0

+ x86-traps-move-kmsan-check-after-instrumentation_begin.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: x86/traps: move kmsan check after instrumentation_begin has been added to the -mm mm-hotfixes-unstable branch. Its filename is x86-traps-move-kmsan-check-after-instrumentation_begin.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Sabyrzhan Tasbolatov <snovitoll(a)gmail.com> Subject: x86/traps: move kmsan check after instrumentation_begin Date: Wed, 16 Oct 2024 20:24:07 +0500 During x86_64 kernel build with CONFIG_KMSAN, the objtool warns following: AR built-in.a AR vmlinux.a LD vmlinux.o vmlinux.o: warning: objtool: handle_bug+0x4: call to kmsan_unpoison_entry_regs() leaves .noinstr.text section OBJCOPY modules.builtin.modinfo GEN modules.builtin MODPOST Module.symvers CC .vmlinux.export.o Moving kmsan_unpoison_entry_regs() _after_ instrumentation_begin() fixes the warning. There is decode_bug(regs->ip, &imm) is left before KMSAN unpoisoining, but it has the return condition and if we include it after instrumentation_begin() it results the warning "return with instrumentation enabled", hence, I'm concerned that regs will not be KMSAN unpoisoned if `ud_type == BUG_NONE` is true. Link: https://lkml.kernel.org/r/20241016152407.3149001-1-snovitoll@gmail.com Fixes: ba54d194f8da ("x86/traps: avoid KMSAN bugs originating from handle_bug()") Signed-off-by: Sabyrzhan Tasbolatov <snovitoll(a)gmail.com> Reviewed-by: Alexander Potapenko <glider(a)google.com> Cc: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- arch/x86/kernel/traps.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/x86/kernel/traps.c~x86-traps-move-kmsan-check-after-instrumentation_begin +++ a/arch/x86/kernel/traps.c @@ -261,12 +261,6 @@ static noinstr bool handle_bug(struct pt int ud_type; u32 imm; - /* - * Normally @regs are unpoisoned by irqentry_enter(), but handle_bug() - * is a rare case that uses @regs without passing them to - * irqentry_enter(). - */ - kmsan_unpoison_entry_regs(regs); ud_type = decode_bug(regs->ip, &imm); if (ud_type == BUG_NONE) return handled; @@ -276,6 +270,12 @@ static noinstr bool handle_bug(struct pt */ instrumentation_begin(); /* + * Normally @regs are unpoisoned by irqentry_enter(), but handle_bug() + * is a rare case that uses @regs without passing them to + * irqentry_enter(). + */ + kmsan_unpoison_entry_regs(regs); + /* * Since we're emulating a CALL with exceptions, restore the interrupt * state to what it was at the exception site. */ _ Patches currently in -mm which might be from snovitoll(a)gmail.com are x86-traps-move-kmsan-check-after-instrumentation_begin.patch mm-kasan-kmsan-copy_from-to_kernel_nofault.patch

2 months, 3 weeks

1
0
0 0

[PATCH] kbuild: Fully disable -Wenum-{compare-conditional,enum-conversion}

by Nathan Chancellor

-Wenum-enum-conversion and -Wenum-compare-conditional were strengthened in clang-19 to warn in C mode, which caused the kernel to move them to W=1 in commit 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") because there were numerous instances of each that would break builds with -Werror. Unfortunately, this is not a full solution, as more and more developers, subsystems, and distributors are building with W=1 as well, so they continue to see the numerous instances of these warnings. Since the move to W=1, there have not been many new instances that have appeared through various build reports and the ones that have appeared seem to be following similar existing patterns, suggesting that most instances of these warnings will not be real issues. The only alternatives for silencing these warnings are adding casts (which is generally seen as an ugly practice) or refactoring the enums to macro defines or a unified enum (which may be undesirable because of type safety in other parts of the code). Disable the warnings altogether so that W=1 users do not see them. Cc: stable(a)vger.kernel.org Fixes: 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") Link: https://lore.kernel.org/ZwRA9SOcOjjLJcpi@google.com/ Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- I am open to discussion around whether or not to disable this entirely but I think it needs to be out of W=1. --- scripts/Makefile.extrawarn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 1d13cecc7cc7808610e635ddc03476cf92b3a8c1..3f124c80bee5133899047c07bc05e3173ee4c7f0 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -31,6 +31,8 @@ KBUILD_CFLAGS-$(CONFIG_CC_NO_ARRAY_BOUNDS) += -Wno-array-bounds ifdef CONFIG_CC_IS_CLANG # The kernel builds with '-std=gnu11' so use of GNU extensions is acceptable. KBUILD_CFLAGS += -Wno-gnu +KBUILD_CFLAGS += -Wno-enum-compare-conditional +KBUILD_CFLAGS += -Wno-enum-enum-conversion else # gcc inanely warns about local variables called 'main' @@ -129,8 +131,6 @@ endif KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast) KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access) -KBUILD_CFLAGS += -Wno-enum-compare-conditional -KBUILD_CFLAGS += -Wno-enum-enum-conversion endif endif --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241016-disable-two-clang-enum-warnings-e7994d44f948 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

2 months, 3 weeks

2
2
0 0

[PATCH v2] arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block

by Abel Vesa

Add missing Broadcast_AND region to the LLCC block for x1e80100, as the LLCC version on this platform is 4.1 and it provides the region. This also fixes the following error caused by the missing region: [ 3.797768] qcom-llcc 25000000.system-cache-controller: error -EINVAL: invalid resource (null) This error started showing up only after the new regmap region called Broadcast_AND that has been added to the llcc-qcom driver. Cc: stable(a)vger.kernel.org # 6.11: 055afc34fd21: soc: qcom: llcc: Add regmap for Broadcast_AND region Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP dts") Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- Changes in v2: - fixed subject line to say x1e80100 instead of sm8450 - mentioned the reason why the new error is showing up and how it is related to the llcc-qcom driver - cc'ed stable with patch dependency for cherry-picking - Link to v1: https://lore.kernel.org/r/20240718-x1e80100-dts-llcc-add-broadcastand_regio… --- arch/arm64/boot/dts/qcom/x1e80100.dtsi | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi index 0e6802c1d2d8375987c614ec69c440e2f38d25c6..fbf1acf8b0d84a2d2c723785242a65f47e63340b 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi @@ -6093,7 +6093,8 @@ system-cache-controller@25000000 { <0 0x25a00000 0 0x200000>, <0 0x25c00000 0 0x200000>, <0 0x25e00000 0 0x200000>, - <0 0x26000000 0 0x200000>; + <0 0x26000000 0 0x200000>, + <0 0x26200000 0 0x200000>; reg-names = "llcc0_base", "llcc1_base", "llcc2_base", @@ -6102,7 +6103,8 @@ system-cache-controller@25000000 { "llcc5_base", "llcc6_base", "llcc7_base", - "llcc_broadcast_base"; + "llcc_broadcast_base", + "llcc_broadcast_and_base"; interrupts = <GIC_SPI 266 IRQ_TYPE_LEVEL_HIGH>; }; --- base-commit: d61a00525464bfc5fe92c6ad713350988e492b88 change-id: 20240718-x1e80100-dts-llcc-add-broadcastand_region-797413ee2a8f Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

2 months, 3 weeks

2
1
0 0

[PATCH 0/2] Fix KASAN crash when using KASAN_VMALLOC

by Linus Walleij

This problem reported by Clement LE GOFFIC manifest when using CONFIG_KASAN_IN_VMALLOC and VMAP_STACK: https://lore.kernel.org/linux-arm-kernel/a1a1d062-f3a2-4d05-9836-3b098de9db… After some analysis it seems we are missing to sync the VMALLOC shadow memory in top level PGD to all CPUs. Add some code to perform this sync, and the bug appears to go away. As suggested by Ard, also perform a dummy read from the shadow memory of the new VMAP_STACK in the low level assembly. Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- Linus Walleij (2): ARM: ioremap: Flush PGDs for VMALLOC shadow ARM: entry: Do a dummy read from VMAP shadow arch/arm/kernel/entry-armv.S | 8 ++++++++ arch/arm/mm/ioremap.c | 7 +++++++ 2 files changed, 15 insertions(+) --- base-commit: 9852d85ec9d492ebef56dc5f229416c925758edc change-id: 20241015-arm-kasan-vmalloc-crash-fcbd51416457 Best regards, -- Linus Walleij <linus.walleij(a)linaro.org>

2 months, 3 weeks

3
7
0 0

[PATCH] fs: don't try and remove empty rbtree node

by Christian Brauner

When copying a namespace we won't have added the new copy into the namespace rbtree until after the copy succeeded. Calling free_mnt_ns() will try to remove the copy from the rbtree which is invalid. Simply free the namespace skeleton directly. Fixes: 1901c92497bd ("fs: keep an index of current mount namespaces") Cc: stable(a)vger.kernel.org # v6.11+ Reported-by: Brad Spengler <spender(a)grsecurity.net> Tested-by: Brad Spengler <spender(a)grsecurity.net> Suggested-by: Brad Spengler <spender(a)grsecurity.net> Signed-off-by: Christian Brauner <brauner(a)kernel.org> --- In vfs.fixes unless I hear objections. --- fs/namespace.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/namespace.c b/fs/namespace.c index 93c377816d75..d26f5e6d2ca3 100644 --- a/fs/namespace.c +++ b/fs/namespace.c @@ -3944,7 +3944,9 @@ struct mnt_namespace *copy_mnt_ns(unsigned long flags, struct mnt_namespace *ns, new = copy_tree(old, old->mnt.mnt_root, copy_flags); if (IS_ERR(new)) { namespace_unlock(); - free_mnt_ns(new_ns); + ns_free_inum(&new_ns->ns); + dec_mnt_namespaces(new_ns->ucounts); + mnt_ns_release(new_ns); return ERR_CAST(new); } if (user_ns != ns->user_ns) { -- 2.45.2

2 months, 3 weeks

1
0
0 0

[PATCH v2] usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()

by Jeongjun Park

iowarrior_read() uses the iowarrior dev structure, but does not use any lock on the structure. This can cause various bugs including data-races, so it is more appropriate to use a mutex lock to safely protect the iowarrior dev structure. When using a mutex lock, you should split the branch to prevent blocking when the O_NONBLOCK flag is set. In addition, it is unnecessary to check for NULL on the iowarrior dev structure obtained by reading file->private_data. Therefore, it is better to remove the check. Cc: stable(a)vger.kernel.org Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Signed-off-by: Jeongjun Park <aha310510(a)gmail.com> --- v1 -> v2: Added cc tag and change log drivers/usb/misc/iowarrior.c | 46 ++++++++++++++++++++++++++++-------- 1 file changed, 36 insertions(+), 10 deletions(-) diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c index 6d28467ce352..a513766b4985 100644 --- a/drivers/usb/misc/iowarrior.c +++ b/drivers/usb/misc/iowarrior.c @@ -277,28 +277,45 @@ static ssize_t iowarrior_read(struct file *file, char __user *buffer, struct iowarrior *dev; int read_idx; int offset; + int retval; dev = file->private_data; + if (file->f_flags & O_NONBLOCK) { + retval = mutex_trylock(&dev->mutex); + if (!retval) + return -EAGAIN; + } else { + retval = mutex_lock_interruptible(&dev->mutex); + if (retval) + return -ERESTARTSYS; + } + /* verify that the device wasn't unplugged */ - if (!dev || !dev->present) - return -ENODEV; + if (!dev->present) { + retval = -ENODEV; + goto exit; + } dev_dbg(&dev->interface->dev, "minor %d, count = %zd\n", dev->minor, count); /* read count must be packet size (+ time stamp) */ if ((count != dev->report_size) - && (count != (dev->report_size + 1))) - return -EINVAL; + && (count != (dev->report_size + 1))) { + retval = -EINVAL; + goto exit; + } /* repeat until no buffer overrun in callback handler occur */ do { atomic_set(&dev->overflow_flag, 0); if ((read_idx = read_index(dev)) == -1) { /* queue empty */ - if (file->f_flags & O_NONBLOCK) - return -EAGAIN; + if (file->f_flags & O_NONBLOCK) { + retval = -EAGAIN; + goto exit; + } else { //next line will return when there is either new data, or the device is unplugged int r = wait_event_interruptible(dev->read_wait, @@ -309,28 +326,37 @@ static ssize_t iowarrior_read(struct file *file, char __user *buffer, -1)); if (r) { //we were interrupted by a signal - return -ERESTART; + retval = -ERESTART; + goto exit; } if (!dev->present) { //The device was unplugged - return -ENODEV; + retval = -ENODEV; + goto exit; } if (read_idx == -1) { // Can this happen ??? - return 0; + retval = 0; + goto exit; } } } offset = read_idx * (dev->report_size + 1); if (copy_to_user(buffer, dev->read_queue + offset, count)) { - return -EFAULT; + retval = -EFAULT; + goto exit; } } while (atomic_read(&dev->overflow_flag)); read_idx = ++read_idx == MAX_INTERRUPT_BUFFER ? 0 : read_idx; atomic_set(&dev->read_idx, read_idx); + mutex_unlock(&dev->mutex); return count; + +exit: + mutex_unlock(&dev->mutex); + return retval; } /* --

2 months, 3 weeks

2
2
0 0

Re: Bad commit backported on the v5.15.y branch ?

by Thorsten Leemhuis

On 11.10.24 10:48, Joel GUITTET wrote: > > I faced some issue related to scaling frequency on ZynqMP device > using v5.15.167 kernel. As an exemple setting the scaling frequency > below show it's not properly set: > > cat /sys/devices/system/cpu/cpufreq/policy0/ > scaling_available_frequencies 299999 399999 599999 1199999 > > echo 399999 > /sys/devices/system/cpu/cpufreq/policy0/ > scaling_setspeed > > cat /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq 399999 > > cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_cur_freq 299999 > ====> Should be 399999 > > After analysis of this issue with the help of Xilinx, it appears > that a commit was backported on the 5.15.y branch, but probably it > should not, or not as is. The commit is > 9117fc44fd3a9538261e530ba5a022dfc9519620 modifying drivers/clk/ > zynqmp/divider.c. FWIW, that is 1fe15be1fb6135 ("drivers: clk: zynqmp: update divider round rate logic") [v6.8-rc1]. > Is anybody reading this message able to answer why it was > backported ? Looks like because it fixes a bug. I CCed the original author and those that handled the patch, maybe they can help us out and tell us what's the best strategy forward here. > The information I have until now is that it is intended > recent kernel version. Dependencies for this modification is > currently under clarification with Xilinx (maybe another commit to > backport). > > By the way, reverting this commit fix the issue shown above. Does 6.12-rc work fine for you? Because if not, we should fix the problem there. Ciao, Thorsten

2 months, 3 weeks

3
4
0 0

[PATCH 6/6] arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch

by Johan Hovold

The NVMe regulator has been left enabled by the boot firmware. Mark it as such to avoid disabling the regulator temporarily during boot. Fixes: eb57cbe730d1 ("arm64: dts: qcom: x1e80100: Describe the PCIe 6a resources") Cc: stable(a)vger.kernel.org # 6.11 Cc: Abel Vesa <abel.vesa(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts index 1c3a6a7b3ed6..5ef030c60abe 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts +++ b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts @@ -253,6 +253,8 @@ vreg_nvme: regulator-nvme { pinctrl-names = "default"; pinctrl-0 = <&nvme_reg_en>; + + regulator-boot-on; }; }; -- 2.45.2

2 months, 3 weeks

1
0
0 0

[PATCH 4/6] arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch

by Johan Hovold

The NVMe regulator has been left enabled by the boot firmware. Mark it as such to avoid disabling the regulator temporarily during boot. Fixes: 45247fe17db2 ("arm64: dts: qcom: x1e80100: add Lenovo Thinkpad Yoga slim 7x devicetree") Cc: stable(a)vger.kernel.org # 6.11 Cc: Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts index 3c13331a9ef4..0cdaff9c8cf0 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts +++ b/arch/arm64/boot/dts/qcom/x1e80100-lenovo-yoga-slim7x.dts @@ -205,6 +205,8 @@ vreg_nvme: regulator-nvme { pinctrl-0 = <&nvme_reg_en>; pinctrl-names = "default"; + + regulator-boot-on; }; }; -- 2.45.2

2 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024