... >>>> diff --git a/drivers/bus/mhi/host/init.c b/drivers/bus/mhi/host/init.c >>>> index 2e0f18c939e68..8f56e73fdc42e 100644 >>>> --- a/drivers/bus/mhi/host/init.c >>>> +++ b/drivers/bus/mhi/host/init.c >>>> @@ -1133,9 +1133,11 @@ int mhi_prepare_for_power_up(struct mhi_controller *mhi_cntrl) >>>> mutex_lock(&mhi_cntrl->pm_mutex); >>>> - ret = mhi_init_dev_ctxt(mhi_cntrl); >>> mhi init dev ctxt also initializes the ring pointers to base value, >>> I think we should take care of them also ? >> Are you referring to mhi_rings? They are getting initialized inside >> mhi_init_dev_ctxt() and de-initialized in __mhi_deinit_dev_ctxt(). That's >> why I've not handled them separately. >> > Maybe I was not clear in my previous comment/not a correct place to do > the comment. > > My point you are not freeing __mhi_deinit_dev_ctxt as part of suspend, > that means we are expecting device will continue to use the rp and wr pointers of ring as the previous i.e before suspend pointers. > > What if PCIe keeps link in D3cold as part of system suspend, will the > device able to handle the previous rp & wp of ring. I don't think > device can handle this. I don't have much internals logic of the driver. I've checked on my device and the read/write pointers have 2 entries for mhi_event and 1 entry for mhi_cmd. But still without resetting these, I've not got any problem. Any idea why? I'll reset rings' read/write pointers in v2.
