Re: SDIO wifi card is not detected with 4.5-rc kernels

[Ulf Hansson <ulf.hansson@linaro.org>]

+Russell, Mike

On 24 March 2016 at 18:50, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Mar 24, 2016 at 2:45 PM, Laszlo Fiat <laszlo.fiat@gmail.com> wrote:
>> Hello,
>>
>> The original issue I reported on 17 Feb is that the SDIO WIFI card is
>> not detected with 4.5RC and now mainline 4.5.0 kernel on baytrail
>> tablets.
>> BzukTuk commented on the bug report, that he has bisected the problem,
>> and found that reverting  patch
>> 520bd7a8b4152aacfbd34eb7f7a447354b631039 ("mmc: core:
>> Optimize boot time by detecting cards simultaneously")  solves the problem.
>> I tested this, by compiling a 4.5.0 kernel with that patch reverted,
>> and the SDIO WiFi works that way.
>
> Adding Ulf on Cc.

>From earlier discussions [1], it seems like Russell pointed out a mmc
pwrseq related bug, but there seems to be yet another issue here.

The bisected bad commit 520bd7a8b415 ("mmc: core: Optimize boot time
by detecting cards simultaneously"), affects the timing and then maybe
also the order of how cards (mmc, sd, sdio) may be detected.

More precisely SD/(e)MMC cards may get different block ids (mmcblk[n])
than they had before. According the information from the logs in
bugzilla [2], a qualified guess is that the firmware to the SDIO WLAN
chip is loaded from an hardcoded path. Since that path gets changed,
the firmware can't be found and loaded, right?

So, just to be clear, there has *never* been any deterministic way to
always get the same mmc block id for a card. If hardcoded paths have
worked, it's because of luck! Let me elaborate a bit on that.

Earlier and with commit 520bd7a8b415, the probe order (a successful
probe) of the mmc host device and whether removable cards are present
or not, affects the mmc block id. The change that commit 520bd7a8b415
introduces is that card detection can now happen simultaneously, thus
it adds another parameter that affects the mmc block id.

Unless I am mistaken, the hard coded paths should be fixed to use
UUID/PARTUUID in favour of reverting 520bd7a8b415.

Kind regards
Uffe

[1]
http://comments.gmane.org/gmane.linux.kernel.mmc/36045

[2]
https://bugzilla.kernel.org/show_bug.cgi?id=112571