Re: [REGRESSION] mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, Dec 3, 2020 at 1:43 PM Andreas Kemnade <andreas@xxxxxxxxxxxx> wrote:
>
> On Tue, 1 Dec 2020 21:00:39 +0100
> Andreas Kemnade <andreas@xxxxxxxxxxxx> wrote:
>
> > Hi,
> >
> > during probing of second mmc host on the GTA04A5 which has a
> > WL1835 wifi chip attached, I get the following oops. From a first glance
> > this seems to be a timing sensitive. Maybe it rings some bells for someone...
> > so I hesitate a bit to start the bisect job.
> Did the bisect job.
> 21b2cec61c04 (mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4)
>
> is the evil commit. Reverting it on top of v5.10-rc6 solves the problem.
>
> > Wild guessing: bus width is set while mmc module is not active, so registers
> > are not accessible.
> > Kernel configuration is omap2plus_defconfig
> >
> > Regards,
> > Andreas
> >
> >

...snip...

> > [    3.152587]  mmcblk0: p1 p2 p3 p4 < p5 p6 p7 p8 >
> > [    3.159393] 0x000000880000-0x000020000000 : "File System"
> > [    3.179534] omap_hsmmc 480b4000.mmc: omap_device_late_idle: enabled but no driver.  Idling

I'm guessing that this is the key line.  It seems to come from
omap_device_late_idle().

I don't know tons about that function, but a quick guess is that it needs a:

wait_for_device_probe();

...at the start of it.  It seems like it's trying to idle devices that
never got probed but not actually waiting for all devices to probe.
It's just assuming that everything is done by late_initcall_sync().

If that doesn't work, you could use the heavy hammer of changing
things to "PROBE_FORCE_SYNCHRONOUS" in your MMC driver, but IMO that's
kinda papering over the problem...

-Doug



[Index of Archives]     [Linux Memonry Technology]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux