All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Abdurrahman Hussain <abdurrahman@nexthop.ai>
Cc: Peter Rosin <peda@lysator.liu.se>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6] i2c: mux: reg: use device property accessors
Date: Wed, 20 May 2026 08:55:33 +0200	[thread overview]
Message-ID: <ag1a5TLH7L-BSWWp@shikoro> (raw)
In-Reply-To: <20260519-i2c-mux-reg-v6-1-a27ff50dee67@nexthop.ai>

[-- Attachment #1: Type: text/plain, Size: 3486 bytes --]

On Tue, May 19, 2026 at 02:18:50PM -0700, 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.
> 
> Acked-by: Peter Rosin <peda@lysator.liu.se>
> Signed-off-by: Abdurrahman Hussain <abdurrahman@nexthop.ai>
> Assisted-by: Claude-Code:claude-opus-4-7
> Assisted-by: sashiko:gemini-3.1-pro-preview

Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-05-20  6:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-19 21:18 [PATCH v6] i2c: mux: reg: use device property accessors Abdurrahman Hussain
2026-05-20  6:55 ` Wolfram Sang [this message]
2026-05-28 21:52   ` Abdurrahman Hussain
2026-05-28 21:55     ` Wolfram Sang
2026-05-28 22:28       ` Abdurrahman Hussain

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ag1a5TLH7L-BSWWp@shikoro \
    --to=wsa+renesas@sang-engineering.com \
    --cc=abdurrahman@nexthop.ai \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peda@lysator.liu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.