Re: [PATCH net-next 1/4] netlink: specs: dpll: add clock-quality-level to the device-get reply
flat view
From: netdev-bot+sashiko@kernel.org
Date: 2026-09-08 07:13:04
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: Critical: 0 · High: 0 · Medium: 0 · Low: 1 (1) - [Low] Documentation/netlink/specs/dpll.yaml: the patch repairs a user- visible uAPI-description defect (the &dev-attrs reply anchor of… Pre-existing issues: - [Low] The hand-written DPLL ABI table in Documentation/driver- api/dpll.rst (``DPLL_CMD_DEVICE_GET`` section, lines ~382-395) still… -- netlink: specs: dpll: add clock-quality-level to the device-get reply The device-get reply anchor (&dev-attrs) in the dpll YAML spec was missing clock-quality-level, even though dpll_device_get_one() puts DPLL_A_CLOCK_QUALITY_LEVEL into every device-get reply, dump entry and device-*-ntf for drivers implementing clock_quality_level_get(). The patch adds the missing entry to the reply list.
quoted hunk ↗ jump to hunk
diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml index cdc8c7b456df8..64a45088c0273 100644 --- a/Documentation/netlink/specs/dpll.yaml +++ b/Documentation/netlink/specs/dpll.yaml@@ -632,6 +632,7 @@ operations: - mode-supported - lock-status - lock-status-error + - clock-quality-level
[Severity: Low]
The commit message names the culprit in prose:
"Missing since commit a1afb959add1 ("dpll: add clock quality level
attribute and op")"
but there is no Fixes: tag. Since this changes what the generated ynl
bindings parse (struct dpll_device_get_rsp gains a field for
DPLL_A_CLOCK_QUALITY_LEVEL that dpll_device_get_rsp_parse() previously
dropped), would a machine-readable tag be preferable here so backport
tooling picks it up?
Fixes: a1afb959add1 ("dpll: add clock quality level attribute and op")
[Severity: Low]
This isn't something introduced by this patch, but there is a second,
hand-written description of the same reply that stays narrower than what
the kernel emits. The ``DPLL_CMD_DEVICE_GET`` table in
Documentation/driver-api/dpll.rst lists only:
``DPLL_A_ID``
``DPLL_A_MODULE_NAME``
``DPLL_A_CLOCK_ID``
``DPLL_A_MODE``
``DPLL_A_MODE_SUPPORTED``
``DPLL_A_LOCK_STATUS``
``DPLL_A_TEMP``
``DPLL_A_TYPE``
while dpll_device_get_one() also puts DPLL_A_CLOCK_QUALITY_LEVEL,
DPLL_A_LOCK_STATUS_ERROR, DPLL_A_PHASE_OFFSET_MONITOR,
DPLL_A_PHASE_OFFSET_AVG_FACTOR and DPLL_A_FREQUENCY_MONITOR into the
message.
The commit message says "dpll.rst does not document it", which reads as the
ynl-generated Documentation/networking/netlink_spec/dpll.rst and is indeed
fixed by this YAML change.
Should the driver-api table get the same treatment, or is it intended to
be superseded by the generated spec documentation?
- temp
- clock-id
- type-- Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260904191023.3869690-1-kuba%40kernel.org