linux-riscv.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"aou@eecs.berkeley.edu" <aou@eecs.berkeley.edu>,
	"jason@lakedaemon.net" <jason@lakedaemon.net>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"maz@kernel.org" <maz@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"atish.patra@wdc.com" <atish.patra@wdc.com>,
	Yash Shah <yash.shah@sifive.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"palmer@dabbelt.com" <palmer@dabbelt.com>,
	Sagar Kadam <sagar.kadam@sifive.com>,
	"Paul Walmsley \( Sifive\)" <paul.walmsley@sifive.com>,
	"tglx@linutronix.de" <tglx@linutronix.de>,
	"bmeng.cn@gmail.com" <bmeng.cn@gmail.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Sachin Ghadi <sachin.ghadi@sifive.com>
Subject: Re: [PATCH 3/4] gpio: sifive: Add GPIO driver for SiFive SoCs
Date: Tue, 19 Nov 2019 17:41:51 +0100	[thread overview]
Message-ID: <CAMpxmJXFK4VLgJU+P0ZMNkduGfFxAeQ_NguRHtedf7cRPav7LQ@mail.gmail.com> (raw)
In-Reply-To: <CACRpkdb9KKPsu7dkjVmHbgQcdo1Zx9uC_jtd6HFwM+RO2EA4nw@mail.gmail.com>

wt., 19 lis 2019 o 16:03 Linus Walleij <linus.walleij@linaro.org> napisał(a):
>
> On Mon, Nov 18, 2019 at 11:15 AM Bartosz Golaszewski
> <bgolaszewski@baylibre.com> wrote:
> > pon., 18 lis 2019 o 11:03 Yash Shah <yash.shah@sifive.com> napisał(a):
>
> > > As suggested in the comments received on the RFC version of this patch[0], I am trying to use regmap MMIO by looking at gpio-mvebu.c. I got your point regarding the usage of own locks is not making any sense.
> > > Here is what I will do in v2:
> > > 1. drop the usage of own locks
> > > 2. consistently use regmap_* apis for register access (replace all iowrites).
> > > Does this make sense now?
> >
> > The thing is: the gpio-mmio code you're (correctly) reusing uses a
> > different lock - namely: bgpio_lock in struct gpio_chip. If you want
> > to use regmap for register operations, then you need to set
> > disable_locking in regmap_config to true and then take this lock
> > manually on every access.
>
> Is it really so? The bgpio_lock does protect the registers used
> by regmap-mmio but unless the interrupt code is also using the
> same registers it is fine to have a different lock for those.
>
> Is the interrupt code really poking into the very same registers
> as passed to bgpio_init()?
>
> Of course it could be seen as a bit dirty to poke around in the
> same memory space with regmap and the bgpio_* accessors
> but in practice it's no problem if they never touch the same
> things.
>
> Yours,
> Linus Walleij

I'm wondering if it won't cause any inconsistencies when for example
interrupts are being triggered on input lines while we're also reading
their values? Seems to me it's just more clear to use a single lock
for a register range. Most drivers using gpio-mmio do just that in
their irq-related routines.

Anyway: even without using bgpio_lock this code is inconsistent: if
we're using regmap for interrupt registers, we should either decide to
rely on locking provided by regmap or disable it and use a locally
defined lock. Also: if we're using regmap, then let's use it
everywhere, not only when it's convenient for updating registers.

Bart

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2019-11-19 16:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 12:11 [PATCH 0/4] GPIO & Hierarchy IRQ support for HiFive Unleashed Yash Shah
2019-11-12 12:11 ` [PATCH 1/4] irqchip: sifive: Support hierarchy irq domain Yash Shah
2019-11-12 12:43   ` Marc Zyngier
2019-11-18  7:14     ` Yash Shah
2019-11-12 12:12 ` [PATCH 2/4] gpio: sifive: Add DT documentation for SiFive GPIO Yash Shah
2019-11-18 16:53   ` Rob Herring
2019-11-12 12:12 ` [PATCH 3/4] gpio: sifive: Add GPIO driver for SiFive SoCs Yash Shah
2019-11-12 12:58   ` Marc Zyngier
2019-11-18  7:50     ` Yash Shah
2019-11-13 13:10   ` Bartosz Golaszewski
2019-11-18 10:03     ` Yash Shah
2019-11-18 10:15       ` Bartosz Golaszewski
2019-11-19 15:02         ` Linus Walleij
2019-11-19 16:41           ` Bartosz Golaszewski [this message]
2019-11-22 12:28             ` Linus Walleij
2019-11-22 12:39               ` Bartosz Golaszewski
2019-11-25  4:54               ` Yash Shah
2019-11-12 12:12 ` [PATCH 4/4] riscv: dts: Add DT support for SiFive FU540 GPIO driver Yash Shah

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=CAMpxmJXFK4VLgJU+P0ZMNkduGfFxAeQ_NguRHtedf7cRPav7LQ@mail.gmail.com \
    --to=bgolaszewski@baylibre.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=atish.patra@wdc.com \
    --cc=bmeng.cn@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jason@lakedaemon.net \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh+dt@kernel.org \
    --cc=sachin.ghadi@sifive.com \
    --cc=sagar.kadam@sifive.com \
    --cc=tglx@linutronix.de \
    --cc=yash.shah@sifive.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).