February 2025 - Linux-stable-mirror

[PATCH] usb: xhci: Restore Renesas uPD72020x support in xhci-pci

by nb＠tipi-net.de

From: Nicolai Buchwitz <nb(a)tipi-net.de> Before commit 25f51b76f90f1 ("xhci-pci: Make xhci-pci-renesas a proper modular driver"), the xhci-pci driver handled the Renesas uPD72020x USB3 PHY and only utilized features of xhci-pci-renesas when no external firmware EEPROM was attached. This allowed devices with a valid firmware stored in EEPROM to function without requiring xhci-pci-renesas. That commit changed the behavior, making xhci-pci-renesas responsible for handling these devices entirely, even when firmware was already present in EEPROM. As a result, unnecessary warnings about missing firmware files appeared, and more critically, USB functionality broke whens CONFIG_USB_XHCI_PCI_RENESAS was not enabled—despite previously workings without it. Fix this by ensuring that devices are only handed over to xhci-pci-renesas if the config option is enabled. Otherwise, restore the original behavior and handle them as standard xhci-pci devices. Signed-off-by: Nicolai Buchwitz <nb(a)tipi-net.de> Fixes: 25f51b76f90f ("xhci-pci: Make xhci-pci-renesas a proper modular driver") --- drivers/usb/host/xhci-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 2d1e205c14c60..4ce80d8ac603e 100644 --- a/drivers/usb/host/xhci-pci.c +++ b/drivers/usb/host/xhci-pci.c @@ -654,9 +654,11 @@ int xhci_pci_common_probe(struct pci_dev *dev, const struct pci_device_id *id) EXPORT_SYMBOL_NS_GPL(xhci_pci_common_probe, "xhci"); static const struct pci_device_id pci_ids_reject[] = { +#if IS_ENABLED(CONFIG_USB_XHCI_PCI_RENESAS) /* handled by xhci-pci-renesas */ { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, 0x0014) }, { PCI_DEVICE(PCI_VENDOR_ID_RENESAS, 0x0015) }, +#endif { /* end: all zeroes */ } }; -- 2.39.5

6 months, 1 week

3
4
0 0

[PATCH 6.1] efivars: Fix "BUG: corrupted list in efivar_entry_remove"

by Alexey Nepomnyashih

Prevent list corruption in efivar_entry_remove() and efivar_entry_list_del_unlock() by verifying that an entry is still in the list (list_empty() == false) before calling list_del(). Also reset the list pointers with INIT_LIST_HEAD() to avoid potential double-removal issues. Ensure robust handling of entries and prevent the kernel BUG observed when list_del() was called on an already-removed entry. Fix https://syzkaller.appspot.com/bug?extid=246ea4feed277471958a Syzkaller report: list_del corruption. prev->next should be ffff0000d86d6828, but was ffff800016216e60. (prev=ffff800016216e60) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:61! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 4299 Comm: syz-executor237 Not tainted 6.1.119-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 lr : __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 Call trace: __list_del_entry_valid+0x13c/0x158 lib/list_debug.c:59 __list_del_entry include/linux/list.h:134 [inline] list_del include/linux/list.h:148 [inline] efivar_entry_remove+0x38/0x110 fs/efivarfs/vars.c:493 efivarfs_destroy+0x20/0x3c fs/efivarfs/super.c:184 efivar_entry_iter+0x94/0xdc fs/efivarfs/vars.c:720 efivarfs_kill_sb+0x58/0x70 fs/efivarfs/super.c:258 deactivate_locked_super+0xac/0x124 fs/super.c:332 deactivate_super+0xf0/0x110 fs/super.c:363 cleanup_mnt+0x394/0x41c fs/namespace.c:1186 __cleanup_mnt+0x20/0x30 fs/namespace.c:1193 task_work_run+0x240/0x2f0 kernel/task_work.c:203 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] do_notify_resume+0x2080/0x2cb8 arch/arm64/kernel/signal.c:1132 prepare_exit_to_user_mode arch/arm64/kernel/entry-common.c:137 [inline] exit_to_user_mode arch/arm64/kernel/entry-common.c:142 [inline] el0_svc+0x9c/0x168 arch/arm64/kernel/entry-common.c:638 el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655 el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:585 Reported-by: syzbot+75dc11...(a)syzkaller.appspotmail.com Fixes: 2d82e6227ea1 ("efi: vars: Move efivar caching layer into efivarfs") Cc: stable(a)vger.kernel.org Signed-off-by: Alexey Nepomnyashih <sdl(a)nppct.ru> --- fs/efivarfs/vars.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/fs/efivarfs/vars.c b/fs/efivarfs/vars.c index 13bc60698955..42977138e30b 100644 --- a/fs/efivarfs/vars.c +++ b/fs/efivarfs/vars.c @@ -490,7 +490,10 @@ void __efivar_entry_add(struct efivar_entry *entry, struct list_head *head) */ void efivar_entry_remove(struct efivar_entry *entry) { - list_del(&entry->list); + if (!list_empty(&entry->list)) { + list_del(&entry->list); + INIT_LIST_HEAD(&entry->list); + } } /* @@ -506,7 +509,10 @@ void efivar_entry_remove(struct efivar_entry *entry) */ static void efivar_entry_list_del_unlock(struct efivar_entry *entry) { - list_del(&entry->list); + if (!list_empty(&entry->list)) { + list_del(&entry->list); + INIT_LIST_HEAD(&entry->list); + } efivar_unlock(); } -- 2.43.0

6 months, 1 week

2
1
0 0

[PATCH] ftrace: Avoid potential division by zero in function_stat_show()

by Nikolay Kuratov

Cases rec->counter == {0, 1} are checked already. While x * (x - 1) * 1000 = 0 have many solutions greater than 1 for both modulo 2^32 and 2^64, that is not the case for x * (x - 1) = 0, so split division into two. It is not scary in practice because mod 2^64 solutions are huge and minimal mod 2^32 solution is 30-bit number. Cc: stable(a)vger.kernel.org Fixes: e31f7939c1c27 ("ftrace: Avoid potential division by zero in function profiler") Signed-off-by: Nikolay Kuratov <kniv(a)yandex-team.ru> --- kernel/trace/ftrace.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 728ecda6e8d4..e1c05c4c29c2 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -570,12 +570,12 @@ static int function_stat_show(struct seq_file *m, void *v) stddev = rec->counter * rec->time_squared - rec->time * rec->time; + stddev = div64_ul(stddev, rec->counter * (rec->counter - 1)); /* * Divide only 1000 for ns^2 -> us^2 conversion. * trace_print_graph_duration will divide 1000 again. */ - stddev = div64_ul(stddev, - rec->counter * (rec->counter - 1) * 1000); + stddev = div64_ul(stddev, 1000); } trace_seq_init(&s); -- 2.34.1

