[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241015072638.764fb0da@kernel.org>
Date: Tue, 15 Oct 2024 07:26:38 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
pabeni@...hat.com, donald.hunter@...il.com, vadim.fedorenko@...ux.dev,
arkadiusz.kubalewski@...el.com, saeedm@...dia.com, leon@...nel.org,
tariqt@...dia.com
Subject: Re: [PATCH net-next v3 1/2] dpll: add clock quality level attribute
and op
On Mon, 14 Oct 2024 10:11:32 +0200 Jiri Pirko wrote:
> + type: enum
> + name: clock-quality-level
> + doc: |
> + level of quality of a clock device. This mainly applies when
> + the dpll lock-status is not DPLL_LOCK_STATUS_LOCKED.
> + The current list is defined according to the table 11-7 contained
> + in ITU-T G.8264/Y.1364 document. One may extend this list freely
> + by other ITU-T defined clock qualities, or different ones defined
> + by another standardization body (for those, please use
> + different prefix).
uAPI extensibility aside - doesn't this belong to clock info?
I'm slightly worried we're stuffing this attr into DPLL because
we have netlink for DPLL but no good way to extend clock info.
> + entries:
> + -
> + name: itu-opt1-prc
> + value: 1
> + -
> + name: itu-opt1-ssu-a
> + -
> + name: itu-opt1-ssu-b
> + -
> + name: itu-opt1-eec1
> + -
> + name: itu-opt1-prtc
> + -
> + name: itu-opt1-eprtc
> + -
> + name: itu-opt1-eeec
> + -
> + name: itu-opt1-eprc
> + render-max: true
Why render max? Just to align with other unnecessary max defines in
the file?
Powered by blists - more mailing lists