[regression, bisected] no MMC on rk3399-gru-kevin with 5.10-rc1

[Vicente Bergas]

Hi Uffe, Doug,

On Monday, November 2, 2020 4:38:38 PM CET, Doug Anderson wrote:
> Hi,
>
> On Mon, Nov 2, 2020 at 7:02 AM Ulf Hansson <ulf.hansson at linaro.org> wrote:
>> 
>> On Fri, 30 Oct 2020 at 23:04, Vicente Bergas <vicencb at gmail.com> wrote:
>>> 
>>> Hi,
>>> commit 21b2cec61c04bd175f0860d9411a472d5a0e7ba1
>>> mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4
>>> broke booting rk3399-gru-kevin.
>>> 
>>> The kernel waits forever for the root device to appear on MMC.
>> 
>> Waiting forever sounds weird to me.

The behaviour is expected because of the "rootwait" kernel parameter.

>>> Removing the line containing PROBE_PREFER_ASYNCHRONOUS in
>>> drivers/mmc/host/dw_mmc-rockchip.c fixes the issue.
>> 
>> I am guessing when we enable async probe, we reveal some other
>> existing error. Or, perhaps the rootfs mount point become wrong?
>> 
>> Would it be possible to share a boot log (before/after) with some
>> driver probe debugging enabled?
>
> Are you sure you haven't just got your MMC block IDs shuffled now?
> Perhaps a careful application of the newly-supported MMC aliases would
> help fix things?  When we landed, Ulf pointed to:
>
> [1]
> https://patchwork.kernel.org/patch/11747669/
> https://patchwork.kernel.org/patch/11747671/
>
> The async probe can cause shuffling of block IDs which were previously
> quite stable though never guaranteed (everyone always yelled loudly
> "use UUIDs").

I've got UUIDs everywhere (fstab and on other machines without root on MMC)
except in the "root" kernel parameter in rk3399-gru-kevin and, as you say,
the device path changed causing the issue.

So, false alarm, this is not a bug.
Still, those MMC aliases providing reliable device naming are really
welcome.

Regards,
  Vicente.

> I will also note that I just put v5.10-rc1 on a rk3399-gru-kevin and
> confirmed that it booted up OK.
>
> -Doug