Re: [RFC PATCH v5 0/4] Create common DPLL/clock configuration API

[Jiri Pirko <jiri@resnulli.us>]

Thu, Jan 19, 2023 at 01:15:25AM CET, kuba@kernel.org wrote:
>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.

I already pointed this out in the past. This is not he only thing that
was ignored during the dpll review. I have to say I'm a bit annoyed by
that.


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