lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 3 Feb 2022 20:43:31 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Alex Elder <elder@...e.org>
Cc:     mhi@...ts.linux.dev, hemantk@...eaurora.org, bbhatt@...eaurora.org,
        quic_jhugo@...cinc.com, vinod.koul@...aro.org,
        bjorn.andersson@...aro.org, dmitry.baryshkov@...aro.org,
        skananth@...eaurora.org, vpernami@...eaurora.org,
        vbadigan@...eaurora.org, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/20] bus: mhi: ep: Add support for creating and
 destroying MHI EP devices

On Wed, Jan 05, 2022 at 06:28:08PM -0600, Alex Elder wrote:
> On 12/2/21 5:35 AM, Manivannan Sadhasivam wrote:
> > This commit adds support for creating and destroying MHI endpoint devices.
> > The MHI endpoint devices binds to the MHI endpoint channels and are used
> > to transfer data between MHI host and endpoint device.
> > 
> > There is a single MHI EP device for each channel pair. The devices will be
> > created when the corresponding channels has been started by the host and
> > will be destroyed during MHI EP power down and reset.
> > 
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> > ---
> >   drivers/bus/mhi/ep/main.c | 85 +++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 85 insertions(+)
> > 
> > diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c
> > index ce0f99f22058..f0b5f49db95a 100644
> > --- a/drivers/bus/mhi/ep/main.c
> > +++ b/drivers/bus/mhi/ep/main.c
> > @@ -63,6 +63,91 @@ static struct mhi_ep_device *mhi_ep_alloc_device(struct mhi_ep_cntrl *mhi_cntrl)
> >   	return mhi_dev;
> >   }
> > +static int mhi_ep_create_device(struct mhi_ep_cntrl *mhi_cntrl, u32 ch_id)
> > +{
> > +	struct mhi_ep_device *mhi_dev;
> > +	struct mhi_ep_chan *mhi_chan = &mhi_cntrl->mhi_chan[ch_id];
> > +	int ret;
> > +
> > +	mhi_dev = mhi_ep_alloc_device(mhi_cntrl);
> > +	if (IS_ERR(mhi_dev))
> > +		return PTR_ERR(mhi_dev);
> > +
> > +	mhi_dev->dev_type = MHI_DEVICE_XFER;
> 
> Elsewhere (at least in mhi_ep_process_tre_ring()) in your code
> you assume that the even-numbered channel is UL.
> 
> I would say, either use that assumption throughout, or do
> not use that assumption at all.  (I prefer the latter.)
> 
> I don't really like how this assumes that the channels
> are defined in adjacent pairs.  It assumes one is
> upload and the next one is download, but doesn't
> specify the order in which they're defined.  If
> you're going to assume they are defined in pairs, you
> should be able to assume which one is defined first,
> and then simplify this code (and even verify that
> they are defined UL before DL, perhaps).
> 

Yes, the UL channel is always even numbered and DL is odd.
I've removed the checks.

> > +	/* Configure primary channel */
> > +	if (mhi_chan->dir == DMA_TO_DEVICE) {
> > +		mhi_dev->ul_chan = mhi_chan;
> > +		mhi_dev->ul_chan_id = mhi_chan->chan;
> > +	} else {
> > +		mhi_dev->dl_chan = mhi_chan;
> > +		mhi_dev->dl_chan_id = mhi_chan->chan;
> > +	}
> > +
> > +	get_device(&mhi_dev->dev);
> > +	mhi_chan->mhi_dev = mhi_dev;
> > +
> > +	/* Configure secondary channel as well */
> > +	mhi_chan++;
> > +	if (mhi_chan->dir == DMA_TO_DEVICE) {
> > +		mhi_dev->ul_chan = mhi_chan;
> > +		mhi_dev->ul_chan_id = mhi_chan->chan;
> > +	} else {
> > +		mhi_dev->dl_chan = mhi_chan;
> > +		mhi_dev->dl_chan_id = mhi_chan->chan;
> > +	}
> > +
> > +	get_device(&mhi_dev->dev);
> > +	mhi_chan->mhi_dev = mhi_dev;
> > +
> > +	/* Channel name is same for both UL and DL */
> 
> You could verify the two channels indeed have the
> same name.
> 

done.

Thanks,
Mani

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