> > > > Card insert/remove events can be system wake events though.  Which
quoted text
> > > > makes that restriction impractical.
> > 
> > This part seems to be ignored by your comment ... wake events.
> 
> How so? How is a wake caused by the MMC controller different
> than any other source? 

They aren't.  Which is part of why the way MMC currently assumes that
insert/remove events don't work is a problem.


quoted text
> > That is, the MMC core doesn't understand wakeup events.
> > 
> > Or, as pointed out elsewhere, well-behaved MMC hosts ... which don't
> > need either such reprobing or the associated remove-on-suspend.
> 
> You need well behaved _systems_, not just hosts to achieve that
> guarantee.

Sure, but a host can't be well behaved all by itself!

And in any case, I had already made clear I was talking
about _systems_ that behave properly.


quoted text
> 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.     

I'm talking about generic MMC/SD controllers of the type
that have been around for years ... on systems which won't
use hibernation ("suspend to disk"), but do use real system
sleep states where card detection (by IRQs) works.

 
quoted text
> 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.

Odd that it's very possible on the systems I mentioned.


quoted text
> The second might be solvable, but noone has done the work.  

I don't know what you mean by "detect a removal after
the fact", or why it'd be needed if you detected it
in the first place.

 
quoted text
> (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.)  

Thing is, I had also pointed out that it wasn't "unsafe"
in the least on many systems.

I'll refresh the patch which improves that mechanism and
updates its description.

- Dave
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/