Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Arnd Bergmann
Date: Tue Mar 31 2026 - 10:12:45 EST
On Tue, Mar 31, 2026, at 15:43, Khristine Andreea Barbulescu wrote:
> On 3/31/2026 1:11 PM, Arnd Bergmann wrote:
>
> Our initial intention had been to expose that SoC-information as
> discussed in the earlier revisions of this series. However,
> taking the review feedback into account, the current direction is
> to stop handling those SoC information registers in the Linux driver
> altogether and instead rely on a boot firmware to pass that
> information forward, as you suggested.
>
> With this approach, the SIUL2 driver would no longer be responsible
> for any separate SoC-information functionality. In that case,
> I understand your point that a monolithic pinctrl/GPIO/irqchip
> driver is a better fit than keeping the MFD structure.
Ok
> However, as you mentioned, this is still weird because it means
> listing individual register areas of the larger device inside.
>
> For this reason, I was wondering whether it would still be
> acceptable to move forward with the new binding introduced
> in this series, but simplify it so that it describes a single
> monolithic SIUL2 pinctrl/GPIO device instead of an MFD,
> following the example node I included in my previous reply [1].
>
> [1]
> https://lore.kernel.org/linux-gpio/20260120115923.3463866-4-khristineandreea.barbulescu@xxxxxxxxxxx/T/#m778088251774a15bde7463350d6e75d5e9b9b57d
I can't think of a justification for making this an incompatible
binding change, if the new "nxp,s32g-siul2-pinctrl" binding is almost
the same as the old "nxp,s32g2-siul2-pinctrl" one, and you still
plan to support both versions in the same driver indefinitely.
It would seem much easier to me to make sure that nxp,s32g-siul2-pinctrl
remains backwards compatible with the existing driver and only
adds the properties for gpio support on top, so a single
driver can handle both old and new dts files.
Arnd