linux-kernel - Re: [PATCH 3/6] irqchip/apple-aic: Switch to irq_domain_create

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 18 Dec 2021 14:36:20 +0900
From:   Hector Martin <marcan@...can.st>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Rob Herring <robh+dt@...nel.org>,
        Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org
Subject: Re: [PATCH 3/6] irqchip/apple-aic: Switch to irq_domain_create_tree
 and sparse hwirqs

On 12/12/2021 23.37, Marc Zyngier wrote:
>> @@ -75,6 +75,7 @@
>>  #define AIC_EVENT_TYPE		GENMASK(31, 16)
>>  #define AIC_EVENT_NUM		GENMASK(15, 0)
>>  
>> +#define AIC_EVENT_TYPE_FIQ	0 /* Software use */
> 
> What does 'SW use' mean? Are you using the fact that the event
> register never returns 0 in the top bits?

Yeah. Since we're switching to tree IRQs we can use the raw hardware
event as the hwirq, and save some cycles munging fields, but we still
need a place for FIQ hwirq numbers to live. Zero here means "no
IRQ/spurious" to the hardware, so it's a convenient place to stick FIQs.
Note that the top-level IRQ handler function does check this field, so
even if newer hardware starts doing something silly here (which I highly
doubt...) it would never end up forwarded to the IRQ domain code without
further code changes.

>> -	aic_ic_write(ic, AIC_MASK_SET + MASK_REG(irqd_to_hwirq(d)),
>> -		     MASK_BIT(irqd_to_hwirq(d)));
>> +	u32 irq = FIELD_GET(AIC_EVENT_NUM, hwirq);
> 
> This expression is used quite a few times, and could use a helper
> clarifying its purpose (converting the event/hwirq to an index?).
> 'irq' is a bit of a misnomer too, but I struggle to find another
> name...

Ack, I'll add a helper. It's extracting the IRQ number field from the
hwirq number. This is relatively trivial at this point in the patch set
(where the only other field is the constant type = 1), but it makes more
sense once I add the die field later on.

>> @@ -492,13 +497,13 @@ static struct irq_chip fiq_chip = {
>>  static int aic_irq_domain_map(struct irq_domain *id, unsigned int irq,
>>  			      irq_hw_number_t hw)
>>  {
>> -	struct aic_irq_chip *ic = id->host_data;
>> +	u32 type = FIELD_GET(AIC_EVENT_TYPE, hw);
>>  
>> -	if (hw < ic->nr_hw) {
>> +	if (type == AIC_EVENT_TYPE_HW) {
>>  		irq_domain_set_info(id, irq, hw, &aic_chip, id->host_data,
>>  				    handle_fasteoi_irq, NULL, NULL);
>>  		irqd_set_single_target(irq_desc_get_irq_data(irq_to_desc(irq)));
>> -	} else {
>> +	} else if (type == AIC_EVENT_TYPE_FIQ) {
> 
> Do we need to check for FIQ? This should be the case by construction,
> right? If there is a risk that it isn't the case, then we probably
> need a default case (and the whole thing would be better written as a
> switch() statement).

Yes, it should be the case by construction; this can just be an else.
I'll change it.

-- 
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub