Date:   Thu, 19 Jan 2023 17:23:42 +0000
From:   "Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>
To:     Jakub Kicinski <kuba@...nel.org>, 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

>-----Original Message-----
>From: Jakub Kicinski <kuba@...nel.org>
>Sent: Thursday, January 19, 2023 1:15 AM
>
>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.

Sure, I will try. Thanks for the manual!

BR, Arkadiusz

Powered by blists - more mailing lists