All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Breathitt Gray <william.gray@linaro.org>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linus.walleij@linaro.org, brgl@bgdev.pl,
	linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
	broonie@kernel.org, techsupport@winsystems.com,
	Paul Demetrotion <pdemetrotion@winsystems.com>
Subject: Re: [PATCH v4 3/3] gpio: ws16c48: Migrate to the regmap API
Date: Tue, 7 Mar 2023 21:51:26 -0500	[thread overview]
Message-ID: <ZAf4LudZkYLsWVWh@fedora> (raw)
In-Reply-To: <ZAX2k9gW1AA88T/P@smile.fi.intel.com>

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Mon, Mar 06, 2023 at 04:20:03PM +0200, Andy Shevchenko wrote:
> On Mon, Mar 06, 2023 at 07:59:53AM -0500, William Breathitt Gray wrote:
> 
> ...
> 
> > -	raw_spinlock_t lock;
> > +	spinlock_t lock;
> 
> This is a regression.
> That said, do we need a support of raw spin locks in the regmap IRQ?

So this code has a similar need as the gpio-pcie-idio-24 patch: guard
registers between handle_mask_sync() and set_type_config(); however, now
we also need to protect registers in regmap_irq_thread(). We can't use a
mutex here because regmap_irq_thread() is executed in an interrupt
context so we cannot sleep.

This might be a mistake in my understanding: I chose spinlock_t here
because I believed it to map out to a raw_spinlock_t anyway underneath,
whereas on RT kernels it would map out to whatever the equivalent is. I
suspect this is not actually the case. Would using raw_spinlock_t
explicitly be the correct way to go for this particular case?

> > +	u8 irq_mask[WS16C48_NUM_IRQS / WS16C48_NGPIO_PER_REG];
> 
> Can this be a bitmap? Or is it too over engineered with it?

I also considered a bitmap at first, but I believe it adds an
unnecessary abstraction in this particular case: irq_mask is just a
buffer to hold the previous mask_buf state to check if it's changed when
ws16c48_handle_mask_sync() is called. Since all we do with it is save
the mask_buf directly, using the bitmap API seems like overkill.

William Breathitt Gray

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2023-03-08  2:51 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06 12:59 [PATCH v4 0/3] Migrate the PCIe-IDIO-24 and WS16C48 GPIO drivers to the regmap API William Breathitt Gray
2023-03-06 12:59 ` [PATCH v4 1/3] regmap: Pass irq_drv_data as a parameter for set_type_config() William Breathitt Gray
2023-03-06 12:59 ` [PATCH v4 2/3] gpio: pcie-idio-24: Migrate to the regmap API William Breathitt Gray
2023-03-06 14:24   ` Andy Shevchenko
2023-03-08  2:29     ` William Breathitt Gray
2023-03-06 14:33   ` Michael Walle
2023-03-06 12:59 ` [PATCH v4 3/3] gpio: ws16c48: " William Breathitt Gray
2023-03-06 14:20   ` Andy Shevchenko
2023-03-08  2:51     ` William Breathitt Gray [this message]
2023-03-08 13:06       ` Andy Shevchenko
2023-03-09 19:33         ` William Breathitt Gray
2023-03-06 14:35   ` Michael Walle
2023-03-06 14:25 ` [PATCH v4 0/3] Migrate the PCIe-IDIO-24 and WS16C48 GPIO drivers " Andy Shevchenko
2023-03-08  2:11   ` William Breathitt Gray

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=ZAf4LudZkYLsWVWh@fedora \
    --to=william.gray@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=brgl@bgdev.pl \
    --cc=broonie@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pdemetrotion@winsystems.com \
    --cc=techsupport@winsystems.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.