[PATCH net-next 0/3] dpll: fix LLM nit picks from the spec scan

[PATCH net-next 0/3] dpll: fix LLM nit picks from the spec scan

[Jakub Kicinski]

Fix issues found by an LLM scan of the Netlink spec for DPLL.

Jakub Kicinski (3):
  dpll: do not truncate the requested pin frequency before checking it
  netlink: specs: dpll: declare pad in the nests which carry 64-bit
    values
  netlink: specs: dpll: drop the reference to DPLL_MODE_DETACHED

 Documentation/netlink/specs/dpll.yaml | 7 +++++--
 include/uapi/linux/dpll.h             | 3 +--
 drivers/dpll/dpll_netlink.c           | 2 +-
 3 files changed, 7 insertions(+), 5 deletions(-)

-- 
2.55.0

[PATCH net-next 1/3] dpll: do not truncate the requested pin frequency before checking it

[Jakub Kicinski]

DPLL_A_PIN_FREQUENCY is a u64 on the wire and dpll_pin_freq_set() keeps it
as one, but dpll_pin_is_freq_supported() takes a u32 while the ranges it
compares against are u64. The supported-frequency check therefore only
looks at the low 32 bits, and the full value is what reaches the driver.

Nothing is hitting this today. Reaching it at all needs a pin-set above
U32_MAX, which no sane caller sends, and the outcome is mild: a pin
advertising 10 kHz accepts 0x1_0000_2710, ice narrows it straight back to
10 kHz in ice_dpll_pin_freq_set(), so the hardware still ends up on an
advertised frequency and only the "frequency is not supported by the
device" rejection goes missing. The other direction - a legitimate request
above U32_MAX wrapping out of the pin's range - needs a driver advertising
such a range, and none does; zl3073x_pin_check_freq() refuses one outright.

So this is types rather than a live bug. Widen the check to match the
attribute, the ranges and the driver callback instead of adding a U32_MAX
rejection, so that the second case stays right if such a driver appears.
dpll_pin_esync_set() already keeps u64 throughout its equivalent loop.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 drivers/dpll/dpll_netlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
index fb24fd53f2e1..e5380d95f238 100644
--- a/drivers/dpll/dpll_netlink.c
+++ b/drivers/dpll/dpll_netlink.c
@@ -608,7 +608,7 @@ dpll_msg_add_pin_ref_sync(struct sk_buff *msg, struct dpll_pin *pin,
 	return -EMSGSIZE;
 }
 
