- Linux-stable-mirror - lists.linaro.org

[PATCH v1] xhci: dbgtty: fix device unregister

by Łukasz Bartosik

From: Łukasz Bartosik <ukaszb(a)chromium.org> When DbC is disconnected then xhci_dbc_tty_unregister_device() is called. However if there is any user space process blocked on write to DbC terminal device then it will never be signalled and thus stay blocked indifinitely. This fix adds a tty_hangup() call in xhci_dbc_tty_unregister_device(). The tty_hangup() wakes up any blocked writers and causes subsequent write attempts to DbC terminal device to fail. Cc: stable(a)vger.kernel.org Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Signed-off-by: Łukasz Bartosik <ukaszb(a)chromium.org> --- drivers/usb/host/xhci-dbgtty.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/host/xhci-dbgtty.c b/drivers/usb/host/xhci-dbgtty.c index d894081d8d15..6ea31af576c7 100644 --- a/drivers/usb/host/xhci-dbgtty.c +++ b/drivers/usb/host/xhci-dbgtty.c @@ -535,6 +535,13 @@ static void xhci_dbc_tty_unregister_device(struct xhci_dbc *dbc) if (!port->registered) return; + /* + * Hang up the TTY. This wakes up any blocked + * writers and causes subsequent writes to fail. + */ + if (port->port.tty) + tty_hangup(port->port.tty); + tty_unregister_device(dbc_tty_driver, port->minor); xhci_dbc_tty_exit_port(port); port->registered = false; -- 2.52.0.rc1.455.g30608eb744-goog

2 weeks, 1 day

2
2
0 0

[PATCH 08/15] dmaengine: sh: rz-dmac: fix device leak on probe failure

by Johan Hovold

Make sure to drop the reference taken when looking up the ICU device during probe also on probe failures (e.g. probe deferral). Fixes: 7de873201c44 ("dmaengine: sh: rz-dmac: Add RZ/V2H(P) support") Cc: stable(a)vger.kernel.org # 6.16 Cc: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/sh/rz-dmac.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/dma/sh/rz-dmac.c b/drivers/dma/sh/rz-dmac.c index 1f687b08d6b8..38137e8d80b9 100644 --- a/drivers/dma/sh/rz-dmac.c +++ b/drivers/dma/sh/rz-dmac.c @@ -854,6 +854,13 @@ static int rz_dmac_chan_probe(struct rz_dmac *dmac, return 0; } +static void rz_dmac_put_device(void *_dev) +{ + struct device *dev = _dev; + + put_device(dev); +} + static int rz_dmac_parse_of_icu(struct device *dev, struct rz_dmac *dmac) { struct device_node *np = dev->of_node; @@ -876,6 +883,10 @@ static int rz_dmac_parse_of_icu(struct device *dev, struct rz_dmac *dmac) return -ENODEV; } + ret = devm_add_action_or_reset(dev, rz_dmac_put_device, &dmac->icu.pdev->dev); + if (ret) + return ret; + dmac_index = args.args[0]; if (dmac_index > RZV2H_MAX_DMAC_INDEX) { dev_err(dev, "DMAC index %u invalid.\n", dmac_index); @@ -1055,8 +1066,6 @@ static void rz_dmac_remove(struct platform_device *pdev) reset_control_assert(dmac->rstc); pm_runtime_put(&pdev->dev); pm_runtime_disable(&pdev->dev); - - platform_device_put(dmac->icu.pdev); } static const struct of_device_id of_rz_dmac_match[] = { -- 2.51.0

2 weeks, 1 day

2
1
0 0

[RFC WIP 1/3] rust: list: Add unsafe for container_of

by Philipp Stanner

