[Letux-kernel] omap_hsmmc_init/omap_hsmmc_late_init

[H. Nikolaus Schaller]

Hi,

> Am 08.09.2017 um 17:03 schrieb Tony Lindgren <tony at atomide.com>:
> 
> * H. Nikolaus Schaller <hns at goldelico.com> [170908 07:25]:
>> Hi Tony,
>> 
>> I am stumbling over some legacy OpenPandora code, which seems to be
>> the last board which needs special hsmmc quirks for the WiFi chip.
> ...
>> 62696d looks like ASCII... Buffer overflow in udevd? Maybe triggered by a duplicate hsmmc
>> device?
>> 
>> But as said it is gone if I work around the omap_hsmmc.2 error.
> 
> Hmm sounds bad..
> 
>> Then I compared some older kernels and it appears as if WiFi and the mmc3 interface is
>> broken for quite some long time:
>> 
>> 4.4.0	no mmc2 sysfs message, WiFi available, DSS works
>> 4.6.0	no mmc2 sysfs message, WiFi available, DSS works
>> 4.7.0	no mmc2 sysfs message, WiFi not available, DSS works
>> 4.8.0	no mmc2 sysfs message, WiFi not available, DSS works
>> 4.12.0	no mmc2 sysfs message, WiFi not available, DSS works
>> 4.13.0	sysfs mmc2 warning, WiFi not available, DSS fails
> 
> Grr. I guess nobody has been using pandora with mainline
> kernel for a while.

Looks the same to me...

> 
>> Any suggestions? Is fixing the omap_hsmmc_done != 1 at least part of a solution?
> 
> Yeah we should fix it.

Ok, I will post my patch for review.

> Then just pass the pandora wifi
> platform_data using pdata-quirks.c as auxdata. Then get
> rid of the last remaining legacy hsmmc code.
> 
> Looks like struct fixed_voltage_config pandora_vwlan can
> become just a dts fixed regulator.

Yes.

> Not sure if we can
> pass the MMC_QUIRK_NONSTD_SDIO via dts, but I think that
> can be passed in platform_data.

BR,
Nikolaus