| Message ID | 20241014081133.15366-2-jiri@resnulli.us (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | dpll: expose clock quality level | expand |
>From: Jiri Pirko <jiri@resnulli.us> >Sent: Monday, October 14, 2024 10:12 AM >To: netdev@vger.kernel.org > >From: Jiri Pirko <jiri@nvidia.com> > >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@nvidia.com> >--- >v2->v3: >- changed "itu" prefix to "itu-opt1" >- changed driver op to pass bitmap to allow to set multiple qualities > and pass it to user over multiple attrs >- enhanced the documentation a bit >v1->v2: >- extended quality enum documentation >- added "itu" prefix to the enum values >--- > Documentation/netlink/specs/dpll.yaml | 35 +++++++++++++++++++++++++++ > drivers/dpll/dpll_netlink.c | 24 ++++++++++++++++++ > include/linux/dpll.h | 4 +++ > include/uapi/linux/dpll.h | 24 ++++++++++++++++++ > 4 files changed, 87 insertions(+) > >diff --git a/Documentation/netlink/specs/dpll.yaml >b/Documentation/netlink/specs/dpll.yaml >index f2894ca35de8..0bd708e136ff 100644 >--- a/Documentation/netlink/specs/dpll.yaml >+++ b/Documentation/netlink/specs/dpll.yaml >@@ -85,6 +85,36 @@ 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. 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). >+ 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 > - > type: const > name: temp-divider >@@ -252,6 +282,11 @@ attribute-sets: > name: lock-status-error > type: u32 > enum: lock-status-error >+ - >+ name: clock-quality-level >+ type: u32 >+ enum: clock-quality-level >+ multi-attr: true > - > name: pin > enum-name: dpll_a_pin >diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c >index fc0280dcddd1..c130f87147fa 100644 >--- a/drivers/dpll/dpll_netlink.c >+++ b/drivers/dpll/dpll_netlink.c >@@ -169,6 +169,27 @@ dpll_msg_add_temp(struct sk_buff *msg, struct dpll_device >*dpll, > return 0; > } > >+static int >+dpll_msg_add_clock_quality_level(struct sk_buff *msg, struct dpll_device >*dpll, >+ struct netlink_ext_ack *extack) >+{ >+ const struct dpll_device_ops *ops = dpll_device_ops(dpll); >+ DECLARE_BITMAP(qls, DPLL_CLOCK_QUALITY_LEVEL_MAX) = { 0 }; >+ enum dpll_clock_quality_level ql; >+ int ret; >+ >+ if (!ops->clock_quality_level_get) >+ return 0; >+ ret = ops->clock_quality_level_get(dpll, dpll_priv(dpll), qls, extack); >+ if (ret) >+ return ret; >+ for_each_set_bit(ql, qls, DPLL_CLOCK_QUALITY_LEVEL_MAX) >+ if (nla_put_u32(msg, DPLL_A_CLOCK_QUALITY_LEVEL, ql)) >+ return -EMSGSIZE; >+ >+ return 0; >+} >+ > static int > dpll_msg_add_pin_prio(struct sk_buff *msg, struct dpll_pin *pin, > struct dpll_pin_ref *ref, >@@ -557,6 +578,9 @@ dpll_device_get_one(struct dpll_device *dpll, struct >sk_buff *msg, > if (ret) > return ret; > ret = dpll_msg_add_lock_status(msg, dpll, extack); >+ if (ret) >+ return ret; >+ ret = dpll_msg_add_clock_quality_level(msg, dpll, extack); > if (ret) > return ret; > ret = dpll_msg_add_mode(msg, dpll, extack); >diff --git a/include/linux/dpll.h b/include/linux/dpll.h >index 81f7b623d0ba..5e4f9ab1cf75 100644 >--- a/include/linux/dpll.h >+++ b/include/linux/dpll.h >@@ -26,6 +26,10 @@ struct dpll_device_ops { > struct netlink_ext_ack *extack); > int (*temp_get)(const struct dpll_device *dpll, void *dpll_priv, > s32 *temp, struct netlink_ext_ack *extack); >+ int (*clock_quality_level_get)(const struct dpll_device *dpll, >+ void *dpll_priv, >+ unsigned long *qls, >+ struct netlink_ext_ack *extack); > }; > > struct dpll_pin_ops { >diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h >index b0654ade7b7e..4b37542eace3 100644 >--- a/include/uapi/linux/dpll.h >+++ b/include/uapi/linux/dpll.h >@@ -79,6 +79,29 @@ enum dpll_lock_status_error { > DPLL_LOCK_STATUS_ERROR_MAX = (__DPLL_LOCK_STATUS_ERROR_MAX - 1) > }; > >+/** >+ * enum dpll_clock_quality_level - 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). >+ */ >+enum dpll_clock_quality_level { >+ DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_PRC = 1, >+ DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_SSU_A, >+ DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_SSU_B, >+ DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EEC1, >+ DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_PRTC, >+ DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EPRTC, >+ DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EEEC, >+ DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EPRC, >+ >+ /* private: */ >+ __DPLL_CLOCK_QUALITY_LEVEL_MAX, >+ DPLL_CLOCK_QUALITY_LEVEL_MAX = (__DPLL_CLOCK_QUALITY_LEVEL_MAX - 1) >+}; >+ > #define DPLL_TEMP_DIVIDER 1000 > > /** >@@ -180,6 +203,7 @@ enum dpll_a { > DPLL_A_TEMP, > DPLL_A_TYPE, > DPLL_A_LOCK_STATUS_ERROR, >+ DPLL_A_CLOCK_QUALITY_LEVEL, > > __DPLL_A_MAX, > DPLL_A_MAX = (__DPLL_A_MAX - 1) >-- >2.47.0 LGTM, Thank you! Reviewed-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
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?
Tue, Oct 15, 2024 at 04:26:38PM CEST, kuba@kernel.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. > >> + 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?
On 15/10/2024 15:26, Jakub Kicinski 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. There is a work going on by Maciek Machnikowski about extending clock info. But the progress is kinda slow.. >> + 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?
Tue, Oct 15, 2024 at 04:50:41PM CEST, vadim.fedorenko@linux.dev wrote: >On 15/10/2024 15:26, Jakub Kicinski 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. > >There is a work going on by Maciek Machnikowski about extending clock >info. But the progress is kinda slow.. Do you have some info about this? A list of attrs at least would help. > >> > + 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? >
On Tue, 15 Oct 2024 16:38:52 +0200 Jiri Pirko wrote: > Tue, Oct 15, 2024 at 04:26:38PM CEST, kuba@kernel.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.
On 15/10/2024 15:56, Jiri Pirko wrote: > Tue, Oct 15, 2024 at 04:50:41PM CEST, vadim.fedorenko@linux.dev wrote: >> On 15/10/2024 15:26, Jakub Kicinski 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. >> >> There is a work going on by Maciek Machnikowski about extending clock >> info. But the progress is kinda slow.. > > Do you have some info about this? A list of attrs at least would help. The mailing list conversation started in this thread: https://lore.kernel.org/netdev/20240813125602.155827-1-maciek@machnikowski.net/ But the idea was presented back at the latest Netdevconf: https://netdevconf.org/0x18/sessions/tutorial/introduction-to-ptp-on-linux-apis.html >> >>>> + 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? >>
Tue, Oct 15, 2024 at 05:01:12PM CEST, vadim.fedorenko@linux.dev wrote: >On 15/10/2024 15:56, Jiri Pirko wrote: >> Tue, Oct 15, 2024 at 04:50:41PM CEST, vadim.fedorenko@linux.dev wrote: >> > On 15/10/2024 15:26, Jakub Kicinski 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. >> > >> > There is a work going on by Maciek Machnikowski about extending clock >> > info. But the progress is kinda slow.. >> >> Do you have some info about this? A list of attrs at least would help. > >The mailing list conversation started in this thread: >https://lore.kernel.org/netdev/20240813125602.155827-1-maciek@machnikowski.net/ What's the relation to ptp? I'm missing something here. > >But the idea was presented back at the latest Netdevconf: >https://netdevconf.org/0x18/sessions/tutorial/introduction-to-ptp-on-linux-apis.html > >> > >> > > > + 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? >> > >
Tue, Oct 15, 2024 at 05:01:08PM CEST, kuba@kernel.org wrote: >On Tue, 15 Oct 2024 16:38:52 +0200 Jiri Pirko wrote: >> Tue, Oct 15, 2024 at 04:26:38PM CEST, kuba@kernel.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. Okay. Then the clock-id we have also does not make much sense. Anyway, what is your desire exactly? Do you want to have a nest attr clock-info to contain this quality-level attr? Or something else? > >> >> + 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. Ok
Tue, Oct 15, 2024 at 05:01:08PM CEST, kuba@kernel.org wrote: >On Tue, 15 Oct 2024 16:38:52 +0200 Jiri Pirko wrote: >> Tue, Oct 15, 2024 at 04:26:38PM CEST, kuba@kernel.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!
Wed, Oct 16, 2024 at 10:19:57AM CEST, jiri@resnulli.us wrote: >Tue, Oct 15, 2024 at 05:01:08PM CEST, kuba@kernel.org wrote: >>On Tue, 15 Oct 2024 16:38:52 +0200 Jiri Pirko wrote: >>> Tue, Oct 15, 2024 at 04:26:38PM CEST, kuba@kernel.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. > >Okay. Then the clock-id we have also does not make much sense. >Anyway, what is your desire exactly? Do you want to have a nest attr >clock-info to contain this quality-level attr? Or something else? Jakub? What's your wish?
On Wed, 16 Oct 2024 10:19:57 +0200 Jiri Pirko wrote: > >> 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. > > Okay. Then the clock-id we have also does not make much sense. > Anyway, what is your desire exactly? Do you want to have a nest attr > clock-info to contain this quality-level attr? Or something else? I thought clock-id is basically clockid_t, IOW a reference. I wish that the information about timekeepers was exposed by the time subsystem rather than DPLL. Something like clock_getres().
Mon, Oct 28, 2024 at 06:14:03PM CET, kuba@kernel.org wrote: >On Wed, 16 Oct 2024 10:19:57 +0200 Jiri Pirko wrote: >> >> 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. >> >> Okay. Then the clock-id we have also does not make much sense. >> Anyway, what is your desire exactly? Do you want to have a nest attr >> clock-info to contain this quality-level attr? Or something else? > >I thought clock-id is basically clockid_t, IOW a reference. >I wish that the information about timekeepers was exposed >by the time subsystem rather than DPLL. Something like clock_getres(). Hmm. From what I understand, the quality of the clock as it is defined by the ITU standard is an attribute of the DPLL device. DPLL device in our model is basically a board, which might combine oscillator, synchronizer and possibly other devices. The clock quality is determined by this combination and I understand that the ITU certification is also applied to this device. That's why it makes sense to have the clock quality as the DPLL attribute. Makes sense?
On Tue, 29 Oct 2024 13:52:12 +0100 Jiri Pirko wrote: > >I thought clock-id is basically clockid_t, IOW a reference. > >I wish that the information about timekeepers was exposed > >by the time subsystem rather than DPLL. Something like clock_getres(). > > Hmm. From what I understand, the quality of the clock as it is defined > by the ITU standard is an attribute of the DPLL device. DPLL device > in our model is basically a board, which might combine oscillator, > synchronizer and possibly other devices. The clock quality is determined > by this combination and I understand that the ITU certification is also > applied to this device. > > That's why it makes sense to have the clock quality as the DPLL > attribute. Makes sense? Hm, reading more carefully sounds like it's the quality of the holdover clock. Can we say that in the documentation? "This mainly applies when the dpll lock-status is not DPLL_LOCK_STATUS_LOCKED" is a bit of a mouthful. I think I missed the "not" first time reading it. Is it marked as multi-attr in case non-ITU clock quality is defined later? Or is it legit to set to ITU bits at once?
Tue, Oct 29, 2024 at 02:51:29PM CET, kuba@kernel.org wrote: >On Tue, 29 Oct 2024 13:52:12 +0100 Jiri Pirko wrote: >> >I thought clock-id is basically clockid_t, IOW a reference. >> >I wish that the information about timekeepers was exposed >> >by the time subsystem rather than DPLL. Something like clock_getres(). >> >> Hmm. From what I understand, the quality of the clock as it is defined >> by the ITU standard is an attribute of the DPLL device. DPLL device >> in our model is basically a board, which might combine oscillator, >> synchronizer and possibly other devices. The clock quality is determined >> by this combination and I understand that the ITU certification is also >> applied to this device. >> >> That's why it makes sense to have the clock quality as the DPLL >> attribute. Makes sense? > >Hm, reading more carefully sounds like it's the quality of the holdover >clock. Can we say that in the documentation? "This mainly applies when Yes. >the dpll lock-status is not DPLL_LOCK_STATUS_LOCKED" is a bit of a mouthful. >I think I missed the "not" first time reading it. Okay, will try to re-phrase to avoid confusion. > >Is it marked as multi-attr in case non-ITU clock quality is defined >later? Or is it legit to set to ITU bits at once? For non-ITU as well as for possibly advertizing quality of different ITU options (option 1 and option 2).
diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/specs/dpll.yaml index f2894ca35de8..0bd708e136ff 100644 --- a/Documentation/netlink/specs/dpll.yaml +++ b/Documentation/netlink/specs/dpll.yaml @@ -85,6 +85,36 @@ 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. 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). + 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 - type: const name: temp-divider @@ -252,6 +282,11 @@ attribute-sets: name: lock-status-error type: u32 enum: lock-status-error + - + name: clock-quality-level + type: u32 + enum: clock-quality-level + multi-attr: true - name: pin enum-name: dpll_a_pin diff --git a/drivers/dpll/dpll_netlink.c b/drivers/dpll/dpll_netlink.c index fc0280dcddd1..c130f87147fa 100644 --- a/drivers/dpll/dpll_netlink.c +++ b/drivers/dpll/dpll_netlink.c @@ -169,6 +169,27 @@ dpll_msg_add_temp(struct sk_buff *msg, struct dpll_device *dpll, return 0; } +static int +dpll_msg_add_clock_quality_level(struct sk_buff *msg, struct dpll_device *dpll, + struct netlink_ext_ack *extack) +{ + const struct dpll_device_ops *ops = dpll_device_ops(dpll); + DECLARE_BITMAP(qls, DPLL_CLOCK_QUALITY_LEVEL_MAX) = { 0 }; + enum dpll_clock_quality_level ql; + int ret; + + if (!ops->clock_quality_level_get) + return 0; + ret = ops->clock_quality_level_get(dpll, dpll_priv(dpll), qls, extack); + if (ret) + return ret; + for_each_set_bit(ql, qls, DPLL_CLOCK_QUALITY_LEVEL_MAX) + if (nla_put_u32(msg, DPLL_A_CLOCK_QUALITY_LEVEL, ql)) + return -EMSGSIZE; + + return 0; +} + static int dpll_msg_add_pin_prio(struct sk_buff *msg, struct dpll_pin *pin, struct dpll_pin_ref *ref, @@ -557,6 +578,9 @@ dpll_device_get_one(struct dpll_device *dpll, struct sk_buff *msg, if (ret) return ret; ret = dpll_msg_add_lock_status(msg, dpll, extack); + if (ret) + return ret; + ret = dpll_msg_add_clock_quality_level(msg, dpll, extack); if (ret) return ret; ret = dpll_msg_add_mode(msg, dpll, extack); diff --git a/include/linux/dpll.h b/include/linux/dpll.h index 81f7b623d0ba..5e4f9ab1cf75 100644 --- a/include/linux/dpll.h +++ b/include/linux/dpll.h @@ -26,6 +26,10 @@ struct dpll_device_ops { struct netlink_ext_ack *extack); int (*temp_get)(const struct dpll_device *dpll, void *dpll_priv, s32 *temp, struct netlink_ext_ack *extack); + int (*clock_quality_level_get)(const struct dpll_device *dpll, + void *dpll_priv, + unsigned long *qls, + struct netlink_ext_ack *extack); }; struct dpll_pin_ops { diff --git a/include/uapi/linux/dpll.h b/include/uapi/linux/dpll.h index b0654ade7b7e..4b37542eace3 100644 --- a/include/uapi/linux/dpll.h +++ b/include/uapi/linux/dpll.h @@ -79,6 +79,29 @@ enum dpll_lock_status_error { DPLL_LOCK_STATUS_ERROR_MAX = (__DPLL_LOCK_STATUS_ERROR_MAX - 1) }; +/** + * enum dpll_clock_quality_level - 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). + */ +enum dpll_clock_quality_level { + DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_PRC = 1, + DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_SSU_A, + DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_SSU_B, + DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EEC1, + DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_PRTC, + DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EPRTC, + DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EEEC, + DPLL_CLOCK_QUALITY_LEVEL_ITU_OPT1_EPRC, + + /* private: */ + __DPLL_CLOCK_QUALITY_LEVEL_MAX, + DPLL_CLOCK_QUALITY_LEVEL_MAX = (__DPLL_CLOCK_QUALITY_LEVEL_MAX - 1) +}; + #define DPLL_TEMP_DIVIDER 1000 /** @@ -180,6 +203,7 @@ enum dpll_a { DPLL_A_TEMP, DPLL_A_TYPE, DPLL_A_LOCK_STATUS_ERROR, + DPLL_A_CLOCK_QUALITY_LEVEL, __DPLL_A_MAX, DPLL_A_MAX = (__DPLL_A_MAX - 1)