On Tue, 2015-05-19 at 09:46 +0200, Ulf Hansson wrote:
> [...]
> 
> >> > Those platforms could still update their DT files and add "broken-cd",
> >> > since that would be the proper description of the HW. Once that's done,
> >> > it would enable you to remove the SDHCI_QUIRK_BROKEN_CARD_DETECTION as
> >> > default, right?
> >> >
> >> Yes, and if remove SDHCI_QUIRK_BROKEN_CARD_DETECTION as default, 
> >> 'borken-cd' would be needed to be added for most platforms using esdhc.
> >
> > I was OK with changing the device tree if it just meant that things that
> > previously didn't work now work.  I'm not OK with requiring the device
> > trees to change in order for things that already work to stay working.
> 
> I get your point, but.. considering maintaince from mmc code point of
> view, I don't like the suggested approach in $subject patch.
> 
> As this patch anyway requires updating DTBs,

Not in a way that causes things that used to work to stop working if
someone uses a new kernel with an old device tree.

> I would like to know the involved platforms and at what level of
> deployment the DTBs are in. In principle what I am asking is, how hard
> is it to update the DTBs?

The change you asked for would affect all platforms with esdhc that are
not on the list being excluded by this patch.  I counted 29 files in
arch/powerpc/boot/dts with "esdhc".  The oldest patch I see introducing
esdhc to a device tree is 5761bc5dae6 from 2008.  This is not new
stuff.

The patch adding the quirk to the esdhc files is 3bb2a9f6a7c08 from
2011, so the driver behavior is also not new.

> BTW, is it only sdhci-of-esdhc.c we are discussing here?

It's only sdhci-of-esdhc.c that would be affected by this patch (though
sdhci-esdhc-imx also sets SDHCI_QUIRK_BROKEN_CARD_DETECTION by default).
If the tests are moved into that file, would you be OK with it?

-Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to