On Sun, 2015-06-14 at 09:36 +0200, Geert Uytterhoeven wrote: > On Thu, Jun 11, 2015 at 5:02 PM, Ben Hutchings > <ben.hutchings@xxxxxxxxxxxxxxx> wrote: > >> I may be misunderstanding the above, if so I apologise, but I would > >> strongly prefer to avoid an arrangement where the kernel and device tree > >> blob (DTS/DTSI -> DTB) need to be upgrade in lock-step as this tends not to > >> lead to a good experience for users. > > > > I agree. > > > >> My preference would be to maintain > >> backwards and forwards compatibility and if appropriate schedule removal of > >> such compatibility. > > [...] > > > > The problem is that the 'sd-uhs-sdr50' property is interpreted by the > > MMC core, so I think it will start trying to use this mode even if the > > driver hasn't implemented the necessary operations. I don't see any way > > around that. > > Can't the core check for driver capabilities? > I'm not familiar with the MMC core, but e.g. the SPI core only tries modes > that match both SPI master (spi_master.mode_bits) and slave (spi_device.mode). The driver already calls mmc_of_parse(), which initialises its capabilities based only on the device tree properties. > > The regression is relatively minor as I think the MMC core will fall > > back to a lower speed after failing to enable SDR50. But it will slow > > down probing of a card. > > So it does fall back (after a while). That's good. I think I've seen this happen but haven't *specifically* tested yet. Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html