[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210901025658.GB18779@hoboy.vegasvil.org>
Date: Tue, 31 Aug 2021 19:56:58 -0700
From: Richard Cochran <richardcochran@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "Machnikowski, Maciej" <maciej.machnikowski@...el.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"intel-wired-lan@...ts.osuosl.org" <intel-wired-lan@...ts.osuosl.org>,
"abyagowi@...com" <abyagowi@...com>,
"Nguyen, Anthony L" <anthony.l.nguyen@...el.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"bsd@...com" <bsd@...com>,
Jonathan Lemon <jonathan.lemon@...il.com>
Subject: Re: [RFC v2 net-next 1/2] rtnetlink: Add new RTM_GETSYNCESTATE
message to get SyncE status
On Tue, Aug 31, 2021 at 07:02:35PM -0700, Jakub Kicinski wrote:
> On Tue, 31 Aug 2021 22:09:18 +0000 Machnikowski, Maciej wrote:
> > 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.
>
> If you mean just reporting state and have a syncE on/off without any
> option for other sources that's fine by me.
Yeah, that is what I also imagined for a generic SyncE interface.
Thanks,
Richard
Powered by blists - more mailing lists