public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Vadim Fedorenko <vfedorenko@novek.ru>
Cc: Jakub Kicinski <kuba@kernel.org>,
	Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>,
	Jonathan Lemon <jonathan.lemon@gmail.com>,
	Vadim Fedorenko <vadfed@fb.com>, Aya Levin <ayal@nvidia.com>,
	netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-clk@vger.kernel.org
Subject: Re: [RFC PATCH v2 0/3] Create common DPLL/clock configuration API
Date: Fri, 30 Sep 2022 10:33:57 +0200	[thread overview]
Message-ID: <Yzap9cfSXvSLA+5y@nanopsycho> (raw)
In-Reply-To: <6b80b6c8-29fd-4c2a-e963-1f273d866f12@novek.ru>

Fri, Sep 30, 2022 at 02:44:25AM CEST, vfedorenko@novek.ru wrote:
>On 29.09.2022 12:40, Jiri Pirko wrote:
>> Sun, Jun 26, 2022 at 09:24:41PM CEST, vfedorenko@novek.ru wrote:
>> > From: Vadim Fedorenko <vadfed@fb.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

What protocol?


>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.

Sure, but more hw does not mean you can't use sysfs. Take netdev as an
example. The sysfs exposed for it is implemented net/core/net-sysfs.c
and is exposed for all netdev instances, no matter what the
driver/hardware is.


>> 
>> 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
>> > 
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-09-30  8:35 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-26 19:24 [RFC PATCH v2 0/3] Create common DPLL/clock configuration API Vadim Fedorenko
2022-06-26 19:24 ` [RFC PATCH v2 1/3] dpll: Add DPLL framework base functions Vadim Fedorenko
2022-06-29  8:34   ` Stephen Boyd
2022-06-29 23:37     ` Vadim Fedorenko
2022-07-11  9:01   ` Kubalewski, Arkadiusz
2022-07-14 23:23     ` Vadim Fedorenko
2022-07-15 17:31       ` Kubalewski, Arkadiusz
2022-06-26 19:24 ` [RFC PATCH v2 2/3] dpll: add netlink events Vadim Fedorenko
2022-07-11  9:02   ` Kubalewski, Arkadiusz
2022-07-14 23:29     ` Vadim Fedorenko
2022-07-15 17:31       ` Kubalewski, Arkadiusz
2022-08-02 14:02         ` Kubalewski, Arkadiusz
2022-08-02 15:52           ` Jakub Kicinski
2022-08-03  0:05           ` Vadim Fedorenko
2022-08-03 15:21   ` Stephen Hemminger
2022-09-29 12:13   ` Jiri Pirko
2022-09-30  0:48     ` Vadim Fedorenko
2022-06-26 19:24 ` [RFC PATCH v2 3/3] ptp_ocp: implement DPLL ops Vadim Fedorenko
2022-06-27 19:34   ` Jonathan Lemon
2022-06-27 22:13     ` Vadim Fedorenko
2022-06-28 19:11       ` Jonathan Lemon
2022-06-29  3:24         ` Jakub Kicinski
2022-06-29 23:31           ` Vadim Fedorenko
2022-09-29 11:33   ` Jiri Pirko
2022-09-30  0:56     ` Vadim Fedorenko
2022-09-01 12:02 ` [RFC PATCH v2 0/3] Create common DPLL/clock configuration API Gal Pressman
2022-09-29 11:40 ` Jiri Pirko
2022-09-30  0:44   ` Vadim Fedorenko
2022-09-30  8:33     ` Jiri Pirko [this message]
2022-09-30 14:33       ` Jakub Kicinski
2022-10-01  5:47         ` Jiri Pirko
2022-10-01 14:18           ` Jakub Kicinski
2022-10-02 14:35             ` Jiri Pirko
2022-10-03 14:28               ` Jakub Kicinski
2022-10-03 17:20                 ` Vadim Fedorenko
2022-10-04  6:33                 ` Jiri Pirko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yzap9cfSXvSLA+5y@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=arkadiusz.kubalewski@intel.com \
    --cc=ayal@nvidia.com \
    --cc=jonathan.lemon@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vadfed@fb.com \
    --cc=vfedorenko@novek.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox