Re: [PATCH net-next 1/4] netlink: specs: dpll: add clock-quality-level to the device-get reply

[netdev-bot+sashiko@kernel.org]

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.

> 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