[Intel-wired-lan] [PATCH net-next v3 1/3] dpll: add phase-offset-monitor feature to netlink spec

Jiri Pirko jiri at resnulli.us
Fri May 9 06:11:56 UTC 2025


Thu, May 08, 2025 at 05:29:07PM +0200, arkadiusz.kubalewski at intel.com wrote:
>>From: Jiri Pirko <jiri at resnulli.us>
>>Sent: Thursday, May 8, 2025 4:26 PM
>>
>>Thu, May 08, 2025 at 02:21:26PM +0200, arkadiusz.kubalewski at intel.com
>>wrote:
>>>Add enum dpll_feature_state for control over features.
>>>
>>>Add dpll device level attribute:
>>>DPLL_A_PHASE_OFFSET_MONITOR - to allow control over a phase offset monitor
>>>feature. Attribute is present and shall return current state of a feature
>>>(enum dpll_feature_state), if the device driver provides such capability,
>>>otherwie attribute shall not be present.
>>>
>>>Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov at intel.com>
>>>Reviewed-by: Milena Olech <milena.olech at intel.com>
>>>Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski at intel.com>
>>>---
>>>v3:
>>>- replace feature flags and capabilities with per feature attribute
>>>  approach,
>>>- add dpll documentation for phase-offset-monitor feature.
>>>---
>>> Documentation/driver-api/dpll.rst     | 16 ++++++++++++++++
>>> Documentation/netlink/specs/dpll.yaml | 24 ++++++++++++++++++++++++
>>> drivers/dpll/dpll_nl.c                |  5 +++--
>>> include/uapi/linux/dpll.h             | 12 ++++++++++++
>>> 4 files changed, 55 insertions(+), 2 deletions(-)
>>>
>>>diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-
>>>api/dpll.rst
>>>index e6855cd37e85..04efb425b411 100644
>>>--- a/Documentation/driver-api/dpll.rst
>>>+++ b/Documentation/driver-api/dpll.rst
>>>@@ -214,6 +214,22 @@ offset values are fractional with 3-digit decimal
>>>places and shell be
>>> divided with ``DPLL_PIN_PHASE_OFFSET_DIVIDER`` to get integer part and
>>> modulo divided to get fractional part.
>>>
>>>+Phase offset monitor
>>>+====================
>>>+
>>>+Phase offset measurement is typically performed against the current
>>>active
>>>+source. However, some DPLL (Digital Phase-Locked Loop) devices may offer
>>>+the capability to monitor phase offsets across all available inputs.
>>>+The attribute and current feature state shall be included in the response
>>>+message of the ``DPLL_CMD_DEVICE_GET`` command for supported DPLL
>>devices.
>>>+In such cases, users can also control the feature using the
>>>+``DPLL_CMD_DEVICE_SET`` command by setting the ``enum
>>>dpll_feature_state``
>>>+values for the attribute.
>>>+
>>>+  =============================== ========================
>>>+  ``DPLL_A_PHASE_OFFSET_MONITOR`` attr state of a feature
>>>+  =============================== ========================
>>>+
>>> Embedded SYNC
>>> =============
>>>
>>>diff --git a/Documentation/netlink/specs/dpll.yaml
>>>b/Documentation/netlink/specs/dpll.yaml
>>>index 8feefeae5376..e9774678b3f3 100644
>>>--- a/Documentation/netlink/specs/dpll.yaml
>>>+++ b/Documentation/netlink/specs/dpll.yaml
>>>@@ -240,6 +240,20 @@ definitions:
>>>       integer part of a measured phase offset value.
>>>       Value of (DPLL_A_PHASE_OFFSET % DPLL_PHASE_OFFSET_DIVIDER) is a
>>>       fractional part of a measured phase offset value.
>>>+  -
>>>+    type: enum
>>>+    name: feature-state
>>>+    doc: |
>>>+      Allow control (enable/disable) and status checking over features.
>>>+    entries:
>>>+      -
>>>+        name: disable
>>>+        doc: |
>>>+          feature shall be disabled
>>>+      -
>>>+        name: enable
>>>+        doc: |
>>>+          feature shall be enabled
>>
>>Is it necessary to introduce an enum for simple bool?
>>I mean, we used to handle this by U8 attr with 0/1 value. Idk what's the
>>usual way carry boolean values to do this these days, but enum looks
>>like overkill.
>>
>
>Well, yeah.. tricky.. There is no bool type in the attribute types?
>Input/output pin direction or eec/pps dpll types are also 2-value-enums
>we use same way..
>
>Had to use something as it is better then plain 0/1, also those values
>could be reused for any other feature.

Okay, I don't mind.

>
>Thank you!
>Arkadiusz
> 
>[...]


More information about the Intel-wired-lan mailing list