Re: [PATCH v5] i2c: mux: reg: use device property accessors

[Peter Rosin]

On 2026-05-19 20:19, Abdurrahman Hussain wrote:
> Convert the device-tree parsing path to the generic fwnode/device
> property accessors so the driver can be probed on ACPI and swnode
> platforms as well as OF. The helper is renamed from
> i2c_mux_reg_probe_dt() to i2c_mux_reg_probe_fw() to reflect that.
>
> Accessor translation:
>
>    of_parse_phandle("i2c-parent") +
>      of_find_i2c_adapter_by_node()    -> fwnode_find_reference() +
>                                           i2c_find_adapter_by_fwnode()
>    of_get_child_count()               -> device_get_child_node_count()
>    of_property_read_bool()            -> device_property_read_bool()
>    for_each_child_of_node()           -> device_for_each_child_node()
>      of_property_read_u32("reg")        on ACPI device nodes:
>                                           acpi_get_local_address()
>                                         everything else (OF, swnode,
>                                         ACPI data nodes):
>                                           fwnode_property_read_u32()
>    of_property_read_u32("idle-state") -> device_property_read_u32()
>
> The child-node branch uses is_acpi_device_node() rather than
> is_acpi_node(): the latter also matches ACPI data nodes (the
> _DSD hierarchical-property children used by PRP0001-style
> firmware), which have no ACPI handle and would make
> acpi_get_local_address() fall back to evaluating _ADR against the
> root namespace and return -ENODATA.  Routing data nodes through
> fwnode_property_read_u32() instead lets them resolve the "reg"
> property the same way OF and swnode children do.
>
> Behavioural preservations (deliberate, to avoid regressing existing
> users):
>
>    - The three-way endian fallback is kept verbatim: an explicit
>      "little-endian" property wins, then "big-endian", and otherwise
>      the host's compile-time byte order. device_is_big_endian() is
>      not used here because it ignores "little-endian" and introduces
>      "native-endian" semantics, which would diverge from the binding.
>
>    - The "if (!mux->data.reg)" guard around
>      devm_platform_get_and_ioremap_resource() in probe() is kept.
>      drivers/platform/mellanox/mlx-platform.c registers i2c-mux-reg
>      platform_devices with no memory resource and supplies a
>      pre-set .reg / .reg_size through struct
>      i2c_mux_reg_platform_data; without the guard those
>      registrations would fail in probe().
>
>    - The "if (!mux->data.reg)" ioremap block (and the paired
>      reg_size validation that depends on it) is hoisted above
>      i2c_get_adapter(mux->data.parent), so the fwnode path
>      preserves master's ordering of "ioremap before parent-adapter
>      get".  For platdata users the validation runs from a slightly
>      earlier position, but mux->data.reg_size is already set from
>      platdata by then, so the order is functionally neutral.
>
> The OF-only of_address_to_resource() translation in the old
> probe_dt() is dropped because the same address is available from
> the platform_device resource table on OF as well as ACPI, and the
> existing fallback in probe() ioremaps it.
>
> Signed-off-by: Abdurrahman Hussain <abdurrahman@xxxxxxxxxx>

Hi!

Thanks for your patience in seeing this through!

Acked-by: Peter Rosin <peda@xxxxxxxxxxxxxx>

Wolfram, can you please pick this one? Perhaps after waiting a bit
for extra tags, see below.

> ---
> - Discriminate ACPI children with is_acpi_device_node() instead of
>    is_acpi_node().  v4 routed every is_acpi_node() child to
>    acpi_get_local_address(), which is wrong for ACPI data nodes
>    (the _DSD hierarchical-property children PRP0001-style firmware
>    uses): data nodes have no ACPI handle, so ACPI_HANDLE_FWNODE()
>    returns NULL, acpi_get_local_address() falls back to evaluating
>    _ADR against the root namespace, and the probe fails with
>    -ENODATA.  is_acpi_device_node() narrows the match to ACPI
>    device nodes (which do carry an _ADR), and the else-branch now
>    resolves "reg" via fwnode_property_read_u32() for OF, swnode,
>    and ACPI data nodes alike.  Flagged by Sashiko on v4.

According to Documentation/process/coding-assistants.rst, you should
perhaps credit the tool with an Assisted-by tag? Given your mail
address I suspect you might have used other AI tools as well? Just
add tags for whatever is appropriate.

Cheers,
Peter