kernel/linux.git/drivers/dpll, branch v6.12.102

dpll: fix clock quality level reporting

2026-08-03T09:17:38+00:00

commit 70d99623d5c11e1a9bcc564b8fbad6fa916913d8 upstream. The DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EPRC is not reported via netlink due to bug in dpll_msg_add_clock_quality_level(). The usage of DPLL_CLOCK_QUALITY_LEVEL_MAX for both DECLARE_BITMAP() and for_each_set_bit() is not correct because these macros requires bitmap size and not the highest valid bit in the bitmap. Use correct bitmap size to fix this issue. Fixes: a1afb959add1 ("dpll: add clock quality level attribute and op") Signed-off-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20250912093331.862333-1-ivecera@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

dpll: add clock quality level attribute and op

2026-08-03T09:17:14+00:00

[ Upstream commit a1afb959add1fad43cb337448c244ed70bac3109 ] In order to allow driver expose quality level of the clock it is running, introduce a new netlink attr with enum to carry it to the userspace. Also, introduce an op the dpll netlink code calls into the driver to obtain the value. Signed-off-by: Jiri Pirko Link: https://patch.msgid.link/20241030081157.966604-2-jiri@resnulli.us Signed-off-by: Jakub Kicinski Stable-dep-of: 11c057d23465 ("net/mlx5: Fix MCIA register buffer overflow on 32 dword reads") Signed-off-by: Sasha Levin

dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync()

2026-07-24T14:11:56+00:00

commit d2e914a4a0d0f753dbae830264850d044026167c upstream. When a dpll_pin is shared across multiple dpll_device instances and those devices are being unregistered (e.g. during driver module removal), a NULL pointer dereference can occur in dpll_msg_add_pin_ref_sync(). This happens under the following conditions: - A pin is registered with two or more dpll devices (dpll_A, dpll_B) - The pin has ref_sync pairs with other pins - During unregistration of dpll_A's pins, a ref_sync partner pin is unregistered first, removing it from dpll_A->pin_refs - But since the partner pin is still registered with dpll_B, its dpll_refs is not empty, so dpll_pin_ref_sync_pair_del() does NOT run and the partner stays in the pin's ref_sync_pins xarray - When the pin itself is then unregistered from dpll_A, the delete notification calls dpll_msg_add_pin_ref_sync() which finds the partner in ref_sync_pins, passes dpll_pin_available() (partner is still registered with dpll_B), but dpll_pin_on_dpll_priv(dpll_A, partner) returns NULL because partner was already removed from dpll_A->pin_refs - The NULL priv pointer is passed to the driver's ref_sync_get callback, which dereferences it BUG: kernel NULL pointer dereference, address: 0000000000000034 Oops: Oops: 0000 [#1] SMP NOPTI RIP: 0010:zl3073x_dpll_input_pin_ref_sync_get+0x73/0x80 [zl3073x] Call Trace: dpll_msg_add_pin_ref_sync+0xb8/0x200 dpll_cmd_pin_get_one+0x3b6/0x4b0 dpll_pin_event_send+0x72/0x140 __dpll_pin_unregister+0x5a/0x2b0 dpll_pin_unregister+0x49/0x70 Fix this by skipping ref_sync pins whose priv pointer cannot be resolved for the current dpll device. Fixes: 58256a26bfb3 ("dpll: add reference sync get/set") Signed-off-by: Ivan Vecera Reviewed-by: Vadim Fedorenko Reviewed-by: Jiri Pirko Link: https://patch.msgid.link/20260710193625.1378822-1-ivecera@redhat.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman

dpll: balance create/delete notifications in __dpll_pin_(un)register

2026-07-24T14:11:02+00:00

[ Upstream commit 1a2292101c0dc422466c673031de03d2e871adbe ] __dpll_pin_register() emits dpll_pin_create_ntf() internally, but __dpll_pin_unregister() left the matching delete to its callers. The counts then diverge on dpll_pin_on_pin_register() rollback and on dpll_pin_on_pin_unregister(), leaking stale notifications. Emit dpll_pin_delete_ntf() inside __dpll_pin_unregister() and drop the now-redundant call in dpll_pin_unregister(). Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260607183045.1213735-8-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

dpll: guard sync-pair removal on full pin unregister

2026-07-24T14:11:02+00:00

[ Upstream commit 0a5c720a7d57d2287d5566c4ad93ee26b7c06845 ] __dpll_pin_unregister() wiped the global sync-pair state on every (dpll, ops, priv, cookie) tuple removed from a pin. When a pin is registered multiple times and only one registration is being torn down, this dropped sync-pair pairings still in use by the surviving registrations. Move dpll_pin_ref_sync_pair_del() inside the xa_empty(&pin->dpll_refs) branch so it only runs when the last registration is gone, alongside clearing the DPLL_REGISTERED mark. Fixes: 58256a26bfb3 ("dpll: add reference sync get/set") Signed-off-by: Grzegorz Nitka Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260607183045.1213735-7-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

dpll: emit per-dpll delete notifications in dpll_pin_on_pin_unregister()

