All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Sergey Shtylyov <s.shtylyov@omp.ru>
Cc: Marc Zyngier <maz@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [PATCH] platform: finally disallow IRQ0 in platform_get_irq() and its ilk
Date: Wed, 12 Jan 2022 19:19:23 +0100	[thread overview]
Message-ID: <Yd8bq7sZ3WNWruqM@kroah.com> (raw)
In-Reply-To: <9c3f9a6e-89b6-b73b-032f-e4b4ee6f72ac@omp.ru>

On Wed, Jan 12, 2022 at 08:53:51PM +0300, Sergey Shtylyov wrote:
> On 1/4/22 12:26 PM, Marc Zyngier wrote:
> 
> > [Adding Geert]
> > 
> > On Sat, 06 Nov 2021 20:26:47 +0000,
> > Sergey Shtylyov <s.shtylyov@omp.ru> wrote:
> >>
> >> The commit a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is
> >> invalid") only calls WARN() when IRQ0 is about to be returned, however
> >> using IRQ0 is considered invalid (according to Linus) outside the arch/
> >> code where it's used by the i8253 drivers. Many driver subsystems treat
> >> 0 specially (e.g. as an indication of the polling mode by libata), so
> >> the users of platform_get_irq[_byname]() in them would have to filter
> >> out IRQ0 explicitly and this (quite obviously) doesn't scale...
> >> Let's finally get this straight and return -EINVAL instead of IRQ0!
> >>
> >> Fixes: a85a6c86c25b ("driver core: platform: Clarify that IRQ 0 is invalid")
> >> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
> >>
> >> ---
> >> The patch is against the 'driver-core-linus' branch of Greg Kroah-Hartman's
> >> 'driver-core.git' repo.
> >>
> >>  drivers/base/platform.c |    6 ++++--
> >>  1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> Index: driver-core/drivers/base/platform.c
> >> ===================================================================
> >> --- driver-core.orig/drivers/base/platform.c
> >> +++ driver-core/drivers/base/platform.c
> >> @@ -231,7 +231,8 @@ int platform_get_irq_optional(struct pla
> >>  out_not_found:
> >>  	ret = -ENXIO;
> >>  out:
> >> -	WARN(ret == 0, "0 is an invalid IRQ number\n");
> >> +	if (WARN(!ret, "0 is an invalid IRQ number\n"))
> >> +		return -EINVAL;
> >>  	return ret;
> >>  }
> >>  EXPORT_SYMBOL_GPL(platform_get_irq_optional);
> >> @@ -445,7 +446,8 @@ static int __platform_get_irq_byname(str
> >>  
> >>  	r = platform_get_resource_byname(dev, IORESOURCE_IRQ, name);
> >>  	if (r) {
> >> -		WARN(r->start == 0, "0 is an invalid IRQ number\n");
> >> +		if (WARN(!r->start, "0 is an invalid IRQ number\n"))
> >> +			return -EINVAL;
> >>  		return r->start;
> >>  	}
> > 
> > Geert recently mentioned that a few architectures (such as sh?) still
> > use IRQ0 as something valid in limited cases.
> > 
> > From my PoV, this patch is fine, but please be prepared to fix things
> > in a couple of years when someone decides to boot a recent kernel on
> > their pet dinosaur. With that in mind:
> > 
> > Acked-by: Marc Zyngier <maz@kernel.org>
> 
>    Greg, so would that ACK be enough? Is there a chance this patch gets finally included
> into 5.17-rc1? Or should I look into fixing the recently found arch/sh/ issue 1st (as you
> can see, just WARN()'ing about IRQ0 wasn't enough to get this fixed)?

5.17-rc1 is way too late, sorry.  It would have had to be in my tree
early last week to make it there, my pull requests are already sent to
Linus.

Please fix this up properly, and resend the correct patch series, there
is no rush.

thanks,

greg k-h

  parent reply	other threads:[~2022-01-12 18:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-06 20:26 [PATCH] platform: finally disallow IRQ0 in platform_get_irq() and its ilk Sergey Shtylyov
2021-11-26 16:20 ` Greg Kroah-Hartman
2021-12-02 21:11   ` Sergey Shtylyov
2021-12-09 20:06 ` Andy Shevchenko
2021-12-09 20:21   ` Sergey Shtylyov
2021-12-10 11:17     ` Andy Shevchenko
2022-01-04 19:27       ` Sergey Shtylyov
2022-01-05 10:09         ` Andy Shevchenko
2022-01-09 11:31           ` Sergey Shtylyov
2022-01-04  9:26 ` Marc Zyngier
2022-01-04  9:47   ` Geert Uytterhoeven
2022-01-04 10:48     ` Marc Zyngier
2022-01-04 10:53       ` Greg Kroah-Hartman
2022-01-04 11:13         ` Marc Zyngier
2022-01-05 10:02         ` Andy Shevchenko
2022-01-04 11:24       ` Geert Uytterhoeven
2022-01-05  9:59         ` Andy Shevchenko
2022-01-04 12:23     ` Sergey Shtylyov
2022-01-04 20:30   ` Sergey Shtylyov
2022-01-12 17:53   ` Sergey Shtylyov
2022-01-12 18:08     ` Marc Zyngier
2022-01-12 20:08       ` Sergey Shtylyov
2022-02-11 20:20       ` Sergey Shtylyov
2022-01-12 18:19     ` Greg Kroah-Hartman [this message]
2022-01-12 20:20       ` Sergey Shtylyov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Yd8bq7sZ3WNWruqM@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=rafael@kernel.org \
    --cc=s.shtylyov@omp.ru \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.