[...] >> >> > The only case where HPI is used in this patch - is during >> >> > sleep_notify >> >> timeout error. >> >> >> >> Why? >> > >> > In case of timeout error, we would like to handle it by sending HPI - to >> > let >> device interrupt/stop the prg state. >> >> Is that according to the spec? I think it would be better to try a reset >> sequence to recover, by using CMD0 and so forth, what do you think? > > Not must by the spec, but there are several options how to handle timeout > error. > Checking the existing driver, the '-ETIMEDOUT' error is handled by > mmc_interrupt_hpi () > in case of mmc_wait_for_req_done() function. > Can we use the same approach?
Currently the logic to recover from errors during system PM suspend, relies on the request-retry mechanism which is executed far later. >From the ->suspend() callback we will only propagate the error code towards the PM core. That means the PM core will bail out and reverse the actions already done for suspended devices. In this initial patch, I suggest we stick to that behaviour. Although, I am open to discuss a more sophisticated error handling, but let's do that from a separate patch. [...] Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
