On Thu, Jun 11, 2015 at 5:02 PM, Ben Hutchings
[off-list ref] wrote:

quoted

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.

quoted

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 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.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds