[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHp75VcFY9RPeCAKC0vnNhXK-_-Zy7cWeLMBSuJLYZEDw_iAGg@mail.gmail.com>
Date: Wed, 5 Jan 2022 12:02:20 +0200
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Marc Zyngier <maz@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Sergey Shtylyov <s.shtylyov@....ru>,
"Rafael J. Wysocki" <rafael@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] platform: finally disallow IRQ0 in platform_get_irq() and
its ilk
On Tue, Jan 4, 2022 at 2:08 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Tue, Jan 04, 2022 at 10:48:00AM +0000, Marc Zyngier wrote:
> > On Tue, 04 Jan 2022 09:47:21 +0000,
> > Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
...
> > I think the end-goal is to never return 0. Either we return a valid
> > interrupt number, or we return an error. It should be the
> > responsibility of the caller to decide what they want to do in the
> > error case.
>
> As 0 still is a valid irq for some platforms (as mentioned above), then
> how is this ever going to be possible?
To avoid that we should first convert that SH case to use IRQ domains
instead of putting some arbitrary (HW dependent) values to IRQ
resources. When that is done it won't use vIRQ0 anymore. So, I agree
with Marc on that, except _optinal variants, but it doesn't contradict
the basic idea.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists