Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module

[Arnd Bergmann]

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