linux-kernel - Re: [PATCH v1 1/1] gpio: Support interrupts in gpio-mlxbf2.c

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] [day] [month] [year] [list]

Message-ID: <YFiTHIy5Amf583X3@lunn.ch>
Date:   Mon, 22 Mar 2021 13:52:44 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Asmaa Mnebhi <asmaa@...dia.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [PATCH v1 1/1] gpio: Support interrupts in gpio-mlxbf2.c

On Mon, Mar 22, 2021 at 01:41:58PM +0100, Linus Walleij wrote:
> On Wed, Mar 10, 2021 at 9:38 PM Asmaa Mnebhi <asmaa@...dia.com> wrote:
> 
> > > That's fine, the hardware description model (I guess in your case
> > > ACPI) should take care of that.
> > >
> > We cannot really pass it through the ACPI table because the ACPI
> > table is common to all BlueField-2 boards. And each board may have
> > a different GPIO pin associated with a particular function. This is
> > why we use ACPI properties instead of GpioInt(). So that the
> > bootloader can change the GPIO pin value based on the board
> > id detected at boot time.
> (...)
> > Yes. It would belong in the ACPI table if we had a different ACPI
> > table for each board. But unfortunately that is not the case.
> 
> You have to agree with Andy about all ACPI details.
> 
> Andy is the ACPI GPIO maintainer and we cannot merge
> a patch with any kind of ACPI support without his ACK,
> so hash it out as he wants it. The only people on the
> planet that can make me think otherwise is if Rafael
> Wysocki and Mika Westerberg say something else,
> which is *extremely* unlikely.

+1

And given this is burried inside a network driver, you are also going
to get push back from the networking maintainers to do this correctly.

   Andrew