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

1 files changed, 17 insertions, 0 deletions

diff --git a/sys/arm/ti/ti_sdhci.c b/sys/arm/ti/ti_sdhci.c
index 7041806b7377..16fa9569f040 100644
--- a/sys/arm/ti/ti_sdhci.c
+++ b/sys/arm/ti/ti_sdhci.c
@@ -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);