[PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
Khristine Andreea Barbulescu
khristineandreea.barbulescu at oss.nxp.com
Fri Feb 20 06:36:37 PST 2026
Hello Krzysztof,
On 2/20/2026 12:16 PM, Krzysztof Kozlowski wrote:
> [You don't often get email from krzk at 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:
siul2: siul2 at 4009c000 {
compatible = "nxp,s32g3-siul2", "nxp,s32g2-siul2";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x4009c000 0x4009c000 0x179c>,
<0x44010000 0x44010000 0x17b0>;
siul20: siul20 at 4009c000 {
compatible = "nxp,s32g-siul2-syscfg", "syscon";
reg = <0x4009c000 0x179c>;
};
siul21: siul21 at 44010000 {
compatible = "nxp,s32g-siul2-syscfg", "syscon";
reg = <0x44010000 0x17b0>;
};
pinctrl: pinctrl {
compatible = "nxp,s32g-siul2-pinctrl";
#gpio-cells = <2>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 102>, <&pinctrl 112 112 79>;
interrupt-controller;
#interrupt-cells = <2>;
interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;
jtag_pins: jtag-pins {
jtag-grp0 {
pinmux = <0x0>;
input-enable;
bias-pull-up;
slew-rate = <166>;
};
};
};
};
Could you please confirm this matches the intent of your feedback, or let me
know if I misunderstood any part? If this looks correct, I’ll move ahead
with the new patch set.
>>
>>>> + required:
>>>> + - compatible
>>>> + - reg
>>>> +
>>>> + "-hog(-[0-9]+)?$":
>>>> + required:
>>>> + - gpio-hog
>>>> +
>>>> + "-pins$":
>>>> + type: object
>>>> + additionalProperties: false
>>>> +
>>>> + patternProperties:
>>>> + "-grp[0-9]$":
>>>> + type: object
>>>> + allOf:
>>>> + - $ref: /schemas/pinctrl/pinmux-node.yaml#
>>>> + - $ref: /schemas/pinctrl/pincfg-node.yaml#
>>>> + description:
>>>> + Pinctrl node's client devices specify pin muxes using subnodes,
>>>> + which in turn use the standard properties below.
>>>> +
>>>> + properties:
>>>> + pinmux:
>>>> + description: |
>>>> + An integer array for representing pinmux configurations of
>>>> + a device. Each integer consists of a PIN_ID and a 4-bit
>>>> + selected signal source(SSS) as IOMUX setting, which is
>>>> + calculated as: pinmux = (PIN_ID << 4 | SSS)
>>>> +
>>>> + slew-rate:
>>>> + description: Supported slew rate based on Fmax values (MHz)
>>>> + enum: [83, 133, 150, 166, 208]
>>>> + required:
>>>> + - pinmux
>>>> +
>>>> + unevaluatedProperties: false
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - gpio-controller
>>>> + - "#gpio-cells"
>>>> + - gpio-ranges
>>>> + - interrupts
>>>> + - interrupt-controller
>>>> + - "#interrupt-cells"
>>>> + - "#address-cells"
>>>> + - "#size-cells"
>>>> + - ranges
>>>> +
>>>> +additionalProperties: false
>>>> +
>>>> +examples:
>>>> + - |
>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> + #include <dt-bindings/interrupt-controller/irq.h>
>>>> +
>>>> + pinctrl at 4009c000 {
>>>> + compatible = "nxp,s32g2-siul2";
>>>> + gpio-controller;
>>>> + #gpio-cells = <2>;
>>>> + gpio-ranges = <&siul2 0 0 102>, <&siul2 112 112 79>;
>>>> + interrupt-controller;
>>>> + #interrupt-cells = <2>;
>>>> + interrupts = <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>>> + ranges;
>>>> +
>>>> + siul2_0: siul2_0 at 4009c000 {
>>>> + compatible = "syscon";
>>>> + reg = <0x0 0x4009c000 0x0 0x179c>;
>>>> + };
>>>> +
>>>> + siul2_1: siul2_1 at 44010000 {
>>>> + compatible = "syscon";
>>>> + reg = <0x0 0x44010000 0x0 0x17b0>;
>>>> + };
>>>> +
>>>> + jtag-pins {
>>>> + jtag-grp0 {
>>>> + pinmux = <0x0>;
>>>> + input-enable;
>>>> + bias-pull-up;
>>>> + slew-rate = <166>;
>>>> + };
>>>> + };
>>>> + };
>>>> +...
>>>> diff --git a/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml
>>>> index a24286e4def6..332397a21394 100644
>>>> --- a/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml
>>>> +++ b/Documentation/devicetree/bindings/pinctrl/nxp,s32g2-siul2-pinctrl.yaml
>>>> @@ -11,6 +11,8 @@ maintainers:
>>>> - Ghennadi Procopciuc <Ghennadi.Procopciuc at oss.nxp.com>
>>>> - Chester Lin <chester62515 at gmail.com>
>>>>
>>>> +deprecated: true
>>>> +
>>>
>>> I don't really see why you can't just extend this binding with GPIO and
>>> interrupt provider properties.
>>
>> The existing SIUL2 pinctrl binding only describes the MSCR/IMCR registers and treats SIUL2 as a standalone pinctrl block. This is incomplete and does not correctly represent the SIUL2 hardware, which also provides GPIO control, interrupt configuration, and MIDR identification registers across two register windows. Extending the old binding would require incompatible ABI changes and would result in carved-out subregions, which is discouraged.
>
> Can you just add missing register ranges to existing device? I really do
> not see how this is incompatible ABI or how does it result in carved-out
> regions.
>
I’m also fine with your proposal to add the missing register ranges to
the existing device. But that would also mean extending it with the
GPIO registers and two syscon subnodes for system info, as they all need
to be provided by this SIUL2 device. This would effectively make the
existing pinctrl binding an MFD.
Is evolving the existing binding acceptable in this manner, or should
we continue with this new MFD binding and leave the old pinctrl
binding deprecated?
>
> Best regards,
> Krzysztof
Best regards,
Khristine
[0] https://lore.kernel.org/linux-gpio/CAKfTPtD6LOMFGhzG3dhiSQCNbYrGLjBiT83eqz9mmwaDVpNV=w@mail.gmail.com/
More information about the linux-arm-kernel
mailing list