On 12/11/18(Mon) 23:36, Ben Pye wrote: > On Mon, Nov 12, 2018 at 06:46:26PM -0200, Martin Pieuchot wrote: > > On 11/11/18(Sun) 13:10, Ben Pye wrote: > > > Hey all, > > > > > > In my quest for better OpenBSD support on my Chromebook 13 I have found > > > that sdmmc(4)'s current strategy for suspend/resume only really works > > > for removable storage. Upon a suspend it marks the device as dying, and > > > upon resume will detach the card and re-scan the bus. This makes sense > > > for removable SD cards as they may be removed whilst the device is > > > asleep, however for non-removable eMMC we can make the assumption that > > > the device will not be removed during sleep. > > > > > > By assuming the device stays present over a sleep we can avoid the > > > detach and re-scan behaviour that sdmmc(4) currently uses. This is > > > important if you root storage device is an eMMC device /and/ you are > > > using softraid(4) as softraid(4) will not handle the detach/attach. > > > Despite this on my hardware at least suspend/resume works more reliably > > > if we can avoid this detach behaviour too, on this device we would > > > really have to detach before we enter sleep as the bus can break during > > > suspend and then the detach/reattach fails after resume meaning that my > > > sd0 device just disappears. > > > > > > Instead for non-removable devices upon sleep we can deselect the card > > > but otherwise leave it configured. On resume we still perform a host > > > reset in sdhc(4) and then we can re-do the device initialisation in > > > sdmmc(4). During initialisation we use some of the values determined in > > > the initial sdmmc(4) init as the goal is to put the device into the same > > > state. We also hook up to the same sdmmc_function's etc so that the > > > child devices (scsibus etc) do not have to do anything special on a > > > resume. With this behaviour suspend/resume works reliably on my HP > > > Chromebook 13 and softraid for encryption continues to work. > > > > > > There are a few unresolved questions however and that's why I'm posting > > > this here now: > > > > > > 1. How do we know if a device is non-removable, I don't think an MMC > > > device indicates this, maybe we have to determine this by the > > > controller? > > > > If you find a way to know that would be interesting. However that > > doesn't mean we want to go this road. > > > > I'd rephrase the question differently. How do we know if a device, > > attached to a removable bus, has been removed or swapped while the > > machine was suspended? > > > > Do you know how other OSes handle this case? What kind of changes > > would be required to handle this in OpenBSD? At which layer? USB > > currently follows the same logic, so it could be solved there as > > well with the same stone. > > Good point. As far as I can tell Linux attempts to keep the device > initialised, removable card or not. They check the CID and if it has > changed I think they are detaching it - so for example, a removable > card.
If you go down this road you need a way to ensure no IO will reach the medium until you've finished to check & validate the CID. Or is there any other way to do it? That is my question, what other OSes do? :) Did you look at USB as well? > Perhaps taking this approach would be better - if we could keep > removable devices attached if they haven't changed then it would be > possible to use them as your root device for example. That would be great but, as usual, somebody has to do the work :)
