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: <CAMuHMdXpynBNC994vTo8tUc4bcD3HVzb3voNPJS1L8A0MRnyHQ@mail.gmail.com>
Date:   Mon, 27 Dec 2021 11:23:47 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] irqchip/renesas-irqc: Use platform_get_irq_optional() to
 get the interrupt

Hi Andy,

On Mon, Dec 27, 2021 at 11:10 AM Andy Shevchenko
<andy.shevchenko@...il.com> wrote:
> On Mon, Dec 27, 2021 at 12:02 PM Geert Uytterhoeven
> <geert@...ux-m68k.org> wrote:
> > On Mon, Dec 27, 2021 at 10:57 AM Andy Shevchenko
> > <andy.shevchenko@...il.com> wrote:
> > > On Mon, Dec 27, 2021 at 11:45 AM Geert Uytterhoeven
> > > <geert@...ux-m68k.org> wrote:
> > > > On Sun, Dec 26, 2021 at 9:49 AM Andy Shevchenko
> > > > <andy.shevchenko@...il.com> wrote:
> > > > > On Sun, Dec 26, 2021 at 1:59 AM Lad, Prabhakar
> > > > > <prabhakar.csengg@...il.com> wrote:
> > > > > > When will this patch be merged for the new api, so that I can base my
> > > > > > patches on top of it to avoid more changes?
> > > > >
> > > > > You can simply imply that, I dunno when it gets merged (from my point
> > > > > of view the users should be fixed first, and since you are adding
> > > > > users, the burden is increasing).
> > > >
> > > > Not only users (drivers), but also providers (architecture-specific code).
> > > > IRQ zero is still valid on some architectures, e.g. on SH[1].
> > >
> > > Are we talking about vIRQ?
> > > And users are fine with a big warning?
> >
> > The warning is only seen when a driver uses platorm_get_irq{,_optional}().
> > There are several other ways to obtain interrupts, avoiding the
> > big warning.
>
> Forgot to comment on this, then why is it a problem to allow
> platfiorm_get_irq_optional() use 0 for no IRQ?
> So, it seems you gave me a good justification for my way :-)

In se that is not a problem, assumed by now everybody should have
seen the warning, right?  Unfortunately that assumption is probably
not true, as people may not upgrade their kernel, cfr. my SH Ethernet
example.

Apart from that, any new conversion to platfiorm_get_irq_optional()
might cause a regression on an obscure platform still using IRQ0.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