All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Linus Walleij <linus.walleij@linaro.org>,
	Dipen Patel <dipenp@nvidia.com>
Subject: Re: [PATCH 5/6] gpiolib: cdev: consolidate edge detector configuration flags
Date: Wed, 13 Jul 2022 18:24:59 +0800	[thread overview]
Message-ID: <20220713102459.GA113115@sol> (raw)
In-Reply-To: <CAHp75VeTyS_77LCp6Uab18M3hJ0dtf5jiSSrPN4tHaBHFEUTkg@mail.gmail.com>

On Wed, Jul 13, 2022 at 12:07:29PM +0200, Andy Shevchenko wrote:
> On Wed, Jul 13, 2022 at 3:39 AM Kent Gibson <warthog618@gmail.com> wrote:
> >
> > Combine the polarity_change flag, struct line eflags, and hte enable
> > flag into a single flag variable.
> >
> > The combination of these flags describes the configuration state
> > of the edge detector, so formalize and clarify that by combining
> > them into a single variable, edflags, in struct line.
> >
> > The edflags is a subset of the GPIO_V2_LINE_FLAGsb relevant to
> > the edge detector, and is also a superset of the eflags it replaces.
> > The eflags name is still used to describe the subset of edflags
> > corresponding to the rising/falling edge flags where edflags is
> > masked down to that subset.
> >
> > This consolidation reduces the number of variables being passed,
> > simplifies state comparisons, and provides a more extensible
> > foundation should additional edge sources be integrated in the
> > future.
> 
> I believe that you have checked this from a locking perspective, so we
> won't have worse lock contamination, if any.
> 

Yeah, they are used in the same way as the old eflags, so there is no
change in that regard.

> ...
> 
> >         struct linereq *lr;
> >         struct gpio_v2_line_event le;
> >         int level;
> > -       u64 eflags;
> > +       u64 edflags;
> 
> I would at the same time move it up before `int level;`.
> 

Ok.  What is the general rule you want applied, cos I'm not seeing it.

Cheers,
Kent.

> ...
> 
> > +       int level = -1, diff_seqno;
> > +       u64 eflags, edflags = READ_ONCE(line->edflags);
> 
> Ditto.
> 
> ...
> 
> >         u32 debounce_period_us;
> >         unsigned long irqflags = 0;
> >         int irq, ret;
> > +       u64 eflags;
> 
> Ditto for similarity.
> 
> -- 
> With Best Regards,
> Andy Shevchenko

  reply	other threads:[~2022-07-13 10:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-13  1:37 [PATCH 0/6] gpiolib: cdev: code cleanup following hte integration Kent Gibson
2022-07-13  1:37 ` [PATCH 1/6] gpiolib: cdev: simplify linereq_free Kent Gibson
2022-07-18  9:27   ` Linus Walleij
2022-07-13  1:37 ` [PATCH 2/6] gpiolib: cdev: simplify parameter in call to hte_edge_setup Kent Gibson
2022-07-13  1:37 ` [PATCH 3/6] gpiolib: cdev: replace if-else chains with switches Kent Gibson
2022-07-13  1:37 ` [PATCH 4/6] gpiolib: cdev: simplify line event identification Kent Gibson
2022-07-13  9:59   ` Andy Shevchenko
2022-07-13 10:27     ` Kent Gibson
2022-07-13 11:24       ` Andy Shevchenko
2022-07-14  0:32         ` Kent Gibson
2022-07-13  1:37 ` [PATCH 5/6] gpiolib: cdev: consolidate edge detector configuration flags Kent Gibson
2022-07-13 10:07   ` Andy Shevchenko
2022-07-13 10:24     ` Kent Gibson [this message]
2022-07-13 11:29       ` Andy Shevchenko
2022-07-13  1:37 ` [PATCH 6/6] gpiolib: cdev: compile out HTE unless CONFIG_HTE selected Kent Gibson
2022-07-13 10:03   ` Andy Shevchenko
2022-07-13 10:30     ` Kent Gibson
2022-07-14  1:08       ` Kent Gibson
2022-07-13 10:08 ` [PATCH 0/6] gpiolib: cdev: code cleanup following hte integration Andy Shevchenko
2022-07-15  2:06 ` Dipen Patel
2022-07-15  2:08   ` Kent Gibson

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=20220713102459.GA113115@sol \
    --to=warthog618@gmail.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=dipenp@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.