linux-kernel - Re: [PATCH v1 1/3] i2c: mux: gpio: Replace custom acpi_get_local

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VcF1TZ5hH42-D+0sRkYkN-A1r797LdHGMT93UO4Sp3wLQ@mail.gmail.com>
Date:   Thu, 18 Nov 2021 12:33:16 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Peter Rosin <peda@...ntia.se>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Evan Green <evgreen@...omium.org>,
        linux-i2c <linux-i2c@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Korsgaard <peter.korsgaard@...co.com>
Subject: Re: [PATCH v1 1/3] i2c: mux: gpio: Replace custom acpi_get_local_address()

+Cc: Rafael

On Thu, Nov 18, 2021 at 12:24 PM Peter Rosin <peda@...ntia.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