February 2025 - Linux-stable-mirror

[PATCH v2 1/3] drm/xe/userptr: restore invalidation list on error

by Matthew Auld

On error restore anything still on the pin_list back to the invalidation list on error. For the actual pin, so long as the vma is tracked on either list it should get picked up on the next pin, however it looks possible for the vma to get nuked but still be present on this per vm pin_list leading to corruption. An alternative might be then to instead just remove the link when destroying the vma. Fixes: ed2bdf3b264d ("drm/xe/vm: Subclass userptr vmas") Suggested-by: Matthew Brost <matthew.brost(a)intel.com> Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ --- drivers/gpu/drm/xe/xe_vm.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index d664f2e418b2..668b0bde7822 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -670,12 +670,12 @@ int xe_vm_userptr_pin(struct xe_vm *vm) list_for_each_entry_safe(uvma, next, &vm->userptr.invalidated, userptr.invalidate_link) { list_del_init(&uvma->userptr.invalidate_link); - list_move_tail(&uvma->userptr.repin_link, - &vm->userptr.repin_list); + list_add_tail(&uvma->userptr.repin_link, + &vm->userptr.repin_list); } spin_unlock(&vm->userptr.invalidated_lock); - /* Pin and move to temporary list */ + /* Pin and move to bind list */ list_for_each_entry_safe(uvma, next, &vm->userptr.repin_list, userptr.repin_link) { err = xe_vma_userptr_pin_pages(uvma); @@ -691,10 +691,10 @@ int xe_vm_userptr_pin(struct xe_vm *vm) err = xe_vm_invalidate_vma(&uvma->vma); xe_vm_unlock(vm); if (err) - return err; + break; } else { - if (err < 0) - return err; + if (err) + break; list_del_init(&uvma->userptr.repin_link); list_move_tail(&uvma->vma.combined_links.rebind, @@ -702,7 +702,19 @@ int xe_vm_userptr_pin(struct xe_vm *vm) } } - return 0; + if (err) { + down_write(&vm->userptr.notifier_lock); + spin_lock(&vm->userptr.invalidated_lock); + list_for_each_entry_safe(uvma, next, &vm->userptr.repin_list, + userptr.repin_link) { + list_del_init(&uvma->userptr.repin_link); + list_move_tail(&uvma->userptr.invalidate_link, + &vm->userptr.invalidated); + } + spin_unlock(&vm->userptr.invalidated_lock); + up_write(&vm->userptr.notifier_lock); + } + return err; } /** -- 2.48.1

1 week, 6 days

3
11
0 0

[PATCH 0/5] arm64: dts: rockchip: pinmux fixes and support for 2 adapters for Theobroma boards

by Quentin Schulz

This is based on top of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git/lo… 6ee0b9ad3995 ("arm64: dts: rockchip: Add rng node to RK3588") as it depends on the (merged) series from https://lore.kernel.org/all/20250211-pre-ict-jaguar-v6-0-4484b0f88cfc@cherr… Patches for Haikou Video Demo adapter for PX30 Ringneck and RK3399 Puma (patches 4 and 5) also depend on the following patch series: https://lore.kernel.org/linux-devicetree/20250220-pca976x-reset-driver-v1-0… This fixes incorrect pinmux on UART0 and UART5 for PX30 Ringneck on Haikou. This adds support for the HAIKOU-LVDS-9904379 adapter for PX30 Ringneck fitted on a Haikou carrierboard. Additionally, this adds support for Haikou Video Demo adapter on PX30 Ringneck and RK3399 Puma fitted on a Haikou carrierboard. Notably missing from the overlay is the OV5675 camera module which expects 19.2MHz which we cannot exactly feed right now. Modifications to the OV5675 drivers will be made so it's more flexible and then support for the camera module will be added. This adapter has a 720x1280 DSI display with a GT911 touchscreen, a GPIO-controllable LED and an I2C GPIO expander. Support for this adapter on RK3588 Tiger is being added in a separate patch series[1]. Note that the DSI panel currently is glitchy on both PX30 Ringneck and RK3399 Puma but this is being tackled in another series[2]. Since this will not be fixed through DT properties for the panel, adding the DT nodes for the DSI panel even if not perfect right now seems acceptable to me. [1] https://lore.kernel.org/linux-rockchip/20241127143719.660658-1-heiko@sntech… [2] https://lore.kernel.org/r/20240626084722.832763-1-heiko@sntech.de Signed-off-by: Quentin Schulz <quentin.schulz(a)cherry.de> --- Quentin Schulz (5): arm64: dts: rockchip: fix pinmux of UART0 for PX30 Ringneck on Haikou arm64: dts: rockchip: fix pinmux of UART5 for PX30 Ringneck on Haikou arm64: dts: rockchip: add support for HAIKOU-LVDS-9904379 adapter for PX30 Ringneck arm64: dts: rockchip: add overlay for PX30 Ringneck Haikou Video Demo adapter arm64: dts: rockchip: add overlay for RK3399 Puma Haikou Video Demo adapter arch/arm64/boot/dts/rockchip/Makefile | 15 ++ .../px30-ringneck-haikou-lvds-9904379.dtso | 130 ++++++++++++++ .../rockchip/px30-ringneck-haikou-video-demo.dtso | 190 +++++++++++++++++++++ .../boot/dts/rockchip/px30-ringneck-haikou.dts | 10 +- .../rockchip/rk3399-puma-haikou-video-demo.dtso | 166 ++++++++++++++++++ 5 files changed, 510 insertions(+), 1 deletion(-) --- base-commit: 6ee0b9ad3995ee5fa229035c69013b7dd0d3634b change-id: 20250128-ringneck-dtbos-98064839355e prerequisite-change-id: 20250219-pca976x-reset-driver-c9aa95869426:v1 prerequisite-patch-id: 24af74693654b4a456aca0a1399ec8509e141c01 prerequisite-patch-id: df17910ec117317f2f456f679a77ed60e9168fa3 Best regards, -- Quentin Schulz <quentin.schulz(a)cherry.de>

1 week, 6 days

4
5
0 0

[PATCH v2] Bluetooth: Add check for mgmt_alloc_skb() in mgmt_device_connected()

by Haoxiang Li

Add check for the return value of mgmt_alloc_skb() in mgmt_device_connected() to prevent null pointer dereference. Fixes: e96741437ef0 ("Bluetooth: mgmt: Make use of mgmt_send_event_skb in MGMT_EV_DEVICE_CONNECTED") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- Changes in v2: - modify the title description. --- net/bluetooth/mgmt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index f53304cb09db..f1a9f58d1c7e 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -9659,7 +9659,8 @@ void mgmt_device_connected(struct hci_dev *hdev, struct hci_conn *conn, skb = mgmt_alloc_skb(hdev, MGMT_EV_DEVICE_CONNECTED, sizeof(*ev) + (name ? eir_precalc_len(name_len) : 0) + eir_precalc_len(sizeof(conn->dev_class))); - + if (!skb) + return; ev = skb_put(skb, sizeof(*ev)); bacpy(&ev->addr.bdaddr, &conn->dst); ev->addr.type = link_to_bdaddr(conn->type, conn->dst_type); -- 2.25.1

1 week, 6 days

1
0
0 0

[PATCH 0/2] driver core: platform: avoid use-after-free on device name

by Théo Lebrun

The use-after-free bug appears when: - A platform device is created from OF, by of_device_add(); - The same device's name is changed afterwards using dev_set_name(), by its probe for example. Out of the 37 drivers that deal with platform devices and do a dev_set_name() call, only one might be affected. That driver is loongson-i2s-plat [0]. All other dev_set_name() calls are on children devices created on the spot. The issue was found on downstream kernels and we don't have what it takes to test loongson-i2s-plat. Note: loongson-i2s-plat maintainers are CCed. ⟩ # Finding potential trouble-makers: ⟩ git grep -l 'struct platform_device' | xargs grep -l dev_set_name The solution proposed is to add a flag to platform_device that tells if it is responsible for freeing its name. We can then duplicate the device name inside of_device_add() instead of copying the pointer. What is done elsewhere? - Platform bus code does a copy of the argument name that is stored alongside the struct platform_device; see platform_device_alloc()[1]. - Other busses duplicate the device name; either through a dynamic allocation [2] or through an array embedded inside devices [3]. - Some busses don't have a separate name; when they want a name they take it from the device [4]. [0]: https://elixir.bootlin.com/linux/v6.13.2/source/sound/soc/loongson/loongson… [1]: https://elixir.bootlin.com/linux/v6.13.2/source/drivers/base/platform.c#L581 [2]: https://elixir.bootlin.com/linux/v6.13.2/source/drivers/gpu/drm/drm_drv.c#L… [3]: https://elixir.bootlin.com/linux/v6.13.2/source/include/linux/i2c.h#L343 [4]: https://elixir.bootlin.com/linux/v6.13.2/source/include/linux/pci.h#L2150 This can be reproduced using Buildroot's qemu_aarch64_virt_defconfig with CONFIG_KASAN=y and a dev_set_name() inside the probe of: drivers/pci/controller/pci-host-common.c The below splat appears at boot. It happens whenever something tries to access pdev->name; one big consumer of this field is platform_match() that fallbacks to name matching. ================================================================== BUG: KASAN: slab-use-after-free in strcmp+0x2c/0x78 Read of size 1 at addr ffffff80c0300160 by task swapper/0/1 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.32 #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x90/0xe8 show_stack+0x18/0x24 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xcc __asan_load1+0x60/0x6c strcmp+0x2c/0x78 platform_match+0xd0/0x140 __driver_attach+0x44/0x240 bus_for_each_dev+0xe4/0x160 driver_attach+0x34/0x44 bus_add_driver+0x134/0x270 driver_register+0xa4/0x1e4 __platform_driver_register+0x44/0x54 ged_driver_init+0x1c/0x28 do_one_initcall+0xdc/0x260 kernel_init_freeable+0x314/0x448 kernel_init+0x2c/0x1e0 ret_from_fork+0x10/0x20 Allocated by task 1: kasan_save_stack+0x3c/0x64 kasan_set_track+0x2c/0x40 kasan_save_alloc_info+0x24/0x34 __kasan_kmalloc+0xb8/0xbc __kmalloc_node_track_caller+0x64/0xa4 kvasprintf+0xcc/0x16c kvasprintf_const+0xe8/0x180 kobject_set_name_vargs+0x54/0xd4 dev_set_name+0xa8/0xe4 of_device_make_bus_id+0x298/0x2b0 of_device_alloc+0x1ec/0x204 of_platform_device_create_pdata+0x60/0x168 of_platform_bus_create+0x20c/0x4a0 of_platform_populate+0x50/0x10c of_platform_default_populate_init+0xe0/0x100 do_one_initcall+0xdc/0x260 kernel_init_freeable+0x314/0x448 kernel_init+0x2c/0x1e0 ret_from_fork+0x10/0x20 Freed by task 1: kasan_save_stack+0x3c/0x64 kasan_set_track+0x2c/0x40 kasan_save_free_info+0x38/0x60 __kasan_slab_free+0xe4/0x150 __kmem_cache_free+0x134/0x26c kfree+0x54/0x6c kfree_const+0x34/0x40 kobject_set_name_vargs+0xa8/0xd4 dev_set_name+0xa8/0xe4 pci_host_common_probe+0x9c/0x294 platform_probe+0x90/0x100 really_probe+0x100/0x3cc __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xc8/0x240 bus_for_each_dev+0xe4/0x160 driver_attach+0x34/0x44 bus_add_driver+0x134/0x270 driver_register+0xa4/0x1e4 __platform_driver_register+0x44/0x54 gen_pci_driver_init+0x1c/0x28 do_one_initcall+0xdc/0x260 kernel_init_freeable+0x314/0x448 kernel_init+0x2c/0x1e0 ret_from_fork+0x10/0x20 The buggy address belongs to the object at ffffff80c0300160 which belongs to the cache kmalloc-16 of size 16 The buggy address is located 0 bytes inside of freed 16-byte region [ffffff80c0300160, ffffff80c0300170) The buggy address belongs to the physical page: page:0000000099fe29a0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x100300 flags: 0x8000000000000800(slab|zone=2) page_type: 0xffffffff() raw: 8000000000000800 ffffff80c00013c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080800080 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffff80c0300000: fa fb fc fc fa fb fc fc 00 07 fc fc 00 07 fc fc ffffff80c0300080: 00 07 fc fc 00 02 fc fc 00 02 fc fc 00 02 fc fc >ffffff80c0300100: 00 06 fc fc 00 06 fc fc 00 06 fc fc fa fb fc fc ^ ffffff80c0300180: 00 00 fc fc 00 00 fc fc 00 06 fc fc 00 06 fc fc ffffff80c0300200: 00 06 fc fc 00 06 fc fc 00 06 fc fc 00 06 fc fc ================================================================== Signed-off-by: Théo Lebrun <theo.lebrun(a)bootlin.com> --- Théo Lebrun (2): driver core: platform: turn pdev->id_auto into pdev->flags driver core: platform: avoid use-after-free on pdev->name drivers/base/platform.c | 8 +++++--- drivers/of/platform.c | 12 +++++++++++- include/linux/platform_device.h | 4 +++- 3 files changed, 19 insertions(+), 5 deletions(-) --- base-commit: 0ad2507d5d93f39619fc42372c347d6006b64319 change-id: 20250217-pdev-uaf-1a779a98d81b Best regards, -- Théo Lebrun <theo.lebrun(a)bootlin.com>

1 week, 6 days

3
10
0 0

[PATCH 1/1] iommu/vt-d: Fix suspicious RCU usage

by Lu Baolu

Commit <d74169ceb0d2> ("iommu/vt-d: Allocate DMAR fault interrupts locally") moved the call to enable_drhd_fault_handling() to a code path that does not hold any lock while traversing the drhd list. Fix it by ensuring the dmar_global_lock lock is held when traversing the drhd list. Without this fix, the following warning is triggered: ============================= WARNING: suspicious RCU usage 6.14.0-rc3 #55 Not tainted ----------------------------- drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 1 2 locks held by cpuhp/1/23: #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0 stack backtrace: CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55 Call Trace: <TASK> dump_stack_lvl+0xb7/0xd0 lockdep_rcu_suspicious+0x159/0x1f0 ? __pfx_enable_drhd_fault_handling+0x10/0x10 enable_drhd_fault_handling+0x151/0x180 cpuhp_invoke_callback+0x1df/0x990 cpuhp_thread_fun+0x1ea/0x2c0 smpboot_thread_fn+0x1f5/0x2e0 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x12a/0x2d0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4a/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Simply holding the lock in enable_drhd_fault_handling() will trigger a lock order splat. Avoid holding the dmar_global_lock when calling iommu_device_register(), which starts the device probe process. Fixes: d74169ceb0d2 ("iommu/vt-d: Allocate DMAR fault interrupts locally") Reported-by: Ido Schimmel <idosch(a)idosch.org> Closes: https://lore.kernel.org/linux-iommu/Zx9OwdLIc_VoQ0-a@shredder.mtl.com/ Cc: stable(a)vger.kernel.org Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> --- drivers/iommu/intel/dmar.c | 1 + drivers/iommu/intel/iommu.c | 7 +++++++ 2 files changed, 8 insertions(+) diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 9f424acf474e..e540092d664d 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -2043,6 +2043,7 @@ int enable_drhd_fault_handling(unsigned int cpu) /* * Enable fault control interrupt. */ + guard(rwsem_read)(&dmar_global_lock); for_each_iommu(iommu, drhd) { u32 fault_status; int ret; diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index cc46098f875b..9a1e61b429ca 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3146,7 +3146,14 @@ int __init intel_iommu_init(void) iommu_device_sysfs_add(&iommu->iommu, NULL, intel_iommu_groups, "%s", iommu->name); + /* + * The iommu device probe is protected by the iommu_probe_device_lock. + * Release the dmar_global_lock before entering the device probe path + * to avoid unnecessary lock order splat. + */ + up_read(&dmar_global_lock); iommu_device_register(&iommu->iommu, &intel_iommu_ops, NULL); + down_read(&dmar_global_lock); iommu_pmu_register(iommu); } -- 2.43.0

