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

[Arnd Bergmann]

On Mon, Mar 23, 2026, at 08:57, Khristine Andreea Barbulescu wrote:
> On 3/14/2026 9:31 AM, Arnd Bergmann wrote:
>> On Fri, Mar 13, 2026, at 18:10, Krzysztof Kozlowski wrote:
>> 
>> 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.
>
> 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 didn't say you would necessarily drop the syscon interface
entirely, but for each user of it, you can see if the data
in it is static at runtime, and if so, you turn it into
devicetree properties.

> However, SerDes presence is not the only information involved.
> As mentioned in the earlier replies, we also have the PCIe device ID,
> which will be needed once PCIe endpoint support is added.
>
> Would it be acceptable to describe this information in DT, as in
> other existing approaches [1], [2], [3], by adding a device-id
> property to the PCIe node?

I don't know how endpoint devices normally get the vendor/device
ID pair, but as far as I can tell, these are not normally assigned
by the boot firmware but are picked by whatever function driver is
running on the endpoint device: the idea for the device ID is
to identify the protocol that a driver on the host side needs to
use, rather than identify what hardware it is running on.

In that case, neither DT nor syscon are an appropriate way to
pass the PCI device ID.

>From looking at the links you provided, all of those appear
to refer to host mode vendor/device ID pairs that get written
into the device at probe time, either because the boot firmware
fails to initialize the devices properly, or because the ID data
is not persistent across a device reset. In endpoint mode,
this would not apply.

      Arnd