linux-kernel - Re: [PATCH v1 0/6] mmc: sdhci-pci: Add some CD GPIO related quirks

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 7 Oct 2021 15:39:02 -0600
From:   Raul Rangel <rrangel@...omium.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Ulf Hansson <ulf.hansson@...aro.org>,
        Eric Biggers <ebiggers@...gle.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCH v1 0/6] mmc: sdhci-pci: Add some CD GPIO related quirks

It looks like you were previously using the `cd-gpios` DT property to
determine this. It also sounds like you switched from DT to ACPI so
you lost the ability to use this field?

Can you not use something like the following:
https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/kernel/v5.10/drivers/mmc/host/sdhci-acpi.c;l=945

p.s.,
Sorry for resending. I sent it as rich text before.


On Thu, Oct 7, 2021 at 10:47 AM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Tue, Oct 05, 2021 at 01:24:24PM +0300, Andy Shevchenko wrote:
> > It appears that one of the supported platform magically worked with the
> > custom IRQ handler (any hints how?) while having two PCB designs with
> > an opposite CD sense level. Here is an attempt to fix it by quirking out
> > CD GPIO.
> >
> > Patch 1 introduces two additional quirks (it's done this way due to
> > patch 3, see below). Patch 2 is an actual fix for the mentioned platform.
> > If backported need to be taken with patch 1 together. Patch 3 is (RFT)
> > clean up. The questionable part here is the locking scheme. Shouldn't
> > we do something similar in the generic IRQ handler of SDHCI? Or Broxton
> > case has something quite different in mind?
> >
> > Patches 4-6 are dead-code removals. Patch 4 accompanying patch 2, patches
> > 5-6 just similar to it, but (functionally) independent. Would like to hear
> > if it's okay to do.
> >
> > Any comments, hints, advice are welcome!
>
> Adrian, Ulf, any comments on this? At least first two fix the regression and
> would be nice to have them in sooner than later (I can split them separately
> if required).
>
> --
> With Best Regards,
> Andy Shevchenko
>
>