6 months, 1 week

2
1
0 0

[PATCH 01/14] drm/i915/dp: Iterate DSC BPP from high to low on all platforms

by Jani Nikula

Commit 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp") tries to find the best compressed bpp for the link. However, it iterates from max to min bpp on display 13+, and from min to max on other platforms. This presumably leads to minimum compressed bpp always being chosen on display 11-12. Iterate from high to low on all platforms to actually use the best possible compressed bpp. Fixes: 1c56e9a39833 ("drm/i915/dp: Get optimal link config to have best compressed bpp") Cc: Ankit Nautiyal <ankit.k.nautiyal(a)intel.com> Cc: Imre Deak <imre.deak(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.7+ Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> --- drivers/gpu/drm/i915/display/intel_dp.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index d1b4fd542a1f..ecf192262eb9 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2073,11 +2073,10 @@ icl_dsc_compute_link_config(struct intel_dp *intel_dp, /* Compressed BPP should be less than the Input DSC bpp */ dsc_max_bpp = min(dsc_max_bpp, output_bpp - 1); - for (i = 0; i < ARRAY_SIZE(valid_dsc_bpp); i++) { - if (valid_dsc_bpp[i] < dsc_min_bpp) + for (i = ARRAY_SIZE(valid_dsc_bpp) - 1; i >= 0; i--) { + if (valid_dsc_bpp[i] < dsc_min_bpp || + valid_dsc_bpp[i] > dsc_max_bpp) continue; - if (valid_dsc_bpp[i] > dsc_max_bpp) - break; ret = dsc_compute_link_config(intel_dp, pipe_config, -- 2.39.5

6 months, 1 week

3
3
0 0

Re: [Fix CVE-2024-50217 in v6.6.y] [PATCH] btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()

by Greg KH

