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

[Abdurrahman Hussain]

On Tue May 12, 2026 at 12:50 AM PDT, Peter Rosin wrote:
> [note change of email adress, I'm now using peda@xxxxxxxxxxxxxx]
>
> On Thu Feb 26, 2026 at 10:28 PM PST, Abdurrahman Hussain wrote:
>> Hi Andy, Peter,
>> 
>> It looks like the patch is marked as "Changes Requested". I haven't
>> heard any feedback lately. Did I miss something?
>
> Hi!
>
> First of all, as usual I'm sorry for being slow to respond.
>
> One specific thing I noticed with your patch that is a potential
> problem is that it replaces the open coded little-ending/big-endian
> logic with a call to device_is_big_endian() which is not an exact
> replacement. The logic provided by device_is_big_endian() is simply
> not equivalent. Further, the new behavior does not match the device
> tree bindings.
>
> At a minimum, you need a matching patch for the binding before doing
> something like this. But that would of course only expose the risk
> for regressions.
>
> Since there are apparently few who can test this driver, and even
> fewer with endian issues, I'm reluctant to make these changes. I
> would prefer to keep the endian logic exactly as it is.
>
> I have not looked all that closely, but you also make the call to
> devm_platform_get_and_ioremap_resource() unconditional. Why will
> that change not cause regressions?
>
> Your commit message is lacking, you make these changes but only
> talk about extending support to non-OF platforms as if that is
> the only thing that is going on.
>
> And, the initail problem still stands. I would like to see some
> tags that indicate that the driver still works for existing users.
> Especially so since there are changes that look problematic.
>
> Cheers,
> Peter

Hi Peter,

A gentle ping on v3 [1] -- just checking whether you've had a
chance to take another look.

The conversion was reworked deliberately across v2 and v3 to keep
existing OF users behaviour-identical:

  - The three-way endian fallback ("little-endian" wins, then
    "big-endian", else the compile-time byte order via the original
    __BYTE_ORDER preprocessor block) is preserved verbatim.
    device_is_big_endian() is deliberately *not* used here because
    it ignores "little-endian" and introduces "native-endian"
    semantics that would diverge from the binding.

  - The "if (!mux->data.reg)" guard around
    devm_platform_get_and_ioremap_resource() is preserved so a
    platdata caller's pre-ioremapped reg from
    struct i2c_mux_reg_platform_data is not clobbered.

  - The dev_err_probe() wrapper at the probe_fw() call site is
    kept so the helper's silent error paths still produce a dmesg
    line on failure.

Tested on ACPI hardware (two of our switches).  The OF-only
in-tree users are on PowerPC/SH so I couldn't bench them, but I'd
appreciate a maintainer read to confirm I haven't missed anything
binding-visible.  Happy to respin if you'd like anything tweaked.

[1] https://lore.kernel.org/r/20260513-i2c-mux-reg-v3-1-0fa7242605bc@xxxxxxxxxx

Thanks,
Abdurrahman