> -----Original Message-----
> From: Richard Cochran <richardcochran@xxxxxxxxx>
> Sent: Tuesday, August 31, 2021 6:19 PM
> To: Jakub Kicinski <kuba@xxxxxxxxxx>
> Subject: Re: [RFC v2 net-next 1/2] rtnetlink: Add new RTM_GETSYNCESTATE
> message to get SyncE status
>
> On Mon, Aug 30, 2021 at 04:29:09PM -0700, Jakub Kicinski wrote:
> > Can we add a genetlink family for clock info/configuration? From
> > what I understood discussing this with Jonathan it sounded like most
> > clocks today have a vendor-specific character device for configuration
> > and reading status.
> >
> > I'm happy to write the plumbing if this seems like an okay idea
> > but too much work for anyone to commit.
>
> This sounds nice.
>
> As you said later on in this thread, any API we merge now will have to
> last. That is why I'm being so picky here. We want new APIs to cover
> current HW _and_ be reasonable for the future.
>
> I don't see a DPLL as either a PTP Hardware Clock or a Network
> Device. It is a PLL.
>
> The kernel can and should have a way to represent the relationship
> between these three different kind of IP block. We already have a
> way to get from PHC to netdev interface.
OK I can strip down the RTNL EEC state interface to only report
the state without any extras, like pin. Next step would be to add
the control over recovered clock also to the netdev subsystem.
The EEC state read is needed for recovered/source clock validation
and that's why I think it belongs to the RTNL part as it gates the QL
for each port.
Those two interfaces will allow a minimalistic ESMC support
(receive the packet, extract the SSM from it, check if my clock is
recovered and my clock is in locked state, if all are good - pass
the message along to other related ports)
In parallel let's work on a proper clock generator subsystem.
For starter It should handle:
- reference configuration
- reference status
- reference priorities
- output settings
Optionally:
- NCO mode (here we'll duplicate the functionality of PHC in some
deployments)
Once we have that in place we can simply
- reroute the internals of the EEC state the clock generator subsystem
on more complex systems,
- keeping the simple state-read for those who use other simpler
Implementations of EEC.
- be able to support any hybrid between 1 and 2
Once we get there we'll know what else should this RTNL return and
extend it if needed.
Regards
Maciek