On Mon, Feb 03, 2025 at 11:40:11AM +0000, Shubham Pushpkar -X (spushpka - E INFOCHIPS PRIVATE LIMITED at Cisco) wrote: > Hi Greg, > > Thank you for your valuable feedback on my recent patch submission regarding the CVE fix. > > I appreciate your point about the CVE reference in the commit message. I will revise the patch to remove the CVE identifier, as it is indeed managed in the assignment database. > > Regarding the cc list, I apologize for not including everyone involved in the original commit. I will ensure to cc all relevant parties when I resubmit the patch to facilitate better communication and feedback. > > Thank you once again for your guidance. Please let me know if there are any additional changes or considerations I should be aware of. Yes, please always test your patches before sending them out. Because of a lack of testing here, I'm going to have to ask you to get a signed-off-by from another of your coworkers so that we know two people have verified that the change is correct and actually works for any future stuff you submit. thanks, greg k-h

6 months, 1 week

1
0
0 0

[PATCH 6.1] drm/amd/display: fix double free issue during amdgpu module unload

by Anastasia Belova

From: Tim Huang <tim.huang(a)amd.com> [ Upstream commit 20b5a8f9f4670a8503aa9fa95ca632e77c6bf55d ] Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] <TASK> [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] </TASK> Reviewed-by: Rodrigo Siqueira <rodrigo.siqueira(a)amd.com> Signed-off-by: Tim Huang <tim.huang(a)amd.com> Reviewed-by: Roman Li <roman.li(a)amd.com> Signed-off-by: Roman Li <roman.li(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [ Anastasia: link_destruct in drivers/gpu/drm/amd/display/dc/link/link_factory.c from upstream was dc_link_destruct in drivers/gpu/drm/amd/display/dc/core/dc_link.c in 6.1 ] Signed-off-by: Anastasia Belova <abelova(a)astralinux.ru> --- Backport fix for CVE-2024-49989 drivers/gpu/drm/amd/display/dc/core/dc_link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index bbaeb6c567d0..f0db2d58fd6b 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -83,7 +83,7 @@ static void dc_link_destruct(struct dc_link *link) if (link->panel_cntl) link->panel_cntl->funcs->destroy(&link->panel_cntl); - if (link->link_enc) { + if (link->link_enc && !link->is_dig_mapping_flexible) { /* Update link encoder resource tracking variables. These are used for * the dynamic assignment of link encoders to streams. Virtual links * are not assigned encoder resources on creation. -- 2.43.0

6 months, 1 week

1
0
0 0

[PATCH] x86/mm: Fix flush_tlb_range() when used for zapping normal PMDs

by Jann Horn

On the following path, flush_tlb_range() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table: collapse_pte_mapped_thp pmdp_collapse_flush flush_tlb_range The arm64 version of flush_tlb_range() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way. Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact: - In native_flush_tlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks. - In Hyper-V TLB paravirtualization, again for lazy TLB stuff. The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see <https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>) would probably be making the impact of this a lot worse. Cc: stable(a)vger.kernel.org Fixes: 016c4d92cd16 ("x86/mm/tlb: Add freed_tables argument to flush_tlb_mm_range") Signed-off-by: Jann Horn <jannh(a)google.com> --- arch/x86/include/asm/tlbflush.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h index 02fc2aa06e9e0ecdba3fe948cafe5892b72e86c0..3da645139748538daac70166618d8ad95116eb74 100644 --- a/arch/x86/include/asm/tlbflush.h +++ b/arch/x86/include/asm/tlbflush.h @@ -242,7 +242,7 @@ void flush_tlb_multi(const struct cpumask *cpumask, flush_tlb_mm_range((vma)->vm_mm, start, end, \ ((vma)->vm_flags & VM_HUGETLB) \ ? huge_page_shift(hstate_vma(vma)) \ - : PAGE_SHIFT, false) + : PAGE_SHIFT, true) extern void flush_tlb_all(void); extern void flush_tlb_mm_range(struct mm_struct *mm, unsigned long start, --- base-commit: aa135d1d0902c49ed45bec98c61c1b4022652b7e change-id: 20250103-x86-collapse-flush-fix-fa87ac4d5834 -- Jann Horn <jannh(a)google.com>

6 months, 1 week

4
6
0 0

Re: Patch "drm/ttm: Add ttm_bo_access" has been added to the 6.12-stable tree

by Christian König

Am 02.02.25 um 05:33 schrieb Sasha Levin: > This is a note to let you know that I've just added the patch titled > > drm/ttm: Add ttm_bo_access > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… This isn't a bug fix but a new feature and therefore shouldn't be backported. Regards, Christian. > > The filename of the patch is: > drm-ttm-add-ttm_bo_access.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit 73b922f15552bb5b47cbcca4b4d2b131b89b786d > Author: Matthew Brost <matthew.brost(a)intel.com> > Date: Tue Nov 26 09:46:09 2024 -0800 > > drm/ttm: Add ttm_bo_access > > [ Upstream commit 7d08df5d0bd3d12d14dcec773fcddbe3eed3a8e8 ] > > Non-contiguous VRAM cannot easily be mapped in TTM nor can non-visible > VRAM easily be accessed. Add ttm_bo_access, which is similar to > ttm_bo_vm_access, to access such memory. > > v4: > - Fix checkpatch warnings (CI) > v5: > - Fix checkpatch warnings (CI) > v6: > - Fix kernel doc (Auld) > v7: > - Move ttm_bo_access to ttm_bo_vm.c (Christian) > > Cc: Christian König <christian.koenig(a)amd.com> > Reported-by: Christoph Manszewski <christoph.manszewski(a)intel.com> > Suggested-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> > Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> > Tested-by: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> > Reviewed-by: Matthew Auld <matthew.auld(a)intel.com> > Reviewed-by: Christian König <christian.koenig(a)amd.com> > Link: https://patchwork.freedesktop.org/patch/msgid/20241126174615.2665852-3-matt… > Stable-dep-of: 5f7bec831f1f ("drm/xe: Use ttm_bo_access in xe_vm_snapshot_capture_delayed") > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c > index 4212b8c91dd42..17667ab31ad4c 100644 > --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c > +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c > @@ -405,13 +405,25 @@ static int ttm_bo_vm_access_kmap(struct ttm_buffer_object *bo, > return len; > } > > -int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, > - void *buf, int len, int write) > +/** > + * ttm_bo_access - Helper to access a buffer object > + * > + * @bo: ttm buffer object > + * @offset: access offset into buffer object > + * @buf: pointer to caller memory to read into or write from > + * @len: length of access > + * @write: write access > + * > + * Utility function to access a buffer object. Useful when buffer object cannot > + * be easily mapped (non-contiguous, non-visible, etc...). Should not directly > + * be exported to user space via a peak / poke interface. > + * > + * Returns: > + * @len if successful, negative error code on failure. > + */ > +int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset, > + void *buf, int len, int write) > { > - struct ttm_buffer_object *bo = vma->vm_private_data; > - unsigned long offset = (addr) - vma->vm_start + > - ((vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node)) > - << PAGE_SHIFT); > int ret; > > if (len < 1 || (offset + len) > bo->base.size) > @@ -429,8 +441,8 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, > break; > default: > if (bo->bdev->funcs->access_memory) > - ret = bo->bdev->funcs->access_memory( > - bo, offset, buf, len, write); > + ret = bo->bdev->funcs->access_memory > + (bo, offset, buf, len, write); > else > ret = -EIO; > } > @@ -439,6 +451,18 @@ int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, > > return ret; > } > +EXPORT_SYMBOL(ttm_bo_access); > + > +int ttm_bo_vm_access(struct vm_area_struct *vma, unsigned long addr, > + void *buf, int len, int write) > +{ > + struct ttm_buffer_object *bo = vma->vm_private_data; > + unsigned long offset = (addr) - vma->vm_start + > + ((vma->vm_pgoff - drm_vma_node_start(&bo->base.vma_node)) > + << PAGE_SHIFT); > + > + return ttm_bo_access(bo, offset, buf, len, write); > +} > EXPORT_SYMBOL(ttm_bo_vm_access); > > static const struct vm_operations_struct ttm_bo_vm_ops = { > diff --git a/include/drm/ttm/ttm_bo.h b/include/drm/ttm/ttm_bo.h > index 7b56d1ca36d75..e383dee82001e 100644 > --- a/include/drm/ttm/ttm_bo.h > +++ b/include/drm/ttm/ttm_bo.h > @@ -421,6 +421,8 @@ void ttm_bo_unpin(struct ttm_buffer_object *bo); > int ttm_bo_evict_first(struct ttm_device *bdev, > struct ttm_resource_manager *man, > struct ttm_operation_ctx *ctx); > +int ttm_bo_access(struct ttm_buffer_object *bo, unsigned long offset, > + void *buf, int len, int write); > vm_fault_t ttm_bo_vm_reserve(struct ttm_buffer_object *bo, > struct vm_fault *vmf); > vm_fault_t ttm_bo_vm_fault_reserved(struct vm_fault *vmf,

6 months, 1 week

2
2
0 0

[PATCH] Input: ads7846 - fix gpiod allocation

by H. Nikolaus Schaller

commit 767d83361aaa ("Input: ads7846 - Convert to use software nodes") has simplified the code but accidentially converted a devm_gpiod_get() to gpiod_get(). This leaves the gpio reserved on module remove and the driver can no longer be loaded again. Fixes: 767d83361aaa ("Input: ads7846 - Convert to use software nodes") Cc: <stable(a)vger.kernel.org> Signed-off-by: H. Nikolaus Schaller <hns(a)goldelico.com> --- drivers/input/touchscreen/ads7846.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/ads7846.c b/drivers/input/touchscreen/ads7846.c index 066dc04003fa8..67264c5b49cb4 100644 --- a/drivers/input/touchscreen/ads7846.c +++ b/drivers/input/touchscreen/ads7846.c @@ -1021,7 +1021,7 @@ static int ads7846_setup_pendown(struct spi_device *spi, if (pdata->get_pendown_state) { ts->get_pendown_state = pdata->get_pendown_state; } else { - ts->gpio_pendown = gpiod_get(&spi->dev, "pendown", GPIOD_IN); + ts->gpio_pendown = devm_gpiod_get(&spi->dev, "pendown", GPIOD_IN); if (IS_ERR(ts->gpio_pendown)) { dev_err(&spi->dev, "failed to request pendown GPIO\n"); return PTR_ERR(ts->gpio_pendown); -- 2.47.0

6 months, 1 week

2
1
0 0

[PATCH v2] tee: optee: Fix supplicant wait loop

by Sumit Garg

OP-TEE supplicant is a user-space daemon and it's possible for it being hung or crashed or killed in the middle of processing an OP-TEE RPC call. It becomes more complicated when there is incorrect shutdown ordering of the supplicant process vs the OP-TEE client application which can eventually lead to system hang-up waiting for the closure of the client application. Allow the client process waiting in kernel for supplicant response to be killed rather than indefinitetly waiting in an unkillable state. This fixes issues observed during system reboot/shutdown when supplicant got hung for some reason or gets crashed/killed which lead to client getting hung in an unkillable state. It in turn lead to system being in hung up state requiring hard power off/on to recover. Fixes: 4fb0a5eb364d ("tee: add OP-TEE driver") Suggested-by: Arnd Bergmann <arnd(a)arndb.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Sumit Garg <sumit.garg(a)linaro.org> --- Changes in v2: - Switch to killable wait instead as suggested by Arnd instead of supplicant timeout. It atleast allow the client to wait for supplicant in killable state which in turn allows system to reboot or shutdown gracefully. drivers/tee/optee/supp.c | 32 +++++++------------------------- 1 file changed, 7 insertions(+), 25 deletions(-) diff --git a/drivers/tee/optee/supp.c b/drivers/tee/optee/supp.c index 322a543b8c27..3fbfa9751931 100644 --- a/drivers/tee/optee/supp.c +++ b/drivers/tee/optee/supp.c @@ -80,7 +80,6 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, struct optee *optee = tee_get_drvdata(ctx->teedev); struct optee_supp *supp = &optee->supp; struct optee_supp_req *req; - bool interruptable; u32 ret; /* @@ -111,36 +110,19 @@ u32 optee_supp_thrd_req(struct tee_context *ctx, u32 func, size_t num_params, /* * Wait for supplicant to process and return result, once we've * returned from wait_for_completion(&req->c) successfully we have - * exclusive access again. + * exclusive access again. Allow the wait to be killable such that + * the wait doesn't turn into an indefinite state if the supplicant + * gets hung for some reason. */ - while (wait_for_completion_interruptible(&req->c)) { - mutex_lock(&supp->mutex); - interruptable = !supp->ctx; - if (interruptable) { - /* - * There's no supplicant available and since the - * supp->mutex currently is held none can - * become available until the mutex released - * again. - * - * Interrupting an RPC to supplicant is only - * allowed as a way of slightly improving the user - * experience in case the supplicant hasn't been - * started yet. During normal operation the supplicant - * will serve all requests in a timely manner and - * interrupting then wouldn't make sense. - */ + if (wait_for_completion_killable(&req->c)) { + if (!mutex_lock_killable(&supp->mutex)) { if (req->in_queue) { list_del(&req->link); req->in_queue = false; } + mutex_unlock(&supp->mutex); } - mutex_unlock(&supp->mutex); - - if (interruptable) { - req->ret = TEEC_ERROR_COMMUNICATION; - break; - } + req->ret = TEEC_ERROR_COMMUNICATION; } ret = req->ret; -- 2.43.0

6 months, 1 week

3
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025