[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zw93d2xz3TpOVp73@nanopsycho.orion>
Date: Wed, 16 Oct 2024 10:21:11 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
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
Tue, Oct 15, 2024 at 05:01:08PM CEST, kuba@...nel.org wrote:
>On Tue, 15 Oct 2024 16:38:52 +0200 Jiri Pirko wrote:
>> Tue, Oct 15, 2024 at 04:26:38PM CEST, kuba@...nel.org wrote:
>> >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.
>>
>> Not sure what do you mean by "clock info". Dpll device and clock is kind
>> of the same thing. The dpll device is identified by clock-id. I see no
>> other attributes on the way this direction to more extend dpll attr
>> namespace.
>
>I'm not an expert but I think the standard definition of a DPLL
>does not include a built-in oscillator, if that's what you mean.
>
>> >> + 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?
>>
>> Yeah, why not?
>
>If it wasn't pointless it would be the default for our code gen.
>Please remove it unless you can point at some code that will likely
>need it. We can always add it later, we can't remove it.
Well, I use it internally to define the length of bitmap. Does that
justify? I mean, it would be very odd to define the bitmap length
differently.
Thanks!
Powered by blists - more mailing lists