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

[Krzysztof Kozlowski <krzk@kernel.org>]

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