September 2023 - Linux-stable-mirror

[PATCH AUTOSEL 6.1 1/4] autofs: fix memory leak of waitqueues in autofs_catatonic_mode

by Sasha Levin

From: Fedor Pchelkin <pchelkin(a)ispras.ru> [ Upstream commit ccbe77f7e45dfb4420f7f531b650c00c6e9c7507 ] Syzkaller reports a memory leak: BUG: memory leak unreferenced object 0xffff88810b279e00 (size 96): comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378 [<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593 [<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619 [<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897 [<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline] [<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline] [<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [inline] [<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd autofs_wait_queue structs should be freed if their wait_ctr becomes zero. Otherwise they will be lost. In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new waitqueue struct is allocated in autofs_wait(), its initial wait_ctr equals 2. After that wait_event_killable() is interrupted (it returns -ERESTARTSYS), so that 'wq->name.name == NULL' condition may be not satisfied. Actually, this condition can be satisfied when autofs_wait_release() or autofs_catatonic_mode() is called and, what is also important, wait_ctr is decremented in those places. Upon the exit of autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process begins: kill_sb calls autofs_catatonic_mode(), which should have freed the waitqueues, but it only decrements its usage counter to zero which is not a correct behaviour. edit:imk This description is of course not correct. The umount performed as a result of an expire is a umount of a mount that has been automounted, it's not the autofs mount itself. They happen independently, usually after everything mounted within the autofs file system has been expired away. If everything hasn't been expired away the automount daemon can still exit leaving mounts in place. But expires done in both cases will result in a notification that calls autofs_wait_release() with a result status. The problem case is the summary execution of of the automount daemon. In this case any waiting processes won't be woken up until either they are terminated or the mount is umounted. end edit: imk So in catatonic mode we should free waitqueues which counter becomes zero. edit: imk Initially I was concerned that the calling of autofs_wait_release() and autofs_catatonic_mode() was not mutually exclusive but that can't be the case (obviously) because the queue entry (or entries) is removed from the list when either of these two functions are called. Consequently the wait entry will be freed by only one of these functions or by the woken process in autofs_wait() depending on the order of the calls. end edit: imk Reported-by: syzbot+5e53f70e69ff0c0a1c0c(a)syzkaller.appspotmail.com Suggested-by: Takeshi Misawa <jeliantsurux(a)gmail.com> Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Signed-off-by: Ian Kent <raven(a)themaw.net> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Andrei Vagin <avagin(a)gmail.com> Cc: autofs(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Message-Id: <169112719161.7590.6700123246297365841.stgit(a)donald.themaw.net> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- fs/autofs/waitq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/autofs/waitq.c b/fs/autofs/waitq.c index 54c1f8b8b0757..efdc76732faed 100644 --- a/fs/autofs/waitq.c +++ b/fs/autofs/waitq.c @@ -32,8 +32,9 @@ void autofs_catatonic_mode(struct autofs_sb_info *sbi) wq->status = -ENOENT; /* Magic is gone - report failure */ kfree(wq->name.name - wq->offset); wq->name.name = NULL; - wq->wait_ctr--; wake_up_interruptible(&wq->queue); + if (!--wq->wait_ctr) + kfree(wq); wq = nwq; } fput(sbi->pipe); /* Close the pipe */ -- 2.40.1

1 year, 7 months

2
5
0 0

[PATCH 5.10 00/11] 5.10.194-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 5.10.194 release. There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat, 02 Sep 2023 11:08:22 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.194-r… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.10.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 5.10.194-rc1 Paul E. McKenney <paulmck(a)kernel.org> rcu-tasks: Add trc_inspect_reader() checks for exiting critical section Paul E. McKenney <paulmck(a)kernel.org> rcu-tasks: Wait for trc_read_check_handler() IPIs Neeraj Upadhyay <neeraju(a)codeaurora.org> rcu-tasks: Fix IPI failure handling in trc_wait_for_one_reader Paul E. McKenney <paulmck(a)kernel.org> rcu: Prevent expedited GP from enabling tick on offline CPU Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "MIPS: Alchemy: fix dbdma2" Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "drm/amdgpu: install stub fence into potential unused fence pointers" Loic Poulain <loic.poulain(a)linaro.org> mhi: pci_generic: Fix implicit conversion warning James Morse <james.morse(a)arm.com> ARM: module: Use module_init_layout_section() to spot init sections James Morse <james.morse(a)arm.com> arm64: module: Use module_init_layout_section() to spot init sections Arnd Bergmann <arnd(a)arndb.de> arm64: module-plts: inline linux/moduleloader.h James Morse <james.morse(a)arm.com> module: Expose module_init_layout_section() ------------- Diffstat: Makefile | 4 ++-- arch/arm/kernel/module-plts.c | 2 +- arch/arm64/kernel/module-plts.c | 3 ++- arch/mips/alchemy/common/dbdma.c | 27 ++++++++++++------------- drivers/bus/mhi/host/pci_generic.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++---- include/linux/moduleloader.h | 5 +++++ kernel/module.c | 2 +- kernel/rcu/tasks.h | 36 ++++++++++++++++++++++++---------- kernel/rcu/tree_exp.h | 5 ++++- 10 files changed, 56 insertions(+), 36 deletions(-)

1 year, 7 months

7
18
0 0

[PATCH AUTOSEL 6.4 01/31] drm/bridge: tc358762: Instruct DSI host to generate HSE packets

by Sasha Levin

From: Marek Vasut <marex(a)denx.de> [ Upstream commit 362fa8f6e6a05089872809f4465bab9d011d05b3 ] This bridge seems to need the HSE packet, otherwise the image is shifted up and corrupted at the bottom. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by: Marek Vasut <marex(a)denx.de> Reviewed-by: Sam Ravnborg <sam(a)ravnborg.org> Signed-off-by: Robert Foss <rfoss(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230615201902.566182-3-marex… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/tc358762.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358762.c b/drivers/gpu/drm/bridge/tc358762.c index 77f7f7f547570..5de3f5b8dd336 100644 --- a/drivers/gpu/drm/bridge/tc358762.c +++ b/drivers/gpu/drm/bridge/tc358762.c @@ -216,7 +216,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi) dsi->lanes = 1; dsi->format = MIPI_DSI_FMT_RGB888; dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE | - MIPI_DSI_MODE_LPM; + MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_VIDEO_HSE; ret = tc358762_parse_dt(ctx); if (ret < 0) -- 2.40.1

1 year, 7 months

2
32
0 0

[PATCH AUTOSEL 6.1 01/22] drm/bridge: tc358762: Instruct DSI host to generate HSE packets

by Sasha Levin

From: Marek Vasut <marex(a)denx.de> [ Upstream commit 362fa8f6e6a05089872809f4465bab9d011d05b3 ] This bridge seems to need the HSE packet, otherwise the image is shifted up and corrupted at the bottom. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by: Marek Vasut <marex(a)denx.de> Reviewed-by: Sam Ravnborg <sam(a)ravnborg.org> Signed-off-by: Robert Foss <rfoss(a)kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230615201902.566182-3-marex… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/bridge/tc358762.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/bridge/tc358762.c b/drivers/gpu/drm/bridge/tc358762.c index 7f4fce1aa9988..8db981e7759b9 100644 --- a/drivers/gpu/drm/bridge/tc358762.c +++ b/drivers/gpu/drm/bridge/tc358762.c @@ -216,7 +216,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi) dsi->lanes = 1; dsi->format = MIPI_DSI_FMT_RGB888; dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_SYNC_PULSE | - MIPI_DSI_MODE_LPM; + MIPI_DSI_MODE_LPM | MIPI_DSI_MODE_VIDEO_HSE; ret = tc358762_parse_dt(ctx); if (ret < 0) -- 2.40.1

1 year, 7 months

3
25
0 0

RE: HIMSS Global Health Conference Attendees List 2023

by Kris jenner

Hi, Would you be interested in acquiring the Healthcare Information and Management Systems Society Attendees List 2023? Number of Contacts: 45,789 Cost: $ 2,175 Interested? Email me back; I would love to provide more information on the list. Kind Regards, Kris jenner Marketing Coordinator

1 year, 7 months

1
0
0 0

[PATCH] ACPI: resource: Skip IRQ override on ASUS ExpertBook B1402CBA

by Hans de Goede

Like various other ASUS ExpertBook-s, the ASUS ExpertBook B1402CBA has an ACPI DSDT table that describes IRQ 1 as ActiveLow while the kernel overrides it to EdgeHigh. This prevents the keyboard from working. To fix this issue, add this laptop to the skip_override_table so that the kernel does not override IRQ 1. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217901 Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/acpi/resource.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 32cfa3f4efd3..8116b55b6c98 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -439,6 +439,13 @@ static const struct dmi_system_id asus_laptop[] = { DMI_MATCH(DMI_BOARD_NAME, "S5602ZA"), }, }, + { + .ident = "Asus ExpertBook B1402CBA", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_BOARD_NAME, "B1402CBA"), + }, + }, { .ident = "Asus ExpertBook B1502CBA", .matches = { -- 2.41.0

1 year, 7 months

2
1
0 0

[PATCH AUTOSEL 6.5 1/6] printk: Reduce console_unblank() usage in unsafe scenarios

by Sasha Levin

From: John Ogness <john.ogness(a)linutronix.de> [ Upstream commit 7b23a66db55ed0a55b020e913f0d6f6d52a1ad2c ] A semaphore is not NMI-safe, even when using down_trylock(). Both down_trylock() and up() are using internal spinlocks and up() might even call wake_up_process(). In the panic() code path it gets even worse because the internal spinlocks of the semaphore may have been taken by a CPU that has been stopped. To reduce the risk of deadlocks caused by the console semaphore in the panic path, make the following changes: - First check if any consoles have implemented the unblank() callback. If not, then there is no reason to take the console semaphore anyway. (This check is also useful for the non-panic path since the locking/unlocking of the console lock can be quite expensive due to console printing.) - If the panic path is in NMI context, bail out without attempting to take the console semaphore or calling any unblank() callbacks. Bailing out is acceptable because console_unblank() would already bail out if the console semaphore is contended. The alternative of ignoring the console semaphore and calling the unblank() callbacks anyway is a bad idea because these callbacks are also not NMI-safe. If consoles with unblank() callbacks exist and console_unblank() is called from a non-NMI panic context, it will still attempt a down_trylock(). This could still result in a deadlock if one of the stopped CPUs is holding the semaphore internal spinlock. But this is a risk that the kernel has been (and continues to be) willing to take. Signed-off-by: John Ogness <john.ogness(a)linutronix.de> Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Reviewed-by: Petr Mladek <pmladek(a)suse.com> Signed-off-by: Petr Mladek <pmladek(a)suse.com> Link: https://lore.kernel.org/r/20230717194607.145135-3-john.ogness@linutronix.de Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/printk/printk.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 357a4d18f6387..7d3f30eb35862 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -3045,9 +3045,27 @@ EXPORT_SYMBOL(console_conditional_schedule); void console_unblank(void) { + bool found_unblank = false; struct console *c; int cookie; + /* + * First check if there are any consoles implementing the unblank() + * callback. If not, there is no reason to continue and take the + * console lock, which in particular can be dangerous if + * @oops_in_progress is set. + */ + cookie = console_srcu_read_lock(); + for_each_console_srcu(c) { + if ((console_srcu_read_flags(c) & CON_ENABLED) && c->unblank) { + found_unblank = true; + break; + } + } + console_srcu_read_unlock(cookie); + if (!found_unblank) + return; + /* * Stop console printing because the unblank() callback may * assume the console is not within its write() callback. @@ -3056,6 +3074,16 @@ void console_unblank(void) * In that case, attempt a trylock as best-effort. */ if (oops_in_progress) { + /* Semaphores are not NMI-safe. */ + if (in_nmi()) + return; + + /* + * Attempting to trylock the console lock can deadlock + * if another CPU was stopped while modifying the + * semaphore. "Hope and pray" that this is not the + * current situation. + */ if (down_trylock_console_sem() != 0) return; } else -- 2.40.1

1 year, 7 months

2
7
0 0

[PATCH] Revert "misc: rtsx: judge ASPM Mode to set PETXCFG Reg"

by Jade Lovelace

This reverts commit 101bd907b4244a726980ee67f95ed9cafab6ff7a. This commit causes the NVMe controller to not work on the Dell XPS 15 9560, and similar laptop models. It appears to happen with any SSD model. This commit is broken on 6.1, 6.4, 6.5, and 6.6-rc1. OpenSUSE has already reverted, and I have submitted a revert to NixOS. As far as I can tell, this regression has fallen through the cracks. Symptom: kernel: nvme nvme0: controller is down; will reset: CSTS=0xffffffff, PCI_STATUS=0xffff kernel: nvme nvme0: Does your device have a faulty power saving mode enabled? kernel: nvme nvme0: Try "nvme_core.default_ps_max_latency_us=0 pcie_aspm=off" and report a bug kernel: nvme 0000:04:00.0: Unable to change power state from D3cold to D0, device inaccessible kernel: nvme nvme0: Disabling device after reset failure: -19 systemd-cryptsetup[169]: Device /dev/disk/by-uuid/b80aedf8-ddd4-46fa-8d09-5215d5f286b9 READ lock released. systemd-cryptsetup[169]: IO error while decrypting keyslot. systemd-cryptsetup[169]: Keyslot 0 (luks2) open failed with -5. systemd-cryptsetup[169]: Keyslot open failed. systemd-cryptsetup[169]: Failed to activate with specified passphrase: Input/output error There are several downstream bugs, these are the ones I know of: - https://bugzilla.suse.com/show_bug.cgi?id=1214428 - https://github.com/NixOS/nixpkgs/issues/253418 - https://bugs.archlinux.org/task/79439#comment221866 Upstream revert links: - https://github.com/openSUSE/kernel-source/commit/1b02b1528a26f4e9b577e215c1… - https://github.com/NixOS/nixpkgs/pull/255824 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217802 Reported-and-bisected-by: Gene <geneslists(a)sapience.com> Link: https://lore.kernel.org/lkml/30b69186-5a6e-4f53-b24c-2221926fc3b4@sapience.… Signed-off-by: Jade Lovelace <lists(a)jade.fyi> --- drivers/misc/cardreader/rts5227.c | 2 +- drivers/misc/cardreader/rts5228.c | 18 ++++++++++++++++++ drivers/misc/cardreader/rts5249.c | 3 ++- drivers/misc/cardreader/rts5260.c | 18 ++++++++++++++++++ drivers/misc/cardreader/rts5261.c | 18 ++++++++++++++++++ drivers/misc/cardreader/rtsx_pcr.c | 5 +---- 6 files changed, 58 insertions(+), 6 deletions(-) diff --git a/drivers/misc/cardreader/rts5227.c b/drivers/misc/cardreader/rts5227.c index 3dae5e3a1697..d676cf63a966 100644 --- a/drivers/misc/cardreader/rts5227.c +++ b/drivers/misc/cardreader/rts5227.c @@ -195,7 +195,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr) } } - if (option->force_clkreq_0 && pcr->aspm_mode == ASPM_MODE_CFG) + if (option->force_clkreq_0) rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW); else diff --git a/drivers/misc/cardreader/rts5228.c b/drivers/misc/cardreader/rts5228.c index f4ab09439da7..cfebad51d1d8 100644 --- a/drivers/misc/cardreader/rts5228.c +++ b/drivers/misc/cardreader/rts5228.c @@ -435,10 +435,17 @@ static void rts5228_init_from_cfg(struct rtsx_pcr *pcr) option->ltr_enabled = false; } } + + if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN + | PM_L1_1_EN | PM_L1_2_EN)) + option->force_clkreq_0 = false; + else + option->force_clkreq_0 = true; } static int rts5228_extra_init_hw(struct rtsx_pcr *pcr) { + struct rtsx_cr_option *option = &pcr->option; rtsx_pci_write_register(pcr, RTS5228_AUTOLOAD_CFG1, CD_RESUME_EN_MASK, CD_RESUME_EN_MASK); @@ -469,6 +476,17 @@ static int rts5228_extra_init_hw(struct rtsx_pcr *pcr) else rtsx_pci_write_register(pcr, PETXCFG, 0x30, 0x00); + /* + * If u_force_clkreq_0 is enabled, CLKREQ# PIN will be forced + * to drive low, and we forcibly request clock. + */ + if (option->force_clkreq_0) + rtsx_pci_write_register(pcr, PETXCFG, + FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW); + else + rtsx_pci_write_register(pcr, PETXCFG, + FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH); + rtsx_pci_write_register(pcr, PWD_SUSPEND_EN, 0xFF, 0xFB); if (pcr->rtd3_en) { diff --git a/drivers/misc/cardreader/rts5249.c b/drivers/misc/cardreader/rts5249.c index 47ab72a43256..91d240dd68fa 100644 --- a/drivers/misc/cardreader/rts5249.c +++ b/drivers/misc/cardreader/rts5249.c @@ -327,11 +327,12 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr) } } + /* * If u_force_clkreq_0 is enabled, CLKREQ# PIN will be forced * to drive low, and we forcibly request clock. */ - if (option->force_clkreq_0 && pcr->aspm_mode == ASPM_MODE_CFG) + if (option->force_clkreq_0) rtsx_pci_write_register(pcr, PETXCFG, FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW); else diff --git a/drivers/misc/cardreader/rts5260.c b/drivers/misc/cardreader/rts5260.c index 79b18f6f73a8..9b42b20a3e5a 100644 --- a/drivers/misc/cardreader/rts5260.c +++ b/drivers/misc/cardreader/rts5260.c @@ -517,10 +517,17 @@ static void rts5260_init_from_cfg(struct rtsx_pcr *pcr) option->ltr_enabled = false; } } + + if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN + | PM_L1_1_EN | PM_L1_2_EN)) + option->force_clkreq_0 = false; + else + option->force_clkreq_0 = true; } static int rts5260_extra_init_hw(struct rtsx_pcr *pcr) { + struct rtsx_cr_option *option = &pcr->option; /* Set mcu_cnt to 7 to ensure data can be sampled properly */ rtsx_pci_write_register(pcr, 0xFC03, 0x7F, 0x07); @@ -539,6 +546,17 @@ static int rts5260_extra_init_hw(struct rtsx_pcr *pcr) rts5260_init_hw(pcr); + /* + * If u_force_clkreq_0 is enabled, CLKREQ# PIN will be forced + * to drive low, and we forcibly request clock. + */ + if (option->force_clkreq_0) + rtsx_pci_write_register(pcr, PETXCFG, + FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW); + else + rtsx_pci_write_register(pcr, PETXCFG, + FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH); + rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10, 0x00); return 0; diff --git a/drivers/misc/cardreader/rts5261.c b/drivers/misc/cardreader/rts5261.c index 94af6bf8a25a..b1e76030cafd 100644 --- a/drivers/misc/cardreader/rts5261.c +++ b/drivers/misc/cardreader/rts5261.c @@ -498,10 +498,17 @@ static void rts5261_init_from_cfg(struct rtsx_pcr *pcr) option->ltr_enabled = false; } } + + if (rtsx_check_dev_flag(pcr, ASPM_L1_1_EN | ASPM_L1_2_EN + | PM_L1_1_EN | PM_L1_2_EN)) + option->force_clkreq_0 = false; + else + option->force_clkreq_0 = true; } static int rts5261_extra_init_hw(struct rtsx_pcr *pcr) { + struct rtsx_cr_option *option = &pcr->option; u32 val; rtsx_pci_write_register(pcr, RTS5261_AUTOLOAD_CFG1, @@ -547,6 +554,17 @@ static int rts5261_extra_init_hw(struct rtsx_pcr *pcr) else rtsx_pci_write_register(pcr, PETXCFG, 0x30, 0x00); + /* + * If u_force_clkreq_0 is enabled, CLKREQ# PIN will be forced + * to drive low, and we forcibly request clock. + */ + if (option->force_clkreq_0) + rtsx_pci_write_register(pcr, PETXCFG, + FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_LOW); + else + rtsx_pci_write_register(pcr, PETXCFG, + FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH); + rtsx_pci_write_register(pcr, PWD_SUSPEND_EN, 0xFF, 0xFB); if (pcr->rtd3_en) { diff --git a/drivers/misc/cardreader/rtsx_pcr.c b/drivers/misc/cardreader/rtsx_pcr.c index a3f4b52bb159..32b7783e9d4f 100644 --- a/drivers/misc/cardreader/rtsx_pcr.c +++ b/drivers/misc/cardreader/rtsx_pcr.c @@ -1326,11 +1326,8 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr) return err; } - if (pcr->aspm_mode == ASPM_MODE_REG) { + if (pcr->aspm_mode == ASPM_MODE_REG) rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, 0x30, 0x30); - rtsx_pci_write_register(pcr, PETXCFG, - FORCE_CLKREQ_DELINK_MASK, FORCE_CLKREQ_HIGH); - } /* No CD interrupt if probing driver with card inserted. * So we need to initialize pcr->card_exist here. -- 2.42.0

1 year, 7 months

2
1
0 0

[Revert] Re: Possible nvme regression in 6.4.11

by Jade Lovelace

This regression affects all copies of the Dell XPS 15 9560 and Dell Precision 5520 with any SSD including aftermarket ones. Per the bugzilla discussion here: https://bugzilla.kernel.org/show_bug.cgi?id=217802 this regression has been confirmed to also affect 6.5.2 and 6.6-rc1, and affects several distros. Known affected branches: 6.1, 6.4, 6.5, 6.6. It has already been reverted by OpenSUSE and is soon to be reverted in NixOS. A patch follows, hopefully with the right metadata tags. I have compiled a kernel 6.1 with the revert and confirmed it now boots again. p.s. this is my first time pointing git-send-email at this particular list, so I'm sorry if I got anything wrong. Jade

1 year, 7 months

1
0
0 0

[PATCH AUTOSEL 6.4 01/25] media: mdp3: Fix resource leaks in of_find_device_by_node

by Sasha Levin

From: Lu Hongfei <luhongfei(a)vivo.com> [ Upstream commit 35ca8ce495366909b4c2e701d1356570dd40c4e2 ] Use put_device to release the object get through of_find_device_by_node, avoiding resource leaks. Signed-off-by: Lu Hongfei <luhongfei(a)vivo.com> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c index 19a4a085f73a1..1fe10a21e395a 100644 --- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c +++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-comp.c @@ -892,11 +892,13 @@ static int mdp_get_subsys_id(struct mdp_dev *mdp, struct device *dev, ret = cmdq_dev_get_client_reg(&comp_pdev->dev, &cmdq_reg, index); if (ret != 0) { dev_err(&comp_pdev->dev, "cmdq_dev_get_subsys fail!\n"); + put_device(&comp_pdev->dev); return -EINVAL; } comp->subsys_id = cmdq_reg.subsys; dev_dbg(&comp_pdev->dev, "subsys id=%d\n", cmdq_reg.subsys); + put_device(&comp_pdev->dev); return 0; } -- 2.40.1

1 year, 7 months

4
29
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror September 2023