Workaround for broken O2 Micro SD card reader support since Linux kernel version 4.1.8

On my Dell Latitude E7450 notebook I regularly update to current versions of the Linux kernel. Along with such a Kernel update my notebook’s SD card reader could no longer be initialized properly:

Jan 23 19:53:47 e7450.bs3.hollants.com kernel: sdhci: Secure Digital Host Controller Interface driver
Jan 23 19:53:47 e7450.bs3.hollants.com kernel: sdhci: Copyright(c) Pierre Ossman
Jan 23 19:53:49 e7450.bs3.hollants.com kernel: sdhci-pci 0000:01:00.0: SDHCI controller found [1217:8520] (rev 1)
Jan 23 19:53:49 e7450.bs3.hollants.com kernel: mmc0: Unknown controller version (3). You may experience problems.
Jan 23 19:53:49 e7450.bs3.hollants.com kernel: sdhci-pci 0000:01:00.0: No vmmc regulator found
Jan 23 19:53:49 e7450.bs3.hollants.com kernel: sdhci-pci 0000:01:00.0: No vqmmc regulator found
Jan 23 19:53:49 e7450.bs3.hollants.com kernel: mmc0: SDHCI controller on PCI [0000:01:00.0] using ADMA
Jan 23 19:53:50 e7450.bs3.hollants.com kernel: sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
Jan 23 19:53:50 e7450.bs3.hollants.com kernel: mmc0: tuning execution failed
Jan 23 19:53:50 e7450.bs3.hollants.com kernel: mmc0: error -5 whilst initialising SD card
Jan 23 19:53:50 e7450.bs3.hollants.com kernel: sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
Jan 23 19:53:50 e7450.bs3.hollants.com kernel: mmc0: tuning execution failed
Jan 23 19:53:50 e7450.bs3.hollants.com kernel: mmc0: error -5 whilst initialising SD card
Jan 23 19:53:51 e7450.bs3.hollants.com kernel: sdhci: Timeout waiting for Buffer Read Ready interrupt during tuning procedure, falling back to fixed sampling clock
Jan 23 19:53:51 e7450.bs3.hollants.com kernel: mmc0: tuning execution failed
Jan 23 19:53:51 e7450.bs3.hollants.com kernel: mmc0: error -5 whilst initialising SD card
Jan 23 19:53:51 e7450.bs3.hollants.com kernel: mmc0: error -84 whilst initialising SD card

…whereas I knew that it used to work before. This is with the current version 4.4.0 of the Linux kernel.

Turns out there is a bug report in the Linux kernel bugtracker which describes a change made in Linux kernel version 4.1.8 that seems to be the culprit.

--- a/drivers/mmc/host/sdhci-pci.c
+++ b/drivers/mmc/host/sdhci-pci.c
@@ -618,6 +618,7 @@ static int jmicron_resume(struct sdhci_p
static const struct sdhci_pci_fixes sdhci_o2 = {
.probe = sdhci_pci_o2_probe,
.quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
+ .quirks2 = SDHCI_QUIRK2_CLEAR_TRANSFERMODE_REG_BEFORE_CMD,
.probe_slot = sdhci_pci_o2_probe_slot,
.resume = sdhci_pci_o2_resume,
}; 

According to this discussion on the linux-mmc mailing list, a proper fix appears to more complicated than just reverting the change above and is not likely to appear just tomorrow.

Luckily we can use a workaround to override the change above: as modinfo sdhci reveals, the sdhci.ko module supports a parameter debug_quirks2 which can be used to override the given, controller type-specific quirks initialization shown above. We can however not just specify debug_quirks2=0 because the parameter will only be interpreted if is non-zero.

No problem, however, at least on my Latitude specifying a different quirks2 flag that doesn’t sound like having too much of a possible bad consequence helps. I chose the following from /usr/src/linux/drivers/mmc/host/sdhci.h:

/* The system physically doesn't support 1.8v, even if the host does */
#define SDHCI_QUIRK2_NO_1_8_V                           (1< <2)

1 << 2 is C code that translates to the number 4. If the following works for you:

rmmod sdhci sdhci_pci sdhci_acpi
modprobe sdhci debug_quirks2="0x4"
modprobe sdhci_pci

you can put a suitable options line in your /etc/modprobe.d/*.conf (or wherever your Linux distribution places kernel module parameters) to make this workaround permanent.

Update May 26th, 2016: a value of 0x04 does have a negative effect as Philip Langdale reports:


A better work around is setting debug_quirks2=”0x10000″ or some other value
that is non zero and doesn’t include any existing quirks. The 0x4 quirk
disables 1.8V support which means the new high speed modes (SDR104, DDR50, etc)
are not available (apparently these are only valid in 1.8V mode).

Update July 13th, 2018: Philip Langdale again added:


So, in the last two years (yeah, it’s been that long), the number of quirk2s in
the driver has been increasing and increasing and in 4.15, it finally got to
0x10000 so the work-around will started turning on a quirk that breaks things.
So, set the value to debug_quirks2=0x80000000 which is the last bit. But
presumably, in another year or two, we’ll fill up quirks2 and move on to
quirks3 and then the work-around will no longer be possible without patching
the kernel itself. Maybe we’ll see it fixed by then? Who knows – I’ve never
observed any negative behaviour with the work-around, but I never tried to
understand why the original quirk was deemed more correct than not having it.

Leave a comment