From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Cochran Date: Fri, 10 Sep 2021 07:14:23 -0700 Subject: [Intel-wired-lan] [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status In-Reply-To: References: <20210907124730.33852895@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210908092115.191fdc28@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210908152027.313d7168@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> <20210909020915.GA30747@hoboy.vegasvil.org> Message-ID: <20210910141423.GA21865@hoboy.vegasvil.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: intel-wired-lan@osuosl.org List-ID: On Thu, Sep 09, 2021 at 08:18:10AM +0000, Machnikowski, Maciej wrote: > Controlling the clock that actually drives any components (PHY/MAC) in > runtime can be a good way to brick the part. I didn't say that. > I feel that, while the reuse > of structures may be a good idea, the userspace API for clocks is not. > They are usually set up once at the board init level and stay like that "forever". > > The outputs we need to control are only a subset of all of them and they > rather fall in the PTP pins level of details, rather than clock ones. clk-gate.c clk-mux.c Making that available for user space to twiddle is a better way that tacking on to the PTP stuff. You can model your device as having a multiplexer in front of it. Thanks, Richard