MIME-Version: 1.0
References: <20211115154201.46579-1-andriy.shevchenko@linux.intel.com> <304efdfe-db6e-051e-b61d-e73a8dfa1c53@axentia.se>
In-Reply-To: <304efdfe-db6e-051e-b61d-e73a8dfa1c53@axentia.se>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Thu, 18 Nov 2021 12:33:16 +0200
Message-ID: <CAHp75VcF1TZ5hH42-D+0sRkYkN-A1r797LdHGMT93UO4Sp3wLQ@mail.gmail.com>
Subject: Re: [PATCH v1 1/3] i2c: mux: gpio: Replace custom acpi_get_local_address()
To:     Peter Rosin <peda@axentia.se>,
        "Rafael J. Wysocki" <rafael@kernel.org>
Cc:     Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Evan Green <evgreen@chromium.org>,
        linux-i2c <linux-i2c@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Peter Korsgaard <peter.korsgaard@barco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

+Cc: Rafael

On Thu, Nov 18, 2021 at 12:24 PM Peter Rosin <peda@axentia.se> wrote:
> On 2021-11-15 16:41, Andy Shevchenko wrote:

...

> > -     *adr =3D adr64;
> > -     if (*adr !=3D adr64) {
> > -             dev_err(dev, "Address out of range\n");
> > -             return -ERANGE;
> > -     }
>
> In the conversion, I read it as if we lose this overflow check.

It depends from which angle you look at this. We relaxed requirements.

> Why is that
> not a problem?

The idea behind the acpi_get_local_address() is to provide a unified
way between DT and ACPI for the same value. In either case we take
only a 32-bit value. We might nevertheless add that check to the API.
Rafael, what do you think?

P.S. Just realized that in ACPI the higher part of the address may be
used as flags by some interfaces (SoundWire is one of them), this is
not applicable to I=C2=B2C muxes right now, but who knows... So I prefer a
relaxed version and, if necessary, documentation should be
amended/updated.


--=20
With Best Regards,
Andy Shevchenko