2026-07-24T14:11:02+00:00

[ Upstream commit df0ba51ccf873e533669578104981109217d8201 ] dpll_pin_on_pin_register() emits a creation notification for every parent->dpll_refs entry, but dpll_pin_on_pin_unregister() emitted only one deletion notification outside the loop. When a pin is registered against multiple parent dplls, userspace sees N creates but a single delete and leaks per-dpll state. Move dpll_pin_delete_ntf() into the loop and call it before __dpll_pin_unregister() so the DPLL_REGISTERED mark is still set when dpll_pin_available() is consulted. Fixes: 9d71b54b65b1 ("dpll: netlink: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260607183045.1213735-6-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

dpll: send delete notification before unregister in on-pin rollback

2026-07-24T14:11:02+00:00

[ Upstream commit e83b403eb142be18d223fc599c0ac45519053671 ] The rollback path in dpll_pin_on_pin_register() called __dpll_pin_unregister() before dpll_pin_delete_ntf(). When the unregister dropped the pin's last DPLL reference it cleared the DPLL_REGISTERED mark in dpll_pin_xa, so the subsequent dpll_pin_event_send() failed dpll_pin_available() and aborted with -ENODEV. As a result userspace was never notified of the rollback deletion and remained out of sync with the kernel. Send the delete notification first, matching the order used by dpll_pin_unregister() and dpll_pin_on_pin_unregister(). Fixes: 9d71b54b65b1 ("dpll: netlink: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka Link: https://patch.msgid.link/20260607183045.1213735-5-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

dpll: fix stale iteration in dpll_pin_on_pin_unregister()

2026-07-24T14:11:02+00:00

[ Upstream commit 32239d600236a986c8e6d16aa814d3d91066b244 ] Neither parent->dpll_refs nor pin->dpll_refs on its own is a correct iteration target at unregister time: - pin->dpll_refs includes DPLLs the child was registered against via a different parent or directly; blind unregister WARNs on the cookie miss in dpll_xa_ref_pin_del(). - parent->dpll_refs reflects the parent's current attachments, not those at child-register time. Another driver may have (un)reg'd the parent against additional DPLLs in the meantime, so we miss registrations that exist and visit DPLLs that have none. Walk pin->dpll_refs and use dpll_pin_registration_find() to filter to entries whose cookie is this parent. Symmetric with dpll_pin_on_pin_register(), correct under any subsequent change to parent->dpll_refs. Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Grzegorz Nitka Link: https://patch.msgid.link/20260607183045.1213735-4-grzegorz.nitka@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

dpll: Enhance and consolidate reference counting logic

2026-07-24T14:11:02+00:00

[ Upstream commit 729f5e0153bda8c0423fb7c5795865b6b77ca050 ] Refactor the reference counting mechanism for DPLL devices and pins to improve consistency and prevent potential lifetime issues. Introduce internal helpers __dpll_{device,pin}_{hold,put}() to centralize reference management. Update the internal XArray reference helpers (dpll_xa_ref_*) to automatically grab a reference to the target object when it is added to a list, and release it when removed. This ensures that objects linked internally (e.g., pins referenced by parent pins) are properly kept alive without relying on the caller to manually manage the count. Consequently, remove the now redundant manual `refcount_inc/dec` calls in dpll_pin_on_pin_{,un}register()`, as ownership is now correctly handled by the dpll_xa_ref_* functions. Additionally, ensure that dpll_device_{,un}register()` takes/releases a reference to the device, ensuring the device object remains valid for the duration of its registration. Reviewed-by: Aleksandr Loktionov Signed-off-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260203174002.705176-7-ivecera@redhat.com Signed-off-by: Paolo Abeni Stable-dep-of: 32239d600236 ("dpll: fix stale iteration in dpll_pin_on_pin_unregister()") Signed-off-by: Sasha Levin

dpll: Support dynamic pin index allocation

2026-07-24T14:11:02+00:00

[ Upstream commit 711696b3e168cea4165e7b7f051f3f442a347430 ] Allow drivers to register DPLL pins without manually specifying a pin index. Currently, drivers must provide a unique pin index when calling dpll_pin_get(). This works well for hardware-mapped pins but creates friction for drivers handling virtual pins or those without a strict hardware indexing scheme. Introduce DPLL_PIN_IDX_UNSPEC (U32_MAX). When a driver passes this value as the pin index: 1. The core allocates a unique index using an IDA 2. The allocated index is mapped to a range starting above `INT_MAX` This separation ensures that dynamically allocated indices never collide with standard driver-provided hardware indices, which are assumed to be within the `0` to `INT_MAX` range. The index is automatically freed when the pin is released in dpll_pin_put(). Reviewed-by: Aleksandr Loktionov Signed-off-by: Ivan Vecera Reviewed-by: Arkadiusz Kubalewski Link: https://patch.msgid.link/20260203174002.705176-5-ivecera@redhat.com Signed-off-by: Paolo Abeni Stable-dep-of: 32239d600236 ("dpll: fix stale iteration in dpll_pin_on_pin_unregister()") Signed-off-by: Sasha Levin