linux-kernel - Re: [PATCH] powerpc: pseries: use irq_of_parse_and

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]

Message-ID: <CAL_JsqLS_7TiQDwAxrDnP=v+63ge0+2SaomDgXQDSfOvwh7XiQ@mail.gmail.com>
Date:   Tue, 23 Jan 2018 08:11:35 -0600
From:   Rob Herring <robh@...nel.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] powerpc: pseries: use irq_of_parse_and_map helper

On Tue, Jan 23, 2018 at 12:53 AM, Michael Ellerman <mpe@...erman.id.au> wrote:
> Rob Herring <robh@...nel.org> writes:
>
>> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call
>> of_irq_parse_and_map instead which does the same thing. This gets us closer
>> to making the former 2 functions static.
>>
>> Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
>> Cc: Paul Mackerras <paulus@...ba.org>
>> Cc: Michael Ellerman <mpe@...erman.id.au>
>> Cc: linuxppc-dev@...ts.ozlabs.org
>> Signed-off-by: Rob Herring <robh@...nel.org>
>> ---
>>  arch/powerpc/platforms/pseries/event_sources.c | 11 ++++-------
>>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> Sorry NAK, this doesn't boot.
>
>> diff --git a/arch/powerpc/platforms/pseries/event_sources.c b/arch/powerpc/platforms/pseries/event_sources.c
>> index 6eeb0d4bab61..b0d8c146fe7b 100644
>> --- a/arch/powerpc/platforms/pseries/event_sources.c
>> +++ b/arch/powerpc/platforms/pseries/event_sources.c
>> @@ -16,7 +16,8 @@
>>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
>>   */
>>
>> -#include <asm/prom.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/of_irq.h>
>>
>>  #include "pseries.h"
>>
>> @@ -25,15 +26,11 @@ void request_event_sources_irqs(struct device_node *np,
>>                               const char *name)
>>  {
>>       int i, index, count = 0;
>> -     struct of_phandle_args oirq;
>>       unsigned int virqs[16];
>>
>>       /* First try to do a proper OF tree parsing */
>> -     for (index = 0; of_irq_parse_one(np, index, &oirq) == 0;
>> -          index++) {
>> -             if (count > 15)
>> -                     break;
>> -             virqs[count] = irq_create_of_mapping(&oirq);
>> +     for (index = 0; count < 16; index++) {
>> +             virqs[count] = irq_of_parse_and_map(np, index);
>>               if (!virqs[count]) {
>>                       pr_err("event-sources: Unable to allocate "
>>                              "interrupt number for %pOF\n",
>
>                                np);
>                         WARN_ON(1);
>                 } else {
>                         count++;
>                 }
>         }
>
>
> Which is an infinite loop if we have less than 16 irqs, and spews the
> warning continuously.
>
> Are you trying to remove the low-level routines or is this just a
> cleanup?

The former, but I'm not sure that will happen. There's a handful of
others left, but they aren't simply a call to of_irq_parse_one and
then irq_create_of_mapping.

> The patch below works, it loses the error handling if the interrupts
> property is corrupt/empty, but that's probably overly paranoid anyway.

Not quite. Previously, it was silent if parsing failed. Only the
mapping would give an error which would mean the interrupt parent had
some error.

Actually, we could use of_irq_get here to preserve the error handling.
It will return error codes from parsing, 0 on mapping failure, or the
Linux irq number. It adds an irq_find_host call for deferred probe,
but that should be harmless. I'll respin it.

Rob