Devicetree

* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Khristine Andreea Barbulescu @ 2026-03-31  7:48 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Arnd Bergmann, Ghennadi Procopciuc
  Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
	Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
	Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
	Aisheng Dong, Jacky Bai, Greg Kroah-Hartman, Rafael J . Wysocki,
	Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
	Eric Chanudet, imx, linux-arm-kernel, open list:GPIO SUBSYSTEM,
	linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
	Vincent Guittot, Rob Herring
In-Reply-To: <f3ff461b-edd7-423a-ac99-e70145aaaaea@kernel.org>

On 3/23/2026 10:07 AM, Krzysztof Kozlowski wrote:
> On 23/03/2026 08:57, Khristine Andreea Barbulescu wrote:
>> On 3/14/2026 9:31 AM, Arnd Bergmann wrote:
>>> On Fri, Mar 13, 2026, at 18:10, Krzysztof Kozlowski wrote:
>>>> On 25/02/2026 10:40, Ghennadi Procopciuc wrote:
>>>>> On 2/23/2026 3:14 PM, Krzysztof Kozlowski wrote:
>>>>>>> there are no resources allocated specifically for nodes like
>>>>>>> "nxp,s32g-siul2-syscfg". Their consumers are the pinctrl/gpio
>>>>>>> driver and other drivers that read SoC‑specific information from
>>>>>>> those shared registers.
>>>>>>>  
>>>>>>> My alternative is to keep two separate syscon providers for the
>>>>>>
>>>>>> You got review already.
>>>>>>
>>>>> I still believe that nvmem is a suitable and accurate mechanism for
>>>>> describing SoC‑specific identification information, as originally
>>>>> proposed in [0], assuming the necessary adjustments are made.
>>>>>
>>>>> More specifically, instead of modeling software-defined cells, the nvmem
>>>>> layout would describe the actual hardware registers backing this
>>>>> information. One advantage of this approach is that consumer nodes (for
>>>>> example PCIe, Ethernet, or other IPs that need SoC identification data)
>>>>> can reference these registers using the standard nvmem-cells /
>>>>> nvmem-cell-names mechanism, without introducing custom, per-subsystem
>>>>> bindings.
>>>>
>>>> nvmem is applicable only if this is NVMEM. Information about the soc is
>>>> not NVMEM, unless this are blow out fuses / efuse. Does not look like,
>>>> because SoC information is set probably during design phase, not board
>>>> assembly.
>>>
>>> Agreed, nvmem clearly makes no sense here, the patch description
>>> appears to accurately describe the MMIO area as hardware registers
>>> with a fixed meaning rather than a convention for how the
>>> memory is being used.
>>>
>>> That said, there is probably room for improvement, since some of
>>> the register contents are read-only and could just be accessed
>>> by the boot firmware in order to move the information into more
>>> regular DT properties instead of defining bindings for drivers
>>> to access the information in raw form.
>>>
>>>     Arnd
>>
>> Hi Krzysztof & Arnd,
>>
>> Assuming we drop the syscon approach entirely, for the SerDes
>> presence information we could follow Arnd’s suggestion and have
>> it provided by the boot firmware instead of exposing it through SIUL2.
> 
> I think there is misunderstanding. By dropping syscon nodes, I meant to
> drop the nodes. Remove them. It implies that whatever their contain must
> go somewhere, right? Because your hardware is fixed and you cannot drop
> it from the hardware, right?
> 
> So their parent node is the syscon.
> 
> Best regards,
> Krzysztof

Hi Krzysztof & Arnd,

Following your suggestions, I reworked the DT so that the SIUL2
register regions are now described directly on the parent node, and
the separate syscon child nodes are removed.

The node would look like this:
    siul2: siul2@4009c000 {
        compatible = "nxp,s32g2-siul2";
        reg = <0x4009c000 0x179c>,
              <0x44010000 0x17b0>;
        reg-names = "siul20", "siul21";

        pinctrl: pinctrl {
            compatible = "nxp,s32g-siul2-pinctrl";
            gpio-controller;
            #gpio-cells = <2>;
            gpio-ranges = <&pinctrl 0 0 102>, <&pinctrl 112 112 79>;
            interrupt-controller;
            #interrupt-cells = <2>;
            interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;

            jtag_pins: jtag-pins {
                ...
            };
        };
    };

With the current layout, the SIUL2 node itself now contains the two
MMIO ranges directly, while the remaining child node is only the
pinctrl/GPIO function.

I am wondering whether it still makes sense to keep the MFD approach
at all. In the current form, the node no longer models multiple
separate child providers such as the previous syscon children, but
rather a single parent node containing the whole register space
together with the pinctrl/GPIO.

Would you recommend dropping the MFD layer entirely and having
the pinctrl/GPIO driver bind directly to the parent `siul2@...`
node instead?

Please let me know whether this is the direction you would prefer,
or if you still see value in keeping the current MFD based approach.

Best regards,
Khristine

^ permalink raw reply