From: Thomas Gleixner <tglx@linutronix.de>
To: Lorenzo Pieralisi <lpieralisi@kernel.org>,
Marc Zyngier <maz@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>
Cc: Sascha Bischoff <sascha.bischoff@arm.com>,
Timothy Hayes <timothy.hayes@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Lorenzo Pieralisi <lpieralisi@kernel.org>
Subject: Re: [PATCH 18/24] irqchip/gic-v5: Add GICv5 PPI support
Date: Tue, 08 Apr 2025 23:42:29 +0200 [thread overview]
Message-ID: <877c3uuy7u.ffs@tglx> (raw)
In-Reply-To: <20250408-gicv5-host-v1-18-1f26db465f8d@kernel.org>
On Tue, Apr 08 2025 at 12:50, Lorenzo Pieralisi wrote:
> +
> +static void gicv5_ppi_priority_init(void)
> +{
> + write_sysreg_s(REPEAT_BYTE(GICV5_IRQ_PRIORITY_MI),
> + SYS_ICC_PPI_PRIORITYR0_EL1);
Just let stick it out. You have 100 characters. All over the place...
> +static int gicv5_ppi_irq_set_irqchip_state(struct irq_data *d,
> + enum irqchip_irq_state which,
> + bool val)
> +{
> + u64 hwirq_id_bit = BIT_ULL(d->hwirq % 64);
> +
> + switch (which) {
> + case IRQCHIP_STATE_PENDING:
> + if (val) {
> + if (d->hwirq < 64)
> + write_sysreg_s(hwirq_id_bit,
> + SYS_ICC_PPI_SPENDR0_EL1);
> + else
> + write_sysreg_s(hwirq_id_bit,
> + SYS_ICC_PPI_SPENDR1_EL1);
> +
> + } else {
> + if (d->hwirq < 64)
> + write_sysreg_s(hwirq_id_bit,
> + SYS_ICC_PPI_CPENDR0_EL1);
> + else
> + write_sysreg_s(hwirq_id_bit,
> + SYS_ICC_PPI_CPENDR1_EL1);
> + }
> +
> + return 0;
> + case IRQCHIP_STATE_ACTIVE:
> + if (val) {
> + if (d->hwirq < 64)
> + write_sysreg_s(hwirq_id_bit,
> + SYS_ICC_PPI_SACTIVER0_EL1);
> + else
> + write_sysreg_s(hwirq_id_bit,
> + SYS_ICC_PPI_SACTIVER1_EL1);
> + } else {
> + if (d->hwirq < 64)
> + write_sysreg_s(hwirq_id_bit,
> + SYS_ICC_PPI_CACTIVER0_EL1);
> + else
> + write_sysreg_s(hwirq_id_bit,
> + SYS_ICC_PPI_CACTIVER1_EL1);
> + }
You already precalculate hwirq_id_bit. Can't you do something similar
for the registers?
case IRQCHIP_STATE_PENDING:
u32 reg = val ? SYS_ICC_PPI_SPENDR1_EL1 : SYS_ICC_PPI_SPENDR0_EL1;
write_sysreg_s(hwirq_id_bit, reg);
return 0;
case IRQCHIP_STATE_ACTIVE:
....
Ditto in the get_state() function.
No?
> +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)) {
It'd be way more readable to invert this check
if (!is_of_node(...))
return -EINVAL;
so that the subsequent checks are just a read through.
> + if (fwspec->param_count < 3)
> + return -EINVAL;
> +
> + if (fwspec->param[0] != GICV5_HWIRQ_TYPE_PPI)
> + return -EINVAL;
> +
> + *hwirq = fwspec->param[1];
> + *type = fwspec->param[2] & IRQ_TYPE_SENSE_MASK;
> +
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +static void gicv5_irq_ppi_domain_free(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs)
> +{
> + struct irq_data *d;
> +
> + if (WARN_ON(nr_irqs != 1))
WARN_ON_ONCE ?
> + return;
> +
> + d = irq_domain_get_irq_data(domain, virq);
> +
> + irq_set_handler(virq, NULL);
> + irq_domain_reset_irq_data(d);
> +}
> +
> +static int gicv5_irq_ppi_domain_select(struct irq_domain *d,
> + struct irq_fwspec *fwspec,
> + enum irq_domain_bus_token bus_token)
> +{
> + /* Not for us */
> + if (fwspec->fwnode != d->fwnode)
> + return 0;
> +
> + if (fwspec->param[0] != GICV5_HWIRQ_TYPE_PPI) {
> + // only handle PPIs
Commenting the obvious?
> + return 0;
> + }
> +
> + return (d == gicv5_global_data.ppi_domain);
> +}
> +
> +static const struct irq_domain_ops gicv5_irq_ppi_domain_ops = {
> + .translate = gicv5_irq_ppi_domain_translate,
> + .alloc = gicv5_irq_ppi_domain_alloc,
> + .free = gicv5_irq_ppi_domain_free,
> + .select = gicv5_irq_ppi_domain_select
> +};
> +
> +static inline void handle_irq_per_domain(u32 hwirq)
> +{
> + u32 hwirq_id;
> + struct irq_domain *domain = NULL;
> + u8 hwirq_type = FIELD_GET(GICV5_HWIRQ_TYPE, hwirq);
So far you managed to comply with the documented reverse fir tree
ordering.
https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#variable-declarations
Why are you changing coding style in the middle of the code?
> +
> + hwirq_id = FIELD_GET(GICV5_HWIRQ_ID, hwirq);
> +
> + if (hwirq_type == GICV5_HWIRQ_TYPE_PPI)
> + domain = gicv5_global_data.ppi_domain;
> +
> + if (generic_handle_domain_irq(domain, hwirq_id)) {
> + pr_err("Could not handle, hwirq = 0x%x", hwirq_id);
pr_err_once() perhaps?
> + gicv5_hwirq_eoi(hwirq_id, hwirq_type);
> + }
> +}
> +
> +static asmlinkage void __exception_irq_entry
> +gicv5_handle_irq(struct pt_regs *regs)
> +{
> + u64 ia;
> + bool valid;
> + u32 hwirq;
See above
> + ia = gicr_insn(GICV5_OP_GICR_CDIA);
> + valid = GICV5_GIC_CDIA_VALID(ia);
And please move that to the declaration lines
> +static int __init gicv5_init_domains(struct fwnode_handle *handle)
> +{
> + gicv5_global_data.fwnode = handle;
> + gicv5_global_data.ppi_domain = irq_domain_create_linear(
> + handle, 128, &gicv5_irq_ppi_domain_ops, NULL);
The ever changing choice of coding styles across functions is really
interesting. Obviously the length of 'gicv5_global_data.ppi_domain'
forces ugly, but that does not mean it needs to be that way:
struct irqdomain *d;
d = irq_domain_create_linear(handle, 128, &gicv5_irq_ppi_domain_ops, NULL);
if (!d)
return - ENOMEM;
irq_domain_update_bus_token(d, DOMAIN_BUS_WIRED);
gicv5_global_data.fwnode = handle;
gicv5_global_data.ppi_domain = d;
return 0;
No?
> +static int __init gicv5_of_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + int ret;
> +
> + ret = gicv5_init_domains(&node->fwnode);
> + if (ret)
> + return ret;
> +
> + gicv5_set_cpuif_pribits();
> +
> + ret = gicv5_starting_cpu(smp_processor_id());
You invoke the CPU hotplug callback for the boot CPU explicitly, but
what the heck installs the actual hotplug callback for the secondary
CPUs?
Thanks,
tglx
next prev parent reply other threads:[~2025-04-08 21:42 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-08 10:49 [PATCH 00/24] Arm GICv5: Host driver implementation Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 01/24] Documentation: devicetree: bindings: Add GICv5 DT bindings Lorenzo Pieralisi
2025-04-08 12:26 ` Rob Herring (Arm)
2025-04-08 14:58 ` Lorenzo Pieralisi
2025-04-08 15:07 ` Rob Herring
2025-04-09 8:20 ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 02/24] arm64/sysreg: Add GCIE field to ID_AA64PFR2_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 03/24] arm64/sysreg: Add ICC_PPI_PRIORITY<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 04/24] arm64/sysreg: Add ICC_ICSR_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 05/24] arm64/sysreg: Add ICC_PPI_HMR<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 06/24] arm64/sysreg: Add ICC_PPI_ENABLER<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 07/24] arm64/sysreg: Add ICC_PPI_{C/S}ACTIVER<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 08/24] arm64/sysreg: Add ICC_PPI_{C/S}PENDR<n>_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 09/24] arm64/sysreg: Add ICC_CR0_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 10/24] arm64/sysreg: Add ICC_PCR_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 11/24] arm64/sysreg: Add ICC_IDR0_EL1 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 12/24] arm64/sysreg: Add ICH_HFGRTR_EL2 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 13/24] arm64/sysreg: Add ICH_HFGWTR_EL2 Lorenzo Pieralisi
2025-04-09 7:48 ` Arnd Bergmann
2025-04-09 8:51 ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 14/24] arm64/sysreg: Add ICH_HFGITR_EL2 Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 15/24] arm64: Disable GICv5 read/write/instruction traps Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 16/24] arm64: cpucaps: Add GCIE capability Lorenzo Pieralisi
2025-04-08 11:26 ` Mark Rutland
2025-04-08 15:02 ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 17/24] arm64: smp: Support non-SGIs for IPIs Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 18/24] irqchip/gic-v5: Add GICv5 PPI support Lorenzo Pieralisi
2025-04-08 21:42 ` Thomas Gleixner [this message]
2025-04-09 7:30 ` Lorenzo Pieralisi
2025-04-17 14:49 ` Lorenzo Pieralisi
2025-04-11 17:06 ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 19/24] irqchip/gic-v5: Add GICv5 IRS/SPI support Lorenzo Pieralisi
2025-04-09 7:02 ` Thomas Gleixner
2025-04-09 7:40 ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 20/24] irqchip/gic-v5: Add GICv5 LPI/IPI support Lorenzo Pieralisi
2025-04-09 8:23 ` Arnd Bergmann
2025-04-09 10:11 ` Lorenzo Pieralisi
2025-04-09 10:56 ` Arnd Bergmann
2025-04-09 13:15 ` Lorenzo Pieralisi
2025-04-09 14:25 ` Arnd Bergmann
2025-04-18 9:21 ` Lorenzo Pieralisi
2025-04-09 8:27 ` Thomas Gleixner
2025-04-09 10:30 ` Lorenzo Pieralisi
2025-04-11 9:26 ` Lorenzo Pieralisi
2025-04-11 9:55 ` Thomas Gleixner
2025-04-11 12:37 ` Lorenzo Pieralisi
2025-04-12 13:01 ` Liam R. Howlett
2025-04-14 8:26 ` Lorenzo Pieralisi
2025-04-14 14:37 ` Liam R. Howlett
2025-04-15 8:08 ` Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 21/24] irqchip/gic-v5: Enable GICv5 SMP booting Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 22/24] irqchip/gic-v5: Add GICv5 ITS support Lorenzo Pieralisi
2025-04-09 11:13 ` Thomas Gleixner
2025-04-09 13:37 ` Lorenzo Pieralisi
2025-04-09 18:57 ` Thomas Gleixner
2025-04-10 8:08 ` Lorenzo Pieralisi
2025-04-10 9:20 ` Thomas Gleixner
2025-04-08 10:50 ` [PATCH 23/24] irqchip/gic-v5: Add GICv5 IWB support Lorenzo Pieralisi
2025-04-08 10:50 ` [PATCH 24/24] arm64: Kconfig: Enable GICv5 Lorenzo Pieralisi
2025-04-09 13:44 ` kernel test robot
2025-04-09 14:04 ` Lorenzo Pieralisi
2025-04-09 14:07 ` Krzysztof Kozlowski
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=877c3uuy7u.ffs@tglx \
--to=tglx@linutronix.de \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=maz@kernel.org \
--cc=robh@kernel.org \
--cc=sascha.bischoff@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox