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

[Ghennadi Procopciuc]

Hi Krzysztof & Arnd,

On 2/25/2026 11:40 AM, Ghennadi Procopciuc wrote:

[ ...]

> Hi Krzysztof & Arnd,
> 
> 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.
> 
> Looking at the nvmem binding documentation [1], it appears that
> individual fields of identification registers (similar to MIDR) could,
> in principle, be exposed using a bits property, for example:
> 
> family_letter at 4009c004 {
>   reg = <0x4009c004 0x4>;
>   bits = <31 26>;
> };
> 
> That said, an alternative (and arguably more common) approach is to
> expose entire registers as fixed-layout cells, and let consumers decode
> bitfields in software. Below is an example of how this would look when
> embedded in the existing SIUL2 node, without relying on per-field bits
> properties:
> 

[...]

> [0]
> https://lore.kernel.org/all/20250710142038.1986052-2-andrei.stefanescu@oss.nxp.com/
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/nvmem/nvmem.yaml#n82
> 

Are you comfortable with this proposal?

I'm asking because it was initially considered a viable option, but the
discussion later shifted to the fact that the nvmem cells were
fabricated and did not accurately describe the underlying hardware.

-- 
Regards,
Ghennadi