[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Jul 2022 13:45:33 +0300
From: Serge Semin <fancer.lancer@...il.com>
To: Marc Zyngier <maz@...nel.org>
Cc: Samuel Holland <samuel@...lland.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Bartosz Golaszewski <brgl@...ev.pl>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
Borislav Petkov <bp@...en8.de>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>,
Chris Zankel <chris@...kel.net>,
Colin Ian King <colin.king@...el.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Dexuan Cui <decui@...rosoft.com>,
Florian Fainelli <f.fainelli@...il.com>,
Guo Ren <guoren@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
Haiyang Zhang <haiyangz@...rosoft.com>,
Helge Deller <deller@....de>, Ingo Molnar <mingo@...hat.com>,
Ivan Kokshaysky <ink@...assic.park.msu.ru>,
"James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
Jan Beulich <jbeulich@...e.com>,
Joerg Roedel <joro@...tes.org>,
Juergen Gross <jgross@...e.com>,
Julia Lawall <Julia.Lawall@...ia.fr>,
"K. Y. Srinivasan" <kys@...rosoft.com>,
Kees Cook <keescook@...omium.org>,
Krzysztof WilczyĆski <kw@...ux.com>,
Linus Walleij <linus.walleij@...aro.org>,
Lorenzo Pieralisi <lpieralisi@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Matt Turner <mattst88@...il.com>,
Max Filippov <jcmvbkbc@...il.com>,
Maximilian Heyne <mheyne@...zon.de>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>,
Rich Felker <dalias@...c.org>,
Richard Henderson <rth@...ddle.net>,
Rikard Falkeborn <rikard.falkeborn@...il.com>,
Rob Herring <robh@...nel.org>,
Russell King <linux@...linux.org.uk>,
Stefano Stabellini <sstabellini@...nel.org>,
Stephen Hemminger <sthemmin@...rosoft.com>,
Sven Schnelle <svens@...ckframe.org>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Wei Liu <wei.liu@...nel.org>, Wei Xu <xuwei5@...ilicon.com>,
Will Deacon <will@...nel.org>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
iommu@...ts.linux-foundation.org, iommu@...ts.linux.dev,
linux-alpha@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-hyperv@...r.kernel.org, linux-ia64@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org,
linux-parisc@...r.kernel.org, linux-pci@...r.kernel.org,
linux-sh@...r.kernel.org, linux-xtensa@...ux-xtensa.org,
x86@...nel.org, xen-devel@...ts.xenproject.org,
kernel test robot <lkp@...el.com>
Subject: Re: [PATCH v3 1/8] irqchip/mips-gic: Only register IPI domain when
SMP is enabled
On Thu, Jul 07, 2022 at 09:22:26AM +0100, Marc Zyngier wrote:
> On Tue, 05 Jul 2022 14:52:43 +0100,
> Serge Semin <fancer.lancer@...il.com> wrote:
> >
> > Hi Samuel
> >
> > On Fri, Jul 01, 2022 at 03:00:49PM -0500, Samuel Holland wrote:
> > > The MIPS GIC irqchip driver may be selected in a uniprocessor
> > > configuration, but it unconditionally registers an IPI domain.
> > >
> > > Limit the part of the driver dealing with IPIs to only be compiled when
> > > GENERIC_IRQ_IPI is enabled, which corresponds to an SMP configuration.
> >
> > Thanks for the patch. Some comment is below.
> >
> > >
> > > Reported-by: kernel test robot <lkp@...el.com>
> > > Signed-off-by: Samuel Holland <samuel@...lland.org>
> > > ---
> > >
> > > Changes in v3:
> > > - New patch to fix build errors in uniprocessor MIPS configs
> > >
> > > drivers/irqchip/Kconfig | 3 +-
> > > drivers/irqchip/irq-mips-gic.c | 80 +++++++++++++++++++++++-----------
> > > 2 files changed, 56 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > > index 1f23a6be7d88..d26a4ff7c99f 100644
> > > --- a/drivers/irqchip/Kconfig
> > > +++ b/drivers/irqchip/Kconfig
> > > @@ -322,7 +322,8 @@ config KEYSTONE_IRQ
> > >
> > > config MIPS_GIC
> > > bool
> > > - select GENERIC_IRQ_IPI
> > > + select GENERIC_IRQ_IPI if SMP
> >
> > > + select IRQ_DOMAIN_HIERARCHY
> >
> > It seems to me that the IRQ domains hierarchy is supposed to be
> > created only if IPI is required. At least that's what the MIPS GIC
> > driver implies. Thus we can go further and CONFIG_IRQ_DOMAIN_HIERARCHY
> > ifdef-out the gic_irq_domain_alloc() and gic_irq_domain_free()
> > methods definition together with the initialization:
> >
> > static const struct irq_domain_ops gic_irq_domain_ops = {
> > .xlate = gic_irq_domain_xlate,
> > +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
> > .alloc = gic_irq_domain_alloc,
> > .free = gic_irq_domain_free,
> > +#endif
> > .map = gic_irq_domain_map,
> > };
> >
> > If the GENERIC_IRQ_IPI config is enabled, CONFIG_IRQ_DOMAIN_HIERARCHY
> > will be automatically selected (see the config definition in
> > kernel/irq/Kconfig). If the IRQs hierarchy is needed for some another
> > functionality like GENERIC_MSI_IRQ_DOMAIN or GPIOs then they will
> > explicitly enable the IRQ_DOMAIN_HIERARCHY config thus activating the
> > denoted .alloc and .free methods definitions.
> >
> > To sum up you can get rid of the IRQ_DOMAIN_HIERARCHY config
> > force-select from this patch and make the MIPS GIC driver code a bit
> > more coherent.
> >
> > @Marc, please correct me if were wrong.
>
> Either way probably works correctly, but Samuel's approach is more
> readable IMO. It is far easier to reason about a high-level feature
> (GENERIC_IRQ_IPI) than an implementation detail (IRQ_DOMAIN_HIERARCHY).
>
The main idea of my comment was to get rid of the forcible
IRQ_DOMAIN_HIERARCHY config selection, because the basic part of the
driver doesn't depends on the hierarchical IRQ-domains functionality.
It's needed only for IPIs and implicitly for the lower level IRQ
device drivers like GPIO or PCIe-controllers, which explicitly enable
the IRQ_DOMAIN_HIERARCHY config anyway. That's why instead of forcible
IRQ_DOMAIN_HIERARCHY config selection (see Samuel patch) I suggested
to make the corresponding functionality defined under the
IRQ_DOMAIN_HIERARCHY config ifdefs, thus having the driver capable of
creating the hierarchical IRQs domains only if it's required.
> If you really want to save a handful of bytes, you can make the
> callbacks conditional on GENERIC_IRQ_IPI, and be done with it.
AFAIU I can't in this case. It must be either IRQ_DOMAIN_HIERARCHY
ifdefs or explicit IRQ_DOMAIN_HIERARCHY select. There can be non-SMP
(UP) systems with no need in IPIs but for instance having a GPIO or
PCIe controller which require the hierarchical IRQ-domains support of
the parental IRQ controller. So making the callbacks definition
depended on the GENERIC_IRQ_IPI config state will break the driver for
these systems. That's why I suggested to use
CONFIG_IRQ_DOMAIN_HIERARCHY which activates the hierarchical IRQ
domains support in the IRQ-chip system (see the irq_domain_ops
structure conditional fields definition) and shall we have the
suggested approach implemented in the MIPS GIC driver.
-Sergey
> But this can come as an additional patch.
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists