[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8d7aced9-4aac-0821-a4b7-d27cb73be301@marcan.st>
Date: Fri, 26 Mar 2021 22:40:26 +0900
From: Hector Martin <marcan@...can.st>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
Marc Zyngier <maz@...nel.org>, Rob Herring <robh@...nel.org>,
Arnd Bergmann <arnd@...nel.org>,
Olof Johansson <olof@...om.net>,
Krzysztof Kozlowski <krzk@...nel.org>,
Mark Kettenis <mark.kettenis@...all.nl>,
Tony Lindgren <tony@...mide.com>,
Mohamed Mediouni <mohamed.mediouni@...amail.com>,
Stan Skowronek <stan@...ellium.com>,
Alexander Graf <graf@...zon.com>,
Will Deacon <will@...nel.org>,
Linus Walleij <linus.walleij@...aro.org>,
Mark Rutland <mark.rutland@....com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jonathan Corbet <corbet@....net>,
Catalin Marinas <catalin.marinas@....com>,
Christoph Hellwig <hch@...radead.org>,
"David S. Miller" <davem@...emloft.net>,
devicetree <devicetree@...r.kernel.org>,
"open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>,
Linux Documentation List <linux-doc@...r.kernel.org>,
Linux Samsung SOC <linux-samsung-soc@...r.kernel.org>,
Linux-Arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFT PATCH v3 16/27] irqchip/apple-aic: Add support for the Apple
Interrupt Controller
On 06/03/2021 00.05, Andy Shevchenko wrote:
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
>
> This is not needed, really, if you have unique / distinguishable
> messages in the first place.
> Rather people include module names, which may be useful.
Makes sense, I'll switch to KBUILD_MODNAME.
>> +#define MASK_BIT(x) BIT((x) & 0x1f)
>
> GENMASK(4,0)
It's not really a register bitmask, but rather extracting the low bits
of an index... but sure, GENMASK also expresses that. Changed.
>> +static atomic_t aic_vipi_flag[AIC_MAX_CPUS];
>> +static atomic_t aic_vipi_enable[AIC_MAX_CPUS];
>
> Isn't it easier to handle these when they are full width, i.e. 32
> items per the array?
I don't think so, it doesn't really buy us anything. It's just a maximum
beyond which the driver doesn't work in its current state anyway (if the
number were much larger it'd make sense to dynamically allocate these,
but not at this point).
>> +static int aic_irq_set_affinity(struct irq_data *d,
>> + const struct cpumask *mask_val, bool force)
>> +{
>> + irq_hw_number_t hwirq = irqd_to_hwirq(d);
>> + struct aic_irq_chip *ic = irq_data_get_irq_chip_data(d);
>> + int cpu;
>> +
>> + if (hwirq > ic->nr_hw)
>
> >= ?
Good catch, but this is actually obsolete. Higher IRQs go into the FIQ
irqchip, so this should never happen (it's a leftover from when they
were a single one). I'll remove it.
Ack on the other comments, thanks!
--
Hector Martin (marcan@...can.st)
Public Key: https://mrcn.st/pub
Powered by blists - more mailing lists