On Tue, Sep 21, 2021 at 02:14:45PM -0700, Jakub Kicinski wrote:
On Tue, 21 Sep 2021 17:58:05 +0300 Ido Schimmel wrote:
The only source type above is 'port' with the ability to set the relevant port, but more can be added. Obviously, 'devlink clock show' will give you the current source in addition to other information such as frequency difference with respect to the input frequency.
We considered devlink interface for configuring the clock/DPLL, but a new concept was born at the list to add a DPLL subsystem that will cover more use cases, like a TimeCard.
The reason I suggested devlink is that it is suited for device-wide configuration and it is already used by both MAC drivers and the TimeCard driver. If we have a good reason to create a new generic netlink family for this stuff, then OK.
For NICs mapping between devlink instances and HW is not clear. Most register devlink per PCI dev which usually maps to a Eth port. So if we have one DPLL on a 2 port NIC mapping will get icky, no?
Yes, having to represent the same EEC in multiple devlink instances is not nice.
Is the motivation to save the boilerplate code associated with new genetlink family or something more?
I don't mind either way. I simply wanted to understand the motivation for not using any existing framework. The above argument is convincing enough, IMO.