Message-ID: <20230118161525.01d6b94f@kernel.org>
Date:   Wed, 18 Jan 2023 16:15:25 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
        Vadim Fedorenko <vadfed@...a.com>
Cc:     "Jiri Pirko" <jiri@...nulli.us>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        "Paolo Abeni" <pabeni@...hat.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>
Subject: Re: [RFC PATCH v5 0/4] Create common DPLL/clock configuration API

On Wed, 18 Jan 2023 18:07:53 +0000 Kubalewski, Arkadiusz wrote:
> Based on today's sync meeting, changes we are going to introduce in next
> version:
> - reduce the muxed-pin number (artificial multiplication) on list of dpll's
> pins, have a single pin which can be connected with multiple parents,
> - introduce separated get command for the pin attributes,
> - allow infinite name length of dpll device,
> - remove a type embedded in dpll's name and introduce new attribute instead,
> - remove clock class attribute as it is not known by the driver without
> compliance testing on given SW/HW configuration,
> - add dpll device "default" quality level attribute, as shall be known
> by driver for a given hardware.

I converted the patches to use the spec, and pushed them out here:

https://github.com/kuba-moo/ynl/tree/dpll

I kept the conversion step-by-step to help the readers a bit but
the conversion patches should all be squashed into the main DPLL patch.

The patches are on top of my YNL branch ('main' in that repo). 
I'll post the YNL patches later today, so hopefully very soon they will
be upstream.

Two major pieces of work which I didn't do for DPLL:
 - docs - I dropped most of the kdocs, the copy-n-pasting was too much;
   if you want to keep the docs in the uAPI you need to add the
   appropriate stuff in the spec (look at the definition of
   pin-signal-type for an example of a fully documented enum)
 - the notifications are quite unorthodox in the current 
   implementation, so I faked the enums :S
   Usually the notification is the same as the response to a get.
   IIRC 'notify' and 'event' operation types should be used in the spec.

There is documentation on the specs in
Documentation/userspace-api/netlink/ which should give some idea of how
things work. There is also another example of a spec here:
https://github.com/kuba-moo/ynl/blob/psp/Documentation/netlink/specs/psp.yaml

To regenerate the C code after changes to YAML:

  ./tools/net/ynl/ynl-regen.sh

if the Python script doing the generation dies and eats the files -
bring them back with:

  git checkout drivers/dpll/dpll_nl.c drivers/dpll/dpll_nl.h \
               include/uapi/linux/dpll.h

There is a "universal CLI" script in:

  ./tools/net/ynl/samples/cli.py

which should be able to take in JSON requests and output JSON responses.
I'm improvising, because I don't have any implementation to try it 
out, but something like:

  ./tools/net/ynl/samples/cli.py \
       --spec Documentation/netlink/specs/dpll.yaml \
       --do device-get --json '{"id": 1}'

should pretty print the info about device with id 1. Actually - it
probably won't because I didn't fill in all the attrs in the pin nest.
But with a bit more work on the spec it should work.

Would you be able to finish this conversion. Just LMK if you have any
problems, the edges are definitely very sharp at this point.

Powered by blists - more mailing lists