netdev - Re: [RFC PATCH v2 0/3] Create common DPLL/clock configuration API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6b80b6c8-29fd-4c2a-e963-1f273d866f12@novek.ru>
Date:   Fri, 30 Sep 2022 01:44:25 +0100
From:   Vadim Fedorenko <vfedorenko@...ek.ru>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Jakub Kicinski <kuba@...nel.org>,
        Arkadiusz Kubalewski <arkadiusz.kubalewski@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        Vadim Fedorenko <vadfed@...com>, Aya Levin <ayal@...dia.com>,
        netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-clk@...r.kernel.org
Subject: Re: [RFC PATCH v2 0/3] Create common DPLL/clock configuration API

On 29.09.2022 12:40, Jiri Pirko wrote:
> Sun, Jun 26, 2022 at 09:24:41PM CEST, vfedorenko@...ek.ru wrote:
>> From: Vadim Fedorenko <vadfed@...com>
>>
>> Implement common API for clock/DPLL configuration and status reporting.
>> The API utilises netlink interface as transport for commands and event
>> notifications. This API aim to extend current pin configuration and
>> make it flexible and easy to cover special configurations.
> 
> Do you have the userspace part somewhere?
> It is very nice to add example outputs of user cmdline of such tool to
> the patch description/cover letter.

Sorry, but we don't have any user-space part for now. It's still WIP and there 
are too many changes in the protocol to implement anything useful on top of it. 
Once we will get to a kind of "stable" proto, I will implement a library to use it.

> 
> Also, did you consider usage of sysfs? Why it isn't a better fit than
> netlink?

We already have sysfs implemented in the ptp_ocp driver. But it looks like more 
hardware is going to be available soon with almost the same functions, so it 
would be great to have common protocol to configure such devices.
> 
> Regarding the naming, is "dpll" the correct one. Forgive me for being a
> syncE greenie, but isn't dpll just one algo to achieve syntonous
> clocks? Perhaps "dco" as for "Digitally Controlled Oscillator" would be
> somewhat better fit?
> 

We will discuss the naming too, thanks!

> 
>>
>> v1 -> v2:
>> * implement returning supported input/output types
>> * ptp_ocp: follow suggestions from Jonathan
>> * add linux-clk mailing list
>> v0 -> v1:
>> * fix code style and errors
>> * add linux-arm mailing list
>>
>>
>> Vadim Fedorenko (3):
>>   dpll: Add DPLL framework base functions
>>   dpll: add netlink events
>>   ptp_ocp: implement DPLL ops
>>
>> MAINTAINERS                 |   8 +
>> drivers/Kconfig             |   2 +
>> drivers/Makefile            |   1 +
>> drivers/dpll/Kconfig        |   7 +
>> drivers/dpll/Makefile       |   7 +
>> drivers/dpll/dpll_core.c    | 161 ++++++++++
>> drivers/dpll/dpll_core.h    |  40 +++
>> drivers/dpll/dpll_netlink.c | 595 ++++++++++++++++++++++++++++++++++++
>> drivers/dpll/dpll_netlink.h |  14 +
>> drivers/ptp/Kconfig         |   1 +
>> drivers/ptp/ptp_ocp.c       | 169 +++++++---
>> include/linux/dpll.h        |  29 ++
>> include/uapi/linux/dpll.h   |  81 +++++
>> 13 files changed, 1079 insertions(+), 36 deletions(-)
>> create mode 100644 drivers/dpll/Kconfig
>> create mode 100644 drivers/dpll/Makefile
>> create mode 100644 drivers/dpll/dpll_core.c
>> create mode 100644 drivers/dpll/dpll_core.h
>> create mode 100644 drivers/dpll/dpll_netlink.c
>> create mode 100644 drivers/dpll/dpll_netlink.h
>> create mode 100644 include/linux/dpll.h
>> create mode 100644 include/uapi/linux/dpll.h
>>
>> -- 
>> 2.27.0
>>