-static bool dpll_pin_is_freq_supported(struct dpll_pin *pin, u32 freq)
+static bool dpll_pin_is_freq_supported(struct dpll_pin *pin, u64 freq)
 {
 	int fs;
 
-- 
2.55.0

[PATCH net-next 2/3] netlink: specs: dpll: declare pad in the nests which carry 64-bit values

[Jakub Kicinski]

Pads need to be propagated to subsets if they are used.
Otherwise Python YNL can fail with:

  YnlException: Space 'frequency-range' has no attribute with value '4'

This affects only platforms which care about alignment
so not much real impact.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/dpll.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
index e2ca4df5699a..7009a64473b1 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -550,6 +550,8 @@ doc: DPLL subsystem.
     attributes:
       -
         name: parent-id
+      -
+        name: pad
       -
         name: direction
       -
@@ -576,6 +578,8 @@ doc: DPLL subsystem.
     name: frequency-range
     subset-of: pin
     attributes:
+      -
+        name: pad
       -
         name: frequency-min
       -
-- 
2.55.0

[PATCH net-next 3/3] netlink: specs: dpll: drop the reference to DPLL_MODE_DETACHED

[Jakub Kicinski]

The lock-status doc tells userspace that DPLL_LOCK_STATUS_UNLOCKED
can be forced by setting DPLL_A_MODE to DPLL_MODE_DETACHED.
But no such value has been defined so far. enum dpll_mode has only
MANUAL and AUTOMATIC. Let's make sure the doc reflects current
reality.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
 Documentation/netlink/specs/dpll.yaml | 3 +--
 include/uapi/linux/dpll.h             | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
index 7009a64473b1..8fa789a50273 100644
--- a/Documentation/netlink/specs/dpll.yaml
+++ b/Documentation/netlink/specs/dpll.yaml
@@ -31,8 +31,7 @@ doc: DPLL subsystem.
       -
         name: unlocked
         doc: |
-          dpll was not yet locked to any valid input (or forced by setting
-          DPLL_A_MODE to DPLL_MODE_DETACHED)
+          dpll was not yet locked to any valid input
         value: 1
       -
         name: locked
diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h
index 85b898b1db5e..8c71fc3f9863 100644
--- a/include/uapi/linux/dpll.h
+++ b/include/uapi/linux/dpll.h
@@ -29,8 +29,7 @@ enum dpll_mode {
 /**
  * enum dpll_lock_status - provides information of dpll device lock status,
  *   valid values for DPLL_A_LOCK_STATUS attribute
- * @DPLL_LOCK_STATUS_UNLOCKED: dpll was not yet locked to any valid input (or
- *   forced by setting DPLL_A_MODE to DPLL_MODE_DETACHED)
+ * @DPLL_LOCK_STATUS_UNLOCKED: dpll was not yet locked to any valid input
  * @DPLL_LOCK_STATUS_LOCKED: dpll is locked to a valid signal, but no holdover
  *   available
  * @DPLL_LOCK_STATUS_LOCKED_HO_ACQ: dpll is locked and holdover acquired
-- 
2.55.0

Re: [PATCH net-next 1/3] dpll: do not truncate the requested pin frequency before checking it

[Ivan Vecera]

On 9/25/26 1:12 AM, Jakub Kicinski wrote:
> DPLL_A_PIN_FREQUENCY is a u64 on the wire and dpll_pin_freq_set() keeps it
> as one, but dpll_pin_is_freq_supported() takes a u32 while the ranges it
> compares against are u64. The supported-frequency check therefore only
> looks at the low 32 bits, and the full value is what reaches the driver.
> 
> Nothing is hitting this today. Reaching it at all needs a pin-set above
> U32_MAX, which no sane caller sends, and the outcome is mild: a pin
> advertising 10 kHz accepts 0x1_0000_2710, ice narrows it straight back to
> 10 kHz in ice_dpll_pin_freq_set(), so the hardware still ends up on an
> advertised frequency and only the "frequency is not supported by the
> device" rejection goes missing. The other direction - a legitimate request
> above U32_MAX wrapping out of the pin's range - needs a driver advertising
> such a range, and none does; zl3073x_pin_check_freq() refuses one outright.
> 
> So this is types rather than a live bug. Widen the check to match the
> attribute, the ranges and the driver callback instead of adding a U32_MAX
> rejection, so that the second case stays right if such a driver appears.
> dpll_pin_esync_set() already keeps u64 throughout its equivalent loop.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>   drivers/dpll/dpll_netlink.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c
> index fb24fd53f2e1..e5380d95f238 100644
> --- a/drivers/dpll/dpll_netlink.c
> +++ b/drivers/dpll/dpll_netlink.c
> @@ -608,7 +608,7 @@ dpll_msg_add_pin_ref_sync(struct sk_buff *msg, struct dpll_pin *pin,
>   	return -EMSGSIZE;
>   }
>   
> -static bool dpll_pin_is_freq_supported(struct dpll_pin *pin, u32 freq)
> +static bool dpll_pin_is_freq_supported(struct dpll_pin *pin, u64 freq)
>   {
>   	int fs;
>   

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH net-next 2/3] netlink: specs: dpll: declare pad in the nests which carry 64-bit values

[Ivan Vecera]

On 9/25/26 1:12 AM, Jakub Kicinski wrote:
> Pads need to be propagated to subsets if they are used.
> Otherwise Python YNL can fail with:
> 
>    YnlException: Space 'frequency-range' has no attribute with value '4'
> 
> This affects only platforms which care about alignment
> so not much real impact.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>   Documentation/netlink/specs/dpll.yaml | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
> index e2ca4df5699a..7009a64473b1 100644
> --- a/Documentation/netlink/specs/dpll.yaml
> +++ b/Documentation/netlink/specs/dpll.yaml
> @@ -550,6 +550,8 @@ doc: DPLL subsystem.
>       attributes:
>         -
>           name: parent-id
> +      -
> +        name: pad
>         -
>           name: direction
>         -
> @@ -576,6 +578,8 @@ doc: DPLL subsystem.
>       name: frequency-range
>       subset-of: pin
>       attributes:
> +      -
> +        name: pad
>         -
>           name: frequency-min
>         -

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH net-next 3/3] netlink: specs: dpll: drop the reference to DPLL_MODE_DETACHED

[Ivan Vecera]

On 9/25/26 1:12 AM, Jakub Kicinski wrote:
> The lock-status doc tells userspace that DPLL_LOCK_STATUS_UNLOCKED
> can be forced by setting DPLL_A_MODE to DPLL_MODE_DETACHED.
> But no such value has been defined so far. enum dpll_mode has only
> MANUAL and AUTOMATIC. Let's make sure the doc reflects current
> reality.
> 
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
>   Documentation/netlink/specs/dpll.yaml | 3 +--
>   include/uapi/linux/dpll.h             | 3 +--
>   2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml
> index 7009a64473b1..8fa789a50273 100644
> --- a/Documentation/netlink/specs/dpll.yaml
> +++ b/Documentation/netlink/specs/dpll.yaml
> @@ -31,8 +31,7 @@ doc: DPLL subsystem.
>         -
>           name: unlocked
>           doc: |
> -          dpll was not yet locked to any valid input (or forced by setting
> -          DPLL_A_MODE to DPLL_MODE_DETACHED)
> +          dpll was not yet locked to any valid input
>           value: 1
>         -
>           name: locked
> diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h
> index 85b898b1db5e..8c71fc3f9863 100644
> --- a/include/uapi/linux/dpll.h
> +++ b/include/uapi/linux/dpll.h
> @@ -29,8 +29,7 @@ enum dpll_mode {
>   /**
>    * enum dpll_lock_status - provides information of dpll device lock status,
>    *   valid values for DPLL_A_LOCK_STATUS attribute
> - * @DPLL_LOCK_STATUS_UNLOCKED: dpll was not yet locked to any valid input (or
> - *   forced by setting DPLL_A_MODE to DPLL_MODE_DETACHED)
> + * @DPLL_LOCK_STATUS_UNLOCKED: dpll was not yet locked to any valid input
>    * @DPLL_LOCK_STATUS_LOCKED: dpll is locked to a valid signal, but no holdover
>    *   available
>    * @DPLL_LOCK_STATUS_LOCKED_HO_ACQ: dpll is locked and holdover acquired

Reviewed-by: Ivan Vecera <ivecera@redhat.com>

Re: [PATCH net-next 0/3] dpll: fix LLM nit picks from the spec scan

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 24 Sep 2026 16:12:08 -0700 you wrote:
> Fix issues found by an LLM scan of the Netlink spec for DPLL.
> 
> Jakub Kicinski (3):
>   dpll: do not truncate the requested pin frequency before checking it
>   netlink: specs: dpll: declare pad in the nests which carry 64-bit
>     values
>   netlink: specs: dpll: drop the reference to DPLL_MODE_DETACHED
> 
> [...]

Here is the summary with links:
  - [net-next,1/3] dpll: do not truncate the requested pin frequency before checking it
    https://git.kernel.org/netdev/net-next/c/7f92b7f381ff
  - [net-next,2/3] netlink: specs: dpll: declare pad in the nests which carry 64-bit values
    https://git.kernel.org/netdev/net-next/c/398f802dba01
  - [net-next,3/3] netlink: specs: dpll: drop the reference to DPLL_MODE_DETACHED
    https://git.kernel.org/netdev/net-next/c/863da457b407

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html