On Sun, 6 Sep 2009, Pierre Ossman wrote: > On Wed, 02 Sep 2009 14:37:23 -0400 > Nicolas Pitre <nico@xxxxxxx> wrote: > > > > > When resuming, we make sure the same card is still inserted by comparing > > the vendor and product IDs. If there is a mismatch, or if there is simply > > no card anymore in the slot, then the previous card is "removed" and the > > new card is detected. > > > > I know this is an area with a lot of differing views, but I see this as > totally insufficient. Like storage cards, this card might have a > non-volatile state that drivers and upper layers rely on being the same > before and after suspend. > > (Then there's also the issue of e.g. having two "identical" wifi cards > but with different MAC addresses). > > I think the right way to go is to retain enough power to the card for > it to stay initialised and then poke it at resume to see if it is still > running in the same state we left it. IMHO the right way to go is instead to consider patch2/4 that goes along with this series and defer such additional intelligence to each function driver's resume method. After all that's where knowledge of MAC addresses and so on should be, not in the core code. And in the context of power management, always having to keep power to the card is somehow against the point, isn't it? Especially considering that this simply is not always possible. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
