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:
signature.asc
Description: OpenPGP digital signature
- Follow-Ups:
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Haavard Skinnemoen <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- References:
- [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Haavard Skinnemoen <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Pierre Ossman <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Haavard Skinnemoen <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Pierre Ossman <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Haavard Skinnemoen <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Pierre Ossman <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Haavard Skinnemoen <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Pierre Ossman <[email protected]>
- Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- From: Haavard Skinnemoen <[email protected]>
- [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- Prev by Date: [PATCH] allow kernel module exclusion on load
- Next by Date: Re: [discuss] [PATCH] spelling fixes: arch/x86_64/
- Previous by thread: Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- Next by thread: Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence
- Index(es):