linux-kernel - Re: sdhci driver card-detect is broken because gpiolib can't fallback to

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: <CAHp75VcQ0SviZ6vsn_5inn5oZxxj-5ZQq5bC+bXPxuF8KOa_Rg@mail.gmail.com>
Date:   Thu, 27 Sep 2018 10:26:42 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Rajat Jain <rajatja@...gle.com>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Dmitry Torokhov <dtor@...gle.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-mmc <linux-mmc@...r.kernel.org>,
        Rajat Jain <rajatxjain@...il.com>
Subject: Re: sdhci driver card-detect is broken because gpiolib can't fallback
 to _CRS?

On Wed, Sep 26, 2018 at 10:26 PM Rajat Jain <rajatja@...gle.com> wrote:
> On Wed, Sep 26, 2018 at 1:42 AM Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
> > On Wed, Sep 26, 2018 at 10:49 AM Mika Westerberg
> > <mika.westerberg@...ux.intel.com> wrote:

> > > Or you can use con_id=<actual string> everywhere and supply
> > > acpi_dev_add_driver_gpios() where needed to cover cases where BIOS does
> > > not provide _DSD.
>
> This sounds like a good idea and I'd like to do this. I have some
> questions though:
>
> 1) If the BIOS does provide a _DSD entry for "cd-gpio", and
> additionally driver also uses devm_acpi_dev_add_driver_gpios() to add
> one more entry for the same string "cd-gpio", which one will (should?)
> actually be returned by the gpiolib? The one in BIOS or the one that
> was added by the driver?

Of course the one that BIOS provides. This hardcoded mapping tables is
a fallback for *old* BIOSes which do not have _DSD.

> 2) Related, I'm trying to understand how can a driver use
> devm_acpi_dev_add_driver_gpios(), for *only* the case where the BIOS
> does not have a _DSD (Or should it really care)? Does the driver need
> to check for _DSD using some other ACPI call?

The magic happens internally in ACPI core.
Whenever one calls gpiod_get() with a name on ACPI-enabled platform,
_DSD would be checked first.

> > See also Documentation/acpi/gpio-properties.txt for
> > > more information.

> > > In case of SDHCI I think the correct way is to stick using _CRS lookup
> > > only because there typically is just one GpioInt() and I have not seen a
> > > single BIOS yet where they implement _DSD for this besides yours. If
> > > there is not way to change the BIOS implementation then I guess we just
> > > need to amend the driver to call acpi_dev_add_driver_gpios().
>
> Since we shouldn't discourage a BIOS that is trying to do the right
> thing by exposing the details in _DST, I think it would be preferable
> if we can solve this in the kernel.

Patches are welcome, I think.

Btw, is there any existing hardware on the market with such BIOS?

-- 
With Best Regards,
Andy Shevchenko