All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Aidan MacDonald <aidanmacdonald.0x0@gmail.com>,
	Marc Zyngier <maz@kernel.org>
Cc: michael@walle.cc, brgl@bgdev.pl, linux-gpio@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] gpio: regmap: Support a custom ->to_irq() hook
Date: Mon, 11 Jul 2022 13:48:50 +0200	[thread overview]
Message-ID: <CACRpkdYEeNY=PmGaNfV=K7cJPJu1vyUa3wREbCU8hCJVJb5YfA@mail.gmail.com> (raw)
In-Reply-To: <ZTG1etjWj47jkqTxIRgriV6pQhW9dasf@localhost>

On Wed, Jul 6, 2022 at 4:21 PM Aidan MacDonald
<aidanmacdonald.0x0@gmail.com> wrote:

> If moving to hierarchical IRQ chips is the plan, could we add a note
> to say .to_irq() is discouraged and shouldn't be used in new code?
> Based on what you're saying (which I agree makes sense) it sounds
> like there's really no reason to ever use .to_irq().

There is a reason to use .to_itq() to get the irq associated with
a GPIO, in a Linux kernel context. Especially when doing exactly
what IRQ keys are doing: finding the IRQ for a GPIO line, if any.

But it is not intended to provide a random IRQ from anywhere
else in the system. Maybe I could clarify that.

There are many old boardfile-instances of GPIO where .to_irq()
may be doing something really funky, these are not really up to
date with the current idea of how we model systems in hardware
description languages such as DT or ACPI DSDT.

There may be archs that do not even have DT or ACPI or similar,
there it would be fine to use it in a more liberal way. This may
be the case for m68k or something so I cannot speak about
everything here.

I understand that it might be annoying that this is a bit fuzzy
around the edges.

> Okay, that sounds like a good plan. I'll look more carefully at the
> existing drivers and see if I can use existing gpiolib helpers.
>
> One potential issue (from reading the code) is that hierarchical IRQ
> domains seemingly can't have a non-hierarchical domain as the parent:
> irq_domain_alloc_irqs_parent() calls irq_domain_alloc_irqs_hierarchy()
> and the latter fails with -ENOSYS for a non-hierarchical domain.

Yes that is a characteristic of hierarchical irq domains, they have to
be hierarchical all the way down. It is very often what we want
as well.

> In my case I'm using a regmap IRQ chip, which is non-hierarchical,
> so perhaps that will need to be expanded?

Yes I'm sorry if it adds work to your plate :(

However I think the end result would be very useful for everyone.
Maybe Marc Z has something to add here?

Yours,
Linus Walleij

      reply	other threads:[~2022-07-11 11:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-03 11:10 [PATCH 0/3] gpio-regmap support for register fields and other hooks Aidan MacDonald
2022-07-03 11:10 ` [PATCH 1/3] gpio: regmap: Support registers with more than one bit per GPIO Aidan MacDonald
2022-07-03 14:09   ` Andy Shevchenko
2022-07-04 16:03     ` Aidan MacDonald
2022-07-04 12:28   ` Michael Walle
2022-07-04 16:01     ` Aidan MacDonald
2022-07-04 19:46       ` Michael Walle
2022-07-06 20:46         ` Aidan MacDonald
2022-07-07  7:44           ` Michael Walle
2022-07-07 14:58             ` Aidan MacDonald
2022-07-03 11:10 ` [PATCH 2/3] gpio: regmap: Support combined GPIO and pin control drivers Aidan MacDonald
2022-07-03 14:14   ` Andy Shevchenko
2022-07-04 15:31     ` Aidan MacDonald
2022-07-03 11:10 ` [PATCH 3/3] gpio: regmap: Support a custom ->to_irq() hook Aidan MacDonald
2022-07-03 14:24   ` Andy Shevchenko
2022-07-04 16:38     ` Aidan MacDonald
2022-07-04 23:05   ` Linus Walleij
2022-07-05 11:09     ` Aidan MacDonald
2022-07-06 11:45       ` Andy Shevchenko
2022-07-06 20:53         ` Aidan MacDonald
2022-07-06 12:02       ` Linus Walleij
2022-07-06 13:50         ` Aidan MacDonald
2022-07-11 11:48           ` Linus Walleij [this message]

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='CACRpkdYEeNY=PmGaNfV=K7cJPJu1vyUa3wREbCU8hCJVJb5YfA@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=aidanmacdonald.0x0@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=michael@walle.cc \
    /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.