From: Jiri Pirko <jiri@resnulli.us>
Sent: Wednesday, June 14, 2023 11:27 AM

Tue, Jun 13, 2023 at 06:38:01PM CEST, kuba@kernel.org wrote:

quoted

On Tue, 13 Jun 2023 11:55:11 +0200 Jiri Pirko wrote:

quoted

quoted

quoted

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

It seems like pin-parent is overloaded, can we split it into two
different nests?

Yeah, we had it as two and converged to this one. The thing is, the rest
of the attrs are the same for both parent pin and parent device. I link
it this way a bit better. No strong feeling.

Do you mean the same attribute enum / "space" / "set"?

Yeah, that is my understanding. Arkadiusz, could you please clarify?

From user perspective the pin object is configured either:
- by itself (DPLL_A_PIN_FREQUENCY), as this affects all registered pin's dplls 
and frequency set ops are called on all of them,
- in a tuples, where ops are called only on particular parent object:
  - pin:'dpll device' (DPLL_A_PIN_STATE, DPLL_A_PIN_PRIO, DPLL_A_PIN_DIRECTION),
  - pin:'parent MUX-type pin' (DPLL_A_PIN_STATE).
  
Right now DPLL_A_PIN_PARENT nest can convey both parent types:
- if the nest contains DPLL_A_ID, other attributes describe config with the
parent dpll device,
- if it contains DPLL_A_PIN_ID, the other attributes describe config with the
parent pin.

The above example is actually a bit misleading, as this relates to the muxed
pin. From user perspective the information on parent dpll devices is redundant,
and I think in this case we shall not pass it to the user, as the pin was not
explicitly registered with a device by device driver.
The user shall only get parent pin related info, like:
``'pin': [{
 {'clock-id': 282574471561216,
  'module-name': 'ice',
  'pin-dpll-caps': 4,
  'pin-id': 13,
  'pin-parent': [{'pin-id': 2, 'pin-state': 'connected'},
                 {'pin-id': 3, 'pin-state': 'disconnected'},
  'pin-type': 'synce-eth-port'}
}]``

Thus will fix this by removing the parent device information from the muxed
pins info.

But to answer the question: for now it seems good enough to have the PIN_PARENT
nest that conveys either parent pin or parent dpll device information.
IMHO the real question here is about the future, are we going to add pin-parent
only config, which would not be a part of pin-device superset and would make
things unclear?
Unfortunately I don't have on my mind anything more that would be needed for
pin:parent_pin tuple..

Surely, we can skip this discussion and split the nest attr into something like:
- PIN_A_PIN_PARENT_DEVICE,
- PIN_A_PIN_PARENT_PIN.

quoted

In the example above the attributes present don't seem to overlap.
For user space its an extra if to sift thru the objects under
pin-parent.

quoted

quoted

Also sounds like setting pin attrs and pin-parent attrs should be
different commands.

Could be, but what't the benefit? Also, you are not configuring
pin-parent. You are configuring pin:pin-parent tuple. Basically the pin
configuration as a child. So this is mainly config of the pin itsest
Therefore does not really make sense to me to split to two comments.

Clarity of the API. If muxing everything thru few calls was the goal
we should also have very few members in struct dpll_pin_ops, and we
don't.

How the the internal kernel api related to the uapi? I mean, it's quite
common to have 1:N relationsip between cmd and op. I have to be missing
your point. Could you be more specific please?

Current code presents PIN_SET command with accepts structured set of
attribute to be set. The core-driver api is pretty clear. Squashing to
a single op would be disaster. Having one command per attr looks like an
overkill without any real benefit. How exactly do you propose to change
this?

Well, I agree that one command per attribute might be an overkill.

Thank you,
Arkadiusz