Bug 194871

Have you tried "delay" (or something like that) boot argument?

Emailing to author of mentioned patch.

I tried rootdelay, did not work.

please attach the dmesg output both before and after reverting the patch.

Created attachment 255563 [details]
Dmesg output (failed boot)

Created attachment 255565 [details]
Dmesg output (successful boot after reverting)

failed boot:
[    3.191110] sdhci-pltfm: SDHCI platform and OF driver helper
[    3.195087] wbsd: Winbond W83L51xD SD/MMC card interface driver
[    3.196255] wbsd: Copyright(c) Pierre Ossman
[    3.222357] ntfs: driver 2.1.32 [Flags: R/W MODULE].
[    3.226963] hidraw: raw HID events driver (C) Jiri Kosina
[    3.231111] usbcore: registered new interface driver usbhid
[    3.232155] usbhid: USB HID core driver
[   14.899096] random: crng init done

successful boot:
[    3.174432] sdhci-acpi 80860F14:01: failed to setup card detect gpio
[    3.181990] mmc1: SDHCI controller on ACPI [80860F14:01] using ADMA
[    3.192197] sdhci-pltfm: SDHCI platform and OF driver helper
[    3.196145] wbsd: Winbond W83L51xD SD/MMC card interface driver
[    3.197274] wbsd: Copyright(c) Pierre Ossman
[    3.226623] hidraw: raw HID events driver (C) Jiri Kosina
[    3.238095] usbcore: registered new interface driver usbhid
[    3.239262] usbhid: USB HID core driver
[    3.580400] mmc1: new ultra high speed SDR104 SDXC card at address 0001
[    3.583923] mmcblk1: mmc1:0001 00000 59.6 GiB 
[    3.587623]  mmcblk1: p1 p2 p3
[    6.283097] EXT4-fs (mmcblk1p3): mounted filesystem with ordered data mode. Opts: (null)
[    6.565851] loop: module loaded


With the patch applied (on failed boot), when mmc_gpiod_request_cd() returns -EPROBE_DEFER, sdhci-acpi does not print any warning message, it just quite and wait to be probed again, but it is never queued again.

With the patch reverted (on failed boot), when when mmc_gpiod_request_cd() returns -EPROBE_DEFER, sdhci-acpi prints "failed to setup card detect gpio", and then it still registers the sdhci host.

So the problem to me is that, why mmc_gpiod_request_cd() returns -EPROBE_DEFER. while it should not.

can you please add a dump_stack() to see why -EPROBE_DEFER is returned, like the patch below.

diff --git a/drivers/mmc/host/sdhci-acpi.c b/drivers/mmc/host/sdhci-acpi.c
index 9dcb704..3669ad1 100644
--- a/drivers/mmc/host/sdhci-acpi.c
+++ b/drivers/mmc/host/sdhci-acpi.c
@@ -469,6 +469,7 @@ static int sdhci_acpi_probe(struct platform_device *pdev)
 
                err = mmc_gpiod_request_cd(host->mmc, NULL, 0, v, 0, NULL);
                if (err) {
+                       dump_stack();
                        if (err == -EPROBE_DEFER)
                                goto err_free;
                        dev_warn(dev, "failed to setup card detect gpio\n");

The Baytrail pincontrol driver will be needed, either in the initrd or built-in:

CONFIG_PINCTRL_BAYTRAIL=y

@Adrian Hunter: Thanks, adding pinctrl_cherryview to initrd solved the problem.

I am not sure if this change of behavior should be considered a problem or not. Just in case someone wants to see further details, I am attaching the new dmesg outputs (with the dump_stack() info).

Created attachment 255573 [details]
Dmesg output (failed bott, with dump_stack())

Created attachment 255575 [details]
Dmesg output (successful boot, no reverting, pinctrl_cherryview loaded)

I think the problem can also be fixed if you set CONFIG_PINCTRL_BAYTRAIL=m, can you confirm?

CONFIG_PINCTRL_BAYTRAIL=y without pinctrl_cherryview didn't work (this computer has Celeron N3050, I specifically avoided Baytrail due to the dreadful bug #109051).

(In reply to Kemal Ilgar Eroğlu from comment #13)
> CONFIG_PINCTRL_BAYTRAIL=y without pinctrl_cherryview didn't work (this
> computer has Celeron N3050, I specifically avoided Baytrail due to the
> dreadful bug #109051).

I'm confused. I think you should either need pinctrl_baytrail or pinctrl_cherryview, as these two drivers are independent.

Please confirm which driver you need by enable one and disable the other, and please also confirm setting the Kconfig option to 'y' and 'm' both works.

Yes, don't know why I thought it was Baytrail.  pinctrl_cherryview is right.

Sorry, I didn't express myself clearly:

- Before the kernel patch mentioned in the first post, neither baytrail nor cherryview pinctrl drivers were needed to boot.
- After this patch, I can not boot without pinctrl_cherryview being available at boot time, independent of CONFIG_PINCTRL_BAYTRAIL=y being set (by the way, this option is y/n, menuconfig does not allow it as a module).

I tested with: cherryview n/m/y, baytrail n/y.