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

[Rajat Jain]

On Fri, Sep 28, 2018 at 1:42 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
>
> On Thu, Sep 27, 2018 at 7:57 PM Rajat Jain <rajatja@xxxxxxxxxx> wrote:
>
> > > Patches are welcome, I think.
> > >
> > > Btw, is there any existing hardware on the market with such BIOS?
> >
> > Yes, all the chrome books available in the market (at least the ones
> > released in last 3 years) have same ACPI layout (provide _DSD for
> > card-detect). They are all working fine today because they use an
> > older kernel, but if we update them to the latest kernel, this part
> > will be broken.
>
> This is not looking good at all.
>
> Andy should we revert the patch or do you have some other
> quick fix in mind we could do? It seems reverting the patch
> could be bad for the mctrl patches IIUC, but this regression
> seems even more serious.

Sorry, I may have made it sound like more serious than it is. Yes,
what I said is true, but we (Google) does not plan to update those
devices to the latest kernel. That regression will only be seen by any
developers who try to do it on their own.

Also, the commit I mentioned above was put in long time back, and I
think it is more reasonable to put a fix in the sdhci driver instead.

I tried using Andy's suggestion yesterday, but was faced with more
questions that I did not have answers to (with my limited
understanding):

 - It seems that 1 SDHCI device may support multiple slots. It was not
clear to me if they could share card detect interrupts, or should have
separate ones? Also, the driver may not really know? So should I add 1
or two pins using the devm_acpi_dev_add_driver_gpios().

- I was unsure what should I set the active_low to.

Given these concerns, it seemed the easiest fix to me, if we can call
mmc_gpiod_request_cd() twice, once with "cd" and then with NULL as a
fallback.

Thanks,

Rajat Jain

>
> Yours,
> Linus Walleij