From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <maz@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Will Deacon <will@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Sascha Bischoff <sascha.bischoff@arm.com>,
Timothy Hayes <timothy.hayes@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Peter Maydell <peter.maydell@linaro.org>,
Mark Rutland <mark.rutland@arm.com>,
Jiri Slaby <jirislaby@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-pci@vger.kernel.org>
Subject: Re: [PATCH v6 20/31] irqchip/gic-v5: Add GICv5 PPI support
Date: Wed, 2 Jul 2025 14:00:22 +0100 [thread overview]
Message-ID: <20250702140022.00001c65@huawei.com> (raw)
In-Reply-To: <aGUqEkascwGFD9x+@lpieralisi>
On Wed, 2 Jul 2025 14:46:10 +0200
Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> On Wed, Jul 02, 2025 at 12:40:19PM +0100, Jonathan Cameron wrote:
> > On Thu, 26 Jun 2025 12:26:11 +0200
> > Lorenzo Pieralisi <lpieralisi@kernel.org> wrote:
> >
> > > The GICv5 CPU interface implements support for PE-Private Peripheral
> > > Interrupts (PPI), that are handled (enabled/prioritized/delivered)
> > > entirely within the CPU interface hardware.
> >
> > I can't remember where I got to last time so if I repeat stuff that
> > you already responded to, feel free to just ignore me this time ;)
> >
> > All superficial stuff. Feel free to completely ignore if you like.
>
> We are at v6.16-rc4, series has been on the lists for 3 months, it has
> been reviewed and we would like to get it into v6.17 if possible and
> deemed reasonable, I am asking you folks please, what should I do ?
>
> I can send a v7 with the changes requested below (no bug fixes there)
> - it is fine by me - but I need to know please asap if we have a
> plan to get this upstream this cycle.
I'm absolutely fine with leaving these be. The mask stuff I would like
to clean up as it applies quite widely in the series but that
can be a follow up as no bugs (so far!).
As Marc said, these are in a good state.
Jonathan
>
> Thanks,
> Lorenzo
>
> > > diff --git a/drivers/irqchip/irq-gic-v5.c b/drivers/irqchip/irq-gic-v5.c
> > > new file mode 100644
> > > index 000000000000..a08daa562d21
> > > --- /dev/null
> > > +++ b/drivers/irqchip/irq-gic-v5.c
> > > @@ -0,0 +1,461 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (C) 2024-2025 ARM Limited, All Rights Reserved.
> > > + */
> > > +
> > > +#define pr_fmt(fmt) "GICv5: " fmt
> > > +
> > > +#include <linux/irqdomain.h>
> > > +#include <linux/wordpart.h>
> > > +
> > > +#include <linux/irqchip.h>
> > > +#include <linux/irqchip/arm-gic-v5.h>
> > > +
> > > +#include <asm/cpufeature.h>
> > > +#include <asm/exception.h>
> > > +
> > > +static u8 pri_bits __ro_after_init = 5;
> > > +
> > > +#define GICV5_IRQ_PRI_MASK 0x1f
> > > +#define GICV5_IRQ_PRI_MI (GICV5_IRQ_PRI_MASK & GENMASK(4, 5 - pri_bits))
> > > +
> > > +#define PPI_NR 128
> > > +
> > > +static bool gicv5_cpuif_has_gcie(void)
> > > +{
> > > + return this_cpu_has_cap(ARM64_HAS_GICV5_CPUIF);
> > > +}
> > > +
> > > +struct gicv5_chip_data {
> > > + struct fwnode_handle *fwnode;
> > > + struct irq_domain *ppi_domain;
> > > +};
> > > +
> > > +static struct gicv5_chip_data gicv5_global_data __read_mostly;
> >
> > > +static void gicv5_hwirq_eoi(u32 hwirq_id, u8 hwirq_type)
> > > +{
> > > + u64 cddi = hwirq_id | FIELD_PREP(GICV5_GIC_CDDI_TYPE_MASK, hwirq_type);
> >
> > Slight preference for not needing to care where hwirq_id goes in CDDI or how big
> > it is (other than when I checked the header defines).
> >
> > u64 cddi = FIELD_PREP(GICV5_GIC_CDDI_ID_MASK, hwirq_id) |
> > FIELD_PREP(GICV5_GIC_CDDI_TYPE_MASK, hwirq_type);
> >
> >
> > > +
> > > + gic_insn(cddi, CDDI);
> > > +
> > > + gic_insn(0, CDEOI);
> > > +}
> >
> > > +static int gicv5_ppi_irq_get_irqchip_state(struct irq_data *d,
> > > + enum irqchip_irq_state which,
> > > + bool *state)
> > > +{
> > > + u64 hwirq_id_bit = BIT_ULL(d->hwirq % 64);
> > > +
> > > + switch (which) {
> > > + case IRQCHIP_STATE_PENDING:
> > > + *state = !!(read_ppi_sysreg_s(d->hwirq, PPI_PENDING) & hwirq_id_bit);
> >
> > Technically don't need the !! but if you really like it I don't mind that much.
> >
> > > + return 0;
> > > + case IRQCHIP_STATE_ACTIVE:
> > > + *state = !!(read_ppi_sysreg_s(d->hwirq, PPI_ACTIVE) & hwirq_id_bit);
> > > + return 0;
> > > + default:
> > > + pr_debug("Unexpected PPI irqchip state\n");
> > > + return -EINVAL;
> > > + }
> > > +}
> >
> >
> > > +static int gicv5_irq_ppi_domain_translate(struct irq_domain *d,
> > > + struct irq_fwspec *fwspec,
> > > + irq_hw_number_t *hwirq,
> > > + unsigned int *type)
> > > +{
> > > + if (!is_of_node(fwspec->fwnode))
> > > + return -EINVAL;
> > > +
> > > + if (fwspec->param_count < 3)
> >
> > I don't care that much, but could relax this seeing as fwspec->param[2]
> > isn't used anyway? Maybe a tiny comment on why it matters?
> >
> > > + return -EINVAL;
> > > +
> > > + if (fwspec->param[0] != GICV5_HWIRQ_TYPE_PPI)
> > > + return -EINVAL;
> > > +
> > > + *hwirq = fwspec->param[1];
> > > +
> > > + /*
> > > + * Handling mode is hardcoded for PPIs, set the type using
> > > + * HW reported value.
> > > + */
> > > + *type = gicv5_ppi_irq_is_level(*hwirq) ? IRQ_TYPE_LEVEL_LOW : IRQ_TYPE_EDGE_RISING;
> > > +
> > > + return 0;
> >
> >
> > > +static int __init gicv5_of_init(struct device_node *node, struct device_node *parent)
> > > +{
> > > + int ret = gicv5_init_domains(of_fwnode_handle(node));
> > > + if (ret)
> > > + return ret;
> > > +
> > > + gicv5_set_cpuif_pribits();
> > > +
> > > + ret = gicv5_starting_cpu(smp_processor_id());
> > > + if (ret)
> > > + goto out_dom;
> > > +
> > > + ret = set_handle_irq(gicv5_handle_irq);
> > > + if (ret)
> > > + goto out_int;
> > > +
> > > + return 0;
> > > +
> > > +out_int:
> > > + gicv5_cpu_disable_interrupts();
> > > +out_dom:
> > > + gicv5_free_domains();
> >
> > Naming is always tricky but I'd not really expect gicv5_free_domains() as the
> > pair of gicv5_init_domains() (which is doing creation rather than just initializing).
> >
> > Ah well, names are never prefect and I don't really mind.
> >
> > > +
> > > + return ret;
> > > +}
> > > +IRQCHIP_DECLARE(gic_v5, "arm,gic-v5", gicv5_of_init);
> >
>
next prev parent reply other threads:[~2025-07-02 14:06 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 10:25 [PATCH v6 00/31] Arm GICv5: Host driver implementation Lorenzo Pieralisi
2025-06-26 10:25 ` [PATCH v6 01/31] dt-bindings: interrupt-controller: Add Arm GICv5 Lorenzo Pieralisi
2025-06-26 10:25 ` [PATCH v6 02/31] arm64/sysreg: Add GCIE field to ID_AA64PFR2_EL1 Lorenzo Pieralisi
2025-06-26 10:25 ` [PATCH v6 03/31] arm64/sysreg: Add ICC_PPI_PRIORITY<n>_EL1 Lorenzo Pieralisi
2025-06-26 10:25 ` [PATCH v6 04/31] arm64/sysreg: Add ICC_ICSR_EL1 Lorenzo Pieralisi
2025-06-26 10:25 ` [PATCH v6 05/31] arm64/sysreg: Add ICC_PPI_HMR<n>_EL1 Lorenzo Pieralisi
2025-06-26 10:25 ` [PATCH v6 06/31] arm64/sysreg: Add ICC_PPI_ENABLER<n>_EL1 Lorenzo Pieralisi
2025-06-26 10:25 ` [PATCH v6 07/31] arm64/sysreg: Add ICC_PPI_{C/S}ACTIVER<n>_EL1 Lorenzo Pieralisi
2025-06-26 10:25 ` [PATCH v6 08/31] arm64/sysreg: Add ICC_PPI_{C/S}PENDR<n>_EL1 Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 09/31] arm64/sysreg: Add ICC_CR0_EL1 Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 10/31] arm64/sysreg: Add ICC_PCR_EL1 Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 11/31] arm64/sysreg: Add ICC_IDR0_EL1 Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 12/31] arm64/sysreg: Add ICH_HFGRTR_EL2 Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 13/31] arm64/sysreg: Add ICH_HFGWTR_EL2 Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 14/31] arm64/sysreg: Add ICH_HFGITR_EL2 Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 15/31] arm64: Disable GICv5 read/write/instruction traps Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 16/31] arm64: cpucaps: Rename GICv3 CPU interface capability Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 17/31] arm64: cpucaps: Add GICv5 CPU interface (GCIE) capability Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 18/31] arm64: smp: Support non-SGIs for IPIs Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 19/31] arm64: Add support for GICv5 GSB barriers Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 20/31] irqchip/gic-v5: Add GICv5 PPI support Lorenzo Pieralisi
2025-07-02 11:40 ` Jonathan Cameron
2025-07-02 12:46 ` Lorenzo Pieralisi
2025-07-02 13:00 ` Jonathan Cameron [this message]
2025-07-02 13:21 ` Lorenzo Pieralisi
2025-07-02 14:09 ` Jonathan Cameron
2025-07-02 14:59 ` Lorenzo Pieralisi
2025-07-02 13:10 ` Arnd Bergmann
2025-06-26 10:26 ` [PATCH v6 21/31] irqchip/gic-v5: Add GICv5 IRS/SPI support Lorenzo Pieralisi
2025-07-02 13:04 ` Jonathan Cameron
2025-06-26 10:26 ` [PATCH v6 22/31] irqchip/gic-v5: Add GICv5 LPI/IPI support Lorenzo Pieralisi
2025-07-02 13:26 ` Jonathan Cameron
2025-06-26 10:26 ` [PATCH v6 23/31] irqchip/gic-v5: Enable GICv5 SMP booting Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 24/31] of/irq: Add of_msi_xlate() helper function Lorenzo Pieralisi
2025-06-27 21:32 ` Rob Herring
2025-06-30 7:58 ` Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 25/31] PCI/MSI: Add pci_msi_map_rid_ctlr_node() " Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 26/31] irqchip/gic-v3: Rename GICv3 ITS MSI parent Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 27/31] irqchip/msi-lib: Add IRQ_DOMAIN_FLAG_FWNODE_PARENT handling Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 28/31] irqchip/gic-v5: Add GICv5 ITS support Lorenzo Pieralisi
2025-07-02 14:06 ` Jonathan Cameron
2025-06-26 10:26 ` [PATCH v6 29/31] irqchip/gic-v5: Add GICv5 IWB support Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 30/31] docs: arm64: gic-v5: Document booting requirements for GICv5 Lorenzo Pieralisi
2025-06-26 10:26 ` [PATCH v6 31/31] arm64: Kconfig: Enable GICv5 Lorenzo Pieralisi
2025-06-30 17:17 ` [PATCH v6 00/31] Arm GICv5: Host driver implementation Marc Zyngier
2025-07-02 14:18 ` Jonathan Cameron
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=20250702140022.00001c65@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=Liam.Howlett@oracle.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jirislaby@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=robh@kernel.org \
--cc=sascha.bischoff@arm.com \
--cc=tglx@linutronix.de \
--cc=timothy.hayes@arm.com \
--cc=will@kernel.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.