All of lore.kernel.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>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-clk@vger.kernel.org
Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API
Date: Wed, 30 Nov 2022 13:32:23 +0100	[thread overview]
Message-ID: <Y4dNV14g7dzIQ3x7@nanopsycho> (raw)
In-Reply-To: <20221129213724.10119-1-vfedorenko@novek.ru>

Tue, Nov 29, 2022 at 10:37:20PM CET, vfedorenko@novek.ru wrote:
>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.

Overall, I see a lot of issues on multiple levels. I will go over them
in follow-up emails. So far, after couple of hours looking trought this,
I have following general feelings/notes:

1) Netlink interface looks much saner than in previous versions. I will
   send couple of notes, mainly around events and object mixtures and
   couple of bugs/redundancies. But overall, looks fineish.

2) I don't like that concept of a shared pin, at all. It makes things
   unnecessary complicated. Just have a pin created for dpll instance
   and that's it. If another instance has the same pin, it should create
   it as well. Keeps things separate and easy to model. Let the
   hw/fw/driver figure out the implementation oddities.
   Why exactly you keep pushing the shared pin idea? Perhaps I'm missing
   something crucial.

3) I don't like the concept of muxed pins and hierarchies of pins. Why
   does user care? If pin is muxed, the rest of the pins related to this
   one should be in state disabled/disconnected. The user only cares
   about to see which pins are related to each other. It can be easily
   exposed by "muxid" like this:
   pin 1
   pin 2
   pin 3 muxid 100
   pin 4 muxid 100
   pin 5 muxid 101
   pin 6 muxid 101
   In this example pins 3,4 and 5,6 are muxed, therefore the user knows
   if he connects one, the other one gets disconnected (or will have to
   disconnect the first one explicitly first).

4) I don't like the "attr" indirection. It makes things very tangled. It
   comes from the concepts of classes and objects and takes it to
   extreme. Not really something we are commonly used to in kernel.
   Also, it brings no value from what I can see, only makes things very
   hard to read and follow.

   Please keep things direct and simple:
   * If some option could be changed for a pin or dpll, just have an
     op that is directly called from netlink handler to change it.
     There should be clear set of ops for configuration of pin and
     dpll object. This "attr" indirection make this totally invisible.
   * If some attribute is const during dpll or pin lifetime, have it
     passed during dpll or pin creation.



>
>v3 -> v4:
> * redesign framework to make pins dynamically allocated (Arkadiusz)
> * implement shared pins (Arkadiusz)
>v2 -> v3:
> * implement source select mode (Arkadiusz)
> * add documentation
> * implementation improvements (Jakub)
>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
>
>
>Arkadiusz Kubalewski (1):
>  dpll: add dpll_attr/dpll_pin_attr helper classes
>
>Vadim Fedorenko (3):
>  dpll: Add DPLL framework base functions
>  dpll: documentation on DPLL subsystem interface
>  ptp_ocp: implement DPLL ops
>
> Documentation/networking/dpll.rst  | 271 ++++++++
> Documentation/networking/index.rst |   1 +
> MAINTAINERS                        |   8 +
> drivers/Kconfig                    |   2 +
> drivers/Makefile                   |   1 +
> drivers/dpll/Kconfig               |   7 +
> drivers/dpll/Makefile              |  11 +
> drivers/dpll/dpll_attr.c           | 278 +++++++++
> drivers/dpll/dpll_core.c           | 760 +++++++++++++++++++++++
> drivers/dpll/dpll_core.h           | 176 ++++++
> drivers/dpll/dpll_netlink.c        | 963 +++++++++++++++++++++++++++++
> drivers/dpll/dpll_netlink.h        |  24 +
> drivers/dpll/dpll_pin_attr.c       | 456 ++++++++++++++
> drivers/ptp/Kconfig                |   1 +
> drivers/ptp/ptp_ocp.c              | 123 ++--
> include/linux/dpll.h               | 261 ++++++++
> include/linux/dpll_attr.h          | 433 +++++++++++++
> include/uapi/linux/dpll.h          | 263 ++++++++
> 18 files changed, 4002 insertions(+), 37 deletions(-)
> create mode 100644 Documentation/networking/dpll.rst
> create mode 100644 drivers/dpll/Kconfig
> create mode 100644 drivers/dpll/Makefile
> create mode 100644 drivers/dpll/dpll_attr.c
> 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 drivers/dpll/dpll_pin_attr.c
> create mode 100644 include/linux/dpll.h
> create mode 100644 include/linux/dpll_attr.h
> create mode 100644 include/uapi/linux/dpll.h
>
>-- 
>2.27.0
>

WARNING: multiple messages have this Message-ID (diff)
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>,
	Paolo Abeni <pabeni@redhat.com>,
	netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-clk@vger.kernel.org
Subject: Re: [RFC PATCH v4 0/4] Create common DPLL/clock configuration API
Date: Wed, 30 Nov 2022 13:32:23 +0100	[thread overview]
Message-ID: <Y4dNV14g7dzIQ3x7@nanopsycho> (raw)
In-Reply-To: <20221129213724.10119-1-vfedorenko@novek.ru>

Tue, Nov 29, 2022 at 10:37:20PM CET, vfedorenko@novek.ru wrote:
>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.

Overall, I see a lot of issues on multiple levels. I will go over them
in follow-up emails. So far, after couple of hours looking trought this,
I have following general feelings/notes:

1) Netlink interface looks much saner than in previous versions. I will
   send couple of notes, mainly around events and object mixtures and
   couple of bugs/redundancies. But overall, looks fineish.

2) I don't like that concept of a shared pin, at all. It makes things
   unnecessary complicated. Just have a pin created for dpll instance
   and that's it. If another instance has the same pin, it should create
   it as well. Keeps things separate and easy to model. Let the
   hw/fw/driver figure out the implementation oddities.
   Why exactly you keep pushing the shared pin idea? Perhaps I'm missing
   something crucial.

3) I don't like the concept of muxed pins and hierarchies of pins. Why
   does user care? If pin is muxed, the rest of the pins related to this
   one should be in state disabled/disconnected. The user only cares
   about to see which pins are related to each other. It can be easily
   exposed by "muxid" like this:
   pin 1
   pin 2
   pin 3 muxid 100
   pin 4 muxid 100
   pin 5 muxid 101
   pin 6 muxid 101
   In this example pins 3,4 and 5,6 are muxed, therefore the user knows
   if he connects one, the other one gets disconnected (or will have to
   disconnect the first one explicitly first).

4) I don't like the "attr" indirection. It makes things very tangled. It
   comes from the concepts of classes and objects and takes it to
   extreme. Not really something we are commonly used to in kernel.
   Also, it brings no value from what I can see, only makes things very
   hard to read and follow.

   Please keep things direct and simple:
   * If some option could be changed for a pin or dpll, just have an
     op that is directly called from netlink handler to change it.
     There should be clear set of ops for configuration of pin and
     dpll object. This "attr" indirection make this totally invisible.
   * If some attribute is const during dpll or pin lifetime, have it
     passed during dpll or pin creation.



>
>v3 -> v4:
> * redesign framework to make pins dynamically allocated (Arkadiusz)
> * implement shared pins (Arkadiusz)
>v2 -> v3:
> * implement source select mode (Arkadiusz)
> * add documentation
> * implementation improvements (Jakub)
>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
>
>
>Arkadiusz Kubalewski (1):
>  dpll: add dpll_attr/dpll_pin_attr helper classes
>
>Vadim Fedorenko (3):
>  dpll: Add DPLL framework base functions
>  dpll: documentation on DPLL subsystem interface
>  ptp_ocp: implement DPLL ops
>
> Documentation/networking/dpll.rst  | 271 ++++++++
> Documentation/networking/index.rst |   1 +
> MAINTAINERS                        |   8 +
> drivers/Kconfig                    |   2 +
> drivers/Makefile                   |   1 +
> drivers/dpll/Kconfig               |   7 +
> drivers/dpll/Makefile              |  11 +
> drivers/dpll/dpll_attr.c           | 278 +++++++++
> drivers/dpll/dpll_core.c           | 760 +++++++++++++++++++++++
> drivers/dpll/dpll_core.h           | 176 ++++++
> drivers/dpll/dpll_netlink.c        | 963 +++++++++++++++++++++++++++++
> drivers/dpll/dpll_netlink.h        |  24 +
> drivers/dpll/dpll_pin_attr.c       | 456 ++++++++++++++
> drivers/ptp/Kconfig                |   1 +
> drivers/ptp/ptp_ocp.c              | 123 ++--
> include/linux/dpll.h               | 261 ++++++++
> include/linux/dpll_attr.h          | 433 +++++++++++++
> include/uapi/linux/dpll.h          | 263 ++++++++
> 18 files changed, 4002 insertions(+), 37 deletions(-)
> create mode 100644 Documentation/networking/dpll.rst
> create mode 100644 drivers/dpll/Kconfig
> create mode 100644 drivers/dpll/Makefile
> create mode 100644 drivers/dpll/dpll_attr.c
> 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 drivers/dpll/dpll_pin_attr.c
> create mode 100644 include/linux/dpll.h
> create mode 100644 include/linux/dpll_attr.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

  parent reply	other threads:[~2022-11-30 12:32 UTC|newest]

