[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20201112032426.GB2491@Mani-XPS-13-9360>
Date: Thu, 12 Nov 2020 08:54:26 +0530
From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To: Bhaumik Bhatt <bbhatt@...eaurora.org>
Cc: Loic Poulain <loic.poulain@...aro.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Hemant Kumar <hemantk@...eaurora.org>,
Jeffrey Hugo <jhugo@...eaurora.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 3/4] bus: mhi: core: Add support to pause or resume
channel data transfers
On Wed, Nov 11, 2020 at 10:11:37AM -0800, Bhaumik Bhatt wrote:
> Hi Loic,
>
[...]
> > > > Look like it is stop and start, not pause and resume?
> > > I wanted to keep it pause and resume because it could get confusing
> > > for
> > > someone
> > > looking at this pair of APIs, that a client driver would also need to
> > > "start"
> > > channels after "preparing" them. Since that is not that case, and the
> > > mhi_prepare_for_transfer() API itself is supposed to also start the
> > > channels, it
> >
> > Yes, because prepare_for_transfer is actually init_and_start. I'm not
> > in favor of hiding what is really done at mhi_core level, start is
> > start and stop is stop, if it's correctly documented that should not
> > be confusing. just saying (stop moves channels in stop state, start in
> > enabled state), but other opinions are welcome.
> >
> I can rename it and have it documented in the mhi_prepare_for_transfer() API
> that we actually already start the channel, so it is not required to be used
> at first. I can improve this documentation in mhi.h as a separate patch.
>
> Later, if a client driver wants to issue stop and start commands, it can do
> so.
> I'm not too picky with the name. Maybe Mani or someone else may have more
> comments.
>
Please use start and stop to match what the function is doing. We should always
name the APIs with respect to their function.
Thanks,
Mani
Powered by blists - more mailing lists