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.