1 week, 6 days

5
6
0 0

[PATCH v6 4/8] crypto: ccp: Fix uapi definitions of PSP errors

by Dionna Glaze

From: Alexey Kardashevskiy <aik(a)amd.com> Additions to the error enum after the explicit 0x27 setting for SEV_RET_INVALID_KEY leads to incorrect value assignments. Use explicit values to match the manufacturer specifications more clearly. Fixes: 3a45dc2b419e ("crypto: ccp: Define the SEV-SNP commands") CC: Sean Christopherson <seanjc(a)google.com> CC: Paolo Bonzini <pbonzini(a)redhat.com> CC: Thomas Gleixner <tglx(a)linutronix.de> CC: Ingo Molnar <mingo(a)redhat.com> CC: Borislav Petkov <bp(a)alien8.de> CC: Dave Hansen <dave.hansen(a)linux.intel.com> CC: Ashish Kalra <ashish.kalra(a)amd.com> CC: Tom Lendacky <thomas.lendacky(a)amd.com> CC: John Allen <john.allen(a)amd.com> CC: Herbert Xu <herbert(a)gondor.apana.org.au> CC: "David S. Miller" <davem(a)davemloft.net> CC: Michael Roth <michael.roth(a)amd.com> CC: Luis Chamberlain <mcgrof(a)kernel.org> CC: Russ Weight <russ.weight(a)linux.dev> CC: Danilo Krummrich <dakr(a)redhat.com> CC: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> CC: "Rafael J. Wysocki" <rafael(a)kernel.org> CC: Tianfei zhang <tianfei.zhang(a)intel.com> CC: Alexey Kardashevskiy <aik(a)amd.com> CC: stable(a)vger.kernel.org Signed-off-by: Alexey Kardashevskiy <aik(a)amd.com> Signed-off-by: Dionna Glaze <dionnaglaze(a)google.com> --- include/uapi/linux/psp-sev.h | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/include/uapi/linux/psp-sev.h b/include/uapi/linux/psp-sev.h index 832c15d9155bd..eeb20dfb1fdaa 100644 --- a/include/uapi/linux/psp-sev.h +++ b/include/uapi/linux/psp-sev.h @@ -73,13 +73,20 @@ typedef enum { SEV_RET_INVALID_PARAM, SEV_RET_RESOURCE_LIMIT, SEV_RET_SECURE_DATA_INVALID, - SEV_RET_INVALID_KEY = 0x27, - SEV_RET_INVALID_PAGE_SIZE, - SEV_RET_INVALID_PAGE_STATE, - SEV_RET_INVALID_MDATA_ENTRY, - SEV_RET_INVALID_PAGE_OWNER, - SEV_RET_INVALID_PAGE_AEAD_OFLOW, - SEV_RET_RMP_INIT_REQUIRED, + SEV_RET_INVALID_PAGE_SIZE = 0x0019, + SEV_RET_INVALID_PAGE_STATE = 0x001A, + SEV_RET_INVALID_MDATA_ENTRY = 0x001B, + SEV_RET_INVALID_PAGE_OWNER = 0x001C, + SEV_RET_AEAD_OFLOW = 0x001D, + SEV_RET_EXIT_RING_BUFFER = 0x001F, + SEV_RET_RMP_INIT_REQUIRED = 0x0020, + SEV_RET_BAD_SVN = 0x0021, + SEV_RET_BAD_VERSION = 0x0022, + SEV_RET_SHUTDOWN_REQUIRED = 0x0023, + SEV_RET_UPDATE_FAILED = 0x0024, + SEV_RET_RESTORE_REQUIRED = 0x0025, + SEV_RET_RMP_INITIALIZATION_FAILED = 0x0026, + SEV_RET_INVALID_KEY = 0x0027, SEV_RET_MAX, } sev_ret_code; -- 2.47.0.277.g8800431eea-goog

