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

[Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>]

On 2/20/2026 4:41 PM, Krzysztof Kozlowski wrote:
> On 20/02/2026 15:36, Khristine Andreea Barbulescu wrote:
>> Hello Krzysztof,
>>
>> On 2/20/2026 12:16 PM, Krzysztof Kozlowski wrote:
>>> [You don't often get email from krzk@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> On 19/02/2026 12:36, Khristine Andreea Barbulescu wrote:
>>>>>
>>>>>> +      reg:
>>>>>> +        maxItems: 1
>>>>>
>>>>> You have 'reg' so the node name should have unit-address.
>>>>>
>>>>> However, there's not any real DT resources in this child node, so you
>>>>> should just drop it.
>>>>>
>>>>
>>>> For context, SIUL2 exposes a set of platform‑capability and SoC identification registers that are split across the two discontiguous ranges: SIUL2-0 and SIUL2-1. These registers are the source of SoC information (e.g. identification and capability flags) that other subsystems are expected to consume (e.g. PCI Express). Because those fields are physically divided between the two SIUL2 ranges, consumers need reliable access to both ranges to correctly discover and configure the platform.
>>>>
>>>> Hence, my proposal is to keep the two 'syscon' child nodes.
>>>
>>> Please wrap your replies correctly, so this will be easily parseable.
>>>
>>> I do not understand the reasoning. If you have two register ranges, you
>>> have two <reg> entries and having a child node has nothing to do with it.
>>>
>>
>> I’ve reorganized the SIUL2 node with two syscon subnodes for the two
>> register regions used to read system info, and a separate
>> pinctrl/GPIO child (as discussed in the v8 06/10 thread [0]). The parent
>> SIUL2 node now carries the bus addressing and ranges:
> 
> That's not the answer to the comment. Read again:
> 
> 1. Reviewer: No resources, so no separate node.
> 2. Your answer: some soc capability and two address spaces
> 3. Reviewer: Does not matter, address spaces can go again to original place
> 4. Irrelevant reply.
> 
> So again, read the first comment - do you have dedicated resources in
> children?
> 
>>  
>>     siul2: siul2@4009c000 {
>>         compatible = "nxp,s32g3-siul2", "nxp,s32g2-siul2";
>>         #address-cells = <1>;
>>         #size-cells = <1>;
>>         ranges = <0x4009c000 0x4009c000 0x179c>,
>> 		 <0x44010000 0x44010000 0x17b0>;
>>  
>>         siul20: siul20@4009c000 {
>>             compatible = "nxp,s32g-siul2-syscfg", "syscon";
>>             reg = <0x4009c000 0x179c>;
> 
> 0x179c is odd size. Looks fake.
> 
> 
>>         };
>>  
>>         siul21: siul21@44010000 {
>>             compatible = "nxp,s32g-siul2-syscfg", "syscon";
> 
> And two same devices with same compatible proof it.
> 
> Best regards,
> Krzysztof

We don’t have dedicated resources for children. In particular,
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
SIUL2-0 and SIUL2-1 and have consumers (pinctrl/gpio , PCIe, etc.)
reference them via phandles:

    siul20: syscon@4009c000 {
        compatible = "nxp,s32g-siul20-syscfg", "syscon";
        reg = <0x4009c000 0x2000>;
    };
 
    siul21: syscon@44010000 {
        compatible = "nxp,s32g-siul21-syscfg", "syscon";
        reg = <0x44010000 0x2000>;
    };
 
    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>;
        syscon = <&siul20>, <&siul21>;
 
        jtag_pins: jtag-pins {
            jtag-grp0 {
                pinmux = <0x0>;
                input-enable;
                bias-pull-up;
                slew-rate = <166>;
            };
        };
    };
 
    pcie@40400000 {
        reg = <...>;
        /* PCIe Dev ID */
        syscon = <&siul20>;
    };
 
I’ve seen similar approaches upstream [0].
Would this be acceptable (even if not ideal),
or do you prefer a different layout?

Best regards,
Khristine
 
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/pinctrl/xlnx,pinctrl-zynq.yaml#n182