Revert to this driver's historic behavior: assume an sd card is writable

if the fdt data doesn't provide a gpio pin for reading the write protect
switch and also doesn't contain a "wp-disable" property.

In r311735 the long-bitrotted code in this driver for using the non-
standard fdt "mmchs-wp-gpio-pin" property was replaced with new common
support code for handling write-protect and card-detect gpio pins.  The
old code never found a property with that name, and the logic was to
assume that no gpio pin meant that the card was not write protected.

The new common code behaves differently.  If there is no fdt data saying
what to do about sensing write protect, the value in the standard SDHCI
PRESENT_STATE register is used.  On this hardware, if there is no signal
for write protect muxed into the sd controller then that bit in the
register indicates write protect.

The real problem here is the fdt data, which should contain "wp-disable"
properties for eMMC and micro-sd slots where write protect is not even
an option in the hardware, but we are not in control of that data, it
comes from linux.  So we have to make the same flawed assumption in our
driver that the corresponding linux driver has: no info means no protect.

Reported by:	several users on the arm@ list
Pointy hat:	me, for not testing enough before committing r311735
This commit is contained in:
Ian Lepore 2017-02-22 03:49:46 +00:00
parent 0a68d61092
commit c5727c468f
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=314071

View File

@ -75,6 +75,7 @@ struct ti_sdhci_softc {
uint32_t sdhci_clkdiv;
boolean_t disable_highspeed;
boolean_t force_card_present;
boolean_t disable_readonly;
};
/*
@ -363,6 +364,9 @@ ti_sdhci_get_ro(device_t brdev, device_t reqdev)
{
struct ti_sdhci_softc *sc = device_get_softc(brdev);
if (sc->disable_readonly)
return (0);
return (sdhci_fdt_gpio_get_readonly(sc->gpio));
}
@ -557,8 +561,21 @@ ti_sdhci_attach(device_t dev)
goto fail;
}
/*
* Set up handling of card-detect and write-protect gpio lines.
*
* If there is no write protect info in the fdt data, fall back to the
* historical practice of assuming that the card is writable. This
* works around bad fdt data from the upstream source. The alternative
* would be to trust the sdhci controller's PRESENT_STATE register WP
* bit, but it may say write protect is in effect when it's not if the
* pinmux setup doesn't route the WP signal into the sdchi block.
*/
sc->gpio = sdhci_fdt_gpio_setup(sc->dev, &sc->slot);
if (!OF_hasprop(node, "wp-gpios") && !OF_hasprop(node, "wp-disable"))
sc->disable_readonly = true;
/* Initialise the MMCHS hardware. */
ti_sdhci_hw_init(dev);