impl_list_item_mod.rs calls container_of() without unsafe blocks at a couple of places. Since container_of() is an unsafe macro / function, the blocks are strictly necessary. For unknown reasons, that problem was so far not visible and only gets visible once one utilizes the list implementation from within the core crate: error[E0133]: call to unsafe function `core::ptr::mut_ptr::<impl *mut T>::byte_sub` is unsafe and requires unsafe block --> rust/kernel/lib.rs:252:29 | 252 | let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; } 100 | | } | |_- in this macro invocation | note: an unsafe function restricts its caller, but its body is safe by default --> rust/kernel/list/impl_list_item_mod.rs:216:13 | 216 | unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | ::: rust/kernel/drm/jq.rs:98:1 | 98 | / impl_list_item! { 99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; } 100 | | } | |_- in this macro invocation = note: requested on the command line with `-D unsafe-op-in-unsafe-fn` = note: this error originates in the macro `$crate::container_of` which comes from the expansion of the macro `impl_list_item` Add unsafe blocks to container_of to fix the issue. Cc: stable(a)vger.kernel.org # v6.17+ Fixes: c77f85b347dd ("rust: list: remove OFFSET constants") Suggested-by: Alice Ryhl <aliceryhl(a)google.com> Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- rust/kernel/list/impl_list_item_mod.rs | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/rust/kernel/list/impl_list_item_mod.rs b/rust/kernel/list/impl_list_item_mod.rs index 202bc6f97c13..7052095efde5 100644 --- a/rust/kernel/list/impl_list_item_mod.rs +++ b/rust/kernel/list/impl_list_item_mod.rs @@ -217,7 +217,7 @@ unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self { // SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it // points at the field `$field` in a value of type `Self`. Thus, reversing that // operation is still in-bounds of the allocation. - $crate::container_of!(me, Self, $($field).*) + unsafe { $crate::container_of!(me, Self, $($field).*) } } // GUARANTEES: @@ -242,7 +242,7 @@ unsafe fn post_remove(me: *mut $crate::list::ListLinks<$num>) -> *const Self { // SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it // points at the field `$field` in a value of type `Self`. Thus, reversing that // operation is still in-bounds of the allocation. - $crate::container_of!(me, Self, $($field).*) + unsafe { $crate::container_of!(me, Self, $($field).*) } } } )*}; @@ -270,9 +270,9 @@ unsafe fn prepare_to_insert(me: *const Self) -> *mut $crate::list::ListLinks<$nu // SAFETY: The caller promises that `me` points at a valid value of type `Self`. let links_field = unsafe { <Self as $crate::list::ListItem<$num>>::view_links(me) }; - let container = $crate::container_of!( + let container = unsafe { $crate::container_of!( links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner - ); + ) }; // SAFETY: By the same reasoning above, `links_field` is a valid pointer. let self_ptr = unsafe { @@ -319,9 +319,9 @@ unsafe fn view_links(me: *const Self) -> *mut $crate::list::ListLinks<$num> { // `ListArc` containing `Self` until the next call to `post_remove`. The value cannot // be destroyed while a `ListArc` reference exists. unsafe fn view_value(links_field: *mut $crate::list::ListLinks<$num>) -> *const Self { - let container = $crate::container_of!( + let container = unsafe { $crate::container_of!( links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner - ); + ) }; // SAFETY: By the same reasoning above, `links_field` is a valid pointer. let self_ptr = unsafe { -- 2.49.0

2 weeks, 1 day

1
0
0 0

[PATCH] drm/amd: Skip power ungate during suspend for VPE

by Mario Limonciello

