On Thu, Jun 18, 2015 at 02:05:31AM +0800, Dong Aisheng wrote: > Commit 8d86e4f mmc: sdhci-esdhc-imx: Call mmc_of_parse() > seriously break the sd card detect/write protect function > of most IMX platforms since a lot of GPIO flags of cd-gpios/wp-gpios > are wrongly set in devicetree. > > It breaks the following things: My opinion would be that we revert the commit 8d86e4f for v4.2, as it's so broken. > 1) cd-gpio function enable > Most IMX boards GPIO card detect function becomes unwork and using card > polling mode instead by mistake. > Openning CONFIG_MMC_DEBUG will easily see that. > It is caused by the default quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION > is not cleared for dt platform by commit 8d86e4f, then > MMC_CAP_NEEDS_POLL is wrongly set. > Patch 1~2 is to fix it. > > 2) cd-gpio/wp-gpio polarity > Before commit 8d86e4f, we do not use GPIO flags passed from > devicetree. But after it, GPIO flags specfied in dt becomes valid > and will affect the normal cd/wp function. > > This is fixed by another dts fix patch series: > [PATCH 0/5] dts: imx: fix sd card gpio polarity specified in device tree > http://www.spinics.net/lists/arm-kernel/msg426156.html > > Since it needs to change a lot board dts files, so i cook the patch > based on Shawn/for-next branch to make sure all board dts file are > changed in the same time. > > The dts fix patches series should be picked before this series since > the driver fixes depend on the correct dts(correct GPIO polarity) > to work properly. So this is a device tree ABI breakage. All the existing DTBs already installed on devices will be broken with the new kernel. You can argue that the device trees are buggy and we're fixing bugs. But if a bugfix breaks things, we should be conservative. Here is my suggestion: 1. Revert commit 8d86e4f for v4.2 2. I queue up your dts fixing series for v4.2 3. Keep things as they are for a few releases and then consider to move to mmc_of_parse() with the hope that those buggy DTBs have been upgraded during that period. Shawn > > 3) max-frequency not work in sdhci > mmc_of_parse will parse the max-frequency from devicetree, > however, its value will be overwritten by common sdhci driver > finnally,so it does not actually work. > Patch 3 is to fix it. > > 4) patch 4~6 clear unneeded parsing code after switch to mmc_of_parse(). > > The series is based on ulf/next tree. > > I also CCed this patch series to all board maintainer related in this > change, hope they can help test it. > I only tested some freescale IMX boards. > > BTW, There's indeed a problem here that dts fix patch series needs to > be picked before this series, but it can't go through Ulf tree > since some board dts changed does not in Ulf's tree. > And this patch series also can not go through Shawn's tree, > since mmc part change depends on some patches in Ulf tree. > Two series are cross dependant. > Hope you guy can find a solution for it. > > Those two patch series is an important fix, hopefully can catch up the > final 4.1 merge window. > > Dong Aisheng (6): > mmc: sdhci-esdhc-imx: fix cd regression for dt platform > mmc: sdhci-esdhc-imx: move all non dt probe code into one function > mmc: sdhci: make max-frequency property in device tree work > mmc: sdhci-esdhc-imx: remove duplicated dts parsing > mmc: sdhci-esdhc-imx: clear f_max in boarddata > dts: mmc: fsl-imx-esdhc: remove fsl,cd-controller support > > .../devicetree/bindings/mmc/fsl-imx-esdhc.txt | 2 - > drivers/mmc/host/sdhci-esdhc-imx.c | 210 ++++++++++----------- > drivers/mmc/host/sdhci.c | 9 +- > include/linux/platform_data/mmc-esdhc-imx.h | 1 - > 4 files changed, 111 insertions(+), 111 deletions(-) > > -- > 1.9.1 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
