netdev - Re: [PATCH net-next 1/2] dpll: add clock quality level attribute and op

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZwaN7XZpS6tEnTdB@nanopsycho.orion>
Date: Wed, 9 Oct 2024 16:06:37 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"donald.hunter@...il.com" <donald.hunter@...il.com>,
	"vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>,
	"saeedm@...dia.com" <saeedm@...dia.com>,
	"leon@...nel.org" <leon@...nel.org>,
	"tariqt@...dia.com" <tariqt@...dia.com>
Subject: Re: [PATCH net-next 1/2] dpll: add clock quality level attribute and
 op

Wed, Oct 09, 2024 at 03:38:38PM CEST, arkadiusz.kubalewski@...el.com wrote:
>>From: Jiri Pirko <jiri@...nulli.us>
>>Sent: Wednesday, October 9, 2024 2:26 PM
>>
>>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 <jiri@...dia.com>
>>---
>> Documentation/netlink/specs/dpll.yaml | 28 +++++++++++++++++++++++++++
>> drivers/dpll/dpll_netlink.c           | 22 +++++++++++++++++++++
>> include/linux/dpll.h                  |  4 ++++
>> include/uapi/linux/dpll.h             | 21 ++++++++++++++++++++
>> 4 files changed, 75 insertions(+)
>>
>>diff --git a/Documentation/netlink/specs/dpll.yaml
>>b/Documentation/netlink/specs/dpll.yaml
>>index f2894ca35de8..77a8e9ddb254 100644
>>--- a/Documentation/netlink/specs/dpll.yaml
>>+++ b/Documentation/netlink/specs/dpll.yaml
>>@@ -85,6 +85,30 @@ definitions:
>>           This may happen for example if dpll device was previously
>>           locked on an input pin of type PIN_TYPE_SYNCE_ETH_PORT.
>>     render-max: true
>>+  -
>>+    type: enum
>>+    name: clock-quality-level
>>+    doc: |
>>+      level of quality of a clock device.
>
>Hi Jiri,
>
>Thanks for your work on this!
>
>I do like the idea, but this part is a bit tricky.
>
>I assume it is all about clock/quality levels as mentioned in
>ITU-T spec "Table 11-7" of REC-G.8264?

For now, yes. That is the usecase I have currently. But, if anyone
will have a need to introduce any sort of different quality, I don't
see why not.

>
>Then what about table 11-8?

The names do not overlap. So if anyone need to add those, he is free to
do it.


>
>And in general about option 2(3?) networks?
>
>AFAIR there are 3 (I don't think 3rd is relevant? But still defined
>In REC-G.781, also REC-G.781 doesn't provide clock types at all,
>just Quality Levels).
>
>Assuming 2(3?) network options shall be available, either user can
>select the one which is shown, or driver just provides all (if can,
>one/none otherwise)?
>
>If we don't want to give the user control and just let the
>driver to either provide this or not, my suggestion would be to name
>the attribute appropriately: "clock-quality-level-o1" to make clear
>provided attribute belongs to option 1 network.

I was thinking about that but there are 2 groups of names in both
tables:
1) different quality levels and names. Then "o1/2" in the name is not
   really needed, as the name itself is the differentiator.
2) same quality leves in both options. Those are:
   PRTC
   ePRTC
   eEEC
   ePRC
   And for thesee, using "o1/2" prefix would lead to have 2 enum values
   for exactly the same quality level.

But, talking about prefixes, perhaps I can put "ITU" as a prefix
to indicate this is ITU standartized clock quality leaving option
for some other clock quality namespace to appear?

[..]