Re: [RFC PATCH v8 01/10] dpll: documentation on DPLL subsystem interface

[Jiri Pirko]

Thu, Jun 15, 2023 at 06:31:11PM CEST, kuba@xxxxxxxxxx wrote:
>On Thu, 15 Jun 2023 12:18:28 +0200 Jiri Pirko wrote:
>> Yeah, that is what we had originally. This just pushes out the
>> different attr selection from the nest one level up to the actualy
>> nesting attribute.
>
>Oh no, no extra nesting. Let me try to fake up the output:

I wasn't implying any extra nesting.

>
>'pin': [{
> {'clock-id': 282574471561216,
>  'module-name': 'ice',
>  'pin-dpll-caps': 4,
>  'pin-id': 13,
>  'parent-device': [{'pin-id': 2, 'pin-state': 'connected'},
>                    {'pin-id': 3, 'pin-state': 'disconnected'}],
>  'parent-pin': [{'id': 0, 'pin-direction': 'input'},
>                 {'id': 1, 'pin-direction': 'input'}],
>  'pin-type': 'synce-eth-port'}

You messed up a bit. Should be:
parent-device : id
parent-pin : pin-id

That is basically my point. The fact if the parent is either device or
pin is carried inside the nest by either providing "id" or "pin-id".
So you add redundant info which could be source of mixups - as you
already demonstrated :)


>}]
>
>> One downside of this is you will have 2 arrays of parent objects,
>> one per parent type. Current code neatly groups them into a single array.
>> 
>> I guess this is a matter of personal preference, I'm fine either way.
>
>Yeah, could be.