From: "Mario Limonciello (AMD)" <superm1(a)kernel.org> During the suspend sequence VPE is already going to be power gated as part of vpe_suspend(). It's unnecessary to call during calls to amdgpu_device_set_pg_state(). It actually can expose a race condition with the firmware if s0i3 sequence starts as well. Drop these calls. Cc: stable(a)vger.kernel.org Cc: Peyton.Lee(a)amd.com Signed-off-by: Mario Limonciello <mario.limonciello(a)amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index 81587f8d66c2..22db0e4154e4 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3419,10 +3419,11 @@ int amdgpu_device_set_pg_state(struct amdgpu_device *adev, (adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_GFX || adev->ip_blocks[i].version->type == AMD_IP_BLOCK_TYPE_SDMA)) continue; - /* skip CG for VCE/UVD, it's handled specially */ + /* skip CG for VCE/UVD/VPE, it's handled specially */ if (adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_UVD && adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VCE && adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VCN && + adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_VPE && adev->ip_blocks[i].version->type != AMD_IP_BLOCK_TYPE_JPEG && adev->ip_blocks[i].version->funcs->set_powergating_state) { /* enable powergating to save power */ -- 2.51.2

2 weeks, 1 day

1
0
0 0

[PATCH v2] drm/xe/oa: Fix potential UAF in xe_oa_add_config_ioctl()

by Sanjay Yadav

In xe_oa_add_config_ioctl(), we accessed oa_config->id after dropping metrics_lock. Since this lock protects the lifetime of oa_config, an attacker could guess the id and call xe_oa_remove_config_ioctl() with perfect timing, freeing oa_config before we dereference it, leading to a potential use-after-free. Fix this by caching the id in a local variable while holding the lock. v2: (Matt A) - Dropped mutex_unlock(&oa->metrics_lock) ordering change from xe_oa_remove_config_ioctl() Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/6614 Fixes: cdf02fe1a94a7 ("drm/xe/oa/uapi: Add/remove OA config perf ops") Cc: <stable(a)vger.kernel.org> # v6.11+ Suggested-by: Matthew Auld <matthew.auld(a)intel.com> Signed-off-by: Sanjay Yadav <sanjay.kumar.yadav(a)intel.com> --- drivers/gpu/drm/xe/xe_oa.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_oa.c b/drivers/gpu/drm/xe/xe_oa.c index 87a2bf53d661..890c363282ae 100644 --- a/drivers/gpu/drm/xe/xe_oa.c +++ b/drivers/gpu/drm/xe/xe_oa.c @@ -2403,11 +2403,13 @@ int xe_oa_add_config_ioctl(struct drm_device *dev, u64 data, struct drm_file *fi goto sysfs_err; } - mutex_unlock(&oa->metrics_lock); + id = oa_config->id; + + drm_dbg(&oa->xe->drm, "Added config %s id=%i\n", oa_config->uuid, id); - drm_dbg(&oa->xe->drm, "Added config %s id=%i\n", oa_config->uuid, oa_config->id); + mutex_unlock(&oa->metrics_lock); - return oa_config->id; + return id; sysfs_err: mutex_unlock(&oa->metrics_lock); -- 2.43.0

2 weeks, 1 day

2
1
0 0

Re: [PATCH] unshare: Fix nsproxy leak on set_cred_ucounts() error path

by Alexey Gladkov

On Tue, Nov 18, 2025 at 02:45:50PM +0800, Pavel Tikhomirov wrote: > If unshare_nsproxy_namespaces() successfully creates the new_nsproxy, > but then set_cred_ucounts() fails, on its error path there is no cleanup > for new_nsproxy, so it is leaked. Let's fix that by freeing new_nsproxy > if it's not NULL on this error path. > > Fixes: 905ae01c4ae2a ("Add a reference to ucounts for each cred") > Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com> Cc: stable(a)vger.kernel.org Acked-by: Alexey Gladkov <legion(a)kernel.org> > --- > kernel/fork.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/kernel/fork.c b/kernel/fork.c > index 3da0f08615a95..6f7332e3e0c8c 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -3133,8 +3133,11 @@ int ksys_unshare(unsigned long unshare_flags) > > if (new_cred) { > err = set_cred_ucounts(new_cred); > - if (err) > + if (err) { > + if (new_nsproxy) > + free_nsproxy(new_nsproxy); > goto bad_unshare_cleanup_cred; > + } > } > > if (new_fs || new_fd || do_sysvsem || new_cred || new_nsproxy) { > -- > 2.51.1 > -- Rgrds, legion

2 weeks, 1 day

1
0
0 0

[PATCH] Bluetooth: HCI: Fix hci0 not release in usb disconnect process

by zhangchen200426＠163.com

From: zhangchen <zhangchen01(a)kylinos.cn> If hci_resume_dev before hci_unregister_dev, the hci command will timeout and the reference count of hdev will not reset to zero. Then the node "hci0" will not release. The output in question is as follows: [ 3391.553518][ 7] [T247244] Bluetooth: hci0: command 0x0c01 tx timeout [ 3391.553588][ 7] [T264732] Bluetooth: hci0: Opcode 0x0c01 failed: -110 [ 3393.569514][ 3] [T247244] Bluetooth: hci0: command 0x0c01 tx timeout [ 3393.569515][ 3] [T264732] Bluetooth: hci0: Opcode 0x0c1a failed: -110 [ 3393.709645][ 6] [T104579] usb 10-1: new full-speed USB device number 95 using xhci-hcd [ 3393.862194][ 6] [T104579] usb 10-1: New USB device found, idVendor=13d3, idProduct=3570, bcdDevice= 0.00 [ 3393.862205][ 6] [T104579] usb 10-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3393.862208][ 6] [T104579] usb 10-1: Product: Bluetooth Radio [ 3393.862210][ 6] [T104579] usb 10-1: Manufacturer: Realtek [ 3393.862212][ 6] [T104579] usb 10-1: SerialNumber: 00e04c000001 [ 3393.867589][ 6] [T247244] Bluetooth: hci1: RTL: examining hci_ver=0b hci_rev=000b lmp_ver=0b lmp_subver=8852 [ 3393.868573][ 6] [T247244] Bluetooth: hci1: RTL: rom_version status=0 version=1 [ 3393.868583][ 6] [T247244] Bluetooth: hci1: RTL: loading rtl_bt/rtl8852bu_fw.bin [ 3393.868672][ 6] [T247244] Bluetooth: hci1: RTL: loading rtl_bt/rtl8852bu_config.bin [ 3393.869699][ 6] [T247244] Bluetooth: hci1: RTL: cfg_sz 6, total sz 65603 The call sequence in question is as follows: usb disconnect: btusb_disconnect hci_unregister_dev hci_dev_set_flag hci_cmd_sync_clear hci_unregister_suspend_notifier hci_dev_do_close device_del device resume: hci_suspend_notifier hci_resume_dev hci_resume_sync hci_set_event_mask_sync __hci_cmd_sync_status __hci_cmd_sync_status_sk __hci_cmd_sync_sk wait_event_interruptible_timeout The output after adding debug information in question is as follows: [ 6378.366215][ 6] [T434033] hci_resume_dev hci name hci0 [ 6378.366218][ 6] [T434033] hci_resume_sync set event mask sync [ 6378.366219][ 6] [T434033] hci_set_event_mask_sync [ 6378.366220][ 6] [T434033] __hci_cmd_sync_sk hci name hci0 Opcode 0x0c01 [ 6378.366227][ 6] [T434033] __hci_cmd_sync_sk wait event interruptible timeout [ 6378.367632][ 6] [T420012] btusb_disconnect intf 0000000024117fc1 [ 6378.367637][ 6] [T420012] btusb_disconnect hci_unregister_dev [ 6378.367638][ 6] [T420012] hci_unregister_dev 0000000064bfd783 name hci0 bus 1 [ 6378.367641][ 6] [T420012] hci_unregister_dev set flag [ 6378.367804][ 6] [T420012] hci_unregister_dev cmd sync clear [ 6378.367807][ 6] [T420012] hci_unregister_dev unregister suspend notifier [ 6380.367544][ 6] [T434033] __hci_cmd_sync_sk cmd timeout [ 6380.367542][ 6] [T197498] Bluetooth: hci0: command 0x0c01 tx timeout [ 6380.367550][ 6] [T434033] __hci_cmd_sync_sk hci0 end: err -110 [ 6380.367552][ 6] [T434033] Bluetooth: hci0: Opcode 0x0c01 failed: -110 [ 6380.367555][ 6] [T434033] hci_resume_sync clear event filter [ 6380.367556][ 6] [T434033] hci_resume_sync resume scan sync [ 6380.367558][ 6] [T434033] __hci_cmd_sync_sk hci name hci0 Opcode 0x0c1a [ 6380.367561][ 6] [T434033] __hci_cmd_sync_sk wait event interruptible timeout [ 6382.383538][ 6] [T197498] Bluetooth: hci0: command 0x0c01 tx timeout [ 6382.383593][ 6] [T434033] __hci_cmd_sync_sk hci0 end: err -110 [ 6382.383597][ 6] [T434033] Bluetooth: hci0: Opcode 0x0c1a failed: -110 The output after adding debug information in normal is as follows: [50.039156][ 6] [ T8360] btusb_disconnect intf 00000000fca35842 [50.039160][ 6] [ T8360] btusb_disconnect hci_unregister_dev [50.039162][ 6] [ T8360] hci_unregister_dev 000000002422b946 name hci0 bus 1 [50.039164][ 6] [ T8360] hci_unregister_dev set flag [50.039224][ 6] [ T8360] hci_unregister_dev cmd sync clear [50.039227][ 5] [ T8360] hci_unregister_dev unregister suspend notifier [50.043542][ 5] [ T8284] hci_resume_dev hci name hci0 This patch add hci_cancel_cmd_sync in hci_unregister_dev to wake up hdev->req_wait_q, and stop __hci_cmd_sync_sk by judging the HCI_UNREGISTER flag. Then stopping hci_resume_dev process based on the returned error code. Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Cc: stable(a)vger.kernel.org Signed-off-by: zhangchen <zhangchen01(a)kylinos.cn> --- net/bluetooth/hci_core.c | 6 ++++++ net/bluetooth/hci_sync.c | 22 ++++++++++++++++------ 2 files changed, 22 insertions(+), 6 deletions(-) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 3418d7b964a1..c977bcba3e76 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -50,6 +50,7 @@ static void hci_rx_work(struct work_struct *work); static void hci_cmd_work(struct work_struct *work); static void hci_tx_work(struct work_struct *work); +static void hci_cancel_cmd_sync(struct hci_dev *hdev, int err); /* HCI device list */ LIST_HEAD(hci_dev_list); @@ -2695,6 +2696,8 @@ void hci_unregister_dev(struct hci_dev *hdev) hci_dev_set_flag(hdev, HCI_UNREGISTER); mutex_unlock(&hdev->unregister_lock); + hci_cancel_cmd_sync(hdev, EINTR); + write_lock(&hci_dev_list_lock); list_del(&hdev->list); write_unlock(&hci_dev_list_lock); @@ -2877,6 +2880,9 @@ int hci_resume_dev(struct hci_dev *hdev) ret = hci_resume_sync(hdev); hci_req_sync_unlock(hdev); + if (ret && hci_dev_test_flag(hdev, HCI_UNREGISTER)) + return 0; + mgmt_resuming(hdev, hdev->wake_reason, &hdev->wake_addr, hdev->wake_addr_type); diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index 6e76798ec786..f48d34fbfff2 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -174,10 +174,11 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen, return ERR_PTR(err); err = wait_event_interruptible_timeout(hdev->req_wait_q, - hdev->req_status != HCI_REQ_PEND, + hdev->req_status != HCI_REQ_PEND || + hci_dev_test_flag(hdev, HCI_UNREGISTER), timeout); - if (err == -ERESTARTSYS) + if (err == -ERESTARTSYS || hci_dev_test_flag(hdev, HCI_UNREGISTER)) return ERR_PTR(-EINTR); switch (hdev->req_status) { @@ -6296,6 +6297,7 @@ static int hci_resume_scan_sync(struct hci_dev *hdev) */ int hci_resume_sync(struct hci_dev *hdev) { + int err; /* If not marked as suspended there nothing to do */ if (!hdev->suspended) return 0; @@ -6303,10 +6305,14 @@ int hci_resume_sync(struct hci_dev *hdev) hdev->suspended = false; /* Restore event mask */ - hci_set_event_mask_sync(hdev); + err = hci_set_event_mask_sync(hdev); + if (err && hci_dev_test_flag(hdev, HCI_UNREGISTER)) + return err; /* Clear any event filters and restore scan state */ - hci_clear_event_filter_sync(hdev); + err = hci_clear_event_filter_sync(hdev); + if (err && hci_dev_test_flag(hdev, HCI_UNREGISTER)) + return err; /* Resume scanning */ hci_resume_scan_sync(hdev); @@ -6315,10 +6321,14 @@ int hci_resume_sync(struct hci_dev *hdev) hci_resume_monitor_sync(hdev); /* Resume other advertisements */ - hci_resume_advertising_sync(hdev); + err = hci_resume_advertising_sync(hdev); + if (err && hci_dev_test_flag(hdev, HCI_UNREGISTER)) + return err; /* Resume discovery */ - hci_resume_discovery_sync(hdev); + err = hci_resume_discovery_sync(hdev); + if (err && hci_dev_test_flag(hdev, HCI_UNREGISTER)) + return err; return 0; } -- 2.25.1

2 weeks, 1 day

1
0
0 0

[PATCH v4 00/22] drm/msm/adreno: Introduce Adreno 8xx family support

by Akhil P Oommen

This series adds the A8xx HWL along with Adreno 840 GPU support to the drm-msm driver. A8x is the next generation in the Adreno family, featuring a significant hardware design change. A major update to the design is the introduction of 'Slice' architecture. Slices are sort of mini-GPUs within the GPU which are more independent in processing Graphics and compute workloads. Also, in addition to the BV and BR pipe we saw in A7x, CP has more concurrency with additional pipes. From KMD-HW SWI perspective, there is significant register shuffling in some of the blocks. For slice or aperture related registers which are virtualized now, KMD/crashdumper has to configure an aperture register to access them. On the GMU front, there are some shuffling in register offsets, but it is manageable as of now. There is a new HFI message to transfer data tables and new power related features to support higher peak currents and thermal mitigations. Adreno 840 GPU is the second generation architecture in the A8x family present in Kaanapali (a.k.a Snapdragon 8 Elite Gen 5) chipset [1]. It has a maximum of 3 slices with 2 SPs per slice. Along with the 3-slice configuration, there is also another 2-slice SKU (Partial Slice SKU). A840 GPU has a bigger 18MB of GMEM which can be utilized for graphics and compute workload. It also features improved Concurrent binning support, UBWC v6 etc. Adreno X2-85 GPU present in Glymur chipset is very similar to A840 architecturally. So adding initial support for it requires just an additional entry in the catalog with the necessary register lists. This series adds only the driver side support along with a few dt bindings updates. Devicetree patches will be sent separately, but those who are interested can take look at it from the Qualcomm's public tree [2]. Features like coredump, gmu power features, ifpc, preemption etc will be added in a future series. Initial few patches are for improving code sharing between a6xx/a7xx and a8x routines. Then there is a patch to rebase GMU register offsets from GPU's base. Rest of the patches add A8x HWL and Adreno 840/X2-85 GPU support. Mesa support for A8x/A840 GPU is WIP and will be posted in the near future. The last patch in the series ("drm/msm/a8xx: Add UBWC v6 support") has a compile time dependency on the below patch from the qcom-soc tree ("soc: qcom: ubwc: Add config for Kaanapali"): https://lore.kernel.org/lkml/20250930-kaana-gpu-support-v1-1-73530b0700ed@o… [1] https://www.qualcomm.com/products/mobile/snapdragon/smartphones/snapdragon-… [2] https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/commit/5fb72c2790… Signed-off-by: Akhil P Oommen <akhilpo(a)oss.qualcomm.com> --- Changes in v4: - Rebase on top of msm-next - Clean up AQE bo during a6xx_destroy (Konrad) - Split out UBWC v6 support into a separate patch to ease merge (Rob) - Rebase gmu register list's offsets in a6xx_gpu_state - Add a new patch#1 to fix Out of boud register access - Link to v3: https://lore.kernel.org/r/20251114-kaana-gpu-support-v3-0-92300c7ec8ff@oss.… Changes in v3: - Squash gpu smmu bindings patches for Kaana and Glymur (Krzysztof) - Reuse a6xx_flush() and drop the patch that added submit_flush callback - Fix GBIF configs for a640 and a650 family (Konrad) - Add partial SKU detection support - Correct Chipids in the catalog - Add a new patch to drop SCRATCH reg dumps (Rob) - Read slice info right after CX gdsc is up - Don't drop raytracing support if preemption is unsupported - Drop the unused A840 pwrup list (Konrad) - Updates to A840 nonctxt list (Rob) - Capture trailers - Link to v2: https://lore.kernel.org/r/20251110-kaana-gpu-support-v2-0-bef18acd5e94@oss.… Changes in v2: - Rebase on top of next-20251110 tag - Include support for Glymur chipset - Drop the ubwc_config driver patch as it is picked up - Sync the latest a6xx register definitions from Rob's tree - New patch to do LRZ flush to fix pagefaults - Reuse a7xx_cx_mem_init(). Dropped related patch (Connor) - Few changes around cp protect configuration to align it with downstream - Fix the incorrect register usage at few places - Updates to non-ctxt register list - Serialize aperture updates (Rob) - More helpful cp error irq logging - Split A8x GMU support patch (Dmitry) - Use devm_platform_get_and_ioremap_resource in GMU init (Konrad) - Link to v1: https://lore.kernel.org/r/20250930-kaana-gpu-support-v1-0-73530b0700ed@oss.… --- Akhil P Oommen (22): drm/msm/a6xx: Fix out of bound IO access in a6xx_get_gmu_registers drm/msm/a6xx: Flush LRZ cache before PT switch drm/msm/a6xx: Fix the gemnoc workaround drm/msm/a6xx: Skip dumping SCRATCH registers drm/msm/adreno: Common-ize PIPE definitions drm/msm/adreno: Move adreno_gpu_func to catalogue drm/msm/adreno: Move gbif_halt() to adreno_gpu_func drm/msm/adreno: Add MMU fault handler to adreno_gpu_func drm/msm/a6xx: Sync latest register definitions drm/msm/a6xx: Rebase GMU register offsets drm/msm/a8xx: Add support for A8x GMU drm/msm/a6xx: Improve MX rail fallback in RPMH vote init drm/msm/a6xx: Share dependency vote table with GMU drm/msm/adreno: Introduce A8x GPU Support drm/msm/adreno: Support AQE engine drm/msm/a8xx: Add support for Adreno 840 GPU drm/msm/adreno: Do CX GBIF config before GMU start drm/msm/a8xx: Add support for Adreno X2-85 GPU dt-bindings: arm-smmu: Add Kaanapali and Glymur GPU SMMU dt-bindings: display/msm/gmu: Add Adreno 840 GMU dt-bindings: display/msm/gmu: Add Adreno X2-85 GMU drm/msm/a8xx: Add UBWC v6 support .../devicetree/bindings/display/msm/gmu.yaml | 60 +- .../devicetree/bindings/iommu/arm,smmu.yaml | 2 + drivers/gpu/drm/msm/Makefile | 2 + drivers/gpu/drm/msm/adreno/a2xx_catalog.c | 7 +- drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 50 +- drivers/gpu/drm/msm/adreno/a2xx_gpu.h | 2 + drivers/gpu/drm/msm/adreno/a3xx_catalog.c | 13 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 52 +- drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 2 + drivers/gpu/drm/msm/adreno/a4xx_catalog.c | 7 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 54 +- drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 2 + drivers/gpu/drm/msm/adreno/a5xx_catalog.c | 17 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 61 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 1 + drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 371 +++- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 287 ++- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 25 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 399 ++-- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 31 +- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 74 +- drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 53 + drivers/gpu/drm/msm/adreno/a6xx_hfi.h | 17 + drivers/gpu/drm/msm/adreno/a8xx_gpu.c | 1205 ++++++++++++ drivers/gpu/drm/msm/adreno/adreno_device.c | 4 +- .../gpu/drm/msm/adreno/adreno_gen7_0_0_snapshot.h | 420 ++--- .../gpu/drm/msm/adreno/adreno_gen7_2_0_snapshot.h | 332 ++-- .../gpu/drm/msm/adreno/adreno_gen7_9_0_snapshot.h | 470 ++--- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 38 +- drivers/gpu/drm/msm/registers/adreno/a6xx.xml | 1954 +++++++++++++++----- .../gpu/drm/msm/registers/adreno/a6xx_enums.xml | 2 +- drivers/gpu/drm/msm/registers/adreno/a6xx_gmu.xml | 283 +-- .../gpu/drm/msm/registers/adreno/a7xx_enums.xml | 7 - .../drm/msm/registers/adreno/a8xx_descriptors.xml | 120 ++ .../gpu/drm/msm/registers/adreno/a8xx_enums.xml | 289 +++ .../gpu/drm/msm/registers/adreno/adreno_common.xml | 12 + 37 files changed, 5043 insertions(+), 1684 deletions(-) --- base-commit: 50a0b122cfc8a7dc35009ef9bf33cf6034c7bd69 change-id: 20250929-kaana-gpu-support-11d21c8fa1dc prerequisite-message-id: <20250930-kaana-gpu-support-v1-1-73530b0700ed(a)oss.qualcomm.com> prerequisite-patch-id: f15bd99b078d228da892fb1224e10cac31f4a5c2 prerequisite-patch-id: 5b3d152595fbcce7c118d42c00f89160bbf03d41 prerequisite-patch-id: 4387aff0073a3217132ae5da358e5d4b2cb23cb3 prerequisite-patch-id: e047a6ea27db881db0089923af688c38729a7dad prerequisite-patch-id: e686f7f592194f7d5e943858ce4dab49da6f4d18 prerequisite-patch-id: 638bc6f946cb2c1a2c68c3713a1ce7e6839c3465 prerequisite-patch-id: a85a264e87f79e9ac34dc22124153b050f97dded prerequisite-patch-id: 8bba83cdb88cb7a8851978590cb24033d95c21de prerequisite-patch-id: 9f08bcf9e33501478a2312e7a317f730f167652d prerequisite-patch-id: 65a2884909f6f0e3f111412388fde0c18a4a3334 prerequisite-patch-id: 3e9a011409f3461e3de7b1a8a4e99de6fbf02abf prerequisite-patch-id: 0ae4c8dc17fd54c84d903badccdf7a2018ec5606 prerequisite-patch-id: 6e0829024fb62bfc4510ef4c5472392dc76efcbf prerequisite-patch-id: 5e5e177cb37fd1c0151568744565483809f357ba prerequisite-patch-id: c2236f76a9fda88c41ea535708be1b51fd4d444c prerequisite-patch-id: 6e26922186365d994987026b674baa66f9ac0139 prerequisite-patch-id: 784df303a9e75f062c1e069d2bdb88578a76ba0e Best regards, -- Akhil P Oommen <akhilpo(a)oss.qualcomm.com>

2 weeks, 1 day

2
2
0 0

[PATCH 09/15] dmaengine: stm32: dmamux: fix device leak on route allocation

by Johan Hovold

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: df7e762db5f6 ("dmaengine: Add STM32 DMAMUX driver") Cc: stable(a)vger.kernel.org # 4.15 Cc: Pierre-Yves MORDRET <pierre-yves.mordret(a)foss.st.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/stm32/stm32-dmamux.c | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/drivers/dma/stm32/stm32-dmamux.c b/drivers/dma/stm32/stm32-dmamux.c index 8d77e2a7939a..791179760782 100644 --- a/drivers/dma/stm32/stm32-dmamux.c +++ b/drivers/dma/stm32/stm32-dmamux.c @@ -90,23 +90,25 @@ static void *stm32_dmamux_route_allocate(struct of_phandle_args *dma_spec, struct stm32_dmamux_data *dmamux = platform_get_drvdata(pdev); struct stm32_dmamux *mux; u32 i, min, max; - int ret; + int ret = -EINVAL; unsigned long flags; if (dma_spec->args_count != 3) { dev_err(&pdev->dev, "invalid number of dma mux args\n"); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } if (dma_spec->args[0] > dmamux->dmamux_requests) { dev_err(&pdev->dev, "invalid mux request number: %d\n", dma_spec->args[0]); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } mux = kzalloc(sizeof(*mux), GFP_KERNEL); - if (!mux) - return ERR_PTR(-ENOMEM); + if (!mux) { + ret = -ENOMEM; + goto err_put_pdev; + } spin_lock_irqsave(&dmamux->lock, flags); mux->chan_id = find_first_zero_bit(dmamux->dma_inuse, @@ -133,7 +135,6 @@ static void *stm32_dmamux_route_allocate(struct of_phandle_args *dma_spec, dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", i - 1); if (!dma_spec->np) { dev_err(&pdev->dev, "can't get dma master\n"); - ret = -EINVAL; goto error; } @@ -160,6 +161,8 @@ static void *stm32_dmamux_route_allocate(struct of_phandle_args *dma_spec, dev_dbg(&pdev->dev, "Mapping DMAMUX(%u) to DMA%u(%u)\n", mux->request, mux->master, mux->chan_id); + put_device(&pdev->dev); + return mux; error: @@ -167,6 +170,9 @@ static void *stm32_dmamux_route_allocate(struct of_phandle_args *dma_spec, error_chan_id: kfree(mux); +err_put_pdev: + put_device(&pdev->dev); + return ERR_PTR(ret); } -- 2.51.0

2 weeks, 1 day

2
2
0 0

[PATCH 06/15] dmaengine: lpc18xx-dmamux: fix device leak on route allocation

by Johan Hovold

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation. Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference. Fixes: e5f4ae84be74 ("dmaengine: add driver for lpc18xx dmamux") Cc: stable(a)vger.kernel.org # 4.3 Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/dma/lpc18xx-dmamux.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/dma/lpc18xx-dmamux.c b/drivers/dma/lpc18xx-dmamux.c index 2b6436f4b193..d3ff521951b8 100644 --- a/drivers/dma/lpc18xx-dmamux.c +++ b/drivers/dma/lpc18xx-dmamux.c @@ -57,30 +57,31 @@ static void *lpc18xx_dmamux_reserve(struct of_phandle_args *dma_spec, struct lpc18xx_dmamux_data *dmamux = platform_get_drvdata(pdev); unsigned long flags; unsigned mux; + int ret = -EINVAL; if (dma_spec->args_count != 3) { dev_err(&pdev->dev, "invalid number of dma mux args\n"); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } mux = dma_spec->args[0]; if (mux >= dmamux->dma_master_requests) { dev_err(&pdev->dev, "invalid mux number: %d\n", dma_spec->args[0]); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } if (dma_spec->args[1] > LPC18XX_DMAMUX_MAX_VAL) { dev_err(&pdev->dev, "invalid dma mux value: %d\n", dma_spec->args[1]); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } /* The of_node_put() will be done in the core for the node */ dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0); if (!dma_spec->np) { dev_err(&pdev->dev, "can't get dma master\n"); - return ERR_PTR(-EINVAL); + goto err_put_pdev; } spin_lock_irqsave(&dmamux->lock, flags); @@ -89,7 +90,8 @@ static void *lpc18xx_dmamux_reserve(struct of_phandle_args *dma_spec, dev_err(&pdev->dev, "dma request %u busy with %u.%u\n", mux, mux, dmamux->muxes[mux].value); of_node_put(dma_spec->np); - return ERR_PTR(-EBUSY); + ret = -EBUSY; + goto err_put_pdev; } dmamux->muxes[mux].busy = true; @@ -106,7 +108,14 @@ static void *lpc18xx_dmamux_reserve(struct of_phandle_args *dma_spec, dev_dbg(&pdev->dev, "mapping dmamux %u.%u to dma request %u\n", mux, dmamux->muxes[mux].value, mux); + put_device(&pdev->dev); + return &dmamux->muxes[mux]; + +err_put_pdev: + put_device(&pdev->dev); + + return ERR_PTR(ret); } static int lpc18xx_dmamux_probe(struct platform_device *pdev) -- 2.51.0

2 weeks, 1 day

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror