On Tue, 4 Mar 2008 01:44:09 -0800 David Brownell <david-b@pacbell.net> wrote:How so? How is a wake caused by the MMC controller different than any other source? You need well behaved _systems_, not just hosts to achieve that guarantee. SDHCI controllers have the ability to wake up the system on card removal, but there is zero guarantee that the platform actually wired the controller up in a way that actually allows it to do this. Throw suspend to disk, where the system might completely lose power, into the mix and you're completely screwed. So for the default behaviour to change, we need one of two things: - Certainty that removals cannot go unnoticed. (even then, you also need wakeup latency guarantees) - Ability to detect a removal after the fact. For the general case, the first one is impossible given todays hardware. The second might be solvable, but noone has done the work. (If your complete system can satisfy the first option, feel free to add the "unsafe" option to you defconfig, but that is hardly adequate reason to have it on by default.) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org --
| Heiko Carstens | [patch -mm] s390: struct bin_attribute changes |
| Andrew Morton | 2.6.25-rc2-mm1 |
| Eric W. Biederman | Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu |
| Jan Engelhardt | intel iommu (Re: -mm merge plans for 2.6.23) |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| Andrew Morton | Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes |
