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, 24 Jun 2021 19:54:53 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     hemantk@...eaurora.org, bbhatt@...eaurora.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        loic.poulain@...aro.org
Subject: Re: [PATCH 6/8] bus: mhi: core: Add support for processing priority
 of event ring

On Thu, Jun 24, 2021 at 03:53:33PM +0200, Greg KH wrote:
> On Mon, Jun 21, 2021 at 09:46:14PM +0530, Manivannan Sadhasivam wrote:
> > From: Hemant Kumar <hemantk@...eaurora.org>
> > 
> > Event ring priorities are currently set to 1 and are unused.
> > Default processing priority for event rings is set to regular
> > tasklet. Controllers can choose to use high priority tasklet
> > scheduling for certain event rings critical for processing such
> > as ones transporting control information if they wish to avoid
> > system scheduling delays for those packets. In order to support
> > these use cases, allow controllers to set event ring priority to
> > high.
> > 
> > Signed-off-by: Hemant Kumar <hemantk@...eaurora.org>
> > Signed-off-by: Bhaumik Bhatt <bbhatt@...eaurora.org>
> > Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> > Link: https://lore.kernel.org/r/1624053903-24653-2-git-send-email-bbhatt@codeaurora.org
> > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> > ---
> >  drivers/bus/mhi/core/init.c | 3 +--
> >  drivers/bus/mhi/core/main.c | 9 +++++++--
> >  include/linux/mhi.h         | 2 +-
> >  3 files changed, 9 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> > index c81b377fca8f..444676034bf0 100644
> > --- a/drivers/bus/mhi/core/init.c
> > +++ b/drivers/bus/mhi/core/init.c
> > @@ -673,8 +673,7 @@ static int parse_ev_cfg(struct mhi_controller *mhi_cntrl,
> >  				&mhi_cntrl->mhi_chan[mhi_event->chan];
> >  		}
> >  
> > -		/* Priority is fixed to 1 for now */
> > -		mhi_event->priority = 1;
> > +		mhi_event->priority = event_cfg->priority;
> >  
> >  		mhi_event->db_cfg.brstmode = event_cfg->mode;
> >  		if (MHI_INVALID_BRSTMODE(mhi_event->db_cfg.brstmode))
> > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> > index 8ac73f9e92a6..3775c77dec63 100644
> > --- a/drivers/bus/mhi/core/main.c
> > +++ b/drivers/bus/mhi/core/main.c
> > @@ -454,10 +454,15 @@ irqreturn_t mhi_irq_handler(int irq_number, void *dev)
> >  
> >  		if (mhi_dev)
> >  			mhi_notify(mhi_dev, MHI_CB_PENDING_DATA);
> > -	} else {
> > -		tasklet_schedule(&mhi_event->task);
> > +
> > +		return IRQ_HANDLED;
> >  	}
> >  
> > +	if (!mhi_event->priority)
> > +		tasklet_hi_schedule(&mhi_event->task);
> > +	else
> > +		tasklet_schedule(&mhi_event->task);
> > +
> >  	return IRQ_HANDLED;
> >  }
> >  
> > diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> > index 86cea5256e3c..bf23c213429c 100644
> > --- a/include/linux/mhi.h
> > +++ b/include/linux/mhi.h
> > @@ -250,7 +250,7 @@ struct mhi_channel_config {
> >   * @irq_moderation_ms: Delay irq for additional events to be aggregated
> >   * @irq: IRQ associated with this ring
> >   * @channel: Dedicated channel number. U32_MAX indicates a non-dedicated ring
> > - * @priority: Priority of this ring. Use 1 for now
> > + * @priority: Processing priority of this ring. 0 is high and 1 is regular
> 
> Why is 0 high and 1 low?  Does that feel backwards?
> 

That's because, "1" was used from the beginning by the controller drivers
as the regular priority. And I thought of using "0" as high priority so
that we can leave the controller drivers unmodified.

> Shouldn't this be a boolean, or if not, an enumerated type so that
> people can read the code over time?
> 

Bhaumik proposed an enum but I wanted 0/1 so that the controller drivers
can be untouched. Also, I don't see any immediate requirement for other
priorities.

Will make it a bool then.

Thanks,
Mani

> thanks,
> 
> greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