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

On 23/03/2026 08:57, Khristine Andreea Barbulescu wrote:

On 3/14/2026 9:31 AM, Arnd Bergmann wrote:

quoted

On Fri, Mar 13, 2026, at 18:10, Krzysztof Kozlowski wrote:

quoted

On 25/02/2026 10:40, Ghennadi Procopciuc wrote:

quoted

On 2/23/2026 3:14 PM, Krzysztof Kozlowski wrote:

quoted

quoted

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