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

[Pierre Ossman <drzeus@drzeus.cx>]

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

Haavard Skinnemoen wrote:
> 
> You're right about my assumptions. Are there any existing drivers that
> break them? Are there even any usb-based controllers around? I though
> most usb-mmc controllers used the USB Mass Storage class and thus
> don't use the mmc subsystem at all.
> 

Yes, but they might show up in the future. My point was that we know of
scenarios that will break this, so it won't be a universal solution (even though
it might work right now).

> 
> I see. The flush_workqueue approach might end up waiting for other
> things than just scanning, is that the problem? Would it be better to
> add a per-host "inital scan complete" completion that we could wait on
> instead?
> 

That would be a cleaner solution yes. That way we don't exploit any current
behaviour that might change in the future.

> 
> I'm not sure how many embedded people actually know how to build an
> initrd for a custom board.
> 

All the ones I have on my desk right now use initrd. ;)

> 
> But if you don't want this issue fixed (i.e. you don't think of it as
> an issue) I guess I have to either start working on yet another initrd
> setup or just apply the patch to our vendor kernel and be done with it.
> The latter certainly is the most tempting, but I suppose the former is
> more like how things are supposed to be done in the future.
> 

Of course I see it as an issue. My concern is if we gain more than we lose.

I had a chat with David Woodhouse and Segher Boessenkool and I think we have
another approach. Basically, we move the waiting which would normally go into
the initrd and move it into the kernel. So you get something like:

"Waiting for root device /dev/mmcblk0p1..."

The only problem here is if the device never shows up, but if that was the case
you would previously get a panic, so it should not be any worse.

Does that sound like something that would work for you? From my point of view
it's a much cleaner solution that has the benefit of not being tied into a
certain subsystem (i.e. this would "fix" usb aswell).

Rgds
Pierre


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