1 week, 6 days

4
4
0 0

[PATCH v3] ufs: core: bsg: Fix memory crash in case arpmb command failed

by Arthur Simchaev

In case the device doesn't support arpmb, the kernel get memory crash due to copy user data in bsg_transport_sg_io_fn level. So in case ufs_bsg_exec_advanced_rpmb_req returned error, do not set the job's reply_len. Memory crash backtrace: 3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22 4,1308,531166555,-;Call Trace: 4,1309,531166559,-; <TASK> 4,1310,531166565,-; ? show_regs+0x6d/0x80 4,1311,531166575,-; ? die+0x37/0xa0 4,1312,531166583,-; ? do_trap+0xd4/0xf0 4,1313,531166593,-; ? do_error_trap+0x71/0xb0 4,1314,531166601,-; ? usercopy_abort+0x6c/0x80 4,1315,531166610,-; ? exc_invalid_op+0x52/0x80 4,1316,531166622,-; ? usercopy_abort+0x6c/0x80 4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20 4,1318,531166643,-; ? usercopy_abort+0x6c/0x80 4,1319,531166652,-; __check_heap_object+0xe3/0x120 4,1320,531166661,-; check_heap_object+0x185/0x1d0 4,1321,531166670,-; __check_object_size.part.0+0x72/0x150 4,1322,531166679,-; __check_object_size+0x23/0x30 4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0 Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg") Cc: stable(a)vger.kernel.org Reviewed-by: Bean Huo <beanhuo(a)micron.com> Signed-off-by: Arthur Simchaev <arthur.simchaev(a)sandisk.com> --- Changes in v3: - changing !rpmb into rpmb and by swapping the two sizeof() expressions --- Changes in v2: - Add Fixes tag - Elaborate commit log --- drivers/ufs/core/ufs_bsg.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/ufs/core/ufs_bsg.c b/drivers/ufs/core/ufs_bsg.c index 8d4ad0a3f2cf..252186124669 100644 --- a/drivers/ufs/core/ufs_bsg.c +++ b/drivers/ufs/core/ufs_bsg.c @@ -194,10 +194,12 @@ static int ufs_bsg_request(struct bsg_job *job) ufshcd_rpm_put_sync(hba); kfree(buff); bsg_reply->result = ret; - job->reply_len = !rpmb ? sizeof(struct ufs_bsg_reply) : sizeof(struct ufs_rpmb_reply); /* complete the job here only if no error */ - if (ret == 0) + if (ret == 0) { + job->reply_len = rpmb ? sizeof(struct ufs_rpmb_reply) : + sizeof(struct ufs_bsg_reply); bsg_job_done(job, ret, bsg_reply->reply_payload_rcv_len); + } return ret; } -- 2.34.1