Thread overview: 172+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-29 21:37 [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Vadim Fedorenko
2022-11-29 21:37 ` Vadim Fedorenko
2022-11-29 21:37 ` [RFC PATCH v4 1/4] dpll: add dpll_attr/dpll_pin_attr helper classes Vadim Fedorenko
2022-11-29 21:37   ` Vadim Fedorenko
2022-11-29 21:37 ` [RFC PATCH v4 2/4] dpll: Add DPLL framework base functions Vadim Fedorenko
2022-11-29 21:37   ` Vadim Fedorenko
2022-11-30 15:21   ` Jiri Pirko
2022-11-30 15:21     ` Jiri Pirko
2022-11-30 16:23     ` Jiri Pirko
2022-11-30 16:23       ` Jiri Pirko
2022-12-23 16:45     ` Kubalewski, Arkadiusz
2022-12-23 16:45       ` Kubalewski, Arkadiusz
2023-01-02 12:28       ` Jiri Pirko
2023-01-02 12:28         ` Jiri Pirko
2022-11-30 16:37   ` Jiri Pirko
2022-11-30 16:37     ` Jiri Pirko
2022-12-02 11:27     ` Kubalewski, Arkadiusz
2022-12-02 11:27       ` Kubalewski, Arkadiusz
2022-12-02 12:39       ` Jiri Pirko
2022-12-02 12:39         ` Jiri Pirko
2022-12-02 14:54         ` Kubalewski, Arkadiusz
2022-12-02 14:54           ` Kubalewski, Arkadiusz
2022-12-02 16:15           ` Jiri Pirko
2022-12-02 16:15             ` Jiri Pirko
     [not found]             ` <20221202212206.3619bd5f@kernel.org>
2022-12-05 10:32               ` Jiri Pirko
2022-12-05 10:32                 ` Jiri Pirko
2022-12-06  0:19                 ` Jakub Kicinski
2022-12-06  0:19                   ` Jakub Kicinski
2022-12-06  8:50                   ` Jiri Pirko
2022-12-06  8:50                     ` Jiri Pirko
2022-12-06 17:27                     ` Jakub Kicinski
2022-12-06 17:27                       ` Jakub Kicinski
2022-12-07 13:10                       ` Jiri Pirko
2022-12-07 13:10                         ` Jiri Pirko
2022-12-07 16:59                         ` Jakub Kicinski
2022-12-07 16:59                           ` Jakub Kicinski
2022-12-08  8:14                           ` Jiri Pirko
2022-12-08  8:14                             ` Jiri Pirko
2022-12-08 16:19                             ` Jakub Kicinski
2022-12-08 16:19                               ` Jakub Kicinski
2022-12-08 16:33                               ` Jiri Pirko
2022-12-08 16:33                                 ` Jiri Pirko
2022-12-08 17:05                                 ` Jakub Kicinski
2022-12-08 17:05                                   ` Jakub Kicinski
2022-12-09  9:29                                   ` Jiri Pirko
2022-12-09  9:29                                     ` Jiri Pirko
2022-12-09 16:19                                     ` Jakub Kicinski
2022-12-09 16:19                                       ` Jakub Kicinski
2022-12-12 13:36                                       ` Jiri Pirko
2022-12-12 13:36                                         ` Jiri Pirko
2022-12-13 18:08                                         ` Kubalewski, Arkadiusz
2022-12-13 18:08                                           ` Kubalewski, Arkadiusz
2022-12-14  7:32                                           ` Jiri Pirko
2022-12-14  7:32                                             ` Jiri Pirko
2022-11-29 21:37 ` [RFC PATCH v4 3/4] dpll: documentation on DPLL subsystem interface Vadim Fedorenko
2022-11-29 21:37   ` Vadim Fedorenko
2022-12-02 12:43   ` kernel test robot
2022-12-19  9:13   ` Paolo Abeni
2022-12-19  9:13     ` Paolo Abeni
2023-01-12 13:45     ` Kubalewski, Arkadiusz
2023-01-12 13:45       ` Kubalewski, Arkadiusz
2022-11-29 21:37 ` [RFC PATCH v4 4/4] ptp_ocp: implement DPLL ops Vadim Fedorenko
2022-11-29 21:37   ` Vadim Fedorenko
2022-11-30  8:30   ` kernel test robot
2022-11-30 12:41   ` Jiri Pirko
2022-11-30 12:41     ` Jiri Pirko
2022-12-02 11:27     ` Kubalewski, Arkadiusz
2022-12-02 11:27       ` Kubalewski, Arkadiusz
2022-12-02 12:48       ` Jiri Pirko
2022-12-02 12:48         ` Jiri Pirko
2022-12-02 14:39         ` Kubalewski, Arkadiusz
2022-12-02 14:39           ` Kubalewski, Arkadiusz
2022-12-02 16:20           ` Jiri Pirko
2022-12-02 16:20             ` Jiri Pirko
2022-12-08  0:35             ` Kubalewski, Arkadiusz
2022-12-08  0:35               ` Kubalewski, Arkadiusz
2022-12-08  8:19               ` Jiri Pirko
2022-12-08  8:19                 ` Jiri Pirko
2022-12-07  2:33           ` Jakub Kicinski
2022-12-07  2:33             ` Jakub Kicinski
2022-12-07 13:19             ` Jiri Pirko
2022-12-07 13:19               ` Jiri Pirko
     [not found]               ` <20221207090524.3f562eeb@kernel.org>
2022-12-08 11:22                 ` Jiri Pirko
2022-12-09  0:36                   ` Jakub Kicinski
2022-12-09  9:32                     ` Jiri Pirko
2022-11-30 12:32 ` Jiri Pirko [this message]
2022-11-30 12:32   ` [RFC PATCH v4 0/4] Create common DPLL/clock configuration API Jiri Pirko
2022-12-02 11:27   ` Kubalewski, Arkadiusz
2022-12-02 11:27     ` Kubalewski, Arkadiusz
2022-12-02 16:12     ` Jiri Pirko
2022-12-02 16:12       ` Jiri Pirko
2022-12-07  2:47       ` Jakub Kicinski
2022-12-07  2:47         ` Jakub Kicinski
2022-12-07 14:09         ` netdev.dump
2022-12-07 14:09           ` netdev.dump
2022-12-07 23:21           ` Jakub Kicinski
2022-12-07 23:21             ` Jakub Kicinski
2022-12-08 11:28             ` Jiri Pirko
2022-12-08 11:28               ` Jiri Pirko
2022-12-09  0:39               ` Jakub Kicinski
2022-12-09  0:39                 ` Jakub Kicinski
2022-12-09  0:56                 ` Kubalewski, Arkadiusz
2022-12-09  0:56                   ` Kubalewski, Arkadiusz
2022-12-08 18:08             ` Maciek Machnikowski
2022-12-08 18:08               ` Maciek Machnikowski
2022-12-09 11:07               ` Jiri Pirko
2022-12-09 11:07                 ` Jiri Pirko
2022-12-09 14:09                 ` Maciek Machnikowski
2022-12-09 14:09                   ` Maciek Machnikowski
2022-12-09 16:31                   ` Jakub Kicinski
2022-12-09 16:31                     ` Jakub Kicinski
2022-12-09 17:11                     ` Maciek Machnikowski
2022-12-09 17:11                       ` Maciek Machnikowski
2022-12-12 13:58                     ` Jiri Pirko
2022-12-12 13:58                       ` Jiri Pirko
2023-01-09 14:43                       ` Kubalewski, Arkadiusz
2023-01-09 14:43                         ` Kubalewski, Arkadiusz
2023-01-09 16:30                         ` Jiri Pirko
2023-01-09 16:30                           ` Jiri Pirko
2023-01-10 10:54                           ` Kubalewski, Arkadiusz
2023-01-10 10:54                             ` Kubalewski, Arkadiusz
2023-01-10 14:28                             ` Jiri Pirko
2023-01-10 14:28                               ` Jiri Pirko
     [not found]                             ` <645a5bfd-0092-2f39-0ff2-3ffb27ccf8fe@machnikowski.net>
2023-01-11 14:17                               ` Kubalewski, Arkadiusz
2023-01-11 14:17                                 ` Kubalewski, Arkadiusz
2023-01-11 14:40                                 ` Maciek Machnikowski
2023-01-11 14:40                                   ` Maciek Machnikowski
2023-01-11 15:30                                   ` Kubalewski, Arkadiusz
2023-01-11 15:30                                     ` Kubalewski, Arkadiusz
2023-01-11 15:54                                     ` Maciek Machnikowski
2023-01-11 15:54                                       ` Maciek Machnikowski
2023-01-11 16:27                                       ` Kubalewski, Arkadiusz
2023-01-11 16:27                                         ` Kubalewski, Arkadiusz
2023-01-10 20:05                         ` Jakub Kicinski
2023-01-10 20:05                           ` Jakub Kicinski
2023-01-11  8:19                           ` Jiri Pirko
2023-01-11  8:19                             ` Jiri Pirko
2023-01-11 14:16                             ` Kubalewski, Arkadiusz
2023-01-11 14:16                               ` Kubalewski, Arkadiusz
2023-01-11 15:04                               ` Jiri Pirko
2023-01-11 15:04                                 ` Jiri Pirko
2023-01-11 15:30                                 ` Kubalewski, Arkadiusz
2023-01-11 15:30                                   ` Kubalewski, Arkadiusz
2023-01-11 16:14                                   ` Jiri Pirko
2023-01-11 16:14                                     ` Jiri Pirko
2023-01-12 12:15                                     ` Kubalewski, Arkadiusz
2023-01-12 12:15                                       ` Kubalewski, Arkadiusz
2023-01-12 14:43                                       ` Jiri Pirko
2023-01-12 14:43                                         ` Jiri Pirko
2022-12-09  0:46             ` Kubalewski, Arkadiusz
2022-12-09  0:46               ` Kubalewski, Arkadiusz
2022-12-07 14:51         ` Jiri Pirko
2022-12-07 14:51           ` Jiri Pirko
     [not found]           ` <20221207091946.3115742f@kernel.org>
2022-12-08 12:02             ` Jiri Pirko
2022-12-08 12:02               ` Jiri Pirko
2022-12-09  0:54               ` Jakub Kicinski
2022-12-08 18:23             ` Kubalewski, Arkadiusz
2022-12-08 18:23               ` Kubalewski, Arkadiusz
2022-12-08  0:27       ` Kubalewski, Arkadiusz
2022-12-08  0:27         ` Kubalewski, Arkadiusz
2022-12-08 11:58         ` Jiri Pirko
2022-12-08 11:58           ` Jiri Pirko
2022-12-08 23:05           ` Kubalewski, Arkadiusz
2022-12-08 23:05             ` Kubalewski, Arkadiusz
2022-12-09 10:01             ` Jiri Pirko
2022-12-09 10:01               ` Jiri Pirko
2023-01-12 12:23 ` Kubalewski, Arkadiusz
2023-01-12 12:23   ` Kubalewski, Arkadiusz
2023-01-12 14:50   ` Jiri Pirko
2023-01-12 14:50     ` Jiri Pirko
2023-01-12 19:09   ` Jakub Kicinski
2023-01-12 19:09     ` Jakub Kicinski

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=Y4dNV14g7dzIQ3x7@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=arkadiusz.kubalewski@intel.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=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.