Re: [PATCH 05/13] dt-bindings: mfd: add Documentation for Airoha EN7581 SCU

Krzysztof Kozlowski
2025-03-10T11:41:20Z

On 10/03/2025 11:47, Christian Marangi wrote:
> On Mon, Mar 10, 2025 at 10:21:45AM +0100, Krzysztof Kozlowski wrote:
>> On 09/03/2025 14:29, Christian Marangi wrote:
>>> Add Documentation for Airoha EN7581 SCU.
>>>
>>> Airoha EN7581 SoC expose registers to control miscellaneous pheriperals
>>> via the SCU (System Controller Unit).
>>>
>>> Example of these pheriperals are reset-controller, clock-controller,
>>> PCIe line speed controller and bits to configure different Serdes ports
>>> for USB or Ethernet usage.
>>>
>>> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
>>> ---
>>> .../mfd/airoha,en7581-scu-sysctl.yaml | 68 +++++++++++++++++++
>>> 1 file changed, 68 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/mfd/airoha,en7581-scu-sysctl.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/airoha,en7581-scu-sysctl.yaml b/Documentation/devicetree/bindings/mfd/airoha,en7581-scu-sysctl.yaml
>>> new file mode 100644
>>> index 000000000000..d7dc66f912c1
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/mfd/airoha,en7581-scu-sysctl.yaml
>>> @@ -0,0 +1,68 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/mfd/airoha,en7581-scu-sysctl.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Airoha EN7581 SCU (System Controller Unit)
>>> +
>>> +maintainers:
>>> + - Christian Marangi <ansuelsmth@gmail.com>
>>> +
>>> +description:
>>> + Airoha EN7581 SoC expose registers to control miscellaneous
>>> + pheriperals via the SCU (System Controller Unit).
>>> +
>> One more comment - there is no such thing as "sysctl" in your hardware.
>> Look at the SCU binding which clearly says that it is the hardware you
>> are duplicating here, so the "System Control Unit".
>>
>> So you have existing "This node defines the System Control Unit of the
>> EN7523 SoC" and you add one more node which defines the "System Control
>> Unit", so you have two "System Control Unit" device nodes?
>>
>> Look also what Stephen asked for:
>>
>> https://lore.kernel.org/all/20220106013100.842FCC36AEB@smtp.kernel.org/
>>
>> so how system-controller can now became clock-controller? Now, it was
>> the system controller since the beginning.
>>
>
> The main problem here (and we had a similar problem with GPIO and PWM)
> is that the Vendor (Airoha) wasn't so bright in placing the different
> registers for the SoC so we have case where everything is mixed and not
> one after another...
>
> Example we have
> - CLK register part 1
> - Some bits that configure PCIe
> - CLK register part 2
> - GPIO
> - CLK register part 3
> - ...

This does not explain that binding said "This node defines the System
Control Unit".

So what are you adding here if not SCU?

>
> The driver solution for this is syscon and the simple-mfd node
> structure.

Let's keep driver entirely separate, we don't talk about them and mixing
arguments won't make it easier.

>
> Now the main problem is how to modle this in DT. There are lots of case
> where the simple-mfd model is used (like the one proposed) but probably
> this is not accepted anymore. But again this should be clearly stated or
> we have a chicken-egg problem when other devs implement similar thing and
> have to implement simple MFD driver to handle this. (and driver
> maintainers say "Use the simple-mfd model like it was already done)

simple-mfd has nothing to do here. Describe the hardware - what is the SCU?

>
> For this specific case (and to give an answer to the clock patch after
> this) the problem is that this register space was originally used only
> to control the clock and I wasn't aware that it was also used to control
> USB. Now that I'm implementing support for it, the disaster happened.
>
> So In short SCU is lots of thing, both a system-controller, a
> clock-controller and even a reset-controller.

And you have bindings for that already. Done.

>
> To make it short, 2 different solution:
> 1. We can keep the current node structure of the node-controller and add a
> child node for the SSR part (with a dedicated compatible).

No, you do not add child nodes just because you want some drivers.

What is SSR? How is it a device?

> 2. Those property need to be be defined in the clock-controller node?

In the SCU node. Do you have only one SCU or more?

>
> The ideal solution is 1. Does it work for you?
>
> Sorry for the long post and hope you understand why this mess of
> reworking the binding.
>

Best regards,
Krzysztof