[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VePjNR8NcvHiDPuryzmxvntenUDa3OgHchoxu_4k+Nc=g@mail.gmail.com>
Date: Fri, 19 Mar 2021 17:44:20 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Asmaa Mnebhi <asmaa@...dia.com>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
David Thompson <davthompson@...dia.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>
Subject: Re: [PATCH v1 1/1] gpio: Support interrupts in gpio-mlxbf2.c
On Fri, Mar 19, 2021 at 3:24 PM Andrew Lunn <andrew@...n.ch> wrote:
>
> > 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.
>
> That sounds very broken.
>
> ACPI describes the hardware. If the hardware is different, you need
> different ACPI. And i assume the ACPI spec says GpioInt() is the
> correct way to do this, and does not say you can hack around
> limitations of your bootloader using properties?
It seems my reply didn't make the mailing list, but I'm on the same
page with you.
On x86 boards the difference is usually provided by firmware via NVS
and corresponding macro(s).
One may google for any DSDT for x86 and check for, for instance,
GNUM() macro and Co.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists