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:
parent
0a68d61092
commit
c5727c468f
@ -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);
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user