public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
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

  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