All of lore.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: Arnd Bergmann <arnd@arndb.de>,
	Sascha Bischoff <sascha.bischoff@arm.com>,
	Timothy Hayes <timothy.hayes@arm.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	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,
	Lorenzo Pieralisi <lpieralisi@kernel.org>
Subject: Re: [PATCH v3 20/25] irqchip/gic-v5: Add GICv5 PPI support
Date: Tue, 06 May 2025 17:00:31 +0200	[thread overview]
Message-ID: <87zffpn5rk.ffs@tglx> (raw)
In-Reply-To: <20250506-gicv5-host-v3-20-6edd5a92fd09@kernel.org>

On Tue, May 06 2025 at 14:23, Lorenzo Pieralisi wrote:
> +
> +static u8 pri_bits = 5;

__ro_after_init ?

> +#define GICV5_IRQ_PRI_MASK 0x1f

Please put a new line before the #define and use a TAB between the
symbol and the value.

> +#define GICV5_IRQ_PRI_MI \
> +		(GICV5_IRQ_PRI_MASK & GENMASK(4, 5 - pri_bits))

No line break required. You have 100 characters

> +#define READ_PPI_REG(irq, reg)							\
> +	({									\
> +		u64 __ppi_val;							\
> +										\
> +		if (irq < 64)							\
> +			__ppi_val = read_sysreg_s(SYS_ICC_PPI_##reg##R0_EL1);	\
> +		else								\
> +			__ppi_val = read_sysreg_s(SYS_ICC_PPI_##reg##R1_EL1);	\
> +		__ppi_val;							\
> +	})
> +
> +#define WRITE_PPI_REG(set, irq, bit, reg)					\
> +	do {									\
> +		if (set) {							\
> +			if (irq < 64)						\
> +				write_sysreg_s(bit, SYS_ICC_PPI_S##reg##R0_EL1);\
> +			else							\
> +				write_sysreg_s(bit, SYS_ICC_PPI_S##reg##R1_EL1);\
> +		} else {							\
> +			if (irq < 64)						\
> +				write_sysreg_s(bit, SYS_ICC_PPI_C##reg##R0_EL1);\
> +			else							\
> +				write_sysreg_s(bit, SYS_ICC_PPI_C##reg##R1_EL1);\
> +		}								\
> +	} while (0)

I'm not convinced that these need to be macros.

static __always_inline u64 read_ppi_sysreg_s(unsigned int irq, const unsigned int which)
{
        switch (which) {
        case PPI_HM:
        	return irq < 64 ? read_sysreg_s(SYS_ICC_PPI_HM_R0_EL1) :
                		  read_sysreg_s(SYS_ICC_PPI_HM_R1_EL1;
        case ....:

        default:
                BUILD_BUG_ON(1);
        }
}

static __always_inline void write_ppi_sysreg_s(unsigned int irq, bool set, const unsigned int which)
{
	u64 bit = BIT_ULL(irq % 64);

        switch (which) {  
        case PPI_HM:
        	if (irq < 64)
                	write_sysreg_s(bit, SYS_ICC_PPI_HM_R0_EL1);
                else
                	write_sysreg_s(bit, SYS_ICC_PPI_HM_R1_EL1;
                return;
        case ....:

        default:
                BUILD_BUG_ON(1);
        }
}

Or something like that.

> +static int gicv5_ppi_set_type(struct irq_data *d, unsigned int type)
> +{
> +	/*
> +	 * The PPI trigger mode is not configurable at runtime,
> +	 * therefore this function simply confirms that the `type`
> +	 * parameter matches what is present.
> +	 */
> +	u64 hmr = READ_PPI_REG(d->hwirq, HM);
> +
> +	switch (type) {
> +	case IRQ_TYPE_LEVEL_HIGH:
> +	case IRQ_TYPE_LEVEL_LOW:
> +		if (((hmr >> (d->hwirq % 64)) & 0x1) != GICV5_PPI_HM_LEVEL)
> +			return -EINVAL;

Blink!

How does this test distinguish between LEVEL_LOW and LEVEL_HIGH? It only
tests for level, no? So the test is interesting at best ...

Secondly this comparison is confusing at best especially given that you
mask with a hex constant (0x1) first.

     		if (hmr & BIT_UL(d->hwirq % 64))
                	return -EINVAL;

Aside of that why do you have a set_type() function if there is no way
to set the type?

> +
> +static int gicv5_ppi_irq_get_irqchip_state(struct irq_data *d,
> +					   enum irqchip_irq_state which,
> +					   bool *val)
> +{
> +	u64 pendr, activer, hwirq_id_bit = BIT_ULL(d->hwirq % 64);
> +
> +	switch (which) {
> +	case IRQCHIP_STATE_PENDING:
> +		pendr = READ_PPI_REG(d->hwirq, SPEND);
> +
> +		*val = !!(pendr & hwirq_id_bit);
> +
> +		return 0;

		*val = !!(read_ppi_reg(d->hwirq, PPI_SPEND) & bit);
                return 0;

would take up less space and be readable.

> +	case IRQCHIP_STATE_ACTIVE:
> +		activer = READ_PPI_REG(d->hwirq, SACTIVE);
> +
> +		*val = !!(activer & hwirq_id_bit);
> +
> +		return 0;
> +	default:
> +		pr_debug("Unexpected PPI irqchip state\n");
> +	}
> +
> +	return -EINVAL;

Move the return into the default case.

> +static int __init gicv5_init_domains(struct fwnode_handle *handle)
> +{
> +	struct irq_domain *d;
> +
> +	d = irq_domain_create_linear(handle, PPI_NR, &gicv5_irq_ppi_domain_ops,
> +				     NULL);

Please use the full 100 charactes all over the place.

> +	if (!d)
> +		return -ENOMEM;
> +
> +	irq_domain_update_bus_token(d, DOMAIN_BUS_WIRED);
> +	gicv5_global_data.ppi_domain = d;
> +
> +	gicv5_global_data.fwnode = handle;

The random choices of seperating code with new lines are really
amazing.

> +static int __init gicv5_of_init(struct device_node *node, struct device_node *parent)
> +{
> +	int ret;
> +
> +	ret = gicv5_init_domains(&node->fwnode);

        int ret = ....;

> +	if (ret)

Thanks,

        tglx


  reply	other threads:[~2025-05-06 18:52 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-06 12:23 [PATCH v3 00/25] Arm GICv5: Host driver implementation Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 01/25] dt-bindings: interrupt-controller: Add Arm GICv5 Lorenzo Pieralisi
2025-05-06 19:08   ` Rob Herring
2025-05-07  8:35     ` Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 02/25] arm64/sysreg: Add GCIE field to ID_AA64PFR2_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 03/25] arm64/sysreg: Add ICC_PPI_PRIORITY<n>_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 04/25] arm64/sysreg: Add ICC_ICSR_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 05/25] arm64/sysreg: Add ICC_PPI_HMR<n>_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 06/25] arm64/sysreg: Add ICC_PPI_ENABLER<n>_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 07/25] arm64/sysreg: Add ICC_PPI_{C/S}ACTIVER<n>_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 08/25] arm64/sysreg: Add ICC_PPI_{C/S}PENDR<n>_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 09/25] arm64/sysreg: Add ICC_CR0_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 10/25] arm64/sysreg: Add ICC_PCR_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 11/25] arm64/sysreg: Add ICC_IDR0_EL1 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 12/25] arm64/sysreg: Add ICH_HFGRTR_EL2 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 13/25] arm64/sysreg: Add ICH_HFGWTR_EL2 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 14/25] arm64/sysreg: Add ICH_HFGITR_EL2 Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 15/25] arm64: Disable GICv5 read/write/instruction traps Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 16/25] arm64: cpucaps: Rename GICv3 CPU interface capability Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 17/25] arm64: cpucaps: Add GICv5 CPU interface (GCIE) capability Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 18/25] arm64: smp: Support non-SGIs for IPIs Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 19/25] arm64: Add support for GICv5 GSB barriers Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 20/25] irqchip/gic-v5: Add GICv5 PPI support Lorenzo Pieralisi
2025-05-06 15:00   ` Thomas Gleixner [this message]
2025-05-07  8:29     ` Lorenzo Pieralisi
2025-05-07  9:14     ` Marc Zyngier
2025-05-07 13:42       ` Thomas Gleixner
2025-05-07 13:52         ` Marc Zyngier
2025-05-07 14:57           ` Thomas Gleixner
2025-05-07 15:48             ` Lorenzo Pieralisi
2025-05-08  7:42             ` Lorenzo Pieralisi
2025-05-08  8:42               ` Marc Zyngier
2025-05-08 10:44                 ` Lorenzo Pieralisi
2025-05-09  8:07                   ` Lorenzo Pieralisi
2025-05-09  8:35                     ` Lorenzo Pieralisi
2025-05-12  8:32                       ` Marc Zyngier
2025-05-12  8:27                   ` Marc Zyngier
2025-05-06 12:23 ` [PATCH v3 21/25] irqchip/gic-v5: Add GICv5 IRS/SPI support Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 22/25] irqchip/gic-v5: Add GICv5 LPI/IPI support Lorenzo Pieralisi
2025-05-06 15:07   ` Thomas Gleixner
2025-05-07  8:30     ` Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 23/25] irqchip/gic-v5: Enable GICv5 SMP booting Lorenzo Pieralisi
2025-05-06 12:23 ` [PATCH v3 24/25] irqchip/gic-v5: Add GICv5 ITS support Lorenzo Pieralisi
2025-05-09  0:47   ` kernel test robot
2025-05-06 12:23 ` [PATCH v3 25/25] arm64: Kconfig: Enable GICv5 Lorenzo Pieralisi
2025-05-06 14:05 ` [PATCH v3 00/25] Arm GICv5: Host driver implementation Marc Zyngier
2025-05-07  7:54   ` Lorenzo Pieralisi
2025-05-07  9:09     ` Marc Zyngier
2025-05-07 10:01       ` Lorenzo Pieralisi

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=87zffpn5rk.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=Liam.Howlett@oracle.com \
    --cc=arnd@arndb.de \
    --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=lpieralisi@kernel.org \
    --cc=mark.rutland@arm.com \
    --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 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.