On Wed, Dec 08, 2021 at 10:07:32AM +0100, Greg KH wrote: [...] > > diff --git a/include/linux/mhi.h b/include/linux/mhi.h > > index 723985879035..102303288cee 100644 > > --- a/include/linux/mhi.h > > +++ b/include/linux/mhi.h > > @@ -660,8 +660,9 @@ int mhi_pm_suspend(struct mhi_controller *mhi_cntrl); > > /** > > * mhi_pm_resume - Resume MHI from suspended state > > * @mhi_cntrl: MHI controller > > + * @force: Force resuming to M0 irrespective of the device MHI state > > */ > > -int mhi_pm_resume(struct mhi_controller *mhi_cntrl); > > +int mhi_pm_resume(struct mhi_controller *mhi_cntrl, bool force); > > apis like this are horrid to work with over time. > > Why not just have: > mhi_pm_resume_force() > which then internally can set a flag that does this? That way the > driver author does not have to stop every time they see this call and > look up exactly what the true/false field means in the function call in > their driver. > Okay. > It also lets you leave alone the existing calls to mhi_pm_suspend() that > do not want to "force" anything. > > self-documenting code is good, this is not self-documenting at all. > > Also, is "force" really what you are doing here? This is a "normal" > resume call, which should always work. The normal resume here is resuming with M3 state only. > The "force" option here really > is just "ignore the current state of suspend for the device". So > perhaps mhi_pm_resume_ignore_current_state() might be better? Or > something shorter? > And we are actually forcing here. As per the MHI spec, the devices has to be in M3 state during resume. So if we allow any device to go through resume without being in M3, that implies we are doing a force resume. I'll use the mhi_pm_resume_force() API as you suggested. Thanks, Mani > Naming is hard, sorry. > > thanks, > > greg k-h
