All OMAP platforms: MMC is broken

[ulf.hansson@linaro.org (Ulf Hansson)]

On 7 October 2015 at 17:52, Tony Lindgren <tony@atomide.com> wrote:
> * Ulf Hansson <ulf.hansson@linaro.org> [151007 06:46]:
>> On 7 October 2015 at 15:26, Tony Lindgren <tony@atomide.com> wrote:
>> >> > Good idea, how about something like the following? AFAIK that's the
>> >> > only .config option needed as MFD_SYSCON is selected by Kconfig
>> >> > already.
>>
>> Similar to MFD_SYSCON, why don't we have REGULATOR_PBIAS to be
>> selected when omap_hsmmc is being used?
>>
>> It seems like that should also be a patch for the rc, right!?
>
> Well selecting CONFIG_REGULATOR is still optional and force selecting
> drivers usually leads into randconfig build issues sooner or later.
> And we'd like to make everything into loadable modules eventually.

I am not sure I get your point. Perhaps I was too vague in what I suggested.

Unless we express the dependencies via Kconfig files (or perhaps via
updated defconfigs), how do you expect build/boot automated tools to
handle this?

*People* can of course manually poll a README to learn about new
dependencies for each new kernel version, but me personally would
prefer if don't have to.

>
> We could print a warning during MMC1 probe if REGULATOR_PBIAS
> is not selected and attempt to continue probing?

No thanks, it would sprinkle drivers with ugly code :-). I would also
expect that we would get warnings even when we shouldn't, especially
as a cross SoC/board driver may have different dependencies.

To me REGULATOR_PBIAS is a dependency required by a certain SoC/board
when MMC_OMAP_HS is selected. Isn't such dependency easiest dealt with
from SoC/board Kconfig files? Llike for example in the OMAP2 case,
arch/arm/mach-omap2/Kconfig.

Kind regards
Uffe