All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Madhumitha Prabakaran <madhumithabiw@gmail.com>,
	mchehab@kernel.org, outreachy-kernel@googlegroups.com
Subject: Re: [Outreachy kernel] Re: [PATCH 2/2] Staging: media: davinci_vpfe: Remove RESETBIT macro and use BIT macro
Date: Fri, 22 Mar 2019 08:07:32 +0100	[thread overview]
Message-ID: <20190322070732.GA6288@kroah.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1903220727420.2621@hadrien>

On Fri, Mar 22, 2019 at 07:31:01AM +0100, Julia Lawall wrote:
> 
> 
> On Fri, 22 Mar 2019, Greg KH wrote:
> 
> > On Thu, Mar 21, 2019 at 08:26:06PM -0500, Madhumitha Prabakaran wrote:
> > > Remove RESETBIT macro and use BIT(x) instead of (1 << x) to improve
> > > codebase.
> > >
> > > Signed-off-by: Madhumitha Prabakaran <madhumithabiw@gmail.com>
> > > ---
> > >  drivers/staging/media/davinci_vpfe/dm365_ipipeif.c | 8 ++++----
> > >  drivers/staging/media/davinci_vpfe/dm365_ipipeif.h | 1 -
> > >  2 files changed, 4 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
> > > index 382d88bee5a7..4f18db127caf 100644
> > > --- a/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
> > > +++ b/drivers/staging/media/davinci_vpfe/dm365_ipipeif.c
> > > @@ -296,14 +296,14 @@ static int ipipeif_hw_setup(struct v4l2_subdev *sd)
> > >  		case MEDIA_BUS_FMT_YUYV8_1X16:
> > >  		case MEDIA_BUS_FMT_UYVY8_2X8:
> > >  		case MEDIA_BUS_FMT_Y8_1X8:
> > > -			RESETBIT(val, IPIPEIF_CFG2_YUV8_SHIFT);
> > > +			val &= ~BIT(IPIPEIF_CFG2_YUV8_SHIFT);
> >
> > clear_bit()?
> >
> > >  			val |= BIT(IPIPEIF_CFG2_YUV16_SHIFT);
> >
> > set_bit()?
> 
> OK, I see that the definition of these things is much more complicated
> than what I was looking for.  These are atomic operations.  There is also
> __set_bit, which is not atomic.  But set_bit does seem to be commonly
> used.

Only use __set_bit() if you know you are safe doing the operation in an
"unordered" fashion.  Given that these originally were "open coded",
it's probably safe, but it's simpler to use the ordered calls for now.

thanks,

greg k-h


  reply	other threads:[~2019-03-22  7:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-22  1:26 [PATCH 0/2] Remove macros and use BIT macros Madhumitha Prabakaran
2019-03-22  1:26 ` [PATCH 1/2] Staging: media: davinci_vpfe: Remove SETBIT macro and use BIT macro Madhumitha Prabakaran
2019-03-22  5:26   ` Greg KH
2019-03-22  1:26 ` [PATCH 2/2] Staging: media: davinci_vpfe: Remove RESETBIT " Madhumitha Prabakaran
2019-03-22  5:26   ` Greg KH
2019-03-22  6:31     ` [Outreachy kernel] " Julia Lawall
2019-03-22  7:07       ` Greg KH [this message]
2019-03-22  6:23   ` [Outreachy kernel] " Julia Lawall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190322070732.GA6288@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=julia.lawall@lip6.fr \
    --cc=madhumithabiw@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=outreachy-kernel@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.