Hey guys, I stumbled over this one again and want to make sure we have a conclusion here.
> The way I understand it, the problem this intends to fix is not the > state the device ends up in, but that it needs to be powered while > registers are read or written. I agree. > It seems to me that that the current "resume" code should work in that > respect, because it changes the PM state to "on" in uart_resume_port() > before any access to hardware registers takes place, so there is > nothing that needs to be fixed. Ack. > That may be different for the "suspend" part, though, because it > assumes that the PM state is "on", and I think that is what the patch > asserts to not be a valid assumption anymore. It's hard to tell if > that is true, though, because I cannot reproduce the issue here; it > just works either way... So, do we agree then that *if* there needs to be a fix for that, it should be in uart_suspend_port() by adding some 'uart_change_pm' shortly before accessing the ops-callbacks? I am not super-fit with the uart layer, but can't we assume because of the "Nothing to do if the console is not suspending"-if-block that (for SCIF at least) it means the port is on because it _is_ the console? (I wonder, though, if the OMAPs won't need such a fix because they seem to use runtime_autosuspend, so their state might be off actually?) Regards, Wolfram
signature.asc
Description: PGP signature