1 week, 6 days

3
2
0 0

[PATCH v2] drm/i915/display: Add check for alloc_ordered_workqueue() and alloc_workqueue()

by Haoxiang Li

Add check for the return value of alloc_ordered_workqueue() and alloc_workqueue(). Furthermore, if some allocations fail, cleanup works are added to avoid potential memory leak problem. Fixes: 40053823baad ("drm/i915/display: move modeset probe/remove functions to intel_display_driver.c") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <haoxiang_li2024(a)163.com> --- Changes in v2: - Split the compound conditional statement into separate conditional statements to facilitate cleanup works. - Add cleanup works to destory work queues if allocations fail, and modify the later goto destination to do the full excercise. - modify the patch description. Thanks, Jani! --- .../drm/i915/display/intel_display_driver.c | 29 +++++++++++++++---- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c b/drivers/gpu/drm/i915/display/intel_display_driver.c index 50ec0c3c7588..0b9971a5626b 100644 --- a/drivers/gpu/drm/i915/display/intel_display_driver.c +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c @@ -241,31 +241,44 @@ int intel_display_driver_probe_noirq(struct intel_display *display) intel_dmc_init(display); display->wq.modeset = alloc_ordered_workqueue("i915_modeset", 0); + if (!display->wq.modeset) { + ret = -ENOMEM; + goto cleanup_vga_client_pw_domain_dmc; + } + display->wq.flip = alloc_workqueue("i915_flip", WQ_HIGHPRI | WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE); + if (!display->wq.flip) { + ret = -ENOMEM; + goto cleanup_wq_modeset; + } display->wq.cleanup = alloc_workqueue("i915_cleanup", WQ_HIGHPRI, 0); + if (!display->wq.cleanup) { + ret = -ENOMEM; + goto cleanup_wq_flip; + } intel_mode_config_init(display); ret = intel_cdclk_init(display); if (ret) - goto cleanup_vga_client_pw_domain_dmc; + goto cleanup_wq_cleanup; ret = intel_color_init(display); if (ret) - goto cleanup_vga_client_pw_domain_dmc; + goto cleanup_wq_cleanup; ret = intel_dbuf_init(i915); if (ret) - goto cleanup_vga_client_pw_domain_dmc; + goto cleanup_wq_cleanup; ret = intel_bw_init(i915); if (ret) - goto cleanup_vga_client_pw_domain_dmc; + goto cleanup_wq_cleanup; ret = intel_pmdemand_init(display); if (ret) - goto cleanup_vga_client_pw_domain_dmc; + goto cleanup_wq_cleanup; intel_init_quirks(display); @@ -273,6 +286,12 @@ int intel_display_driver_probe_noirq(struct intel_display *display) return 0; +cleanup_wq_cleanup: + destroy_workqueue(display->wq.cleanup); +cleanup_wq_flip: + destroy_workqueue(display->wq.flip); +cleanup_wq_modeset: + destroy_workqueue(display->wq.modeset); cleanup_vga_client_pw_domain_dmc: intel_dmc_fini(display); intel_power_domains_driver_remove(display); -- 2.25.1

