Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence

[Pierre Ossman <drzeus@drzeus.cx>]

[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

Haavard Skinnemoen wrote:
> 
> Ok, is there any better way to achieve the same this? As far as I
> can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the
> same purpose -- it ensures that scans that have already been started
> will have completed before the function continues.
> 

Not quite. mmc_remove_host() doesn't care if a detect has been executed or not,
it only cares about whether or not one is executing right now. So in order for
your patch to work, there must be no way that mmc_finish_detect() is called
before the detect is scheduled.

> 
> I wouldn't call it luck. The way mmc_rescan() is implemented, any scans
> that are started before late_initcall time are completed before
> mmc_finish_detect() returns. The steps are all done synchronously in
> the workqueue function.
> 

Indeed. But it is not by design that they are scheduled before late_initcall().
Also, flushing the workqueue is also not a by-design way of completing a scan,
it just happens to be that way right now.

> And I never realized that using a block device as a parameter to the
> root= parameter could possibly be "unofficial" functionality...?

Then you've learned something new. ;)

Only some devices work that way (generally only those with "simple" interfaces).
And most things are these days behind more advanced buses, more akin to a network.

Generally, not waiting for a lot of hardware is a good thing as it speeds up
boot times. In my mind, the proper way is having a script in an initrd that
waits for just the parts of the hardware that this particular system needs.
Everything else can be brought up in the background.

Rgds
Pierre



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]