From: Andy Shevchenko <andy.shevchenko@gmail.com>
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>
Subject: Re: [PATCH v1 1/3] i2c: mux: gpio: Replace custom acpi_get_local_address()
Date: Thu, 18 Nov 2021 12:33:16 +0200 [thread overview]
Message-ID: <CAHp75VcF1TZ5hH42-D+0sRkYkN-A1r797LdHGMT93UO4Sp3wLQ@mail.gmail.com> (raw)
In-Reply-To: <304efdfe-db6e-051e-b61d-e73a8dfa1c53@axentia.se>
+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 = adr64;
> > - if (*adr != 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²C muxes right now, but who knows... So I prefer a
relaxed version and, if necessary, documentation should be
amended/updated.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2021-11-18 10:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-15 15:41 [PATCH v1 1/3] i2c: mux: gpio: Replace custom acpi_get_local_address() Andy Shevchenko
2021-11-15 15:42 ` [PATCH v1 2/3] i2c: mux: gpio: Don't dereference fwnode from struct device Andy Shevchenko
2021-11-15 17:01 ` Evan Green
2021-11-18 9:48 ` Peter Rosin
2021-11-23 10:55 ` Wolfram Sang
2021-11-15 15:42 ` [PATCH v1 3/3] i2c: mux: gpio: Use array_size() helper Andy Shevchenko
2021-11-15 17:01 ` Evan Green
2021-11-18 9:49 ` Peter Rosin
2021-11-23 10:55 ` Wolfram Sang
2021-11-15 16:55 ` [PATCH v1 1/3] i2c: mux: gpio: Replace custom acpi_get_local_address() Evan Green
2021-11-18 9:36 ` Peter Rosin
2021-11-18 10:33 ` Andy Shevchenko [this message]
2021-11-18 11:24 ` Peter Rosin
2021-11-23 10:52 ` Wolfram Sang
2021-11-23 10:55 ` Wolfram Sang
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=CAHp75VcF1TZ5hH42-D+0sRkYkN-A1r797LdHGMT93UO4Sp3wLQ@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=evgreen@chromium.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=peter.korsgaard@barco.com \
--cc=rafael@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).