1 week, 6 days

1
0
0 0

[PATCH net V3] net: stmmac: dwmac-loongson: Add fix_soc_reset() callback

by Qunqin Zhao

Loongson's DWMAC device may take nearly two seconds to complete DMA reset, however, the default waiting time for reset is 200 milliseconds. Therefore, the following error message may appear: [14.427169] dwmac-loongson-pci 0000:00:03.2: Failed to reset the dma Fixes: 803fc61df261 ("net: stmmac: dwmac-loongson: Add Loongson Multi-channels GMAC support") Cc: stable(a)vger.kernel.org Signed-off-by: Qunqin Zhao <zhaoqunqin(a)loongson.cn> Reviewed-by: Huacai Chen <chenhuacai(a)loongson.cn> --- v3: Added "Cc: stable(a)vger.kernel.org" tag. Added error message to commit message. v2: Added comments. Changed callback name to loongson_dwmac_fix_reset. .../net/ethernet/stmicro/stmmac/dwmac-loongson.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c index bfe6e2d631bd..f5acfb7d4ff6 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c @@ -516,6 +516,19 @@ static int loongson_dwmac_acpi_config(struct pci_dev *pdev, return 0; } +/* Loongson's DWMAC device may take nearly two seconds to complete DMA reset */ +static int loongson_dwmac_fix_reset(void *priv, void __iomem *ioaddr) +{ + u32 value = readl(ioaddr + DMA_BUS_MODE); + + value |= DMA_BUS_MODE_SFT_RESET; + writel(value, ioaddr + DMA_BUS_MODE); + + return readl_poll_timeout(ioaddr + DMA_BUS_MODE, value, + !(value & DMA_BUS_MODE_SFT_RESET), + 10000, 2000000); +} + static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id *id) { struct plat_stmmacenet_data *plat; @@ -566,6 +579,7 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id plat->bsp_priv = ld; plat->setup = loongson_dwmac_setup; + plat->fix_soc_reset = loongson_dwmac_fix_reset; ld->dev = &pdev->dev; ld->loongson_id = readl(res.addr + GMAC_VERSION) & 0xff; base-commit: a64dcfb451e254085a7daee5fe51bf22959d52d3 -- 2.43.0

1 week, 6 days

4
3
0 0

[PATCH RFT 4/5] phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power off

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> Assert PLL reset on PHY power off. This saves power. Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver") Cc: stable(a)vger.kernel.org Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- drivers/phy/renesas/phy-rcar-gen3-usb2.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c b/drivers/phy/renesas/phy-rcar-gen3-usb2.c index 5c0ceba09b67..087937407b0b 100644 --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c @@ -537,9 +537,16 @@ static int rcar_gen3_phy_usb2_power_off(struct phy *p) struct rcar_gen3_chan *channel = rphy->ch; int ret = 0; - scoped_guard(spinlock_irqsave, &channel->lock) + scoped_guard(spinlock_irqsave, &channel->lock) { rphy->powered = false; + if (rcar_gen3_are_all_rphys_power_off(channel)) { + u32 val = readl(channel->base + USB2_USBCTR); + val |= USB2_USBCTR_PLL_RST; + writel(val, channel->base + USB2_USBCTR); + } + } + if (channel->vbus) ret = regulator_disable(channel->vbus); -- 2.43.0

1 week, 6 days

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror February 2025