[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0ef7b7be-4132-669a-448d-ce7c9f198d57@nvidia.com>
Date: Tue, 31 Jan 2023 10:43:55 -0600
From: Shanker Donthineni <sdonthineni@...dia.com>
To: Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <maz@...nel.org>, Michael Walle <michael@...le.cc>
Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Hans de Goede <hdegoede@...hat.com>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 4/5] genirq: Use the common function irq_expand_nr_irqs()
On 1/31/23 03:35, Thomas Gleixner wrote:
> External email: Use caution opening links or attachments
>
>
> On Sun, Jan 29 2023 at 18:57, Shanker Donthineni wrote:
>
>> Subject: genirq: Use the common function ...
>
> genirq: Unify irq_expand_nr_irqs()
>
> irq_expand_nr_irqs() is implemented as a stub function for !SPARSEIRQ
> builds. That's not necessary as the SPARSEIRQ version returns -ENOMEM
> correctly even for the !SPARSEIRQ case as the ....
>
>
> But this common function is non-obvious for the !SPARSEIRQ case. It at
> least needs a comment
>
>> +static int irq_expand_nr_irqs(unsigned int nr)
>> +{
>> + if (nr > MAX_SPARSE_IRQS)
>> + return -ENOMEM;
>> + nr_irqs = nr;
>> + return 0;
>> +}
>
> or preferrably something like this:
>
> if (!IS_ENABLED(CONFIG_SPARSEIRQ) || nr > MAX_SPARSE_IRQS)
> return -ENOMEM;
>
> which makes it entirely clear and also allows the compiler to optimize
> is down to a 'return -ENOMEM'.
>
I'll drop this patch since you're suggesting to remove !SPARSEIRQ support.
Powered by blists - more mailing lists