From: Thomas Gleixner <tglx@linutronix.de>
To: Randy Dunlap <rdunlap@infradead.org>, linux-kernel@vger.kernel.org
Cc: Randy Dunlap <rdunlap@infradead.org>,
Marc Zyngier <maz@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
linux-arch@vger.kernel.org, linux-gpio@vger.kernel.org
Subject: Re: [PATCH v2] irq domain: drop IRQ_DOMAIN_HIERARCHY option, make it always on
Date: Thu, 23 Mar 2023 21:53:04 +0100 [thread overview]
Message-ID: <877cv78a1b.ffs@tglx> (raw)
In-Reply-To: <20230313023935.31037-1-rdunlap@infradead.org>
On Sun, Mar 12 2023 at 19:39, Randy Dunlap wrote:
> In preparation for dropping the IRQ_DOMAIN Kconfig option (effectively
> making it always set/on), first drop IRQ_DOMAIN_HIERARCHY as an option,
> making its code always set/on.
>
> This has been built successfully on all ARCHes except hexagon,
> both 32-bit and 64-bit where applicable.
I really like where this is going, but reviewing this is a pain. I tried
to split it up into more digestable pieces:
https://tglx.de/~tglx/patches.tar
That's not completely equivalent to your patch as I did some of the
changes below. It builds on various oddball architectures with
IRQ_DOMAIN=n, but is otherwise completely untested.
It should be actually trivial after that to make IRQ_DOMAIN def_bool y
and then gradually remove the IRQ_DOMAIN selects and ifdeffery.
> v2: add stubs in include/linux/irqdomain.h for the config case of
> IRQ_DOMAIN is not set. If these are not added, there will be plenty
> of build errors (not so much for modern arches as for older ones).
I'm not really convinced that all of these stubs are required. Why would
there suddenly be a requirement to expose stubs for functions which
depend on CONFIG_IRQ_DOMAIN=y already today just by removing the
hierarchy config?
Even exposing stubs for functions which have been only available via
CONFIG_IRQ_DOMAIN_HIERARCHY is questionable simply because there cannot
be any code which invokes them unconditionally if
CONFIG_IRQ_DOMAIN_HIERARCHY=n today.
IOW, the sum of required stubs cannot be larger than number of stubs
required today.
If there is code which has a #ifdef CONFIG_IRQ_DOMAIN_HIERARCHY then
this needs to be changed to CONFIG_IRQ_DOMAIN or the required functions
have to be exposed unconditionally, right?
> diff -- a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -361,7 +361,7 @@ config GPIO_IXP4XX
> depends on OF
> select GPIO_GENERIC
> select GPIOLIB_IRQCHIP
> - select IRQ_DOMAIN_HIERARCHY
> + select IRQ_DOMAIN
IRQ_DOMAIN is already selected by GPIOLIB_IRQCHIP, so this select is
redundant for all GPIO configs which select GPIOLIB_IRQCHIP.
Thanks,
tglx
next prev parent reply other threads:[~2023-03-23 20:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-13 2:39 [PATCH v2] irq domain: drop IRQ_DOMAIN_HIERARCHY option, make it always on Randy Dunlap
2023-03-23 20:53 ` Thomas Gleixner [this message]
2023-03-24 6:11 ` Randy Dunlap
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=877cv78a1b.ffs@tglx \
--to=tglx@linutronix.de \
--cc=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=rdunlap@infradead.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.