Re: [PATCH v1 0/6] mmc: sdhci-pci: Add some CD GPIO related quirks
From: Raul Rangel
Date: Thu Oct 07 2021 - 17:39:19 EST
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@xxxxxxxxxxxxxxx> 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
>
>