[Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Daniel Vetter]

In my very first KS I found the maintainership model presentations
(x86-tip & armsoc) rather interesting. And last year we've had an
ad-hoc discussion about group maintainership again. I think drm&i915
would be an interesting case since over the past year I've done some
changes which are at the edge of what's common in the kernel, and it
seems to work (at least for us) fairly well. I discussed this a bit
with a few folks at ELC San Diego too.

Short summary: i915 has now a two-level maintenance model with 2
maintainers (who take the blame) and 15 people who can push patches.
In a way a rather big group, but not so big that people don't all know
each another any more personally. We have some detailed docs about the
patch flow and expectations:

https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html

and about the dim tool used to support this all

https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html

But I think the more interesting bits are why I decided to try this
out, what I hoped would happen, what I feared might happen. And with 1
year of experience, what actually happens and what I think is needed
to make this work and an actual benefit over more traditional
maintainer models. And of course I'd like to compare notes with other
group maintainers.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Darren Hart]

On Wed, Jul 20, 2016 at 02:11:58PM +0200, Daniel Vetter wrote:
> In my very first KS I found the maintainership model presentations
> (x86-tip & armsoc) rather interesting. And last year we've had an
> ad-hoc discussion about group maintainership again. I think drm&i915
> would be an interesting case since over the past year I've done some
> changes which are at the edge of what's common in the kernel, and it
> seems to work (at least for us) fairly well. I discussed this a bit
> with a few folks at ELC San Diego too.
> 
> Short summary: i915 has now a two-level maintenance model with 2
> maintainers (who take the blame) and 15 people who can push patches.
> In a way a rather big group, but not so big that people don't all know
> each another any more personally. We have some detailed docs about the
> patch flow and expectations:
> 
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
> 
> and about the dim tool used to support this all
> 
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html
> 
> But I think the more interesting bits are why I decided to try this
> out, what I hoped would happen, what I feared might happen. And with 1
> year of experience, what actually happens and what I think is needed
> to make this work and an actual benefit over more traditional
> maintainer models. And of course I'd like to compare notes with other
> group maintainers.

I'd be interested in the discussion. I think having it would also serve to
minimize the differences between policies across subsystems (which is a common
topic people have raised with me).

-- 
Darren Hart
Intel Open Source Technology Center

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Daniel Vetter]

On Fri, Jul 22, 2016 at 10:02 PM, Darren Hart <dvhart@infradead.org> wrote:
> On Wed, Jul 20, 2016 at 02:11:58PM +0200, Daniel Vetter wrote:
>> In my very first KS I found the maintainership model presentations
>> (x86-tip & armsoc) rather interesting. And last year we've had an
>> ad-hoc discussion about group maintainership again. I think drm&i915
>> would be an interesting case since over the past year I've done some
>> changes which are at the edge of what's common in the kernel, and it
>> seems to work (at least for us) fairly well. I discussed this a bit
>> with a few folks at ELC San Diego too.
>>
>> Short summary: i915 has now a two-level maintenance model with 2
>> maintainers (who take the blame) and 15 people who can push patches.
>> In a way a rather big group, but not so big that people don't all know
>> each another any more personally. We have some detailed docs about the
>> patch flow and expectations:
>>
>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
>>
>> and about the dim tool used to support this all
>>
>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html
>>
>> But I think the more interesting bits are why I decided to try this
>> out, what I hoped would happen, what I feared might happen. And with 1
>> year of experience, what actually happens and what I think is needed
>> to make this work and an actual benefit over more traditional
>> maintainer models. And of course I'd like to compare notes with other
>> group maintainers.
>
> I'd be interested in the discussion. I think having it would also serve to
> minimize the differences between policies across subsystems (which is a common
> topic people have raised with me).

Not sure I'm helping, since I think this new i915 model makes the
spread in different policies worse ;-) What do you have in mind here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Darren Hart]

On Mon, Jul 25, 2016 at 07:57:04AM +0200, Daniel Vetter wrote:
> On Fri, Jul 22, 2016 at 10:02 PM, Darren Hart <dvhart@infradead.org> wrote:
> > On Wed, Jul 20, 2016 at 02:11:58PM +0200, Daniel Vetter wrote:
> >> In my very first KS I found the maintainership model presentations
> >> (x86-tip & armsoc) rather interesting. And last year we've had an
> >> ad-hoc discussion about group maintainership again. I think drm&i915
> >> would be an interesting case since over the past year I've done some
> >> changes which are at the edge of what's common in the kernel, and it
> >> seems to work (at least for us) fairly well. I discussed this a bit
> >> with a few folks at ELC San Diego too.
> >>
> >> Short summary: i915 has now a two-level maintenance model with 2
> >> maintainers (who take the blame) and 15 people who can push patches.
> >> In a way a rather big group, but not so big that people don't all know
> >> each another any more personally. We have some detailed docs about the
> >> patch flow and expectations:
> >>
> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
> >>
> >> and about the dim tool used to support this all
> >>
> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html
> >>
> >> But I think the more interesting bits are why I decided to try this
> >> out, what I hoped would happen, what I feared might happen. And with 1
> >> year of experience, what actually happens and what I think is needed
> >> to make this work and an actual benefit over more traditional
> >> maintainer models. And of course I'd like to compare notes with other
> >> group maintainers.
> >
> > I'd be interested in the discussion. I think having it would also serve to
> > minimize the differences between policies across subsystems (which is a common
> > topic people have raised with me).
> 
> Not sure I'm helping, since I think this new i915 model makes the
> spread in different policies worse ;-) What do you have in mind here?

Just talking about what maintainers are doing, which is always evolving, will
help keep us in sync, and adopting improved methods.

-- 
Darren Hart
Intel Open Source Technology Center

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Bjorn Helgaas]

On Tue, Jul 26, 2016 at 11:22 AM, Darren Hart <dvhart@infradead.org> wrote:
> On Mon, Jul 25, 2016 at 07:57:04AM +0200, Daniel Vetter wrote:
>> On Fri, Jul 22, 2016 at 10:02 PM, Darren Hart <dvhart@infradead.org> wrote:
>> > On Wed, Jul 20, 2016 at 02:11:58PM +0200, Daniel Vetter wrote:
>> >> In my very first KS I found the maintainership model presentations
>> >> (x86-tip & armsoc) rather interesting. And last year we've had an
>> >> ad-hoc discussion about group maintainership again. I think drm&i915
>> >> would be an interesting case since over the past year I've done some
>> >> changes which are at the edge of what's common in the kernel, and it
>> >> seems to work (at least for us) fairly well. I discussed this a bit
>> >> with a few folks at ELC San Diego too.
>> >>
>> >> Short summary: i915 has now a two-level maintenance model with 2
>> >> maintainers (who take the blame) and 15 people who can push patches.
>> >> In a way a rather big group, but not so big that people don't all know
>> >> each another any more personally. We have some detailed docs about the
>> >> patch flow and expectations:
>> >>
>> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
>> >>
>> >> and about the dim tool used to support this all
>> >>
>> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html
>> >>
>> >> But I think the more interesting bits are why I decided to try this
>> >> out, what I hoped would happen, what I feared might happen. And with 1
>> >> year of experience, what actually happens and what I think is needed
>> >> to make this work and an actual benefit over more traditional
>> >> maintainer models. And of course I'd like to compare notes with other
>> >> group maintainers.
>> >
>> > I'd be interested in the discussion. I think having it would also serve to
>> > minimize the differences between policies across subsystems (which is a common
>> > topic people have raised with me).
>>
>> Not sure I'm helping, since I think this new i915 model makes the
>> spread in different policies worse ;-) What do you have in mind here?
>
> Just talking about what maintainers are doing, which is always evolving, will
> help keep us in sync, and adopting improved methods.

I'm interested in this discussion, since I still work with stone
knives and bearskins.

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Olof Johansson]

Hi,

On Wed, Jul 20, 2016 at 5:11 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> In my very first KS I found the maintainership model presentations
> (x86-tip & armsoc) rather interesting. And last year we've had an
> ad-hoc discussion about group maintainership again. I think drm&i915
> would be an interesting case since over the past year I've done some
> changes which are at the edge of what's common in the kernel, and it
> seems to work (at least for us) fairly well. I discussed this a bit
> with a few folks at ELC San Diego too.
>
> Short summary: i915 has now a two-level maintenance model with 2
> maintainers (who take the blame) and 15 people who can push patches.
> In a way a rather big group, but not so big that people don't all know
> each another any more personally. We have some detailed docs about the
> patch flow and expectations:
>
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
>
> and about the dim tool used to support this all
>
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html
>
> But I think the more interesting bits are why I decided to try this
> out, what I hoped would happen, what I feared might happen. And with 1
> year of experience, what actually happens and what I think is needed
> to make this work and an actual benefit over more traditional
> maintainer models. And of course I'd like to compare notes with other
> group maintainers.

Very interested in participating here, for obvious reasons -- learning
from others how we can do things even better as well as sharing how
things are working for us, 5 years into the endeavor.

One thing we're low on for arm-soc is tooling, I know the x86 guys
have quite a bit more than we do in this area, so ideas on what we can
do to make our own lives easier is valuable.


-Olof

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Vinod Koul]

On Tue, Jul 26, 2016 at 09:45:35AM -0700, Olof Johansson wrote:
> Hi,
> 
> On Wed, Jul 20, 2016 at 5:11 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > But I think the more interesting bits are why I decided to try this
> > out, what I hoped would happen, what I feared might happen. And with 1
> > year of experience, what actually happens and what I think is needed
> > to make this work and an actual benefit over more traditional
> > maintainer models. And of course I'd like to compare notes with other
> > group maintainers.
> 
> Very interested in participating here, for obvious reasons -- learning
> from others how we can do things even better as well as sharing how
> things are working for us, 5 years into the endeavor.

Am interested in this discussion as well for very obvious reasons

> One thing we're low on for arm-soc is tooling, I know the x86 guys
> have quite a bit more than we do in this area, so ideas on what we can
> do to make our own lives easier is valuable.

Okay one of the gripes I have is that it is a bit hard to compile arm
drivers. I regularly compile all drivers in subsystem I maintain and arm
ones are not always straightforward. Figuring our which config to use
for compile testing involves a bit of time, which I would like to avoid.

Having said that stuff like multi_xx_defconfig has improved a bit and
seem to be in right direction (not an expert at arm arch's) but doesn't
seem to cover all. Right now I am manually maintaining 4 different arm
configs to compile test all the drivers in dmaengine subsystem which
isn't a very big subsystem. For other arch's it is one config per
subsystem.

So if you have suggestions to improve my flow, I would like to hear
that, maybe I am doing something not right here...

-- 
~Vinod

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 988 bytes --]

> Okay one of the gripes I have is that it is a bit hard to compile arm
> drivers. I regularly compile all drivers in subsystem I maintain and arm
> ones are not always straightforward. Figuring our which config to use
> for compile testing involves a bit of time, which I would like to avoid.
...
> So if you have suggestions to improve my flow, I would like to hear
> that, maybe I am doing something not right here...

What I do to here when reviewing i2c patches:

- at rc1 time, decompress all configs to somewhere
- if a driver fails to build with the current config
	- get the filenames from the patch and assume .o are the objs
	- parse Makefiles for those obj files and hope there is
	  a obj-$(CONFIG_xy)=<obj> attached to it
	- grep my decompressed configs for the CONFIG_xy symbol
- use the found config

Doesn't work 100% of course, but good enough for me. Also, the rise of
COMPILE_TEST really helps that some config will do, so I encourage using
it.

Regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Arnd Bergmann]

On Wednesday, July 27, 2016 8:34:06 AM CEST Vinod Koul wrote:
> > One thing we're low on for arm-soc is tooling, I know the x86 guys
> > have quite a bit more than we do in this area, so ideas on what we can
> > do to make our own lives easier is valuable.
> 
> Okay one of the gripes I have is that it is a bit hard to compile arm
> drivers. I regularly compile all drivers in subsystem I maintain and arm
> ones are not always straightforward. Figuring our which config to use
> for compile testing involves a bit of time, which I would like to avoid.
> 
> Having said that stuff like multi_xx_defconfig has improved a bit and
> seem to be in right direction (not an expert at arm arch's) but doesn't
> seem to cover all. Right now I am manually maintaining 4 different arm
> configs to compile test all the drivers in dmaengine subsystem which
> isn't a very big subsystem. For other arch's it is one config per
> subsystem.
> 
> So if you have suggestions to improve my flow, I would like to hear
> that, maybe I am doing something not right here...

We should be at the point where an 'allmodconfig' build on ARM
gets you most of the drivers and builds without warnings (using
gcc-4.9 or higher).

It will take a while to do the entire 'allmodconfig' build but
it's something that can be done as a background task.

One thing that we should still do is figure out which ARM specific
drivers are not included in allmodconfig and find a way to include
them too. Most platforms are compatible with a 'multiplatform'
setup (those that are not very rarely see patches at all and are
less likely to break), but allmodconfig will only include ARMv6
and ARMv7 based platforms, not ARMv4/ARMv4T/ARMv5. I've thought
about adding '|| COMPILE_TEST' dependencies to the platforms
with ARMv4/5 CPUs to have everything included in allmodconfig, but
I haven't actually tied that and I'm sure we'd see a lot of
build failures for correct code at first that we'd have to fix up
to make it work.

	Arnd

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Vinod Koul]

On Wed, Jul 27, 2016 at 09:53:24AM +0200, Arnd Bergmann wrote:
> On Wednesday, July 27, 2016 8:34:06 AM CEST Vinod Koul wrote:
> > > One thing we're low on for arm-soc is tooling, I know the x86 guys
> > > have quite a bit more than we do in this area, so ideas on what we can
> > > do to make our own lives easier is valuable.
> > 
> > Okay one of the gripes I have is that it is a bit hard to compile arm
> > drivers. I regularly compile all drivers in subsystem I maintain and arm
> > ones are not always straightforward. Figuring our which config to use
> > for compile testing involves a bit of time, which I would like to avoid.
> > 
> > Having said that stuff like multi_xx_defconfig has improved a bit and
> > seem to be in right direction (not an expert at arm arch's) but doesn't
> > seem to cover all. Right now I am manually maintaining 4 different arm
> > configs to compile test all the drivers in dmaengine subsystem which
> > isn't a very big subsystem. For other arch's it is one config per
> > subsystem.
> > 
> > So if you have suggestions to improve my flow, I would like to hear
> > that, maybe I am doing something not right here...
> 
> We should be at the point where an 'allmodconfig' build on ARM
> gets you most of the drivers and builds without warnings (using
> gcc-4.9 or higher).

The problem is drivers depend on various ARM sub arch's. That is the
sole reason why I have multiple configs now.

> It will take a while to do the entire 'allmodconfig' build but
> it's something that can be done as a background task.
> 
> One thing that we should still do is figure out which ARM specific
> drivers are not included in allmodconfig and find a way to include
> them too. Most platforms are compatible with a 'multiplatform'
> setup (those that are not very rarely see patches at all and are
> less likely to break), but allmodconfig will only include ARMv6
> and ARMv7 based platforms, not ARMv4/ARMv4T/ARMv5. I've thought
> about adding '|| COMPILE_TEST' dependencies to the platforms
> with ARMv4/5 CPUs to have everything included in allmodconfig, but
> I haven't actually tied that and I'm sure we'd see a lot of
> build failures for correct code at first that we'd have to fix up
> to make it work.

Which brings me to another problem :-) why should individual drivers
depend on ARM sub arch's. Depends on ARM, yes. First look at code tells
me they shouldn't!, probably sometime back that was true, but I don't
think that should be the case now, ofcourse you would know better!

And yes some are ARMv4/v5 ones..

-- 
~Vinod

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

On Wed, Jul 27, 2016 at 06:27:51PM +0530, Vinod Koul wrote:
> On Wed, Jul 27, 2016 at 09:53:24AM +0200, Arnd Bergmann wrote:

> > We should be at the point where an 'allmodconfig' build on ARM
> > gets you most of the drivers and builds without warnings (using
> > gcc-4.9 or higher).

> The problem is drivers depend on various ARM sub arch's. That is the
> sole reason why I have multiple configs now.

That shouldn't be the case at least for any new code, things should at
least build OK with an || COMPILE_TEST normally.  Old code may need
fixing up for this.

> Which brings me to another problem :-) why should individual drivers
> depend on ARM sub arch's. Depends on ARM, yes. First look at code tells
> me they shouldn't!, probably sometime back that was true, but I don't
> think that should be the case now, ofcourse you would know better!

The dependencies are there to improve UX when people are configuring
their kernels - it stops them being asked about hardware they can't
possibly have in their system.  If there's no build time reason for it
then it should be (ARCH_FOO || COMPILE_TEST) so people can do build
tests.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Vinod Koul]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

On Wed, Jul 27, 2016 at 03:22:21PM +0100, Mark Brown wrote:
> On Wed, Jul 27, 2016 at 06:27:51PM +0530, Vinod Koul wrote:
> > On Wed, Jul 27, 2016 at 09:53:24AM +0200, Arnd Bergmann wrote:
> 
> > > We should be at the point where an 'allmodconfig' build on ARM
> > > gets you most of the drivers and builds without warnings (using
> > > gcc-4.9 or higher).
> 
> > The problem is drivers depend on various ARM sub arch's. That is the
> > sole reason why I have multiple configs now.
> 
> That shouldn't be the case at least for any new code, things should at
> least build OK with an || COMPILE_TEST normally.  Old code may need
> fixing up for this.

That's right, this is problematic mostly with older code and for ARMv5 and
below. As I said later code & sub-ARCHs seems to be well covered with
current multi-vx-configs...

> > Which brings me to another problem :-) why should individual drivers
> > depend on ARM sub arch's. Depends on ARM, yes. First look at code tells
> > me they shouldn't!, probably sometime back that was true, but I don't
> > think that should be the case now, ofcourse you would know better!
> 
> The dependencies are there to improve UX when people are configuring
> their kernels - it stops them being asked about hardware they can't
> possibly have in their system.  If there's no build time reason for it
> then it should be (ARCH_FOO || COMPILE_TEST) so people can do build
> tests.

That is a valid point as well. This seems better suggestion to me.

-- 
~Vinod

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Arnd Bergmann]

On Wednesday, July 27, 2016 10:45:51 PM CEST Vinod Koul wrote:
> On Wed, Jul 27, 2016 at 03:22:21PM +0100, Mark Brown wrote:
> > On Wed, Jul 27, 2016 at 06:27:51PM +0530, Vinod Koul wrote:
> > > On Wed, Jul 27, 2016 at 09:53:24AM +0200, Arnd Bergmann wrote:
> > 
> > > > We should be at the point where an 'allmodconfig' build on ARM
> > > > gets you most of the drivers and builds without warnings (using
> > > > gcc-4.9 or higher).
> > 
> > > The problem is drivers depend on various ARM sub arch's. That is the
> > > sole reason why I have multiple configs now.
> > 
> > That shouldn't be the case at least for any new code, things should at
> > least build OK with an || COMPILE_TEST normally.  Old code may need
> > fixing up for this.
> 
> That's right, this is problematic mostly with older code and for ARMv5 and
> below. As I said later code & sub-ARCHs seems to be well covered with
> current multi-vx-configs...
>
> > > Which brings me to another problem  why should individual drivers
> > > depend on ARM sub arch's. Depends on ARM, yes. First look at code tells
> > > me they shouldn't!, probably sometime back that was true, but I don't
> > > think that should be the case now, ofcourse you would know better!
> > 
> > The dependencies are there to improve UX when people are configuring
> > their kernels - it stops them being asked about hardware they can't
> > possibly have in their system.  If there's no build time reason for it
> > then it should be (ARCH_FOO || COMPILE_TEST) so people can do build
> > tests.
> 
> That is a valid point as well. This seems better suggestion to me.

Unfortunately, we have too many different ways of handling this, and
the preferred style differs by subsystem. The style that Mark
mentioned is particularly nice and concise:

config FOO
	bool "foo driver"
	depends on ARCH_FOO || COMPILE_TEST
	depends on GPIOLIB && I2C && OF && WHATEVER

These days we should rarely need a 'depends on ARM || PPC' statement
in there, but it's very common to limit drivers by architecture as
well for historic reasons.

For old drivers, we often have

config FOO
	bool "foo driver"
	depends on ARCH_FOO

and this used to be a compile-time requirement as each ARM platform
had their own headers, but now this is only needed (on ARM) for
really old platforms that will remain like this (strongarm, ixp4xx,
iop, ...) or those that are a little more recent but still in the
long process of being converted (omap1, davinci, lpc32xx, ep93xx, ...).
On other architectures (MIPS, sh, avr32, ...) this is however much
more common.

We have had a couple of per-subsystem efforts to identify the drivers
that actually build on other architectures and add the '|| COMPILE_TEST'
statements. This typically causes a few regressions initially and then
just works.

Some subsystems have essential drivers without which a platform cannot
work (clock, irqchip, reset, ...) and those often don't allow the
driver to be user-selectable at all. I'd like to see more of those
get enabled for COMPILE_TEST, but the Kconfig statement for this
is rather unintuitive:

config FOO
	bool "foo driver" if COMPILE_TEST && !ARCH_FOO
	default ARCH_FOO
	depends on GPIOLIB && I2C && OF && WHATEVER

This becomes a silent always-on symbol if the platform is used,
and user-selectable on every other platform with COMPILE_TEST.

	Arnd

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Alexandre Belloni]

Hi,

On 28/07/2016 at 10:44:23 +0200, Arnd Bergmann wrote :
> Some subsystems have essential drivers without which a platform cannot
> work (clock, irqchip, reset, ...) and those often don't allow the
> driver to be user-selectable at all. I'd like to see more of those
> get enabled for COMPILE_TEST, but the Kconfig statement for this
> is rather unintuitive:
> 
> config FOO
> 	bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> 	default ARCH_FOO
> 	depends on GPIOLIB && I2C && OF && WHATEVER
> 
> This becomes a silent always-on symbol if the platform is used,
> and user-selectable on every other platform with COMPILE_TEST.
> 

Note that some maintainers prefer having the symbol selected directly
from ARCH_FOO or SOC_FOO instead of defaulting to it which may be more
explicit. I'm fine with both but my subsystem is not exactly essential
;)

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Stephen Rothwell]

Hi Alexandre,

On Fri, 29 Jul 2016 01:48:23 +0200 Alexandre Belloni <alexandre.belloni@free-electrons.com> wrote:
>
> On 28/07/2016 at 10:44:23 +0200, Arnd Bergmann wrote :
> > Some subsystems have essential drivers without which a platform cannot
> > work (clock, irqchip, reset, ...) and those often don't allow the
> > driver to be user-selectable at all. I'd like to see more of those
> > get enabled for COMPILE_TEST, but the Kconfig statement for this
> > is rather unintuitive:
> > 
> > config FOO
> > 	bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> > 	default ARCH_FOO
> > 	depends on GPIOLIB && I2C && OF && WHATEVER
> > 
> > This becomes a silent always-on symbol if the platform is used,
> > and user-selectable on every other platform with COMPILE_TEST.
> >   
> 
> Note that some maintainers prefer having the symbol selected directly
> from ARCH_FOO or SOC_FOO instead of defaulting to it which may be more
> explicit. I'm fine with both but my subsystem is not exactly essential
> ;)

You should avoid, if at all possible, selecting any symbol that has
dependencies ...

-- 
Cheers,
Stephen Rothwell

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Vinod Koul]

On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
 
> config FOO
> 	bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> 	default ARCH_FOO
> 	depends on GPIOLIB && I2C && OF && WHATEVER
> 
> This becomes a silent always-on symbol if the platform is used,
> and user-selectable on every other platform with COMPILE_TEST.

Yeah this seems a bit more better. I am perhaps thinking to add top
level arch dependency if required. I will try this out on DMAengine to
start with and ease my build tests :)

-- 
~Vinod

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Arnd Bergmann]

On Sunday, July 31, 2016 11:27:53 PM CEST Vinod Koul wrote:
> On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
>  
> > config FOO
> >       bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> >       default ARCH_FOO
> >       depends on GPIOLIB && I2C && OF && WHATEVER
> > 
> > This becomes a silent always-on symbol if the platform is used,
> > and user-selectable on every other platform with COMPILE_TEST.
> 
> Yeah this seems a bit more better. I am perhaps thinking to add top
> level arch dependency if required. I will try this out on DMAengine to
> start with and ease my build tests 

Sounds good. Let me know if you end up having to add a 'depends on ARM'
dependency anywhere, as that might indicate that we are doing something
different on ARM that should be done in a more generic way.

	Arnd

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Laurent Pinchart]

On Monday 01 Aug 2016 08:56:30 Arnd Bergmann wrote:
> On Sunday, July 31, 2016 11:27:53 PM CEST Vinod Koul wrote:
> > On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
> > > config FOO
> > > 
> > >       bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> > >       default ARCH_FOO
> > >       depends on GPIOLIB && I2C && OF && WHATEVER
> > > 
> > > This becomes a silent always-on symbol if the platform is used,
> > > and user-selectable on every other platform with COMPILE_TEST.
> > 
> > Yeah this seems a bit more better. I am perhaps thinking to add top
> > level arch dependency if required. I will try this out on DMAengine to
> > start with and ease my build tests
> 
> Sounds good. Let me know if you end up having to add a 'depends on ARM'
> dependency anywhere, as that might indicate that we are doing something
> different on ARM that should be done in a more generic way.

OMAP DMA comes to mind, we still depend on the implementation provided by 
arch/arm/plat-omap/dma.c.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Arnd Bergmann]

On Monday, August 1, 2016 10:36:01 AM CEST Laurent Pinchart wrote:
> On Monday 01 Aug 2016 08:56:30 Arnd Bergmann wrote:
> > On Sunday, July 31, 2016 11:27:53 PM CEST Vinod Koul wrote:
> > > On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
> > > > config FOO
> > > > 
> > > >       bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> > > >       default ARCH_FOO
> > > >       depends on GPIOLIB && I2C && OF && WHATEVER
> > > > 
> > > > This becomes a silent always-on symbol if the platform is used,
> > > > and user-selectable on every other platform with COMPILE_TEST.
> > > 
> > > Yeah this seems a bit more better. I am perhaps thinking to add top
> > > level arch dependency if required. I will try this out on DMAengine to
> > > start with and ease my build tests
> > 
> > Sounds good. Let me know if you end up having to add a 'depends on ARM'
> > dependency anywhere, as that might indicate that we are doing something
> > different on ARM that should be done in a more generic way.
> 
> OMAP DMA comes to mind, we still depend on the implementation provided by 
> arch/arm/plat-omap/dma.c.

That's a dependency on MACH_OMAP instead of ARM though, which is a bit
different.

(Getting offtopic and) speaking of this one, is anyone working
on converting the last four or five drivers to the dmaengine framework?

drivers/media/platform/omap/omap_vout_vrfb.c
drivers/mtd/onenand/omap2.c
drivers/usb/gadget/udc/omap_udc.c
drivers/usb/musb/tusb6010_omap.c
(and a bit of drivers/video/fbdev/omap/omapfb_main.c)

I guess we could improve build coverage by moving 
arch/arm/plat-omap/dma.c into drivers/dma/omap-dma.c, but that
has the disadvantage of exposing a nonstandard interface from
somewhere inside of the dmaengine subsystem.

	Arnd

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Vinod Koul]

On Mon, Aug 01, 2016 at 04:10:29PM +0200, Arnd Bergmann wrote:
> On Monday, August 1, 2016 10:36:01 AM CEST Laurent Pinchart wrote:
> > On Monday 01 Aug 2016 08:56:30 Arnd Bergmann wrote:
> > > On Sunday, July 31, 2016 11:27:53 PM CEST Vinod Koul wrote:
> > > > On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
> > > > > config FOO
> > > > > 
> > > > >       bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> > > > >       default ARCH_FOO
> > > > >       depends on GPIOLIB && I2C && OF && WHATEVER
> > > > > 
> > > > > This becomes a silent always-on symbol if the platform is used,
> > > > > and user-selectable on every other platform with COMPILE_TEST.
> > > > 
> > > > Yeah this seems a bit more better. I am perhaps thinking to add top
> > > > level arch dependency if required. I will try this out on DMAengine to
> > > > start with and ease my build tests
> > > 
> > > Sounds good. Let me know if you end up having to add a 'depends on ARM'
> > > dependency anywhere, as that might indicate that we are doing something
> > > different on ARM that should be done in a more generic way.
> > 
> > OMAP DMA comes to mind, we still depend on the implementation provided by 
> > arch/arm/plat-omap/dma.c.
> 
> That's a dependency on MACH_OMAP instead of ARM though, which is a bit
> different.
> 
> (Getting offtopic and) speaking of this one, is anyone working
> on converting the last four or five drivers to the dmaengine framework?

Rather lets' move this conversation to dmaengine list?

> drivers/media/platform/omap/omap_vout_vrfb.c
> drivers/mtd/onenand/omap2.c
> drivers/usb/gadget/udc/omap_udc.c
> drivers/usb/musb/tusb6010_omap.c
> (and a bit of drivers/video/fbdev/omap/omapfb_main.c)

Peter?

> 
> I guess we could improve build coverage by moving 
> arch/arm/plat-omap/dma.c into drivers/dma/omap-dma.c, but that
> has the disadvantage of exposing a nonstandard interface from
> somewhere inside of the dmaengine subsystem.

yeah that won't be nice. I think we should get these removed... We have omap
as well as edma driver in dmaengine.

-- 
~Vinod

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Peter Ujfalusi]

On 08/02/16 07:46, Vinod Koul wrote:
> On Mon, Aug 01, 2016 at 04:10:29PM +0200, Arnd Bergmann wrote:
>> On Monday, August 1, 2016 10:36:01 AM CEST Laurent Pinchart wrote:
>>> On Monday 01 Aug 2016 08:56:30 Arnd Bergmann wrote:
>>>> On Sunday, July 31, 2016 11:27:53 PM CEST Vinod Koul wrote:
>>>>> On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
>>>>>> config FOO
>>>>>>
>>>>>>       bool "foo driver" if COMPILE_TEST && !ARCH_FOO
>>>>>>       default ARCH_FOO
>>>>>>       depends on GPIOLIB && I2C && OF && WHATEVER
>>>>>>
>>>>>> This becomes a silent always-on symbol if the platform is used,
>>>>>> and user-selectable on every other platform with COMPILE_TEST.
>>>>>
>>>>> Yeah this seems a bit more better. I am perhaps thinking to add top
>>>>> level arch dependency if required. I will try this out on DMAengine to
>>>>> start with and ease my build tests
>>>>
>>>> Sounds good. Let me know if you end up having to add a 'depends on ARM'
>>>> dependency anywhere, as that might indicate that we are doing something
>>>> different on ARM that should be done in a more generic way.
>>>
>>> OMAP DMA comes to mind, we still depend on the implementation provided by 
>>> arch/arm/plat-omap/dma.c.
>>
>> That's a dependency on MACH_OMAP instead of ARM though, which is a bit
>> different.
>>
>> (Getting offtopic and) speaking of this one, is anyone working
>> on converting the last four or five drivers to the dmaengine framework?
> 
> Rather lets' move this conversation to dmaengine list?
> 
>> drivers/media/platform/omap/omap_vout_vrfb.c

Needs the interleaved transfer type support in omap-dma. Now it is in -next.

>> drivers/mtd/onenand/omap2.c

Using memcpy, I have sent the patches:
https://patchwork.kernel.org/patch/7842891/
https://patchwork.kernel.org/patch/7851881/

but I need to revisit. I think the 'fix' will be to drop the DMA support from it.

>> drivers/usb/gadget/udc/omap_udc.c
>> drivers/usb/musb/tusb6010_omap.c

They are mostly slave implementations, but. As I recall they do some really
interesting non symmetric setup for the TX/RX DMA which I still need to figure
out. And I'm looking for HW to check for regression...

>> (and a bit of drivers/video/fbdev/omap/omapfb_main.c)

Hrm, that is OMAP1. Looks like highly coupled with mach-omap1/lcd_dma.c. This
is going to be a bit complicated IMHO.

> 
> Peter?
> 
>>
>> I guess we could improve build coverage by moving 
>> arch/arm/plat-omap/dma.c into drivers/dma/omap-dma.c, but that
>> has the disadvantage of exposing a nonstandard interface from
>> somewhere inside of the dmaengine subsystem.
> 
> yeah that won't be nice. I think we should get these removed... We have omap
> as well as edma driver in dmaengine.

I'm not going to move the legacy API under dmaengine, it makes no sense.

My plan is to do what I did with the eDMA driver stack:
- convert drivers using the legacy API to dmaengine
- 'merge' the code from plat-omap to the dmaengine driver
  - while doing this the legacy API will vanish along with the plat-omap/dma.c

As with the eDMA, the sDMA stack will need some cleanup, but the good thing is
that the dmaengine driver have minimal dependency on the legacy
plat-omap/dma.c API.

-- 
Péter

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Arnd Bergmann]

On Tuesday, August 2, 2016 9:48:53 AM CEST Peter Ujfalusi wrote:
> On 08/02/16 07:46, Vinod Koul wrote:
> > On Mon, Aug 01, 2016 at 04:10:29PM +0200, Arnd Bergmann wrote:
> >> On Monday, August 1, 2016 10:36:01 AM CEST Laurent Pinchart wrote:
> >>> On Monday 01 Aug 2016 08:56:30 Arnd Bergmann wrote:
> >>>> On Sunday, July 31, 2016 11:27:53 PM CEST Vinod Koul wrote:
> >>>>> On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
> >>>>>> config FOO
> >>>>>>
> >>>>>>       bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> >>>>>>       default ARCH_FOO
> >>>>>>       depends on GPIOLIB && I2C && OF && WHATEVER
> >>>>>>
> >>>>>> This becomes a silent always-on symbol if the platform is used,
> >>>>>> and user-selectable on every other platform with COMPILE_TEST.
> >>>>>
> >>>>> Yeah this seems a bit more better. I am perhaps thinking to add top
> >>>>> level arch dependency if required. I will try this out on DMAengine to
> >>>>> start with and ease my build tests
> >>>>
> >>>> Sounds good. Let me know if you end up having to add a 'depends on ARM'
> >>>> dependency anywhere, as that might indicate that we are doing something
> >>>> different on ARM that should be done in a more generic way.
> >>>
> >>> OMAP DMA comes to mind, we still depend on the implementation provided by 
> >>> arch/arm/plat-omap/dma.c.
> >>
> >> That's a dependency on MACH_OMAP instead of ARM though, which is a bit
> >> different.
> >>
> >> (Getting offtopic and) speaking of this one, is anyone working
> >> on converting the last four or five drivers to the dmaengine framework?
> > 
> > Rather lets' move this conversation to dmaengine list?
> > 
> >> drivers/media/platform/omap/omap_vout_vrfb.c
> 
> Needs the interleaved transfer type support in omap-dma. Now it is in -next.

Ok

> >> drivers/mtd/onenand/omap2.c
> 
> Using memcpy, I have sent the patches:
> https://patchwork.kernel.org/patch/7842891/
> https://patchwork.kernel.org/patch/7851881/
> 
> but I need to revisit. I think the 'fix' will be to drop the DMA support from it.

Sounds like it might even possible to remove the entire driver based
on that thread.

> >> drivers/usb/gadget/udc/omap_udc.c
> >> drivers/usb/musb/tusb6010_omap.c
> 
> They are mostly slave implementations, but. As I recall they do some really
> interesting non symmetric setup for the TX/RX DMA which I still need to figure
> out. And I'm looking for HW to check for regression...

Ok

> >> (and a bit of drivers/video/fbdev/omap/omapfb_main.c)
> 
> Hrm, that is OMAP1. Looks like highly coupled with mach-omap1/lcd_dma.c. This
> is going to be a bit complicated IMHO.

It's just a single function call: 

omap_set_dma_priority(0, OMAP_DMA_PORT_EMIFF, 15);

We can probably open-code that in mach-omap1/lcd_dma.c and
have a callback pointer in the platform_data.

> >> I guess we could improve build coverage by moving 
> >> arch/arm/plat-omap/dma.c into drivers/dma/omap-dma.c, but that
> >> has the disadvantage of exposing a nonstandard interface from
> >> somewhere inside of the dmaengine subsystem.
> > 
> > yeah that won't be nice. I think we should get these removed... We have omap
> > as well as edma driver in dmaengine.
> 
> I'm not going to move the legacy API under dmaengine, it makes no sense.
> 
> My plan is to do what I did with the eDMA driver stack:
> - convert drivers using the legacy API to dmaengine
> - 'merge' the code from plat-omap to the dmaengine driver
>   - while doing this the legacy API will vanish along with the plat-omap/dma.c
> 
> As with the eDMA, the sDMA stack will need some cleanup, but the good thing is
> that the dmaengine driver have minimal dependency on the legacy
> plat-omap/dma.c API.

Ok, thanks for the background information. I agree on the approach, this
is the right way to do it. I just wasn't sure if there was someone actually
working on it, and it's clear that you are, even if it will take a while.

	Arnd

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Peter Ujfalusi]

On 08/02/16 10:27, Arnd Bergmann wrote:
> On Tuesday, August 2, 2016 9:48:53 AM CEST Peter Ujfalusi wrote:
>> On 08/02/16 07:46, Vinod Koul wrote:
>>> On Mon, Aug 01, 2016 at 04:10:29PM +0200, Arnd Bergmann wrote:
>>>> On Monday, August 1, 2016 10:36:01 AM CEST Laurent Pinchart wrote:
>>>>> On Monday 01 Aug 2016 08:56:30 Arnd Bergmann wrote:
>>>>>> On Sunday, July 31, 2016 11:27:53 PM CEST Vinod Koul wrote:
>>>>>>> On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
>>>>>>>> config FOO
>>>>>>>>
>>>>>>>>       bool "foo driver" if COMPILE_TEST && !ARCH_FOO
>>>>>>>>       default ARCH_FOO
>>>>>>>>       depends on GPIOLIB && I2C && OF && WHATEVER
>>>>>>>>
>>>>>>>> This becomes a silent always-on symbol if the platform is used,
>>>>>>>> and user-selectable on every other platform with COMPILE_TEST.
>>>>>>>
>>>>>>> Yeah this seems a bit more better. I am perhaps thinking to add top
>>>>>>> level arch dependency if required. I will try this out on DMAengine to
>>>>>>> start with and ease my build tests
>>>>>>
>>>>>> Sounds good. Let me know if you end up having to add a 'depends on ARM'
>>>>>> dependency anywhere, as that might indicate that we are doing something
>>>>>> different on ARM that should be done in a more generic way.
>>>>>
>>>>> OMAP DMA comes to mind, we still depend on the implementation provided by 
>>>>> arch/arm/plat-omap/dma.c.
>>>>
>>>> That's a dependency on MACH_OMAP instead of ARM though, which is a bit
>>>> different.
>>>>
>>>> (Getting offtopic and) speaking of this one, is anyone working
>>>> on converting the last four or five drivers to the dmaengine framework?
>>>
>>> Rather lets' move this conversation to dmaengine list?
>>>
>>>> drivers/media/platform/omap/omap_vout_vrfb.c
>>
>> Needs the interleaved transfer type support in omap-dma. Now it is in -next.
> 
> Ok
> 
>>>> drivers/mtd/onenand/omap2.c
>>
>> Using memcpy, I have sent the patches:
>> https://patchwork.kernel.org/patch/7842891/
>> https://patchwork.kernel.org/patch/7851881/
>>
>> but I need to revisit. I think the 'fix' will be to drop the DMA support from it.
> 
> Sounds like it might even possible to remove the entire driver based
> on that thread.
> 
>>>> drivers/usb/gadget/udc/omap_udc.c
>>>> drivers/usb/musb/tusb6010_omap.c
>>
>> They are mostly slave implementations, but. As I recall they do some really
>> interesting non symmetric setup for the TX/RX DMA which I still need to figure
>> out. And I'm looking for HW to check for regression...
> 
> Ok
> 
>>>> (and a bit of drivers/video/fbdev/omap/omapfb_main.c)
>>
>> Hrm, that is OMAP1. Looks like highly coupled with mach-omap1/lcd_dma.c. This
>> is going to be a bit complicated IMHO.
> 
> It's just a single function call: 
> 
> omap_set_dma_priority(0, OMAP_DMA_PORT_EMIFF, 15);
> 
> We can probably open-code that in mach-omap1/lcd_dma.c and
> have a callback pointer in the platform_data.

Looking at the omap_set_dma_priority(), it will grant high priority for _all_
DMA access via EMIFF (or EMIFS, OCPT1, OCPT2). It is global priority over
targets. The same register is used to give 'priority' to OCPI, DMA, DSP or MPU
masters.
The whole priority configuration should get it's own API, something like:
omap1_set_ocpi_priority(master, target, priority);

I will see what is the best when I get to this.

>>>> I guess we could improve build coverage by moving 
>>>> arch/arm/plat-omap/dma.c into drivers/dma/omap-dma.c, but that
>>>> has the disadvantage of exposing a nonstandard interface from
>>>> somewhere inside of the dmaengine subsystem.
>>>
>>> yeah that won't be nice. I think we should get these removed... We have omap
>>> as well as edma driver in dmaengine.
>>
>> I'm not going to move the legacy API under dmaengine, it makes no sense.
>>
>> My plan is to do what I did with the eDMA driver stack:
>> - convert drivers using the legacy API to dmaengine
>> - 'merge' the code from plat-omap to the dmaengine driver
>>   - while doing this the legacy API will vanish along with the plat-omap/dma.c
>>
>> As with the eDMA, the sDMA stack will need some cleanup, but the good thing is
>> that the dmaengine driver have minimal dependency on the legacy
>> plat-omap/dma.c API.
> 
> Ok, thanks for the background information. I agree on the approach, this
> is the right way to do it. I just wasn't sure if there was someone actually
> working on it, and it's clear that you are, even if it will take a while.

The eDMA got higher priority over the sDMA. Now that we have interleaved
support via omap-dma, we can start working on this. Only the most problematic
drivers were left to convert (or the ones no one cares about?).

-- 
Péter

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Laurent Pinchart]

Hi Peter,

On Tuesday 02 Aug 2016 09:48:53 Peter Ujfalusi wrote:
> On 08/02/16 07:46, Vinod Koul wrote:
> > On Mon, Aug 01, 2016 at 04:10:29PM +0200, Arnd Bergmann wrote:
> >> On Monday, August 1, 2016 10:36:01 AM CEST Laurent Pinchart wrote:
> >>> On Monday 01 Aug 2016 08:56:30 Arnd Bergmann wrote:
> >>>> On Sunday, July 31, 2016 11:27:53 PM CEST Vinod Koul wrote:
> >>>>> On Thu, Jul 28, 2016 at 10:44:23AM +0200, Arnd Bergmann wrote:
> >>>>>> config FOO
> >>>>>> 
> >>>>>>       bool "foo driver" if COMPILE_TEST && !ARCH_FOO
> >>>>>>       default ARCH_FOO
> >>>>>>       depends on GPIOLIB && I2C && OF && WHATEVER
> >>>>>> 
> >>>>>> This becomes a silent always-on symbol if the platform is used,
> >>>>>> and user-selectable on every other platform with COMPILE_TEST.
> >>>>> 
> >>>>> Yeah this seems a bit more better. I am perhaps thinking to add top
> >>>>> level arch dependency if required. I will try this out on DMAengine to
> >>>>> start with and ease my build tests
> >>>> 
> >>>> Sounds good. Let me know if you end up having to add a 'depends on ARM'
> >>>> dependency anywhere, as that might indicate that we are doing something
> >>>> different on ARM that should be done in a more generic way.
> >>> 
> >>> OMAP DMA comes to mind, we still depend on the implementation provided
> >>> by arch/arm/plat-omap/dma.c.
> >> 
> >> That's a dependency on MACH_OMAP instead of ARM though, which is a bit
> >> different.
> >> 
> >> (Getting offtopic and) speaking of this one, is anyone working
> >> on converting the last four or five drivers to the dmaengine framework?
> > 
> > Rather lets' move this conversation to dmaengine list?
> > 
> >> drivers/media/platform/omap/omap_vout_vrfb.c
> 
> Needs the interleaved transfer type support in omap-dma. Now it is in -next.

Thank you for your work on this. When you'll have patches for 
omap_vout_vrfb.c, please let me know and I'll test them.

> >> drivers/mtd/onenand/omap2.c
> 
> Using memcpy, I have sent the patches:
> https://patchwork.kernel.org/patch/7842891/
> https://patchwork.kernel.org/patch/7851881/
> 
> but I need to revisit. I think the 'fix' will be to drop the DMA support
> from it.
> >> drivers/usb/gadget/udc/omap_udc.c
> >> drivers/usb/musb/tusb6010_omap.c
> 
> They are mostly slave implementations, but. As I recall they do some really
> interesting non symmetric setup for the TX/RX DMA which I still need to
> figure out. And I'm looking for HW to check for regression...
> 
> >> (and a bit of drivers/video/fbdev/omap/omapfb_main.c)
> 
> Hrm, that is OMAP1. Looks like highly coupled with mach-omap1/lcd_dma.c.
> This is going to be a bit complicated IMHO.
> 
> > Peter?
> > 
> >> I guess we could improve build coverage by moving
> >> arch/arm/plat-omap/dma.c into drivers/dma/omap-dma.c, but that
> >> has the disadvantage of exposing a nonstandard interface from
> >> somewhere inside of the dmaengine subsystem.
> > 
> > yeah that won't be nice. I think we should get these removed... We have
> > omap as well as edma driver in dmaengine.
> 
> I'm not going to move the legacy API under dmaengine, it makes no sense.
> 
> My plan is to do what I did with the eDMA driver stack:
> - convert drivers using the legacy API to dmaengine
> - 'merge' the code from plat-omap to the dmaengine driver
>   - while doing this the legacy API will vanish along with the
> plat-omap/dma.c
> 
> As with the eDMA, the sDMA stack will need some cleanup, but the good thing
> is that the dmaengine driver have minimal dependency on the legacy
> plat-omap/dma.c API.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Tony Lindgren]

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [160802 01:33]:
> On Tuesday 02 Aug 2016 09:48:53 Peter Ujfalusi wrote:
> > >> drivers/media/platform/omap/omap_vout_vrfb.c
> > 
> > Needs the interleaved transfer type support in omap-dma. Now it is in -next.
> 
> Thank you for your work on this. When you'll have patches for 
> omap_vout_vrfb.c, please let me know and I'll test them.
> 
> > >> drivers/mtd/onenand/omap2.c
> > 
> > Using memcpy, I have sent the patches:
> > https://patchwork.kernel.org/patch/7842891/
> > https://patchwork.kernel.org/patch/7851881/
> >
> > but I need to revisit. I think the 'fix' will be to drop the DMA support
> > from it.

Yeah let's remove the DMA support from onenand/omapp.c. It's
wrongly using GPIO line instead of the external DMA trigger
line, and already mostly disabled. I doubt that anybody will
miss the DMA support here.

> > >> drivers/usb/gadget/udc/omap_udc.c
> > >> drivers/usb/musb/tusb6010_omap.c
> > 
> > They are mostly slave implementations, but. As I recall they do some really
> > interesting non symmetric setup for the TX/RX DMA which I still need to
> > figure out. And I'm looking for HW to check for regression...

I think the omap_udc.c is also used for modems on omap4 based
phones?

The tusb6010_omap.c case is a very good test case with variable
size ping test over USB Ethernet :) It's probably also the only
mainline DMA test case for omap external DMA request pins, so I'd
rather have it updated,

> > >> (and a bit of drivers/video/fbdev/omap/omapfb_main.c)
> > 
> > Hrm, that is OMAP1. Looks like highly coupled with mach-omap1/lcd_dma.c.
> > This is going to be a bit complicated IMHO.
> > 
> > > Peter?
> > > 
> > >> I guess we could improve build coverage by moving
> > >> arch/arm/plat-omap/dma.c into drivers/dma/omap-dma.c, but that
> > >> has the disadvantage of exposing a nonstandard interface from
> > >> somewhere inside of the dmaengine subsystem.
> > > 
> > > yeah that won't be nice. I think we should get these removed... We have
> > > omap as well as edma driver in dmaengine.
> > 
> > I'm not going to move the legacy API under dmaengine, it makes no sense.
> > 
> > My plan is to do what I did with the eDMA driver stack:
> > - convert drivers using the legacy API to dmaengine
> > - 'merge' the code from plat-omap to the dmaengine driver
> >   - while doing this the legacy API will vanish along with the
> > plat-omap/dma.c
> > 
> > As with the eDMA, the sDMA stack will need some cleanup, but the good thing
> > is that the dmaengine driver have minimal dependency on the legacy
> > plat-omap/dma.c API.

We can move the omap1 legacy dma support to be mach-omap1 specific
once the problem drivers are fixed.

Regards,

Tony

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Russell King - ARM Linux]

On Tue, Aug 02, 2016 at 09:48:53AM +0300, Peter Ujfalusi wrote:
> I'm not going to move the legacy API under dmaengine, it makes no sense.
> 
> My plan is to do what I did with the eDMA driver stack:
> - convert drivers using the legacy API to dmaengine
> - 'merge' the code from plat-omap to the dmaengine driver
>   - while doing this the legacy API will vanish along with the plat-omap/dma.c
> 
> As with the eDMA, the sDMA stack will need some cleanup, but the good
> thing is that the dmaengine driver have minimal dependency on the legacy
> plat-omap/dma.c API.

I totally oppose moving arch/arm/plat-omap/dma.c into drivers/dma.
The omap-dma driver in drivers/dma is a replacement modern driver
for the legacy crap, and most users of the legacy crap have been
converted.

Why we still have users of the legacy crap is because:

(a) they don't fit into the DMA engine API very well
(b) I don't have hardware to be able to test them

and, because of that, I'm not going to start proposing DMA engine API
extensions to support something that I've no way to even test.

I've asked for help from TI on this when I was woring on the DMA
engine implementation, and there was no interest - it kept being
put back on me as something for me to sort.  It became an impossible
situation.

So, how things were left was that I'd introduce a warning into the
legacy driver, and in a few years time we'd strip it out of users
and delete the legacy driver.

The warning (which is rather large, because it's a WARN(), so
involves a kernel stack dump) has not produced (afaik) any complaints
from anyone.  So, we can probably conclude that any of these drivers
which are using the legacy DMA code are probably not being used.

This means we can save ourselves a lot of work and just delete all
these drivers using the legacy OMAP DMA along with the legacy OMAP
DMA driver.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Laurent Pinchart]

Hi Russell,

On Tuesday 02 Aug 2016 09:41:36 Russell King - ARM Linux wrote:
> On Tue, Aug 02, 2016 at 09:48:53AM +0300, Peter Ujfalusi wrote:
> > I'm not going to move the legacy API under dmaengine, it makes no sense.
> > 
> > My plan is to do what I did with the eDMA driver stack:
> > - convert drivers using the legacy API to dmaengine
> > - 'merge' the code from plat-omap to the dmaengine driver
> >   - while doing this the legacy API will vanish along with the
> >   plat-omap/dma.c
> >
> > As with the eDMA, the sDMA stack will need some cleanup, but the good
> > thing is that the dmaengine driver have minimal dependency on the legacy
> > plat-omap/dma.c API.
> 
> I totally oppose moving arch/arm/plat-omap/dma.c into drivers/dma.
> The omap-dma driver in drivers/dma is a replacement modern driver
> for the legacy crap, and most users of the legacy crap have been
> converted.
> 
> Why we still have users of the legacy crap is because:
> 
> (a) they don't fit into the DMA engine API very well
> (b) I don't have hardware to be able to test them
> 
> and, because of that, I'm not going to start proposing DMA engine API
> extensions to support something that I've no way to even test.
> 
> I've asked for help from TI on this when I was woring on the DMA
> engine implementation, and there was no interest - it kept being
> put back on me as something for me to sort.  It became an impossible
> situation.
> 
> So, how things were left was that I'd introduce a warning into the
> legacy driver, and in a few years time we'd strip it out of users
> and delete the legacy driver.
> 
> The warning (which is rather large, because it's a WARN(), so
> involves a kernel stack dump) has not produced (afaik) any complaints
> from anyone.  So, we can probably conclude that any of these drivers
> which are using the legacy DMA code are probably not being used.

I know of devices that ship with a recent kernel (v4.4 last time I checked) 
patched to remove the warning. We could argue that the vendor should submit 
patches to fix the offending driver(s), but the reality is that they don't 
have enough kernel development experience to do so. This doesn't mean we have 
to fix the problem for them, but I'm afraid we can't conclude this easily that 
those drivers are not used.

> This means we can save ourselves a lot of work and just delete all
> these drivers using the legacy OMAP DMA along with the legacy OMAP
> DMA driver.

-- 
Regards,

Laurent Pinchart

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Russell King - ARM Linux]

On Tue, Aug 02, 2016 at 12:21:16PM +0300, Laurent Pinchart wrote:
> Hi Russell,
> 
> On Tuesday 02 Aug 2016 09:41:36 Russell King - ARM Linux wrote:
> > On Tue, Aug 02, 2016 at 09:48:53AM +0300, Peter Ujfalusi wrote:
> > > I'm not going to move the legacy API under dmaengine, it makes no sense.
> > > 
> > > My plan is to do what I did with the eDMA driver stack:
> > > - convert drivers using the legacy API to dmaengine
> > > - 'merge' the code from plat-omap to the dmaengine driver
> > >   - while doing this the legacy API will vanish along with the
> > >   plat-omap/dma.c
> > >
> > > As with the eDMA, the sDMA stack will need some cleanup, but the good
> > > thing is that the dmaengine driver have minimal dependency on the legacy
> > > plat-omap/dma.c API.
> > 
> > I totally oppose moving arch/arm/plat-omap/dma.c into drivers/dma.
> > The omap-dma driver in drivers/dma is a replacement modern driver
> > for the legacy crap, and most users of the legacy crap have been
> > converted.
> > 
> > Why we still have users of the legacy crap is because:
> > 
> > (a) they don't fit into the DMA engine API very well
> > (b) I don't have hardware to be able to test them
> > 
> > and, because of that, I'm not going to start proposing DMA engine API
> > extensions to support something that I've no way to even test.
> > 
> > I've asked for help from TI on this when I was woring on the DMA
> > engine implementation, and there was no interest - it kept being
> > put back on me as something for me to sort.  It became an impossible
> > situation.
> > 
> > So, how things were left was that I'd introduce a warning into the
> > legacy driver, and in a few years time we'd strip it out of users
> > and delete the legacy driver.
> > 
> > The warning (which is rather large, because it's a WARN(), so
> > involves a kernel stack dump) has not produced (afaik) any complaints
> > from anyone.  So, we can probably conclude that any of these drivers
> > which are using the legacy DMA code are probably not being used.
> 
> I know of devices that ship with a recent kernel (v4.4 last time I checked) 
> patched to remove the warning. We could argue that the vendor should submit 
> patches to fix the offending driver(s), but the reality is that they don't 
> have enough kernel development experience to do so. This doesn't mean we have 
> to fix the problem for them, but I'm afraid we can't conclude this easily that 
> those drivers are not used.

If vendors want to ship legacy code, then that's up to them.  However,
that doesn't mean mainline has to have the support burden of that code.

I don't see that this really changes anything as far as mainline goes.
We can still delete the drivers or code for DMA in these drivers, and
lessen the burden in mainline.  Vendors can revert those commits, just
as they're (presumably) reverting my commit adding the warning.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Vinod Koul]

On Mon, Aug 01, 2016 at 08:56:30AM +0200, Arnd Bergmann wrote:
> 
> Sounds good. Let me know if you end up having to add a 'depends on ARM'
> dependency anywhere, as that might indicate that we are doing something
> different on ARM that should be done in a more generic way.

Only one thing :)

Arm seems to define NO_IRQ. This is not available in other arch and one
driver (moxart-dma) is using it. I don't see why this should be arm specific.

FWIW, now I have a single arm config like x86, ppc, mips for my subsystem with
this change.

Thanks for the suggestion :)

-- 
~Vinod

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Linus Torvalds]

On Fri, Sep 2, 2016 at 3:46 AM, Vinod Koul <vinod.koul@intel.com> wrote:
>
> Arm seems to define NO_IRQ. This is not available in other arch and one
> driver (moxart-dma) is using it. I don't see why this should be arm specific.

NO_IRQ is broken. We long long since agreed that 0 is "no irq", and
that the right way to test for it is just

   if (!irq) ...

which is what all the generic drivers use.

See for example

   git grep '(!.*irq)'

for how common that is.

(If you grep for NO_IRQ, you'll find a lot in particularly powerpc
drivers and platforms, but there NO_IRQ is actually just defined to
(0), so it ends up being the same thing).

The fact that ARM still has a NO_IRQ that seems to be defined to
((unsigned int)-1) just means that there are bugs hiding: if ARM
actually _uses_ that value for "no IRQ", then all the generic drivers
will be broken, and if ARM core doesn't, then the drivers that still
use NO_IRQ are broken. Either way you can't win.

So please make sure that NO_IRQ goes away entirely (or, if you insist
on having the confusing #define for some legacy reason, make it be 0
like powerpc, so that the real way of just testing "!irq" also works)

Some people have said "..but but but I have a real irq that has the
value 0", but that's irrelevant - the kernel "irq" value isn't
necessarily the same as the value that an interrupt _controller_ sees,
since the interrupt controller can be hiding behind various other
nested controllers etc. So an architecture might need to translate
"irq" into the actual hw interrupt controller value.

             Linus

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Arnd Bergmann]

On Friday, September 2, 2016 10:25:09 AM CEST Linus Torvalds wrote:
> On Fri, Sep 2, 2016 at 3:46 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> >
> > Arm seems to define NO_IRQ. This is not available in other arch and one
> > driver (moxart-dma) is using it. I don't see why this should be arm specific.
> 
> NO_IRQ is broken. We long long since agreed that 0 is "no irq", and
> that the right way to test for it is just
> 
>    if (!irq) ...
> 
> which is what all the generic drivers use.

Right, this one must have escaped review. We had NO_IRQ almost eliminated
from ARM specific drivers, and this one was probably added later.

> See for example
> 
>    git grep '(!.*irq)'
> 
> for how common that is.
> 
> (If you grep for NO_IRQ, you'll find a lot in particularly powerpc
> drivers and platforms, but there NO_IRQ is actually just defined to
> (0), so it ends up being the same thing).
> 
> The fact that ARM still has a NO_IRQ that seems to be defined to
> ((unsigned int)-1) just means that there are bugs hiding: if ARM
> actually _uses_ that value for "no IRQ", then all the generic drivers
> will be broken, and if ARM core doesn't, then the drivers that still
> use NO_IRQ are broken. Either way you can't win.
>
> So please make sure that NO_IRQ goes away entirely (or, if you insist
> on having the confusing #define for some legacy reason, make it be 0
> like powerpc, so that the real way of just testing "!irq" also works)

I'll throw this patch at my randconfig builder and see what breaks:

diff --git a/arch/arm/include/asm/irq.h b/arch/arm/include/asm/irq.h
index 1bd9510de1b9..b5b8354c1d9e 100644
--- a/arch/arm/include/asm/irq.h
+++ b/arch/arm/include/asm/irq.h
@@ -13,14 +13,6 @@
 #define irq_canonicalize(i)	(i)
 #endif
 
-/*
- * Use this value to indicate lack of interrupt
- * capability
- */
-#ifndef NO_IRQ
-#define NO_IRQ	((unsigned int)(-1))
-#endif
-
 #ifndef __ASSEMBLY__
 struct irqaction;
 struct pt_regs;


When I once looked, I thought all drivers using NO_IRQ were specific
to powerpc or one of the less common architectures.  We do have
these files however:

arch/arm/common/locomo.c:       if (lchip->irq != NO_IRQ && lchip->irq_base != NO_IRQ)
arch/arm/common/locomo.c:       if (lchip->irq != NO_IRQ) {
arch/arm/common/sa1111.c:       if (sachip->irq != NO_IRQ) {
arch/arm/common/sa1111.c:       if (sachip->irq != NO_IRQ) {
arch/arm/mach-mmp/devices.c:    if (desc->irq != NO_IRQ) {
arch/arm/mach-mv78xx0/common.c:                 NO_IRQ,
arch/arm/mach-mv78xx0/common.c:                 NO_IRQ);
arch/arm/mach-mv78xx0/common.c:                 NO_IRQ);
arch/arm/mach-orion5x/rd88f5181l-fxo-setup.c:   orion5x_eth_switch_init(&rd88f5181l_fxo_switch_plat_data, NO_IRQ);
arch/arm/mach-orion5x/rd88f6183ap-ge-setup.c:           .irq            = NO_IRQ,
arch/arm/mach-orion5x/wnr854t-setup.c:  orion5x_eth_switch_init(&wnr854t_switch_plat_data, NO_IRQ);
arch/arm/mach-orion5x/wrt350n-v2-setup.c:       orion5x_eth_switch_init(&wrt350n_v2_switch_plat_data, NO_IRQ);
arch/arm/plat-orion/common.c:   if (irq != NO_IRQ) {
arch/arm/plat-orion/common.c:                  mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
arch/arm/plat-orion/common.c:                  mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
arch/arm/plat-orion/common.c:                  mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
arch/arm/plat-orion/common.c:                  mapbase + 0x2000, SZ_16K - 1, NO_IRQ);
arch/arm/plat-orion/common.c:   if (irq != NO_IRQ) {
arch/arm/plat-orion/common.c:                  mapbase, SZ_512 - 1, NO_IRQ);
arch/arm/plat-orion/common.c:                  mapbase, SZ_512 - 1, NO_IRQ);

I can have another look what can be done about them. IIRC, plat-orion (which
includes mach-orion5x and mv78xx0) until recently still had devices with
IRQ as a valid number, but that was finally fixed now, so we should be able to
clean up most of them.

	Arnd

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Linus Torvalds]

On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> When I once looked, I thought all drivers using NO_IRQ were specific
> to powerpc or one of the less common architectures.

powerpc definitely does seem to be the biggest case, with about half
the instances of NO_IRQ being under arch/powerpc/ (and a few more in
ppc-specific drivers).

Adding the powerpc maintainers to the list - because it would really
be nice to get rid of it, or at least make it *so* rare that we don't
have people re-introducing it again because they thought it was the
right thing to do.

A fair amount of of it could even be done by some trivial scripting.
Something like

  git grep -wl NO_IRQ arch/powerpc/ | while read a
  do
      sed 's/(\([a-z_]*irq\) != NO_IRQ)/(\1)/' < $a > $a.new
      sed 's/(\([a-z_]*irq\) == NO_IRQ)/(!\1)/' < $a.new > $a
  done

does fix at least a few of the cases. It still leaves several
assignments and "return NO_IRQ;" statements, but a few more
sed-scripts would take care of most of it. Then remove the #define,
and do a full build to find any straggling cases.

Michael? Ben?

             Linus

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Linus Torvalds]

On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> When I once looked, I thought all drivers using NO_IRQ were specific
> to powerpc or one of the less common architectures.

powerpc definitely does seem to be the biggest case, with about half
the instances of NO_IRQ being under arch/powerpc/ (and a few more in
ppc-specific drivers).

Adding the powerpc maintainers to the list - because it would really
be nice to get rid of it, or at least make it *so* rare that we don't
have people re-introducing it again because they thought it was the
right thing to do.

A fair amount of of it could even be done by some trivial scripting.
Something like

  git grep -wl NO_IRQ arch/powerpc/ | while read a
  do
      sed 's/(\([a-z_]*irq\) != NO_IRQ)/(\1)/' < $a > $a.new
      sed 's/(\([a-z_]*irq\) == NO_IRQ)/(!\1)/' < $a.new > $a
  done

does fix at least a few of the cases. It still leaves several
assignments and "return NO_IRQ;" statements, but a few more
sed-scripts would take care of most of it. Then remove the #define,
and do a full build to find any straggling cases.

Michael? Ben?

             Linus

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Julia Lawall]

On Fri, 2 Sep 2016, Linus Torvalds wrote:

> On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > When I once looked, I thought all drivers using NO_IRQ were specific
> > to powerpc or one of the less common architectures.
>
> powerpc definitely does seem to be the biggest case, with about half
> the instances of NO_IRQ being under arch/powerpc/ (and a few more in
> ppc-specific drivers).
>
> Adding the powerpc maintainers to the list - because it would really
> be nice to get rid of it, or at least make it *so* rare that we don't
> have people re-introducing it again because they thought it was the
> right thing to do.
>
> A fair amount of of it could even be done by some trivial scripting.
> Something like
>
>   git grep -wl NO_IRQ arch/powerpc/ | while read a
>   do
>       sed 's/(\([a-z_]*irq\) != NO_IRQ)/(\1)/' < $a > $a.new
>       sed 's/(\([a-z_]*irq\) == NO_IRQ)/(!\1)/' < $a.new > $a
>   done
>
> does fix at least a few of the cases. It still leaves several
> assignments and "return NO_IRQ;" statements, but a few more
> sed-scripts would take care of most of it. Then remove the #define,
> and do a full build to find any straggling cases.

Like this?

@@
expression e;
@@

e
- != NO_IRQ

@@
expression e;
@@

+!
e
- == NO_IRQ

@@
@@

- NO_IRQ
+ 0

---

Is it always correct to replace return NO_IRQ by return 0?

Completely untested patch below.

julia

diff -u -p a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -511,7 +511,7 @@ unsigned int mpc52xx_get_irq(void)
 			irq |= (MPC52xx_IRQ_L1_PERP << MPC52xx_IRQ_L1_OFFSET);
 		}
 	} else {
-		return NO_IRQ;
+		return 0;
 	}

 	return irq_linear_revmap(mpc52xx_irqhost, irq);
diff -u -p a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -368,7 +368,7 @@ static void chrp_8259_cascade(struct irq
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -514,7 +514,7 @@ static void __init chrp_find_8259(void)
 	}
 	if (chrp_mpic != NULL) {
 		cascade_irq = irq_of_parse_and_map(pic, 0);
-		if (cascade_irq == NO_IRQ)
+		if (!cascade_irq)
 			printk(KERN_ERR "i8259: failed to map cascade irq\n");
 		else
 			irq_set_chained_handler(cascade_irq,
diff -u -p a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -552,7 +552,7 @@ void maple_pci_irq_fixup(struct pci_dev
 	    pci_bus_to_host(dev->bus) == u4_pcie) {
 		printk(KERN_DEBUG "Fixup U4 PCIe IRQ\n");
 		dev->irq = irq_create_mapping(NULL, 1);
-		if (dev->irq != NO_IRQ)
+		if (dev->irq)
 			irq_set_irq_type(dev->irq, IRQ_TYPE_LEVEL_LOW);
 	}

@@ -562,7 +562,7 @@ void maple_pci_irq_fixup(struct pci_dev
 	if (dev->vendor == PCI_VENDOR_ID_AMD &&
 	    dev->device == PCI_DEVICE_ID_AMD_8111_IDE &&
 	    (dev->class & 5) != 5) {
-		dev->irq = NO_IRQ;
+		dev->irq = 0;
 	}

 	DBG(" <- maple_pci_irq_fixup\n");
@@ -648,7 +648,7 @@ int maple_pci_get_legacy_ide_irq(struct
 		return defirq;
 	}
 	irq = irq_of_parse_and_map(np, channel & 0x1);
-	if (irq == NO_IRQ) {
+	if (!irq) {
 		printk("Failed to map onboard IDE interrupt for channel %d\n",
 		       channel);
 		return defirq;
diff -u -p a/arch/powerpc/platforms/embedded6xx/flipper-pic.c b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
--- a/arch/powerpc/platforms/embedded6xx/flipper-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
@@ -181,7 +181,7 @@ unsigned int flipper_pic_get_irq(void)
 	irq_status = in_be32(io_base + FLIPPER_ICR) &
 		     in_be32(io_base + FLIPPER_IMR);
 	if (irq_status == 0)
-		return NO_IRQ;	/* no more IRQs pending */
+		return 0;	/* no more IRQs pending */

 	irq = __ffs(irq_status);
 	return irq_linear_revmap(flipper_irq_host, irq);
diff -u -p a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
--- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
@@ -114,7 +114,7 @@ static unsigned int __hlwd_pic_get_irq(s
 	irq_status = in_be32(io_base + HW_BROADWAY_ICR) &
 		     in_be32(io_base + HW_BROADWAY_IMR);
 	if (irq_status == 0)
-		return NO_IRQ;	/* no more IRQs pending */
+		return 0;	/* no more IRQs pending */

 	irq = __ffs(irq_status);
 	return irq_linear_revmap(h, irq);
@@ -131,7 +131,7 @@ static void hlwd_pic_irq_cascade(struct
 	raw_spin_unlock(&desc->lock);

 	virq = __hlwd_pic_get_irq(irq_domain);
-	if (virq != NO_IRQ)
+	if (virq)
 		generic_handle_irq(virq);
 	else
 		pr_err("spurious interrupt!\n");
diff -u -p a/arch/powerpc/platforms/embedded6xx/mvme5100.c b/arch/powerpc/platforms/embedded6xx/mvme5100.c
--- a/arch/powerpc/platforms/embedded6xx/mvme5100.c
+++ b/arch/powerpc/platforms/embedded6xx/mvme5100.c
@@ -47,7 +47,7 @@ static void mvme5100_8259_cascade(struct
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -84,7 +84,7 @@ static void __init mvme5100_pic_init(voi
 	}

 	cirq = irq_of_parse_and_map(cp, 0);
-	if (cirq == NO_IRQ) {
+	if (!cirq) {
 		pr_warn("mvme5100_pic_init: no cascade interrupt?\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/pasemi/misc.c b/arch/powerpc/platforms/pasemi/misc.c
--- a/arch/powerpc/platforms/pasemi/misc.c
+++ b/arch/powerpc/platforms/pasemi/misc.c
@@ -76,7 +76,7 @@ static int __init pasemi_register_i2c_de
 			}

 			info.irq = irq_of_parse_and_map(node, 0);
-			if (info.irq == NO_IRQ)
+			if (!info.irq)
 				info.irq = -1;

 			if (find_i2c_driver(node, &info) < 0)
diff -u -p a/arch/powerpc/platforms/pasemi/msi.c b/arch/powerpc/platforms/pasemi/msi.c
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -68,7 +68,7 @@ static void pasemi_msi_teardown_msi_irqs
 	pr_debug("pasemi_msi_teardown_msi_irqs, pdev %p\n", pdev);

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		hwirq = virq_to_hw(entry->irq);
@@ -109,7 +109,7 @@ static int pasemi_msi_setup_msi_irqs(str
 		}

 		virq = irq_create_mapping(msi_mpic->irqhost, hwirq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_debug("pasemi_msi: failed mapping hwirq 0x%x\n",
 				  hwirq);
 			msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap, hwirq,
diff -u -p a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -59,7 +59,7 @@ struct mce_regs {

 static struct mce_regs mce_regs[MAX_MCE_REGS];
 static int num_mce_regs;
-static int nmi_virq = NO_IRQ;
+static int nmi_virq = 0;


 static void __noreturn pas_restart(char *cmd)
@@ -264,7 +264,7 @@ static int pas_machine_check_handler(str
 	srr0 = regs->nip;
 	srr1 = regs->msr;

-	if (nmi_virq != NO_IRQ && mpic_get_mcirq() == nmi_virq) {
+	if (nmi_virq && mpic_get_mcirq() == nmi_virq) {
 		printk(KERN_ERR "NMI delivered\n");
 		debugger(regs);
 		mpic_end_irq(irq_get_irq_data(nmi_virq));
diff -u -p a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -76,7 +76,7 @@ void __init mpc85xx_cpm2_pic_init(void)
 		return;
 	}
 	irq = irq_of_parse_and_map(np, 0);
-	if (irq == NO_IRQ) {
+	if (!irq) {
 		of_node_put(np);
 		printk(KERN_ERR "PIC init: got no IRQ for cpm cascade\n");
 		return;
diff -u -p a/arch/powerpc/platforms/85xx/socrates_fpga_pic.c b/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
--- a/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
+++ b/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
@@ -78,7 +78,7 @@ static inline unsigned int socrates_fpga
 			break;
 	}
 	if (i == 3)
-		return NO_IRQ;
+		return 0;

 	raw_spin_lock_irqsave(&socrates_fpga_pic_lock, flags);
 	cause = socrates_fpga_pic_read(FPGA_PIC_IRQMASK(i));
@@ -103,7 +103,7 @@ static void socrates_fpga_pic_cascade(st
 	 */
 	cascade_irq = socrates_fpga_pic_get_irq(irq);

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);
 	chip->irq_eoi(&desc->irq_data);
 }
@@ -292,7 +292,7 @@ void socrates_fpga_pic_init(struct devic

 	for (i = 0; i < 3; i++) {
 		socrates_fpga_irqs[i] = irq_of_parse_and_map(pic, i);
-		if (socrates_fpga_irqs[i] == NO_IRQ) {
+		if (!socrates_fpga_irqs[i]) {
 			pr_warning("FPGA PIC: can't get irq%d.\n", i);
 			continue;
 		}
diff -u -p a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -196,7 +196,7 @@ static void mpc85xx_8259_cascade_handler
 {
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		/* handle an interrupt from the 8259 */
 		generic_handle_irq(cascade_irq);

@@ -247,7 +247,7 @@ static int mpc85xx_cds_8259_attach(void)
 	}

 	cascade_irq = irq_of_parse_and_map(cascade_node, 0);
-	if (cascade_irq == NO_IRQ) {
+	if (!cascade_irq) {
 		printk(KERN_ERR "Failed to map cascade interrupt\n");
 		return -ENXIO;
 	}
diff -u -p a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -51,7 +51,7 @@ static void mpc85xx_8259_cascade(struct
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ) {
+	if (cascade_irq) {
 		generic_handle_irq(cascade_irq);
 	}
 	chip->irq_eoi(&desc->irq_data);
@@ -96,7 +96,7 @@ void __init mpc85xx_ds_pic_init(void)
 	}

 	cascade_irq = irq_of_parse_and_map(cascade_node, 0);
-	if (cascade_irq == NO_IRQ) {
+	if (!cascade_irq) {
 		printk(KERN_ERR "Failed to map cascade interrupt\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/83xx/suspend.c b/arch/powerpc/platforms/83xx/suspend.c
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -352,7 +352,7 @@ static int pmc_probe(struct platform_dev
 		return -ENODEV;

 	pmc_irq = irq_of_parse_and_map(np, 0);
-	if (pmc_irq != NO_IRQ) {
+	if (pmc_irq) {
 		ret = request_irq(pmc_irq, pmc_irq_handler, IRQF_SHARED,
 		                  "pmc", ofdev);

@@ -400,7 +400,7 @@ out_syscr:
 out_pmc:
 	iounmap(pmc_regs);
 out:
-	if (pmc_irq != NO_IRQ)
+	if (pmc_irq)
 		free_irq(pmc_irq, ofdev);

 	return ret;
diff -u -p a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -89,7 +89,7 @@ static int __init of_fsl_spi_probe(char
 			goto err;

 		ret = of_irq_to_resource(np, 0, &res[1]);
-		if (ret == NO_IRQ)
+		if (!ret)
 			goto err;

 		pdev = platform_device_alloc("mpc83xx_spi", i);
diff -u -p a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -204,7 +204,7 @@ static void pika_setup_critical_temp(str
 	i2c_smbus_write_byte_data(client, 3,  0); /* Tlow */

 	irq = irq_of_parse_and_map(np, 0);
-	if (irq  == NO_IRQ) {
+	if (!irq) {
 		printk(KERN_ERR __FILE__ ": Unable to get ad7414 irq\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/86xx/pic.c b/arch/powerpc/platforms/86xx/pic.c
--- a/arch/powerpc/platforms/86xx/pic.c
+++ b/arch/powerpc/platforms/86xx/pic.c
@@ -22,7 +22,7 @@ static void mpc86xx_8259_cascade(struct
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -58,7 +58,7 @@ void __init mpc86xx_init_irq(void)
 	}

 	cascade_irq = irq_of_parse_and_map(cascade_node, 0);
-	if (cascade_irq == NO_IRQ) {
+	if (!cascade_irq) {
 		printk(KERN_ERR "Failed to map cascade interrupt\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -119,7 +119,7 @@ static void rtas_teardown_msi_irqs(struc
 	struct msi_desc *entry;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		irq_set_msi_desc(entry->irq, NULL);
@@ -471,7 +471,7 @@ again:

 		virq = irq_create_mapping(NULL, hwirq);

-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);
 			return -ENOSPC;
 		}
@@ -490,7 +490,7 @@ again:
 static void rtas_msi_pci_irq_fixup(struct pci_dev *pdev)
 {
 	/* No LSI -> leave MSIs (if any) configured */
-	if (pdev->irq == NO_IRQ) {
+	if (!pdev->irq) {
 		dev_dbg(&pdev->dev, "rtas_msi: no LSI, nothing to do.\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/pseries/event_sources.c b/arch/powerpc/platforms/pseries/event_sources.c
--- a/arch/powerpc/platforms/pseries/event_sources.c
+++ b/arch/powerpc/platforms/pseries/event_sources.c
@@ -34,7 +34,7 @@ void request_event_sources_irqs(struct d
 		if (count > 15)
 			break;
 		virqs[count] = irq_create_of_mapping(&oirq);
-		if (virqs[count] == NO_IRQ) {
+		if (!virqs[count]) {
 			pr_err("event-sources: Unable to allocate "
 			       "interrupt number for %s\n",
 			       np->full_name);
diff -u -p a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -114,7 +114,7 @@ static void pseries_8259_cascade(struct
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -141,7 +141,7 @@ static void __init pseries_setup_i8259_c
 	}

 	cascade = irq_of_parse_and_map(found, 0);
-	if (cascade == NO_IRQ) {
+	if (!cascade) {
 		printk(KERN_ERR "pic: failed to map cascade interrupt");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -192,7 +192,7 @@ static int ps3_virq_setup(enum ps3_cpu_b

 	*virq = irq_create_mapping(NULL, outlet);

-	if (*virq == NO_IRQ) {
+	if (!*virq) {
 		FAIL("%s:%d: irq_create_mapping failed: outlet %lu\n",
 			__func__, __LINE__, outlet);
 		result = -ENOMEM;
@@ -339,7 +339,7 @@ int ps3_event_receive_port_setup(enum ps
 	if (result) {
 		FAIL("%s:%d: lv1_construct_event_receive_port failed: %s\n",
 			__func__, __LINE__, ps3_result(result));
-		*virq = NO_IRQ;
+		*virq = 0;
 		return result;
 	}

@@ -418,7 +418,7 @@ int ps3_sb_event_receive_port_setup(stru
 			" failed: %s\n", __func__, __LINE__,
 			ps3_result(result));
 		ps3_event_receive_port_destroy(*virq);
-		*virq = NO_IRQ;
+		*virq = 0;
 		return result;
 	}

@@ -724,12 +724,12 @@ static unsigned int ps3_get_irq(void)
 	asm volatile("cntlzd %0,%1" : "=r" (plug) : "r" (x));
 	plug &= 0x3f;

-	if (unlikely(plug == NO_IRQ)) {
+	if (unlikely(!plug)) {
 		DBG("%s:%d: no plug found: thread_id %llu\n", __func__,
 			__LINE__, pd->thread_id);
 		dump_bmp(&per_cpu(ps3_private, 0));
 		dump_bmp(&per_cpu(ps3_private, 1));
-		return NO_IRQ;
+		return 0;
 	}

 #if defined(DEBUG)
diff -u -p a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -91,7 +91,7 @@ static void __init ps3_smp_probe(void)
 			result = smp_request_message_ipi(virqs[i], i);

 			if (result)
-				virqs[i] = NO_IRQ;
+				virqs[i] = 0;
 			else
 				ps3_register_ipi_irq(cpu, virqs[i]);
 		}
@@ -112,7 +112,7 @@ void ps3_smp_cleanup_cpu(int cpu)
 	for (i = 0; i < MSG_COUNT; i++) {
 		/* Can't call free_irq from interrupt context. */
 		ps3_event_receive_port_destroy(virqs[i]);
-		virqs[i] = NO_IRQ;
+		virqs[i] = 0;
 	}

 	DBG(" <- %s:%d: (%d)\n", __func__, __LINE__, cpu);
diff -u -p a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -284,7 +284,7 @@ fail_alloc_2:
 fail_alloc_1:
 	ps3_spe_irq_destroy(spu->irqs[0]);
 fail_alloc_0:
-	spu->irqs[0] = spu->irqs[1] = spu->irqs[2] = NO_IRQ;
+	spu->irqs[0] = spu->irqs[1] = spu->irqs[2] = 0;
 	return result;
 }

@@ -334,7 +334,7 @@ static int ps3_destroy_spu(struct spu *s
 	ps3_spe_irq_destroy(spu->irqs[1]);
 	ps3_spe_irq_destroy(spu->irqs[0]);

-	spu->irqs[0] = spu->irqs[1] = spu->irqs[2] = NO_IRQ;
+	spu->irqs[0] = spu->irqs[1] = spu->irqs[2] = 0;

 	spu_unmap(spu);

diff -u -p a/arch/powerpc/platforms/powermac/pic.c b/arch/powerpc/platforms/powermac/pic.c
--- a/arch/powerpc/platforms/powermac/pic.c
+++ b/arch/powerpc/platforms/powermac/pic.c
@@ -251,7 +251,7 @@ static unsigned int pmac_pic_get_irq(voi
 	}
 	raw_spin_unlock_irqrestore(&pmac_pic_lock, flags);
 	if (unlikely(irq < 0))
-		return NO_IRQ;
+		return 0;
 	return irq_linear_revmap(pmac_pic_host, irq);
 }

@@ -389,7 +389,7 @@ static void __init pmac_pic_probe_oldsty
 		out_le32(&pmac_irq_hw[i]->enable, 0);

 	/* Hookup cascade irq */
-	if (slave && pmac_irq_cascade != NO_IRQ)
+	if (slave && pmac_irq_cascade)
 		setup_irq(pmac_irq_cascade, &gatwick_cascade_action);

 	printk(KERN_INFO "irq: System has %d possible interrupts\n", max_irqs);
@@ -444,7 +444,7 @@ static void __init pmac_pic_setup_mpic_n
 	pswitch = of_find_node_by_name(NULL, "programmer-switch");
 	if (pswitch) {
 		nmi_irq = irq_of_parse_and_map(pswitch, 0);
-		if (nmi_irq != NO_IRQ) {
+		if (nmi_irq) {
 			mpic_irq_set_priority(nmi_irq, 9);
 			setup_irq(nmi_irq, &xmon_action);
 		}
diff -u -p a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -401,7 +401,7 @@ static int kw_i2c_xfer(struct pmac_i2c_b
 {
 	struct pmac_i2c_host_kw *host = bus->hostdata;
 	u8 mode_reg = host->speed;
-	int use_irq = host->irq != NO_IRQ && !bus->polled;
+	int use_irq = host->irq && !bus->polled;

 	/* Setup mode & subaddress if any */
 	switch(bus->mode) {
@@ -535,7 +535,7 @@ static struct pmac_i2c_host_kw *__init k
 		break;
 	}
 	host->irq = irq_of_parse_and_map(np, 0);
-	if (host->irq == NO_IRQ)
+	if (!host->irq)
 		printk(KERN_WARNING
 		       "low_i2c: Failed to map interrupt for %s\n",
 		       np->full_name);
@@ -557,7 +557,7 @@ static struct pmac_i2c_host_kw *__init k
 	 */
 	if (request_irq(host->irq, kw_i2c_irq, IRQF_NO_SUSPEND,
 			"keywest i2c", host))
-		host->irq = NO_IRQ;
+		host->irq = 0;

 	printk(KERN_INFO "KeyWest i2c @0x%08x irq %d %s\n",
 	       *addrp, host->irq, np->full_name);
diff -u -p a/arch/powerpc/platforms/powermac/pfunc_base.c b/arch/powerpc/platforms/powermac/pfunc_base.c
--- a/arch/powerpc/platforms/powermac/pfunc_base.c
+++ b/arch/powerpc/platforms/powermac/pfunc_base.c
@@ -26,7 +26,7 @@ static irqreturn_t macio_gpio_irq(int ir
 static int macio_do_gpio_irq_enable(struct pmf_function *func)
 {
 	unsigned int irq = irq_of_parse_and_map(func->node, 0);
-	if (irq == NO_IRQ)
+	if (!irq)
 		return -EINVAL;
 	return request_irq(irq, macio_gpio_irq, 0, func->node->name, func);
 }
@@ -34,7 +34,7 @@ static int macio_do_gpio_irq_enable(stru
 static int macio_do_gpio_irq_disable(struct pmf_function *func)
 {
 	unsigned int irq = irq_of_parse_and_map(func->node, 0);
-	if (irq == NO_IRQ)
+	if (!irq)
 		return -EINVAL;
 	free_irq(irq, func);
 	return 0;
diff -u -p a/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c b/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
--- a/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
@@ -97,7 +97,7 @@ cpld_pic_get_irq(int offset, u8 ignore,
 	status |= (ignore | mask);

 	if (status == 0xff)
-		return NO_IRQ;
+		return 0;

 	cpld_irq = ffz(status) + offset;

@@ -110,14 +110,14 @@ static void cpld_pic_cascade(struct irq_

 	irq = cpld_pic_get_irq(0, PCI_IGNORE, &cpld_regs->pci_status,
 		&cpld_regs->pci_mask);
-	if (irq != NO_IRQ) {
+	if (irq) {
 		generic_handle_irq(irq);
 		return;
 	}

 	irq = cpld_pic_get_irq(8, MISC_IGNORE, &cpld_regs->misc_status,
 		&cpld_regs->misc_mask);
-	if (irq != NO_IRQ) {
+	if (irq) {
 		generic_handle_irq(irq);
 		return;
 	}
@@ -177,7 +177,7 @@ mpc5121_ads_cpld_pic_init(void)
 		goto end;

 	cascade_irq = irq_of_parse_and_map(np, 0);
-	if (cascade_irq == NO_IRQ)
+	if (!cascade_irq)
 		goto end;

 	/*
diff -u -p a/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
--- a/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
+++ b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
@@ -473,7 +473,7 @@ static int mpc512x_lpbfifo_probe(struct
 	}

 	lpbfifo.irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
-	if (lpbfifo.irq == NO_IRQ) {
+	if (!lpbfifo.irq) {
 		dev_err(&pdev->dev, "mapping irq failed\n");
 		ret = -ENODEV;
 		goto err0;
diff -u -p a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -241,6 +241,6 @@ void __init mpc8xx_pics_init(void)
 	}

 	irq = cpm_pic_init();
-	if (irq != NO_IRQ)
+	if (irq)
 		irq_set_chained_handler(irq, cpm_cascade);
 }
diff -u -p a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -131,7 +131,7 @@ int __init pq2ads_pci_init_irq(void)
 	}

 	irq = irq_of_parse_and_map(np, 0);
-	if (irq == NO_IRQ) {
+	if (!irq) {
 		printk(KERN_ERR "No interrupt in pci pic node.\n");
 		of_node_put(np);
 		goto out;
diff -u -p a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -402,7 +402,7 @@ static int spu_request_irqs(struct spu *
 {
 	int ret = 0;

-	if (spu->irqs[0] != NO_IRQ) {
+	if (spu->irqs[0]) {
 		snprintf(spu->irq_c0, sizeof (spu->irq_c0), "spe%02d.0",
 			 spu->number);
 		ret = request_irq(spu->irqs[0], spu_irq_class_0,
@@ -410,7 +410,7 @@ static int spu_request_irqs(struct spu *
 		if (ret)
 			goto bail0;
 	}
-	if (spu->irqs[1] != NO_IRQ) {
+	if (spu->irqs[1]) {
 		snprintf(spu->irq_c1, sizeof (spu->irq_c1), "spe%02d.1",
 			 spu->number);
 		ret = request_irq(spu->irqs[1], spu_irq_class_1,
@@ -418,7 +418,7 @@ static int spu_request_irqs(struct spu *
 		if (ret)
 			goto bail1;
 	}
-	if (spu->irqs[2] != NO_IRQ) {
+	if (spu->irqs[2]) {
 		snprintf(spu->irq_c2, sizeof (spu->irq_c2), "spe%02d.2",
 			 spu->number);
 		ret = request_irq(spu->irqs[2], spu_irq_class_2,
@@ -429,10 +429,10 @@ static int spu_request_irqs(struct spu *
 	return 0;

 bail2:
-	if (spu->irqs[1] != NO_IRQ)
+	if (spu->irqs[1])
 		free_irq(spu->irqs[1], spu);
 bail1:
-	if (spu->irqs[0] != NO_IRQ)
+	if (spu->irqs[0])
 		free_irq(spu->irqs[0], spu);
 bail0:
 	return ret;
@@ -440,11 +440,11 @@ bail0:

 static void spu_free_irqs(struct spu *spu)
 {
-	if (spu->irqs[0] != NO_IRQ)
+	if (spu->irqs[0])
 		free_irq(spu->irqs[0], spu);
-	if (spu->irqs[1] != NO_IRQ)
+	if (spu->irqs[1])
 		free_irq(spu->irqs[1], spu);
-	if (spu->irqs[2] != NO_IRQ)
+	if (spu->irqs[2])
 		free_irq(spu->irqs[2], spu);
 }

diff -u -p a/arch/powerpc/platforms/cell/interrupt.c b/arch/powerpc/platforms/cell/interrupt.c
--- a/arch/powerpc/platforms/cell/interrupt.c
+++ b/arch/powerpc/platforms/cell/interrupt.c
@@ -123,7 +123,7 @@ static void iic_ioexc_cascade(struct irq
 				unsigned int cirq =
 					irq_linear_revmap(iic_host,
 							  base | cascade);
-				if (cirq != NO_IRQ)
+				if (cirq)
 					generic_handle_irq(cirq);
 			}
 		/* post-ack level interrupts */
@@ -153,10 +153,10 @@ static unsigned int iic_get_irq(void)
 	*(unsigned long *) &pending =
 		in_be64((u64 __iomem *) &iic->regs->pending_destr);
 	if (!(pending.flags & CBE_IIC_IRQ_VALID))
-		return NO_IRQ;
+		return 0;
 	virq = irq_linear_revmap(iic_host, iic_pending_to_hwnum(pending));
-	if (virq == NO_IRQ)
-		return NO_IRQ;
+	if (!virq)
+		return 0;
 	iic->eoi_stack[++iic->eoi_ptr] = pending.prio;
 	BUG_ON(iic->eoi_ptr > 15);
 	return virq;
@@ -198,7 +198,7 @@ static void iic_request_ipi(int msg)
 	int virq;

 	virq = irq_create_mapping(iic_host, iic_msg_to_irq(msg));
-	if (virq == NO_IRQ) {
+	if (!virq) {
 		printk(KERN_ERR
 		       "iic: failed to map IPI %s\n", smp_ipi_name[msg]);
 		return;
@@ -353,7 +353,7 @@ static int __init setup_iic(void)
 		cascade |= 1 << IIC_IRQ_CLASS_SHIFT;
 		cascade |= IIC_UNIT_IIC;
 		cascade = irq_create_mapping(iic_host, cascade);
-		if (cascade == NO_IRQ)
+		if (!cascade)
 			continue;
 		/*
 		 * irq_data is a generic pointer that gets passed back
diff -u -p a/arch/powerpc/platforms/cell/pmu.c b/arch/powerpc/platforms/cell/pmu.c
--- a/arch/powerpc/platforms/cell/pmu.c
+++ b/arch/powerpc/platforms/cell/pmu.c
@@ -385,7 +385,7 @@ static int __init cbe_init_pm_irq(void)
 	for_each_online_node(node) {
 		irq = irq_create_mapping(NULL, IIC_IRQ_IOEX_PMI |
 					       (node << IIC_IRQ_NODE_SHIFT));
-		if (irq == NO_IRQ) {
+		if (!irq) {
 			printk("ERROR: Unable to allocate irq for node %d\n",
 			       node);
 			return -EINVAL;
@@ -412,7 +412,7 @@ void cbe_sync_irq(int node)
 			       IIC_IRQ_IOEX_PMI
 			       | (node << IIC_IRQ_NODE_SHIFT));

-	if (irq == NO_IRQ) {
+	if (!irq) {
 		printk(KERN_WARNING "ERROR, unable to get existing irq %d " \
 		"for node %d\n", irq, node);
 		return;
diff -u -p a/arch/powerpc/platforms/cell/spider-pic.c b/arch/powerpc/platforms/cell/spider-pic.c
--- a/arch/powerpc/platforms/cell/spider-pic.c
+++ b/arch/powerpc/platforms/cell/spider-pic.c
@@ -207,11 +207,11 @@ static void spider_irq_cascade(struct ir

 	cs = in_be32(pic->regs + TIR_CS) >> 24;
 	if (cs == SPIDER_IRQ_INVALID)
-		virq = NO_IRQ;
+		virq = 0;
 	else
 		virq = irq_linear_revmap(pic->host, cs);

-	if (virq != NO_IRQ)
+	if (virq)
 		generic_handle_irq(virq);

 	chip->irq_eoi(&desc->irq_data);
@@ -245,19 +245,19 @@ static unsigned int __init spider_find_c
 	/* Now do the horrible hacks */
 	tmp = of_get_property(of_node, "#interrupt-cells", NULL);
 	if (tmp == NULL)
-		return NO_IRQ;
+		return 0;
 	intsize = *tmp;
 	imap = of_get_property(of_node, "interrupt-map", &imaplen);
 	if (imap == NULL || imaplen < (intsize + 1))
-		return NO_IRQ;
+		return 0;
 	iic = of_find_node_by_phandle(imap[intsize]);
 	if (iic == NULL)
-		return NO_IRQ;
+		return 0;
 	imap += intsize + 1;
 	tmp = of_get_property(iic, "#interrupt-cells", NULL);
 	if (tmp == NULL) {
 		of_node_put(iic);
-		return NO_IRQ;
+		return 0;
 	}
 	intsize = *tmp;
 	/* Assume unit is last entry of interrupt specifier */
@@ -266,7 +266,7 @@ static unsigned int __init spider_find_c
 	tmp = of_get_property(iic, "ibm,interrupt-server-ranges", NULL);
 	if (tmp == NULL) {
 		of_node_put(iic);
-		return NO_IRQ;
+		return 0;
 	}
 	/* ugly as hell but works for now */
 	pic->node_id = (*tmp) >> 1;
@@ -281,7 +281,7 @@ static unsigned int __init spider_find_c
 				  (pic->node_id << IIC_IRQ_NODE_SHIFT) |
 				  (2 << IIC_IRQ_CLASS_SHIFT) |
 				  unit);
-	if (virq == NO_IRQ)
+	if (!virq)
 		printk(KERN_ERR "spider_pic: failed to map cascade !");
 	return virq;
 }
@@ -318,7 +318,7 @@ static void __init spider_init_one(struc

 	/* Hook up the cascade interrupt to the iic and nodeid */
 	virq = spider_find_cascade_and_node(pic);
-	if (virq == NO_IRQ)
+	if (!virq)
 		return;
 	irq_set_handler_data(virq, pic);
 	irq_set_chained_handler(virq, spider_irq_cascade);
diff -u -p a/arch/powerpc/platforms/cell/spu_manage.c b/arch/powerpc/platforms/cell/spu_manage.c
--- a/arch/powerpc/platforms/cell/spu_manage.c
+++ b/arch/powerpc/platforms/cell/spu_manage.c
@@ -105,7 +105,7 @@ static int __init spu_map_interrupts_old
 	spu->irqs[2] = irq_create_mapping(NULL, IIC_IRQ_CLASS_2 | isrc);

 	/* Right now, we only fail if class 2 failed */
-	return spu->irqs[2] == NO_IRQ ? -EINVAL : 0;
+	return !spu->irqs[2] ? -EINVAL : 0;
 }

 static void __iomem * __init spu_map_prop_old(struct spu *spu,
@@ -191,7 +191,7 @@ static int __init spu_map_interrupts(str
 		pr_debug("  irq %d no 0x%x on %s\n", i, oirq.args[0],
 			 oirq.np->full_name);
 		spu->irqs[i] = irq_create_of_mapping(&oirq);
-		if (spu->irqs[i] == NO_IRQ) {
+		if (!spu->irqs[i]) {
 			pr_debug("spu_new: failed to map it !\n");
 			goto err;
 		}
@@ -202,7 +202,7 @@ err:
 	pr_debug("failed to map irq %x for spu %s\n", *oirq.args,
 		spu->name);
 	for (; i >= 0; i--) {
-		if (spu->irqs[i] != NO_IRQ)
+		if (spu->irqs[i])
 			irq_dispose_mapping(spu->irqs[i]);
 	}
 	return ret;
diff -u -p a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -411,7 +411,7 @@ static void cell_iommu_enable_hardware(s

 	virq = irq_create_mapping(NULL,
 			IIC_IRQ_IOEX_ATI | (iommu->nid << IIC_IRQ_NODE_SHIFT));
-	BUG_ON(virq == NO_IRQ);
+	BUG_ON(!virq);

 	ret = request_irq(virq, ioc_interrupt, 0, iommu->name, iommu);
 	BUG_ON(ret);
diff -u -p a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -271,7 +271,7 @@ static int axon_msi_setup_msi_irqs(struc

 	for_each_pci_msi_entry(entry, dev) {
 		virq = irq_create_direct_mapping(msic->irq_domain);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			dev_warn(&dev->dev,
 				 "axon_msi: virq allocation failed!\n");
 			return -1;
@@ -293,7 +293,7 @@ static void axon_msi_teardown_msi_irqs(s
 	dev_dbg(&dev->dev, "axon_msi: tearing down msi irqs\n");

 	for_each_pci_msi_entry(entry, dev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		irq_set_msi_desc(entry->irq, NULL);
@@ -375,7 +375,7 @@ static int axon_msi_probe(struct platfor
 	}

 	virq = irq_of_parse_and_map(dn, 0);
-	if (virq == NO_IRQ) {
+	if (!virq) {
 		printk(KERN_ERR "axon_msi: irq parse and map failed for %s\n",
 		       dn->full_name);
 		goto out_free_fifo;
diff -u -p a/arch/powerpc/platforms/powernv/opal-irqchip.c b/arch/powerpc/platforms/powernv/opal-irqchip.c
--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -222,7 +222,7 @@ int __init opal_event_init(void)
 		/* Get hardware and virtual IRQ */
 		irq = be32_to_cpup(irqs);
 		virq = irq_create_mapping(NULL, irq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_warn("Failed to map irq 0x%x\n", irq);
 			continue;
 		}
@@ -260,7 +260,7 @@ machine_arch_initcall(powernv, opal_even
 int opal_event_request(unsigned int opal_event_nr)
 {
 	if (WARN_ON_ONCE(!opal_event_irqchip.domain))
-		return NO_IRQ;
+		return 0;

 	return irq_create_mapping(opal_event_irqchip.domain, opal_event_nr);
 }
diff -u -p a/arch/powerpc/platforms/powernv/pci-cxl.c b/arch/powerpc/platforms/powernv/pci-cxl.c
--- a/arch/powerpc/platforms/powernv/pci-cxl.c
+++ b/arch/powerpc/platforms/powernv/pci-cxl.c
@@ -344,7 +344,7 @@ int pnv_cxl_cx4_setup_msi_irqs(struct pc
 			return (hwirq ? hwirq : -ENOMEM);

 		virq = irq_create_mapping(NULL, hwirq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_warn("%s: Failed to map cxl mode MSI to linux irq\n",
 				pci_name(pdev));
 			return -ENOMEM;
@@ -374,7 +374,7 @@ void pnv_cxl_cx4_teardown_msi_irqs(struc
 		return;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;
 		hwirq = virq_to_hw(entry->irq);
 		irq_set_msi_desc(entry->irq, NULL);
diff -u -p a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -186,7 +186,7 @@ int pnv_setup_msi_irqs(struct pci_dev *p
 			return -ENOSPC;
 		}
 		virq = irq_create_mapping(NULL, phb->msi_base + hwirq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_warn("%s: Failed to map MSI to linux irq\n",
 				pci_name(pdev));
 			msi_bitmap_free_hwirqs(&phb->msi_bmp, hwirq, 1);
@@ -217,7 +217,7 @@ void pnv_teardown_msi_irqs(struct pci_de
 		return;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;
 		hwirq = virq_to_hw(entry->irq);
 		irq_set_msi_desc(entry->irq, NULL);
diff -u -p a/arch/powerpc/sysdev/ehv_pic.c b/arch/powerpc/sysdev/ehv_pic.c
--- a/arch/powerpc/sysdev/ehv_pic.c
+++ b/arch/powerpc/sysdev/ehv_pic.c
@@ -168,7 +168,7 @@ unsigned int ehv_pic_get_irq(void)
 		ev_int_iack(0, &irq); /* legacy mode */

 	if (irq == 0xFFFF)    /* 0xFFFF --> no irq is pending */
-		return NO_IRQ;
+		return 0;

 	/*
 	 * this will also setup revmap[] in the slow path for the first
diff -u -p a/arch/powerpc/sysdev/xics/icp-hv.c b/arch/powerpc/sysdev/xics/icp-hv.c
--- a/arch/powerpc/sysdev/xics/icp-hv.c
+++ b/arch/powerpc/sysdev/xics/icp-hv.c
@@ -112,10 +112,10 @@ static unsigned int icp_hv_get_irq(void)
 	unsigned int irq;

 	if (vec == XICS_IRQ_SPURIOUS)
-		return NO_IRQ;
+		return 0;

 	irq = irq_find_mapping(xics_host, vec);
-	if (likely(irq != NO_IRQ)) {
+	if (likely(irq)) {
 		xics_push_cppr(vec);
 		return irq;
 	}
@@ -126,7 +126,7 @@ static unsigned int icp_hv_get_irq(void)
 	/* We might learn about it later, so EOI it */
 	icp_hv_set_xirr(xirr);

-	return NO_IRQ;
+	return 0;
 }

 static void icp_hv_set_cpu_priority(unsigned char cppr)
diff -u -p a/arch/powerpc/sysdev/xics/xics-common.c b/arch/powerpc/sysdev/xics/xics-common.c
--- a/arch/powerpc/sysdev/xics/xics-common.c
+++ b/arch/powerpc/sysdev/xics/xics-common.c
@@ -131,7 +131,7 @@ static void xics_request_ipi(void)
 	unsigned int ipi;

 	ipi = irq_create_mapping(xics_host, XICS_IPI);
-	BUG_ON(ipi == NO_IRQ);
+	BUG_ON(!ipi);

 	/*
 	 * IPIs are marked IRQF_PERCPU. The handler was set in map.
diff -u -p a/arch/powerpc/sysdev/xics/icp-native.c b/arch/powerpc/sysdev/xics/icp-native.c
--- a/arch/powerpc/sysdev/xics/icp-native.c
+++ b/arch/powerpc/sysdev/xics/icp-native.c
@@ -124,10 +124,10 @@ static unsigned int icp_native_get_irq(v
 	unsigned int irq;

 	if (vec == XICS_IRQ_SPURIOUS)
-		return NO_IRQ;
+		return 0;

 	irq = irq_find_mapping(xics_host, vec);
-	if (likely(irq != NO_IRQ)) {
+	if (likely(irq)) {
 		xics_push_cppr(vec);
 		return irq;
 	}
@@ -138,7 +138,7 @@ static unsigned int icp_native_get_irq(v
 	/* We might learn about it later, so EOI it */
 	icp_native_set_xirr(xirr);

-	return NO_IRQ;
+	return 0;
 }

 #ifdef CONFIG_SMP
diff -u -p a/arch/powerpc/sysdev/xics/icp-opal.c b/arch/powerpc/sysdev/xics/icp-opal.c
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -51,14 +51,14 @@ static unsigned int icp_opal_get_irq(voi

 	rc = opal_int_get_xirr(&xirr, false);
 	if (rc < 0)
-		return NO_IRQ;
+		return 0;
 	xirr = be32_to_cpu(xirr);
 	vec = xirr & 0x00ffffff;
 	if (vec == XICS_IRQ_SPURIOUS)
-		return NO_IRQ;
+		return 0;

 	irq = irq_find_mapping(xics_host, vec);
-	if (likely(irq != NO_IRQ)) {
+	if (likely(irq)) {
 		xics_push_cppr(vec);
 		return irq;
 	}
@@ -69,7 +69,7 @@ static unsigned int icp_opal_get_irq(voi
 	/* We might learn about it later, so EOI it */
 	opal_int_eoi(xirr);

-	return NO_IRQ;
+	return 0;
 }

 static void icp_opal_set_cpu_priority(unsigned char cppr)
diff -u -p a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8xx_pic.c
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -79,7 +79,7 @@ unsigned int mpc8xx_get_irq(void)
 	irq = in_be32(&siu_reg->sc_sivec) >> 26;

 	if (irq == PIC_VEC_SPURRIOUS)
-		irq = NO_IRQ;
+		irq = 0;

         return irq_linear_revmap(mpc8xx_pic_host, irq);

diff -u -p a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
--- a/arch/powerpc/sysdev/tsi108_pci.c
+++ b/arch/powerpc/sysdev/tsi108_pci.c
@@ -433,7 +433,7 @@ void tsi108_irq_cascade(struct irq_desc
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = get_pci_source();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
diff -u -p a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -131,7 +131,7 @@ static void fsl_teardown_msi_irqs(struct
 	irq_hw_number_t hwirq;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;
 		hwirq = virq_to_hw(entry->irq);
 		msi_data = irq_get_chip_data(entry->irq);
@@ -250,7 +250,7 @@ static int fsl_setup_msi_irqs(struct pci

 		virq = irq_create_mapping(msi_data->irqhost, hwirq);

-		if (virq == NO_IRQ) {
+		if (!virq) {
 			dev_err(&pdev->dev, "fail mapping hwirq %i\n", hwirq);
 			msi_bitmap_free_hwirqs(&msi_data->bitmap, hwirq, 1);
 			rc = -ENOSPC;
@@ -285,7 +285,7 @@ static irqreturn_t fsl_msi_cascade(int i
 	msir_index = cascade_data->index;

 	if (msir_index >= NR_MSI_REG_MAX)
-		cascade_irq = NO_IRQ;
+		cascade_irq = 0;

 	switch (msi_data->feature & FSL_PIC_IP_MASK) {
 	case FSL_PIC_IP_MPIC:
@@ -315,7 +315,7 @@ static irqreturn_t fsl_msi_cascade(int i
 		cascade_irq = irq_linear_revmap(msi_data->irqhost,
 				msi_hwirq(msi_data, msir_index,
 					  intr_index + have_shift));
-		if (cascade_irq != NO_IRQ) {
+		if (cascade_irq) {
 			generic_handle_irq(cascade_irq);
 			ret = IRQ_HANDLED;
 		}
@@ -337,7 +337,7 @@ static int fsl_of_msi_remove(struct plat
 		if (msi->cascade_array[i]) {
 			virq = msi->cascade_array[i]->virq;

-			BUG_ON(virq == NO_IRQ);
+			BUG_ON(!virq);

 			free_irq(virq, msi->cascade_array[i]);
 			kfree(msi->cascade_array[i]);
@@ -362,7 +362,7 @@ static int fsl_msi_setup_hwirq(struct fs
 	int virt_msir, i, ret;

 	virt_msir = irq_of_parse_and_map(dev->dev.of_node, irq_index);
-	if (virt_msir == NO_IRQ) {
+	if (!virt_msir) {
 		dev_err(&dev->dev, "%s: Cannot translate IRQ index %d\n",
 			__func__, irq_index);
 		return 0;
diff -u -p a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -238,7 +238,7 @@ static int mpic_msgr_probe(struct platfo

 		if (receive_mask & (1 << i)) {
 			msgr->irq = irq_of_parse_and_map(np, irq_index);
-			if (msgr->irq == NO_IRQ) {
+			if (!msgr->irq) {
 				dev_err(&dev->dev,
 						"Missing interrupt specifier");
 				kfree(msgr);
@@ -246,7 +246,7 @@ static int mpic_msgr_probe(struct platfo
 			}
 			irq_index += 1;
 		} else {
-			msgr->irq = NO_IRQ;
+			msgr->irq = 0;
 		}

 		mpic_msgrs[reg_number] = msgr;
diff -u -p a/arch/powerpc/sysdev/mv64x60_pic.c b/arch/powerpc/sysdev/mv64x60_pic.c
--- a/arch/powerpc/sysdev/mv64x60_pic.c
+++ b/arch/powerpc/sysdev/mv64x60_pic.c
@@ -272,7 +272,7 @@ unsigned int mv64x60_get_irq(void)
 	u32 cause;
 	int level1;
 	irq_hw_number_t hwirq;
-	int virq = NO_IRQ;
+	int virq = 0;

 	cause = in_le32(mv64x60_irq_reg_base + MV64X60_IC_CPU0_SELECT_CAUSE);
 	if (cause & MV64X60_SELECT_CAUSE_HIGH) {
diff -u -p a/arch/powerpc/sysdev/ge/ge_pic.c b/arch/powerpc/sysdev/ge/ge_pic.c
--- a/arch/powerpc/sysdev/ge/ge_pic.c
+++ b/arch/powerpc/sysdev/ge/ge_pic.c
@@ -102,7 +102,7 @@ static void gef_pic_cascade(struct irq_d
 	 */
 	cascade_irq = gef_pic_get_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -206,7 +206,7 @@ void __init gef_pic_init(struct device_n

 	/* Map controller */
 	gef_pic_cascade_irq = irq_of_parse_and_map(np, 0);
-	if (gef_pic_cascade_irq == NO_IRQ) {
+	if (!gef_pic_cascade_irq) {
 		printk(KERN_ERR "SBC610: failed to map cascade interrupt");
 		return;
 	}
@@ -228,7 +228,7 @@ void __init gef_pic_init(struct device_n
 unsigned int gef_pic_get_irq(void)
 {
 	u32 cause, mask, active;
-	unsigned int virq = NO_IRQ;
+	unsigned int virq = 0;
 	int hwirq;

 	cause = in_be32(gef_pic_irq_reg_base + GEF_PIC_INTR_STATUS);
diff -u -p a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -110,7 +110,7 @@ static void u3msi_teardown_msi_irqs(stru
 	irq_hw_number_t hwirq;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		hwirq = virq_to_hw(entry->irq);
@@ -155,7 +155,7 @@ static int u3msi_setup_msi_irqs(struct p
 		msg.address_hi = addr >> 32;

 		virq = irq_create_mapping(msi_mpic->irqhost, hwirq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_debug("u3msi: failed mapping hwirq 0x%x\n", hwirq);
 			msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap, hwirq, 1);
 			return -ENOSPC;
diff -u -p a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1649,7 +1649,7 @@ void __init mpic_init(struct mpic *mpic)
 	/* Check if this MPIC is chained from a parent interrupt controller */
 	if (mpic->flags & MPIC_SECONDARY) {
 		int virq = irq_of_parse_and_map(mpic->node, 0);
-		if (virq != NO_IRQ) {
+		if (virq) {
 			printk(KERN_INFO "%s: hooking up to IRQ %d\n",
 					mpic->node->full_name, virq);
 			irq_set_handler_data(virq, mpic);
@@ -1778,13 +1778,13 @@ static unsigned int _mpic_get_one_irq(st
 	if (unlikely(src == mpic->spurious_vec)) {
 		if (mpic->flags & MPIC_SPV_EOI)
 			mpic_eoi(mpic);
-		return NO_IRQ;
+		return 0;
 	}
 	if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
 		printk_ratelimited(KERN_WARNING "%s: Got protected source %d !\n",
 				   mpic->name, (int)src);
 		mpic_eoi(mpic);
-		return NO_IRQ;
+		return 0;
 	}

 	return irq_linear_revmap(mpic->irqhost, src);
@@ -1817,17 +1817,17 @@ unsigned int mpic_get_coreint_irq(void)
 	if (unlikely(src == mpic->spurious_vec)) {
 		if (mpic->flags & MPIC_SPV_EOI)
 			mpic_eoi(mpic);
-		return NO_IRQ;
+		return 0;
 	}
 	if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
 		printk_ratelimited(KERN_WARNING "%s: Got protected source %d !\n",
 				   mpic->name, (int)src);
-		return NO_IRQ;
+		return 0;
 	}

 	return irq_linear_revmap(mpic->irqhost, src);
 #else
-	return NO_IRQ;
+	return 0;
 #endif
 }

@@ -1852,7 +1852,7 @@ void mpic_request_ipis(void)
 	for (i = 0; i < 4; i++) {
 		unsigned int vipi = irq_create_mapping(mpic->irqhost,
 						       mpic->ipi_vecs[0] + i);
-		if (vipi == NO_IRQ) {
+		if (!vipi) {
 			printk(KERN_ERR "Failed to map %s\n", smp_ipi_name[i]);
 			continue;
 		}
diff -u -p a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -102,7 +102,7 @@ static int ppc4xx_setup_msi_irqs(struct
 					__func__);
 		}
 		virq = irq_of_parse_and_map(msi_data->msi_dev, int_no);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			dev_err(&dev->dev, "%s: fail mapping irq\n", __func__);
 			msi_bitmap_free_hwirqs(&msi_data->bitmap, int_no, 1);
 			return -ENOSPC;
@@ -129,7 +129,7 @@ void ppc4xx_teardown_msi_irqs(struct pci
 	dev_dbg(&dev->dev, "PCIE-MSI: tearing down msi irqs\n");

 	for_each_pci_msi_entry(entry, dev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;
 		hwirq = virq_to_hw(entry->irq);
 		irq_set_msi_desc(entry->irq, NULL);
@@ -201,7 +201,7 @@ static int ppc4xx_of_msi_remove(struct p

 	for (i = 0; i < msi_irqs; i++) {
 		virq = msi->msi_virqs[i];
-		if (virq != NO_IRQ)
+		if (virq)
 			irq_dispose_mapping(virq);
 	}

diff -u -p a/arch/powerpc/sysdev/fsl_mpic_err.c b/arch/powerpc/sysdev/fsl_mpic_err.c
--- a/arch/powerpc/sysdev/fsl_mpic_err.c
+++ b/arch/powerpc/sysdev/fsl_mpic_err.c
@@ -115,8 +115,8 @@ static irqreturn_t fsl_error_int_handler
 		errint = __builtin_clz(eisr);
 		cascade_irq = irq_linear_revmap(mpic->irqhost,
 				 mpic->err_int_vecs[errint]);
-		WARN_ON(cascade_irq == NO_IRQ);
-		if (cascade_irq != NO_IRQ) {
+		WARN_ON(!cascade_irq);
+		if (cascade_irq) {
 			generic_handle_irq(cascade_irq);
 		} else {
 			eimr |=  1 << (31 - errint);
@@ -134,7 +134,7 @@ void mpic_err_int_init(struct mpic *mpic
 	int ret;

 	virq = irq_create_mapping(mpic->irqhost, irqnum);
-	if (virq == NO_IRQ) {
+	if (!virq) {
 		pr_err("Error interrupt setup failed\n");
 		return;
 	}
diff -u -p a/arch/powerpc/sysdev/i8259.c b/arch/powerpc/sysdev/i8259.c
--- a/arch/powerpc/sysdev/i8259.c
+++ b/arch/powerpc/sysdev/i8259.c
@@ -68,9 +68,9 @@ unsigned int i8259_irq(void)
 		if (!pci_intack)
 			outb(0x0B, 0x20);	/* ISR register */
 		if(~inb(0x20) & 0x80)
-			irq = NO_IRQ;
+			irq = 0;
 	} else if (irq == 0xff)
-		irq = NO_IRQ;
+		irq = 0;

 	if (lock)
 		raw_spin_unlock(&i8259_lock);
diff -u -p a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
--- a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
@@ -60,7 +60,7 @@ static int hsta_setup_msi_irqs(struct pc
 		}

 		hwirq = ppc4xx_hsta_msi.irq_map[irq];
-		if (hwirq == NO_IRQ) {
+		if (!hwirq) {
 			pr_err("%s: Failed mapping irq %d\n", __func__, irq);
 			return -EINVAL;
 		}
@@ -110,7 +110,7 @@ static void hsta_teardown_msi_irqs(struc
 	int irq;

 	for_each_pci_msi_entry(entry, dev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		irq = hsta_find_hwirq_offset(entry->irq);
@@ -166,7 +166,7 @@ static int hsta_msi_probe(struct platfor
 	for (irq = 0; irq < irq_count; irq++) {
 		ppc4xx_hsta_msi.irq_map[irq] =
 			irq_of_parse_and_map(dev->of_node, irq);
-		if (ppc4xx_hsta_msi.irq_map[irq] == NO_IRQ) {
+		if (!ppc4xx_hsta_msi.irq_map[irq]) {
 			dev_err(dev, "Unable to map IRQ\n");
 			ret = -EINVAL;
 			goto out2;
diff -u -p a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -240,7 +240,7 @@ static int axon_ram_probe(struct platfor
 	device_add_disk(&device->dev, bank->disk);

 	bank->irq_id = irq_of_parse_and_map(device->dev.of_node, 0);
-	if (bank->irq_id == NO_IRQ) {
+	if (!bank->irq_id) {
 		dev_err(&device->dev, "Cannot access ECC interrupt ID\n");
 		rc = -EFAULT;
 		goto failed;
@@ -250,7 +250,7 @@ static int axon_ram_probe(struct platfor
 			AXON_RAM_IRQ_FLAGS, bank->disk->disk_name, device);
 	if (rc != 0) {
 		dev_err(&device->dev, "Cannot register ECC interrupt handler\n");
-		bank->irq_id = NO_IRQ;
+		bank->irq_id = 0;
 		rc = -EFAULT;
 		goto failed;
 	}
@@ -268,7 +268,7 @@ static int axon_ram_probe(struct platfor

 failed:
 	if (bank != NULL) {
-		if (bank->irq_id != NO_IRQ)
+		if (bank->irq_id)
 			free_irq(bank->irq_id, device);
 		if (bank->disk != NULL) {
 			if (bank->disk->major > 0)
diff -u -p a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
--- a/arch/powerpc/sysdev/fsl_gtm.c
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -406,7 +406,7 @@ static int __init fsl_gtm_init(void)
 			unsigned int irq;

 			irq = irq_of_parse_and_map(np, i);
-			if (irq == NO_IRQ) {
+			if (!irq) {
 				pr_err("%s: not enough interrupts specified\n",
 				       np->full_name);
 				goto err;
diff -u -p a/arch/powerpc/sysdev/pmi.c b/arch/powerpc/sysdev/pmi.c
--- a/arch/powerpc/sysdev/pmi.c
+++ b/arch/powerpc/sysdev/pmi.c
@@ -158,7 +158,7 @@ static int pmi_of_probe(struct platform_
 	data->dev = dev;

 	data->irq = irq_of_parse_and_map(np, 0);
-	if (data->irq == NO_IRQ) {
+	if (!data->irq) {
 		printk(KERN_ERR "pmi: invalid interrupt.\n");
 		rc = -EFAULT;
 		goto error_cleanup_iomap;
diff -u -p a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -132,7 +132,7 @@ unsigned int cpm_pic_init(void)
 {
 	struct device_node *np = NULL;
 	struct resource res;
-	unsigned int sirq = NO_IRQ, hwirq, eirq;
+	unsigned int sirq = 0, hwirq, eirq;
 	int ret;

 	pr_debug("cpm_pic_init\n");
@@ -154,7 +154,7 @@ unsigned int cpm_pic_init(void)
 		goto end;

 	sirq = irq_of_parse_and_map(np, 0);
-	if (sirq == NO_IRQ)
+	if (!sirq)
 		goto end;

 	/* Initialize the CPM interrupt controller. */
@@ -168,7 +168,7 @@ unsigned int cpm_pic_init(void)
 	cpm_pic_host = irq_domain_add_linear(np, 64, &cpm_pic_host_ops, NULL);
 	if (cpm_pic_host == NULL) {
 		printk(KERN_ERR "CPM2 PIC: failed to allocate irq host!\n");
-		sirq = NO_IRQ;
+		sirq = 0;
 		goto end;
 	}

@@ -182,7 +182,7 @@ unsigned int cpm_pic_init(void)
 	}

 	eirq = irq_of_parse_and_map(np, 0);
-	if (eirq == NO_IRQ)
+	if (!eirq)
 		goto end;

 	if (setup_irq(eirq, &cpm_error_irqaction))
diff -u -p a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
--- a/arch/powerpc/sysdev/ppc4xx_soc.c
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -109,7 +109,7 @@ static int __init ppc4xx_l2c_probe(void)

 	/* Get and map irq number from device tree */
 	irq = irq_of_parse_and_map(np, 0);
-	if (irq == NO_IRQ) {
+	if (!irq) {
 		printk(KERN_ERR "irq_of_parse_and_map failed\n");
 		of_node_put(np);
 		return -ENODEV;
diff -u -p a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -864,7 +864,7 @@ unsigned int ipic_get_irq(void)
 	irq = ipic_read(primary_ipic->regs, IPIC_SIVCR) & IPIC_SIVCR_VECTOR_MASK;

 	if (irq == 0)    /* 0 --> no irq is pending */
-		return NO_IRQ;
+		return 0;

 	return irq_linear_revmap(primary_ipic->irqhost, irq);
 }
diff -u -p a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -193,10 +193,10 @@ static int __init add_legacy_soc_port(st
 	 */
 	if (tsi && !strcmp(tsi->type, "tsi-bridge"))
 		return add_legacy_port(np, -1, UPIO_TSI, addr, addr,
-				       NO_IRQ, legacy_port_flags, 0);
+				       0, legacy_port_flags, 0);
 	else
 		return add_legacy_port(np, -1, UPIO_MEM, addr, addr,
-				       NO_IRQ, legacy_port_flags, 0);
+				       0, legacy_port_flags, 0);
 }

 static int __init add_legacy_isa_port(struct device_node *np,
@@ -242,7 +242,7 @@ static int __init add_legacy_isa_port(st

 	/* Add port, irq will be dealt with later */
 	return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]),
-			       taddr, NO_IRQ, legacy_port_flags, 0);
+			       taddr, 0, legacy_port_flags, 0);

 }

@@ -314,7 +314,7 @@ static int __init add_legacy_pci_port(st
 	/* Add port, irq will be dealt with later. We passed a translated
 	 * IO port value. It will be fixed up later along with the irq
 	 */
-	return add_legacy_port(np, index, iotype, base, addr, NO_IRQ,
+	return add_legacy_port(np, index, iotype, base, addr, 0,
 			       legacy_port_flags, np != pci_dev);
 }
 #endif
@@ -462,14 +462,14 @@ static void __init fixup_port_irq(int in
 	DBG("fixup_port_irq(%d)\n", index);

 	virq = irq_of_parse_and_map(np, 0);
-	if (virq == NO_IRQ && legacy_serial_infos[index].irq_check_parent) {
+	if (!virq && legacy_serial_infos[index].irq_check_parent) {
 		np = of_get_parent(np);
 		if (np == NULL)
 			return;
 		virq = irq_of_parse_and_map(np, 0);
 		of_node_put(np);
 	}
-	if (virq == NO_IRQ)
+	if (!virq)
 		return;

 	port->irq = virq;
@@ -543,7 +543,7 @@ static int __init serial_dev_init(void)
 		struct plat_serial8250_port *port = &legacy_serial_ports[i];
 		struct device_node *np = legacy_serial_infos[i].np;

-		if (port->irq == NO_IRQ)
+		if (!port->irq)
 			fixup_port_irq(i, np, port);
 		if (port->iotype == UPIO_PORT)
 			fixup_port_pio(i, np, port);
diff -u -p a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -178,7 +178,7 @@ struct pci_dev *of_create_pci_dev(struct
 		dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
 		dev->rom_base_reg = PCI_ROM_ADDRESS;
 		/* Maybe do a default OF mapping here */
-		dev->irq = NO_IRQ;
+		dev->irq = 0;
 	}

 	of_pci_parse_addrs(node, dev);
diff -u -p a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -324,7 +324,7 @@ static int pci_read_irq_line(struct pci_
 			 line, pin);

 		virq = irq_create_mapping(NULL, line);
-		if (virq != NO_IRQ)
+		if (virq)
 			irq_set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
 	} else {
 		pr_debug(" Got one, spec %d cells (0x%08x 0x%08x...) on %s\n",
@@ -333,7 +333,7 @@ static int pci_read_irq_line(struct pci_

 		virq = irq_create_of_mapping(&oirq);
 	}
-	if(virq == NO_IRQ) {
+	if(!virq) {
 		pr_debug(" Failed to map !\n");
 		return -1;
 	}
diff -u -p a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -514,7 +514,7 @@ void __do_irq(struct pt_regs *regs)
 	may_hard_irq_enable();

 	/* And finally process it */
-	if (unlikely(irq == NO_IRQ))
+	if (unlikely(!irq))
 		__this_cpu_inc(irq_stat.spurious_irqs);
 	else
 		generic_handle_irq(irq);
diff -u -p a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -227,7 +227,7 @@ int ibmebus_request_irq(u32 ist, irq_han
 {
 	unsigned int irq = irq_create_mapping(NULL, ist);

-	if (irq == NO_IRQ)
+	if (!irq)
 		return -EINVAL;

 	return request_irq(irq, handler, irq_flags, devname, dev_id);

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Julia Lawall]

On Fri, 2 Sep 2016, Linus Torvalds wrote:

> On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > When I once looked, I thought all drivers using NO_IRQ were specific
> > to powerpc or one of the less common architectures.
>
> powerpc definitely does seem to be the biggest case, with about half
> the instances of NO_IRQ being under arch/powerpc/ (and a few more in
> ppc-specific drivers).
>
> Adding the powerpc maintainers to the list - because it would really
> be nice to get rid of it, or at least make it *so* rare that we don't
> have people re-introducing it again because they thought it was the
> right thing to do.
>
> A fair amount of of it could even be done by some trivial scripting.
> Something like
>
>   git grep -wl NO_IRQ arch/powerpc/ | while read a
>   do
>       sed 's/(\([a-z_]*irq\) != NO_IRQ)/(\1)/' < $a > $a.new
>       sed 's/(\([a-z_]*irq\) == NO_IRQ)/(!\1)/' < $a.new > $a
>   done
>
> does fix at least a few of the cases. It still leaves several
> assignments and "return NO_IRQ;" statements, but a few more
> sed-scripts would take care of most of it. Then remove the #define,
> and do a full build to find any straggling cases.

Like this?

@@
expression e;
@@

e
- != NO_IRQ

@@
expression e;
@@

+!
e
- == NO_IRQ

@@
@@

- NO_IRQ
+ 0

---

Is it always correct to replace return NO_IRQ by return 0?

Completely untested patch below.

julia

diff -u -p a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -511,7 +511,7 @@ unsigned int mpc52xx_get_irq(void)
 			irq |= (MPC52xx_IRQ_L1_PERP << MPC52xx_IRQ_L1_OFFSET);
 		}
 	} else {
-		return NO_IRQ;
+		return 0;
 	}

 	return irq_linear_revmap(mpc52xx_irqhost, irq);
diff -u -p a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -368,7 +368,7 @@ static void chrp_8259_cascade(struct irq
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -514,7 +514,7 @@ static void __init chrp_find_8259(void)
 	}
 	if (chrp_mpic != NULL) {
 		cascade_irq = irq_of_parse_and_map(pic, 0);
-		if (cascade_irq == NO_IRQ)
+		if (!cascade_irq)
 			printk(KERN_ERR "i8259: failed to map cascade irq\n");
 		else
 			irq_set_chained_handler(cascade_irq,
diff -u -p a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -552,7 +552,7 @@ void maple_pci_irq_fixup(struct pci_dev
 	    pci_bus_to_host(dev->bus) == u4_pcie) {
 		printk(KERN_DEBUG "Fixup U4 PCIe IRQ\n");
 		dev->irq = irq_create_mapping(NULL, 1);
-		if (dev->irq != NO_IRQ)
+		if (dev->irq)
 			irq_set_irq_type(dev->irq, IRQ_TYPE_LEVEL_LOW);
 	}

@@ -562,7 +562,7 @@ void maple_pci_irq_fixup(struct pci_dev
 	if (dev->vendor == PCI_VENDOR_ID_AMD &&
 	    dev->device == PCI_DEVICE_ID_AMD_8111_IDE &&
 	    (dev->class & 5) != 5) {
-		dev->irq = NO_IRQ;
+		dev->irq = 0;
 	}

 	DBG(" <- maple_pci_irq_fixup\n");
@@ -648,7 +648,7 @@ int maple_pci_get_legacy_ide_irq(struct
 		return defirq;
 	}
 	irq = irq_of_parse_and_map(np, channel & 0x1);
-	if (irq == NO_IRQ) {
+	if (!irq) {
 		printk("Failed to map onboard IDE interrupt for channel %d\n",
 		       channel);
 		return defirq;
diff -u -p a/arch/powerpc/platforms/embedded6xx/flipper-pic.c b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
--- a/arch/powerpc/platforms/embedded6xx/flipper-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/flipper-pic.c
@@ -181,7 +181,7 @@ unsigned int flipper_pic_get_irq(void)
 	irq_status = in_be32(io_base + FLIPPER_ICR) &
 		     in_be32(io_base + FLIPPER_IMR);
 	if (irq_status == 0)
-		return NO_IRQ;	/* no more IRQs pending */
+		return 0;	/* no more IRQs pending */

 	irq = __ffs(irq_status);
 	return irq_linear_revmap(flipper_irq_host, irq);
diff -u -p a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
--- a/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
+++ b/arch/powerpc/platforms/embedded6xx/hlwd-pic.c
@@ -114,7 +114,7 @@ static unsigned int __hlwd_pic_get_irq(s
 	irq_status = in_be32(io_base + HW_BROADWAY_ICR) &
 		     in_be32(io_base + HW_BROADWAY_IMR);
 	if (irq_status == 0)
-		return NO_IRQ;	/* no more IRQs pending */
+		return 0;	/* no more IRQs pending */

 	irq = __ffs(irq_status);
 	return irq_linear_revmap(h, irq);
@@ -131,7 +131,7 @@ static void hlwd_pic_irq_cascade(struct
 	raw_spin_unlock(&desc->lock);

 	virq = __hlwd_pic_get_irq(irq_domain);
-	if (virq != NO_IRQ)
+	if (virq)
 		generic_handle_irq(virq);
 	else
 		pr_err("spurious interrupt!\n");
diff -u -p a/arch/powerpc/platforms/embedded6xx/mvme5100.c b/arch/powerpc/platforms/embedded6xx/mvme5100.c
--- a/arch/powerpc/platforms/embedded6xx/mvme5100.c
+++ b/arch/powerpc/platforms/embedded6xx/mvme5100.c
@@ -47,7 +47,7 @@ static void mvme5100_8259_cascade(struct
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -84,7 +84,7 @@ static void __init mvme5100_pic_init(voi
 	}

 	cirq = irq_of_parse_and_map(cp, 0);
-	if (cirq == NO_IRQ) {
+	if (!cirq) {
 		pr_warn("mvme5100_pic_init: no cascade interrupt?\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/pasemi/misc.c b/arch/powerpc/platforms/pasemi/misc.c
--- a/arch/powerpc/platforms/pasemi/misc.c
+++ b/arch/powerpc/platforms/pasemi/misc.c
@@ -76,7 +76,7 @@ static int __init pasemi_register_i2c_de
 			}

 			info.irq = irq_of_parse_and_map(node, 0);
-			if (info.irq == NO_IRQ)
+			if (!info.irq)
 				info.irq = -1;

 			if (find_i2c_driver(node, &info) < 0)
diff -u -p a/arch/powerpc/platforms/pasemi/msi.c b/arch/powerpc/platforms/pasemi/msi.c
--- a/arch/powerpc/platforms/pasemi/msi.c
+++ b/arch/powerpc/platforms/pasemi/msi.c
@@ -68,7 +68,7 @@ static void pasemi_msi_teardown_msi_irqs
 	pr_debug("pasemi_msi_teardown_msi_irqs, pdev %p\n", pdev);

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		hwirq = virq_to_hw(entry->irq);
@@ -109,7 +109,7 @@ static int pasemi_msi_setup_msi_irqs(str
 		}

 		virq = irq_create_mapping(msi_mpic->irqhost, hwirq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_debug("pasemi_msi: failed mapping hwirq 0x%x\n",
 				  hwirq);
 			msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap, hwirq,
diff -u -p a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -59,7 +59,7 @@ struct mce_regs {

 static struct mce_regs mce_regs[MAX_MCE_REGS];
 static int num_mce_regs;
-static int nmi_virq = NO_IRQ;
+static int nmi_virq = 0;


 static void __noreturn pas_restart(char *cmd)
@@ -264,7 +264,7 @@ static int pas_machine_check_handler(str
 	srr0 = regs->nip;
 	srr1 = regs->msr;

-	if (nmi_virq != NO_IRQ && mpic_get_mcirq() == nmi_virq) {
+	if (nmi_virq && mpic_get_mcirq() == nmi_virq) {
 		printk(KERN_ERR "NMI delivered\n");
 		debugger(regs);
 		mpic_end_irq(irq_get_irq_data(nmi_virq));
diff -u -p a/arch/powerpc/platforms/85xx/common.c b/arch/powerpc/platforms/85xx/common.c
--- a/arch/powerpc/platforms/85xx/common.c
+++ b/arch/powerpc/platforms/85xx/common.c
@@ -76,7 +76,7 @@ void __init mpc85xx_cpm2_pic_init(void)
 		return;
 	}
 	irq = irq_of_parse_and_map(np, 0);
-	if (irq == NO_IRQ) {
+	if (!irq) {
 		of_node_put(np);
 		printk(KERN_ERR "PIC init: got no IRQ for cpm cascade\n");
 		return;
diff -u -p a/arch/powerpc/platforms/85xx/socrates_fpga_pic.c b/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
--- a/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
+++ b/arch/powerpc/platforms/85xx/socrates_fpga_pic.c
@@ -78,7 +78,7 @@ static inline unsigned int socrates_fpga
 			break;
 	}
 	if (i == 3)
-		return NO_IRQ;
+		return 0;

 	raw_spin_lock_irqsave(&socrates_fpga_pic_lock, flags);
 	cause = socrates_fpga_pic_read(FPGA_PIC_IRQMASK(i));
@@ -103,7 +103,7 @@ static void socrates_fpga_pic_cascade(st
 	 */
 	cascade_irq = socrates_fpga_pic_get_irq(irq);

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);
 	chip->irq_eoi(&desc->irq_data);
 }
@@ -292,7 +292,7 @@ void socrates_fpga_pic_init(struct devic

 	for (i = 0; i < 3; i++) {
 		socrates_fpga_irqs[i] = irq_of_parse_and_map(pic, i);
-		if (socrates_fpga_irqs[i] == NO_IRQ) {
+		if (!socrates_fpga_irqs[i]) {
 			pr_warning("FPGA PIC: can't get irq%d.\n", i);
 			continue;
 		}
diff -u -p a/arch/powerpc/platforms/85xx/mpc85xx_cds.c b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
--- a/arch/powerpc/platforms/85xx/mpc85xx_cds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_cds.c
@@ -196,7 +196,7 @@ static void mpc85xx_8259_cascade_handler
 {
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		/* handle an interrupt from the 8259 */
 		generic_handle_irq(cascade_irq);

@@ -247,7 +247,7 @@ static int mpc85xx_cds_8259_attach(void)
 	}

 	cascade_irq = irq_of_parse_and_map(cascade_node, 0);
-	if (cascade_irq == NO_IRQ) {
+	if (!cascade_irq) {
 		printk(KERN_ERR "Failed to map cascade interrupt\n");
 		return -ENXIO;
 	}
diff -u -p a/arch/powerpc/platforms/85xx/mpc85xx_ds.c b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
--- a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_ds.c
@@ -51,7 +51,7 @@ static void mpc85xx_8259_cascade(struct
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ) {
+	if (cascade_irq) {
 		generic_handle_irq(cascade_irq);
 	}
 	chip->irq_eoi(&desc->irq_data);
@@ -96,7 +96,7 @@ void __init mpc85xx_ds_pic_init(void)
 	}

 	cascade_irq = irq_of_parse_and_map(cascade_node, 0);
-	if (cascade_irq == NO_IRQ) {
+	if (!cascade_irq) {
 		printk(KERN_ERR "Failed to map cascade interrupt\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/83xx/suspend.c b/arch/powerpc/platforms/83xx/suspend.c
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -352,7 +352,7 @@ static int pmc_probe(struct platform_dev
 		return -ENODEV;

 	pmc_irq = irq_of_parse_and_map(np, 0);
-	if (pmc_irq != NO_IRQ) {
+	if (pmc_irq) {
 		ret = request_irq(pmc_irq, pmc_irq_handler, IRQF_SHARED,
 		                  "pmc", ofdev);

@@ -400,7 +400,7 @@ out_syscr:
 out_pmc:
 	iounmap(pmc_regs);
 out:
-	if (pmc_irq != NO_IRQ)
+	if (pmc_irq)
 		free_irq(pmc_irq, ofdev);

 	return ret;
diff -u -p a/arch/powerpc/platforms/83xx/mpc832x_rdb.c b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
--- a/arch/powerpc/platforms/83xx/mpc832x_rdb.c
+++ b/arch/powerpc/platforms/83xx/mpc832x_rdb.c
@@ -89,7 +89,7 @@ static int __init of_fsl_spi_probe(char
 			goto err;

 		ret = of_irq_to_resource(np, 0, &res[1]);
-		if (ret == NO_IRQ)
+		if (!ret)
 			goto err;

 		pdev = platform_device_alloc("mpc83xx_spi", i);
diff -u -p a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -204,7 +204,7 @@ static void pika_setup_critical_temp(str
 	i2c_smbus_write_byte_data(client, 3,  0); /* Tlow */

 	irq = irq_of_parse_and_map(np, 0);
-	if (irq  == NO_IRQ) {
+	if (!irq) {
 		printk(KERN_ERR __FILE__ ": Unable to get ad7414 irq\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/86xx/pic.c b/arch/powerpc/platforms/86xx/pic.c
--- a/arch/powerpc/platforms/86xx/pic.c
+++ b/arch/powerpc/platforms/86xx/pic.c
@@ -22,7 +22,7 @@ static void mpc86xx_8259_cascade(struct
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -58,7 +58,7 @@ void __init mpc86xx_init_irq(void)
 	}

 	cascade_irq = irq_of_parse_and_map(cascade_node, 0);
-	if (cascade_irq == NO_IRQ) {
+	if (!cascade_irq) {
 		printk(KERN_ERR "Failed to map cascade interrupt\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/pseries/msi.c b/arch/powerpc/platforms/pseries/msi.c
--- a/arch/powerpc/platforms/pseries/msi.c
+++ b/arch/powerpc/platforms/pseries/msi.c
@@ -119,7 +119,7 @@ static void rtas_teardown_msi_irqs(struc
 	struct msi_desc *entry;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		irq_set_msi_desc(entry->irq, NULL);
@@ -471,7 +471,7 @@ again:

 		virq = irq_create_mapping(NULL, hwirq);

-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_debug("rtas_msi: Failed mapping hwirq %d\n", hwirq);
 			return -ENOSPC;
 		}
@@ -490,7 +490,7 @@ again:
 static void rtas_msi_pci_irq_fixup(struct pci_dev *pdev)
 {
 	/* No LSI -> leave MSIs (if any) configured */
-	if (pdev->irq == NO_IRQ) {
+	if (!pdev->irq) {
 		dev_dbg(&pdev->dev, "rtas_msi: no LSI, nothing to do.\n");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/pseries/event_sources.c b/arch/powerpc/platforms/pseries/event_sources.c
--- a/arch/powerpc/platforms/pseries/event_sources.c
+++ b/arch/powerpc/platforms/pseries/event_sources.c
@@ -34,7 +34,7 @@ void request_event_sources_irqs(struct d
 		if (count > 15)
 			break;
 		virqs[count] = irq_create_of_mapping(&oirq);
-		if (virqs[count] == NO_IRQ) {
+		if (!virqs[count]) {
 			pr_err("event-sources: Unable to allocate "
 			       "interrupt number for %s\n",
 			       np->full_name);
diff -u -p a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -114,7 +114,7 @@ static void pseries_8259_cascade(struct
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = i8259_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -141,7 +141,7 @@ static void __init pseries_setup_i8259_c
 	}

 	cascade = irq_of_parse_and_map(found, 0);
-	if (cascade == NO_IRQ) {
+	if (!cascade) {
 		printk(KERN_ERR "pic: failed to map cascade interrupt");
 		return;
 	}
diff -u -p a/arch/powerpc/platforms/ps3/interrupt.c b/arch/powerpc/platforms/ps3/interrupt.c
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -192,7 +192,7 @@ static int ps3_virq_setup(enum ps3_cpu_b

 	*virq = irq_create_mapping(NULL, outlet);

-	if (*virq == NO_IRQ) {
+	if (!*virq) {
 		FAIL("%s:%d: irq_create_mapping failed: outlet %lu\n",
 			__func__, __LINE__, outlet);
 		result = -ENOMEM;
@@ -339,7 +339,7 @@ int ps3_event_receive_port_setup(enum ps
 	if (result) {
 		FAIL("%s:%d: lv1_construct_event_receive_port failed: %s\n",
 			__func__, __LINE__, ps3_result(result));
-		*virq = NO_IRQ;
+		*virq = 0;
 		return result;
 	}

@@ -418,7 +418,7 @@ int ps3_sb_event_receive_port_setup(stru
 			" failed: %s\n", __func__, __LINE__,
 			ps3_result(result));
 		ps3_event_receive_port_destroy(*virq);
-		*virq = NO_IRQ;
+		*virq = 0;
 		return result;
 	}

@@ -724,12 +724,12 @@ static unsigned int ps3_get_irq(void)
 	asm volatile("cntlzd %0,%1" : "=r" (plug) : "r" (x));
 	plug &= 0x3f;

-	if (unlikely(plug == NO_IRQ)) {
+	if (unlikely(!plug)) {
 		DBG("%s:%d: no plug found: thread_id %llu\n", __func__,
 			__LINE__, pd->thread_id);
 		dump_bmp(&per_cpu(ps3_private, 0));
 		dump_bmp(&per_cpu(ps3_private, 1));
-		return NO_IRQ;
+		return 0;
 	}

 #if defined(DEBUG)
diff -u -p a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -91,7 +91,7 @@ static void __init ps3_smp_probe(void)
 			result = smp_request_message_ipi(virqs[i], i);

 			if (result)
-				virqs[i] = NO_IRQ;
+				virqs[i] = 0;
 			else
 				ps3_register_ipi_irq(cpu, virqs[i]);
 		}
@@ -112,7 +112,7 @@ void ps3_smp_cleanup_cpu(int cpu)
 	for (i = 0; i < MSG_COUNT; i++) {
 		/* Can't call free_irq from interrupt context. */
 		ps3_event_receive_port_destroy(virqs[i]);
-		virqs[i] = NO_IRQ;
+		virqs[i] = 0;
 	}

 	DBG(" <- %s:%d: (%d)\n", __func__, __LINE__, cpu);
diff -u -p a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -284,7 +284,7 @@ fail_alloc_2:
 fail_alloc_1:
 	ps3_spe_irq_destroy(spu->irqs[0]);
 fail_alloc_0:
-	spu->irqs[0] = spu->irqs[1] = spu->irqs[2] = NO_IRQ;
+	spu->irqs[0] = spu->irqs[1] = spu->irqs[2] = 0;
 	return result;
 }

@@ -334,7 +334,7 @@ static int ps3_destroy_spu(struct spu *s
 	ps3_spe_irq_destroy(spu->irqs[1]);
 	ps3_spe_irq_destroy(spu->irqs[0]);

-	spu->irqs[0] = spu->irqs[1] = spu->irqs[2] = NO_IRQ;
+	spu->irqs[0] = spu->irqs[1] = spu->irqs[2] = 0;

 	spu_unmap(spu);

diff -u -p a/arch/powerpc/platforms/powermac/pic.c b/arch/powerpc/platforms/powermac/pic.c
--- a/arch/powerpc/platforms/powermac/pic.c
+++ b/arch/powerpc/platforms/powermac/pic.c
@@ -251,7 +251,7 @@ static unsigned int pmac_pic_get_irq(voi
 	}
 	raw_spin_unlock_irqrestore(&pmac_pic_lock, flags);
 	if (unlikely(irq < 0))
-		return NO_IRQ;
+		return 0;
 	return irq_linear_revmap(pmac_pic_host, irq);
 }

@@ -389,7 +389,7 @@ static void __init pmac_pic_probe_oldsty
 		out_le32(&pmac_irq_hw[i]->enable, 0);

 	/* Hookup cascade irq */
-	if (slave && pmac_irq_cascade != NO_IRQ)
+	if (slave && pmac_irq_cascade)
 		setup_irq(pmac_irq_cascade, &gatwick_cascade_action);

 	printk(KERN_INFO "irq: System has %d possible interrupts\n", max_irqs);
@@ -444,7 +444,7 @@ static void __init pmac_pic_setup_mpic_n
 	pswitch = of_find_node_by_name(NULL, "programmer-switch");
 	if (pswitch) {
 		nmi_irq = irq_of_parse_and_map(pswitch, 0);
-		if (nmi_irq != NO_IRQ) {
+		if (nmi_irq) {
 			mpic_irq_set_priority(nmi_irq, 9);
 			setup_irq(nmi_irq, &xmon_action);
 		}
diff -u -p a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c
--- a/arch/powerpc/platforms/powermac/low_i2c.c
+++ b/arch/powerpc/platforms/powermac/low_i2c.c
@@ -401,7 +401,7 @@ static int kw_i2c_xfer(struct pmac_i2c_b
 {
 	struct pmac_i2c_host_kw *host = bus->hostdata;
 	u8 mode_reg = host->speed;
-	int use_irq = host->irq != NO_IRQ && !bus->polled;
+	int use_irq = host->irq && !bus->polled;

 	/* Setup mode & subaddress if any */
 	switch(bus->mode) {
@@ -535,7 +535,7 @@ static struct pmac_i2c_host_kw *__init k
 		break;
 	}
 	host->irq = irq_of_parse_and_map(np, 0);
-	if (host->irq == NO_IRQ)
+	if (!host->irq)
 		printk(KERN_WARNING
 		       "low_i2c: Failed to map interrupt for %s\n",
 		       np->full_name);
@@ -557,7 +557,7 @@ static struct pmac_i2c_host_kw *__init k
 	 */
 	if (request_irq(host->irq, kw_i2c_irq, IRQF_NO_SUSPEND,
 			"keywest i2c", host))
-		host->irq = NO_IRQ;
+		host->irq = 0;

 	printk(KERN_INFO "KeyWest i2c @0x%08x irq %d %s\n",
 	       *addrp, host->irq, np->full_name);
diff -u -p a/arch/powerpc/platforms/powermac/pfunc_base.c b/arch/powerpc/platforms/powermac/pfunc_base.c
--- a/arch/powerpc/platforms/powermac/pfunc_base.c
+++ b/arch/powerpc/platforms/powermac/pfunc_base.c
@@ -26,7 +26,7 @@ static irqreturn_t macio_gpio_irq(int ir
 static int macio_do_gpio_irq_enable(struct pmf_function *func)
 {
 	unsigned int irq = irq_of_parse_and_map(func->node, 0);
-	if (irq == NO_IRQ)
+	if (!irq)
 		return -EINVAL;
 	return request_irq(irq, macio_gpio_irq, 0, func->node->name, func);
 }
@@ -34,7 +34,7 @@ static int macio_do_gpio_irq_enable(stru
 static int macio_do_gpio_irq_disable(struct pmf_function *func)
 {
 	unsigned int irq = irq_of_parse_and_map(func->node, 0);
-	if (irq == NO_IRQ)
+	if (!irq)
 		return -EINVAL;
 	free_irq(irq, func);
 	return 0;
diff -u -p a/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c b/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
--- a/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
+++ b/arch/powerpc/platforms/512x/mpc5121_ads_cpld.c
@@ -97,7 +97,7 @@ cpld_pic_get_irq(int offset, u8 ignore,
 	status |= (ignore | mask);

 	if (status == 0xff)
-		return NO_IRQ;
+		return 0;

 	cpld_irq = ffz(status) + offset;

@@ -110,14 +110,14 @@ static void cpld_pic_cascade(struct irq_

 	irq = cpld_pic_get_irq(0, PCI_IGNORE, &cpld_regs->pci_status,
 		&cpld_regs->pci_mask);
-	if (irq != NO_IRQ) {
+	if (irq) {
 		generic_handle_irq(irq);
 		return;
 	}

 	irq = cpld_pic_get_irq(8, MISC_IGNORE, &cpld_regs->misc_status,
 		&cpld_regs->misc_mask);
-	if (irq != NO_IRQ) {
+	if (irq) {
 		generic_handle_irq(irq);
 		return;
 	}
@@ -177,7 +177,7 @@ mpc5121_ads_cpld_pic_init(void)
 		goto end;

 	cascade_irq = irq_of_parse_and_map(np, 0);
-	if (cascade_irq == NO_IRQ)
+	if (!cascade_irq)
 		goto end;

 	/*
diff -u -p a/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
--- a/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
+++ b/arch/powerpc/platforms/512x/mpc512x_lpbfifo.c
@@ -473,7 +473,7 @@ static int mpc512x_lpbfifo_probe(struct
 	}

 	lpbfifo.irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
-	if (lpbfifo.irq == NO_IRQ) {
+	if (!lpbfifo.irq) {
 		dev_err(&pdev->dev, "mapping irq failed\n");
 		ret = -ENODEV;
 		goto err0;
diff -u -p a/arch/powerpc/platforms/8xx/m8xx_setup.c b/arch/powerpc/platforms/8xx/m8xx_setup.c
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -241,6 +241,6 @@ void __init mpc8xx_pics_init(void)
 	}

 	irq = cpm_pic_init();
-	if (irq != NO_IRQ)
+	if (irq)
 		irq_set_chained_handler(irq, cpm_cascade);
 }
diff -u -p a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
--- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
+++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c
@@ -131,7 +131,7 @@ int __init pq2ads_pci_init_irq(void)
 	}

 	irq = irq_of_parse_and_map(np, 0);
-	if (irq == NO_IRQ) {
+	if (!irq) {
 		printk(KERN_ERR "No interrupt in pci pic node.\n");
 		of_node_put(np);
 		goto out;
diff -u -p a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -402,7 +402,7 @@ static int spu_request_irqs(struct spu *
 {
 	int ret = 0;

-	if (spu->irqs[0] != NO_IRQ) {
+	if (spu->irqs[0]) {
 		snprintf(spu->irq_c0, sizeof (spu->irq_c0), "spe%02d.0",
 			 spu->number);
 		ret = request_irq(spu->irqs[0], spu_irq_class_0,
@@ -410,7 +410,7 @@ static int spu_request_irqs(struct spu *
 		if (ret)
 			goto bail0;
 	}
-	if (spu->irqs[1] != NO_IRQ) {
+	if (spu->irqs[1]) {
 		snprintf(spu->irq_c1, sizeof (spu->irq_c1), "spe%02d.1",
 			 spu->number);
 		ret = request_irq(spu->irqs[1], spu_irq_class_1,
@@ -418,7 +418,7 @@ static int spu_request_irqs(struct spu *
 		if (ret)
 			goto bail1;
 	}
-	if (spu->irqs[2] != NO_IRQ) {
+	if (spu->irqs[2]) {
 		snprintf(spu->irq_c2, sizeof (spu->irq_c2), "spe%02d.2",
 			 spu->number);
 		ret = request_irq(spu->irqs[2], spu_irq_class_2,
@@ -429,10 +429,10 @@ static int spu_request_irqs(struct spu *
 	return 0;

 bail2:
-	if (spu->irqs[1] != NO_IRQ)
+	if (spu->irqs[1])
 		free_irq(spu->irqs[1], spu);
 bail1:
-	if (spu->irqs[0] != NO_IRQ)
+	if (spu->irqs[0])
 		free_irq(spu->irqs[0], spu);
 bail0:
 	return ret;
@@ -440,11 +440,11 @@ bail0:

 static void spu_free_irqs(struct spu *spu)
 {
-	if (spu->irqs[0] != NO_IRQ)
+	if (spu->irqs[0])
 		free_irq(spu->irqs[0], spu);
-	if (spu->irqs[1] != NO_IRQ)
+	if (spu->irqs[1])
 		free_irq(spu->irqs[1], spu);
-	if (spu->irqs[2] != NO_IRQ)
+	if (spu->irqs[2])
 		free_irq(spu->irqs[2], spu);
 }

diff -u -p a/arch/powerpc/platforms/cell/interrupt.c b/arch/powerpc/platforms/cell/interrupt.c
--- a/arch/powerpc/platforms/cell/interrupt.c
+++ b/arch/powerpc/platforms/cell/interrupt.c
@@ -123,7 +123,7 @@ static void iic_ioexc_cascade(struct irq
 				unsigned int cirq =
 					irq_linear_revmap(iic_host,
 							  base | cascade);
-				if (cirq != NO_IRQ)
+				if (cirq)
 					generic_handle_irq(cirq);
 			}
 		/* post-ack level interrupts */
@@ -153,10 +153,10 @@ static unsigned int iic_get_irq(void)
 	*(unsigned long *) &pending =
 		in_be64((u64 __iomem *) &iic->regs->pending_destr);
 	if (!(pending.flags & CBE_IIC_IRQ_VALID))
-		return NO_IRQ;
+		return 0;
 	virq = irq_linear_revmap(iic_host, iic_pending_to_hwnum(pending));
-	if (virq == NO_IRQ)
-		return NO_IRQ;
+	if (!virq)
+		return 0;
 	iic->eoi_stack[++iic->eoi_ptr] = pending.prio;
 	BUG_ON(iic->eoi_ptr > 15);
 	return virq;
@@ -198,7 +198,7 @@ static void iic_request_ipi(int msg)
 	int virq;

 	virq = irq_create_mapping(iic_host, iic_msg_to_irq(msg));
-	if (virq == NO_IRQ) {
+	if (!virq) {
 		printk(KERN_ERR
 		       "iic: failed to map IPI %s\n", smp_ipi_name[msg]);
 		return;
@@ -353,7 +353,7 @@ static int __init setup_iic(void)
 		cascade |= 1 << IIC_IRQ_CLASS_SHIFT;
 		cascade |= IIC_UNIT_IIC;
 		cascade = irq_create_mapping(iic_host, cascade);
-		if (cascade == NO_IRQ)
+		if (!cascade)
 			continue;
 		/*
 		 * irq_data is a generic pointer that gets passed back
diff -u -p a/arch/powerpc/platforms/cell/pmu.c b/arch/powerpc/platforms/cell/pmu.c
--- a/arch/powerpc/platforms/cell/pmu.c
+++ b/arch/powerpc/platforms/cell/pmu.c
@@ -385,7 +385,7 @@ static int __init cbe_init_pm_irq(void)
 	for_each_online_node(node) {
 		irq = irq_create_mapping(NULL, IIC_IRQ_IOEX_PMI |
 					       (node << IIC_IRQ_NODE_SHIFT));
-		if (irq == NO_IRQ) {
+		if (!irq) {
 			printk("ERROR: Unable to allocate irq for node %d\n",
 			       node);
 			return -EINVAL;
@@ -412,7 +412,7 @@ void cbe_sync_irq(int node)
 			       IIC_IRQ_IOEX_PMI
 			       | (node << IIC_IRQ_NODE_SHIFT));

-	if (irq == NO_IRQ) {
+	if (!irq) {
 		printk(KERN_WARNING "ERROR, unable to get existing irq %d " \
 		"for node %d\n", irq, node);
 		return;
diff -u -p a/arch/powerpc/platforms/cell/spider-pic.c b/arch/powerpc/platforms/cell/spider-pic.c
--- a/arch/powerpc/platforms/cell/spider-pic.c
+++ b/arch/powerpc/platforms/cell/spider-pic.c
@@ -207,11 +207,11 @@ static void spider_irq_cascade(struct ir

 	cs = in_be32(pic->regs + TIR_CS) >> 24;
 	if (cs == SPIDER_IRQ_INVALID)
-		virq = NO_IRQ;
+		virq = 0;
 	else
 		virq = irq_linear_revmap(pic->host, cs);

-	if (virq != NO_IRQ)
+	if (virq)
 		generic_handle_irq(virq);

 	chip->irq_eoi(&desc->irq_data);
@@ -245,19 +245,19 @@ static unsigned int __init spider_find_c
 	/* Now do the horrible hacks */
 	tmp = of_get_property(of_node, "#interrupt-cells", NULL);
 	if (tmp == NULL)
-		return NO_IRQ;
+		return 0;
 	intsize = *tmp;
 	imap = of_get_property(of_node, "interrupt-map", &imaplen);
 	if (imap == NULL || imaplen < (intsize + 1))
-		return NO_IRQ;
+		return 0;
 	iic = of_find_node_by_phandle(imap[intsize]);
 	if (iic == NULL)
-		return NO_IRQ;
+		return 0;
 	imap += intsize + 1;
 	tmp = of_get_property(iic, "#interrupt-cells", NULL);
 	if (tmp == NULL) {
 		of_node_put(iic);
-		return NO_IRQ;
+		return 0;
 	}
 	intsize = *tmp;
 	/* Assume unit is last entry of interrupt specifier */
@@ -266,7 +266,7 @@ static unsigned int __init spider_find_c
 	tmp = of_get_property(iic, "ibm,interrupt-server-ranges", NULL);
 	if (tmp == NULL) {
 		of_node_put(iic);
-		return NO_IRQ;
+		return 0;
 	}
 	/* ugly as hell but works for now */
 	pic->node_id = (*tmp) >> 1;
@@ -281,7 +281,7 @@ static unsigned int __init spider_find_c
 				  (pic->node_id << IIC_IRQ_NODE_SHIFT) |
 				  (2 << IIC_IRQ_CLASS_SHIFT) |
 				  unit);
-	if (virq == NO_IRQ)
+	if (!virq)
 		printk(KERN_ERR "spider_pic: failed to map cascade !");
 	return virq;
 }
@@ -318,7 +318,7 @@ static void __init spider_init_one(struc

 	/* Hook up the cascade interrupt to the iic and nodeid */
 	virq = spider_find_cascade_and_node(pic);
-	if (virq == NO_IRQ)
+	if (!virq)
 		return;
 	irq_set_handler_data(virq, pic);
 	irq_set_chained_handler(virq, spider_irq_cascade);
diff -u -p a/arch/powerpc/platforms/cell/spu_manage.c b/arch/powerpc/platforms/cell/spu_manage.c
--- a/arch/powerpc/platforms/cell/spu_manage.c
+++ b/arch/powerpc/platforms/cell/spu_manage.c
@@ -105,7 +105,7 @@ static int __init spu_map_interrupts_old
 	spu->irqs[2] = irq_create_mapping(NULL, IIC_IRQ_CLASS_2 | isrc);

 	/* Right now, we only fail if class 2 failed */
-	return spu->irqs[2] == NO_IRQ ? -EINVAL : 0;
+	return !spu->irqs[2] ? -EINVAL : 0;
 }

 static void __iomem * __init spu_map_prop_old(struct spu *spu,
@@ -191,7 +191,7 @@ static int __init spu_map_interrupts(str
 		pr_debug("  irq %d no 0x%x on %s\n", i, oirq.args[0],
 			 oirq.np->full_name);
 		spu->irqs[i] = irq_create_of_mapping(&oirq);
-		if (spu->irqs[i] == NO_IRQ) {
+		if (!spu->irqs[i]) {
 			pr_debug("spu_new: failed to map it !\n");
 			goto err;
 		}
@@ -202,7 +202,7 @@ err:
 	pr_debug("failed to map irq %x for spu %s\n", *oirq.args,
 		spu->name);
 	for (; i >= 0; i--) {
-		if (spu->irqs[i] != NO_IRQ)
+		if (spu->irqs[i])
 			irq_dispose_mapping(spu->irqs[i]);
 	}
 	return ret;
diff -u -p a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -411,7 +411,7 @@ static void cell_iommu_enable_hardware(s

 	virq = irq_create_mapping(NULL,
 			IIC_IRQ_IOEX_ATI | (iommu->nid << IIC_IRQ_NODE_SHIFT));
-	BUG_ON(virq == NO_IRQ);
+	BUG_ON(!virq);

 	ret = request_irq(virq, ioc_interrupt, 0, iommu->name, iommu);
 	BUG_ON(ret);
diff -u -p a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -271,7 +271,7 @@ static int axon_msi_setup_msi_irqs(struc

 	for_each_pci_msi_entry(entry, dev) {
 		virq = irq_create_direct_mapping(msic->irq_domain);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			dev_warn(&dev->dev,
 				 "axon_msi: virq allocation failed!\n");
 			return -1;
@@ -293,7 +293,7 @@ static void axon_msi_teardown_msi_irqs(s
 	dev_dbg(&dev->dev, "axon_msi: tearing down msi irqs\n");

 	for_each_pci_msi_entry(entry, dev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		irq_set_msi_desc(entry->irq, NULL);
@@ -375,7 +375,7 @@ static int axon_msi_probe(struct platfor
 	}

 	virq = irq_of_parse_and_map(dn, 0);
-	if (virq == NO_IRQ) {
+	if (!virq) {
 		printk(KERN_ERR "axon_msi: irq parse and map failed for %s\n",
 		       dn->full_name);
 		goto out_free_fifo;
diff -u -p a/arch/powerpc/platforms/powernv/opal-irqchip.c b/arch/powerpc/platforms/powernv/opal-irqchip.c
--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
+++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
@@ -222,7 +222,7 @@ int __init opal_event_init(void)
 		/* Get hardware and virtual IRQ */
 		irq = be32_to_cpup(irqs);
 		virq = irq_create_mapping(NULL, irq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_warn("Failed to map irq 0x%x\n", irq);
 			continue;
 		}
@@ -260,7 +260,7 @@ machine_arch_initcall(powernv, opal_even
 int opal_event_request(unsigned int opal_event_nr)
 {
 	if (WARN_ON_ONCE(!opal_event_irqchip.domain))
-		return NO_IRQ;
+		return 0;

 	return irq_create_mapping(opal_event_irqchip.domain, opal_event_nr);
 }
diff -u -p a/arch/powerpc/platforms/powernv/pci-cxl.c b/arch/powerpc/platforms/powernv/pci-cxl.c
--- a/arch/powerpc/platforms/powernv/pci-cxl.c
+++ b/arch/powerpc/platforms/powernv/pci-cxl.c
@@ -344,7 +344,7 @@ int pnv_cxl_cx4_setup_msi_irqs(struct pc
 			return (hwirq ? hwirq : -ENOMEM);

 		virq = irq_create_mapping(NULL, hwirq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_warn("%s: Failed to map cxl mode MSI to linux irq\n",
 				pci_name(pdev));
 			return -ENOMEM;
@@ -374,7 +374,7 @@ void pnv_cxl_cx4_teardown_msi_irqs(struc
 		return;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;
 		hwirq = virq_to_hw(entry->irq);
 		irq_set_msi_desc(entry->irq, NULL);
diff -u -p a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -186,7 +186,7 @@ int pnv_setup_msi_irqs(struct pci_dev *p
 			return -ENOSPC;
 		}
 		virq = irq_create_mapping(NULL, phb->msi_base + hwirq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_warn("%s: Failed to map MSI to linux irq\n",
 				pci_name(pdev));
 			msi_bitmap_free_hwirqs(&phb->msi_bmp, hwirq, 1);
@@ -217,7 +217,7 @@ void pnv_teardown_msi_irqs(struct pci_de
 		return;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;
 		hwirq = virq_to_hw(entry->irq);
 		irq_set_msi_desc(entry->irq, NULL);
diff -u -p a/arch/powerpc/sysdev/ehv_pic.c b/arch/powerpc/sysdev/ehv_pic.c
--- a/arch/powerpc/sysdev/ehv_pic.c
+++ b/arch/powerpc/sysdev/ehv_pic.c
@@ -168,7 +168,7 @@ unsigned int ehv_pic_get_irq(void)
 		ev_int_iack(0, &irq); /* legacy mode */

 	if (irq == 0xFFFF)    /* 0xFFFF --> no irq is pending */
-		return NO_IRQ;
+		return 0;

 	/*
 	 * this will also setup revmap[] in the slow path for the first
diff -u -p a/arch/powerpc/sysdev/xics/icp-hv.c b/arch/powerpc/sysdev/xics/icp-hv.c
--- a/arch/powerpc/sysdev/xics/icp-hv.c
+++ b/arch/powerpc/sysdev/xics/icp-hv.c
@@ -112,10 +112,10 @@ static unsigned int icp_hv_get_irq(void)
 	unsigned int irq;

 	if (vec == XICS_IRQ_SPURIOUS)
-		return NO_IRQ;
+		return 0;

 	irq = irq_find_mapping(xics_host, vec);
-	if (likely(irq != NO_IRQ)) {
+	if (likely(irq)) {
 		xics_push_cppr(vec);
 		return irq;
 	}
@@ -126,7 +126,7 @@ static unsigned int icp_hv_get_irq(void)
 	/* We might learn about it later, so EOI it */
 	icp_hv_set_xirr(xirr);

-	return NO_IRQ;
+	return 0;
 }

 static void icp_hv_set_cpu_priority(unsigned char cppr)
diff -u -p a/arch/powerpc/sysdev/xics/xics-common.c b/arch/powerpc/sysdev/xics/xics-common.c
--- a/arch/powerpc/sysdev/xics/xics-common.c
+++ b/arch/powerpc/sysdev/xics/xics-common.c
@@ -131,7 +131,7 @@ static void xics_request_ipi(void)
 	unsigned int ipi;

 	ipi = irq_create_mapping(xics_host, XICS_IPI);
-	BUG_ON(ipi == NO_IRQ);
+	BUG_ON(!ipi);

 	/*
 	 * IPIs are marked IRQF_PERCPU. The handler was set in map.
diff -u -p a/arch/powerpc/sysdev/xics/icp-native.c b/arch/powerpc/sysdev/xics/icp-native.c
--- a/arch/powerpc/sysdev/xics/icp-native.c
+++ b/arch/powerpc/sysdev/xics/icp-native.c
@@ -124,10 +124,10 @@ static unsigned int icp_native_get_irq(v
 	unsigned int irq;

 	if (vec == XICS_IRQ_SPURIOUS)
-		return NO_IRQ;
+		return 0;

 	irq = irq_find_mapping(xics_host, vec);
-	if (likely(irq != NO_IRQ)) {
+	if (likely(irq)) {
 		xics_push_cppr(vec);
 		return irq;
 	}
@@ -138,7 +138,7 @@ static unsigned int icp_native_get_irq(v
 	/* We might learn about it later, so EOI it */
 	icp_native_set_xirr(xirr);

-	return NO_IRQ;
+	return 0;
 }

 #ifdef CONFIG_SMP
diff -u -p a/arch/powerpc/sysdev/xics/icp-opal.c b/arch/powerpc/sysdev/xics/icp-opal.c
--- a/arch/powerpc/sysdev/xics/icp-opal.c
+++ b/arch/powerpc/sysdev/xics/icp-opal.c
@@ -51,14 +51,14 @@ static unsigned int icp_opal_get_irq(voi

 	rc = opal_int_get_xirr(&xirr, false);
 	if (rc < 0)
-		return NO_IRQ;
+		return 0;
 	xirr = be32_to_cpu(xirr);
 	vec = xirr & 0x00ffffff;
 	if (vec == XICS_IRQ_SPURIOUS)
-		return NO_IRQ;
+		return 0;

 	irq = irq_find_mapping(xics_host, vec);
-	if (likely(irq != NO_IRQ)) {
+	if (likely(irq)) {
 		xics_push_cppr(vec);
 		return irq;
 	}
@@ -69,7 +69,7 @@ static unsigned int icp_opal_get_irq(voi
 	/* We might learn about it later, so EOI it */
 	opal_int_eoi(xirr);

-	return NO_IRQ;
+	return 0;
 }

 static void icp_opal_set_cpu_priority(unsigned char cppr)
diff -u -p a/arch/powerpc/sysdev/mpc8xx_pic.c b/arch/powerpc/sysdev/mpc8xx_pic.c
--- a/arch/powerpc/sysdev/mpc8xx_pic.c
+++ b/arch/powerpc/sysdev/mpc8xx_pic.c
@@ -79,7 +79,7 @@ unsigned int mpc8xx_get_irq(void)
 	irq = in_be32(&siu_reg->sc_sivec) >> 26;

 	if (irq == PIC_VEC_SPURRIOUS)
-		irq = NO_IRQ;
+		irq = 0;

         return irq_linear_revmap(mpc8xx_pic_host, irq);

diff -u -p a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
--- a/arch/powerpc/sysdev/tsi108_pci.c
+++ b/arch/powerpc/sysdev/tsi108_pci.c
@@ -433,7 +433,7 @@ void tsi108_irq_cascade(struct irq_desc
 	struct irq_chip *chip = irq_desc_get_chip(desc);
 	unsigned int cascade_irq = get_pci_source();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
diff -u -p a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -131,7 +131,7 @@ static void fsl_teardown_msi_irqs(struct
 	irq_hw_number_t hwirq;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;
 		hwirq = virq_to_hw(entry->irq);
 		msi_data = irq_get_chip_data(entry->irq);
@@ -250,7 +250,7 @@ static int fsl_setup_msi_irqs(struct pci

 		virq = irq_create_mapping(msi_data->irqhost, hwirq);

-		if (virq == NO_IRQ) {
+		if (!virq) {
 			dev_err(&pdev->dev, "fail mapping hwirq %i\n", hwirq);
 			msi_bitmap_free_hwirqs(&msi_data->bitmap, hwirq, 1);
 			rc = -ENOSPC;
@@ -285,7 +285,7 @@ static irqreturn_t fsl_msi_cascade(int i
 	msir_index = cascade_data->index;

 	if (msir_index >= NR_MSI_REG_MAX)
-		cascade_irq = NO_IRQ;
+		cascade_irq = 0;

 	switch (msi_data->feature & FSL_PIC_IP_MASK) {
 	case FSL_PIC_IP_MPIC:
@@ -315,7 +315,7 @@ static irqreturn_t fsl_msi_cascade(int i
 		cascade_irq = irq_linear_revmap(msi_data->irqhost,
 				msi_hwirq(msi_data, msir_index,
 					  intr_index + have_shift));
-		if (cascade_irq != NO_IRQ) {
+		if (cascade_irq) {
 			generic_handle_irq(cascade_irq);
 			ret = IRQ_HANDLED;
 		}
@@ -337,7 +337,7 @@ static int fsl_of_msi_remove(struct plat
 		if (msi->cascade_array[i]) {
 			virq = msi->cascade_array[i]->virq;

-			BUG_ON(virq == NO_IRQ);
+			BUG_ON(!virq);

 			free_irq(virq, msi->cascade_array[i]);
 			kfree(msi->cascade_array[i]);
@@ -362,7 +362,7 @@ static int fsl_msi_setup_hwirq(struct fs
 	int virt_msir, i, ret;

 	virt_msir = irq_of_parse_and_map(dev->dev.of_node, irq_index);
-	if (virt_msir == NO_IRQ) {
+	if (!virt_msir) {
 		dev_err(&dev->dev, "%s: Cannot translate IRQ index %d\n",
 			__func__, irq_index);
 		return 0;
diff -u -p a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -238,7 +238,7 @@ static int mpic_msgr_probe(struct platfo

 		if (receive_mask & (1 << i)) {
 			msgr->irq = irq_of_parse_and_map(np, irq_index);
-			if (msgr->irq == NO_IRQ) {
+			if (!msgr->irq) {
 				dev_err(&dev->dev,
 						"Missing interrupt specifier");
 				kfree(msgr);
@@ -246,7 +246,7 @@ static int mpic_msgr_probe(struct platfo
 			}
 			irq_index += 1;
 		} else {
-			msgr->irq = NO_IRQ;
+			msgr->irq = 0;
 		}

 		mpic_msgrs[reg_number] = msgr;
diff -u -p a/arch/powerpc/sysdev/mv64x60_pic.c b/arch/powerpc/sysdev/mv64x60_pic.c
--- a/arch/powerpc/sysdev/mv64x60_pic.c
+++ b/arch/powerpc/sysdev/mv64x60_pic.c
@@ -272,7 +272,7 @@ unsigned int mv64x60_get_irq(void)
 	u32 cause;
 	int level1;
 	irq_hw_number_t hwirq;
-	int virq = NO_IRQ;
+	int virq = 0;

 	cause = in_le32(mv64x60_irq_reg_base + MV64X60_IC_CPU0_SELECT_CAUSE);
 	if (cause & MV64X60_SELECT_CAUSE_HIGH) {
diff -u -p a/arch/powerpc/sysdev/ge/ge_pic.c b/arch/powerpc/sysdev/ge/ge_pic.c
--- a/arch/powerpc/sysdev/ge/ge_pic.c
+++ b/arch/powerpc/sysdev/ge/ge_pic.c
@@ -102,7 +102,7 @@ static void gef_pic_cascade(struct irq_d
 	 */
 	cascade_irq = gef_pic_get_irq();

-	if (cascade_irq != NO_IRQ)
+	if (cascade_irq)
 		generic_handle_irq(cascade_irq);

 	chip->irq_eoi(&desc->irq_data);
@@ -206,7 +206,7 @@ void __init gef_pic_init(struct device_n

 	/* Map controller */
 	gef_pic_cascade_irq = irq_of_parse_and_map(np, 0);
-	if (gef_pic_cascade_irq == NO_IRQ) {
+	if (!gef_pic_cascade_irq) {
 		printk(KERN_ERR "SBC610: failed to map cascade interrupt");
 		return;
 	}
@@ -228,7 +228,7 @@ void __init gef_pic_init(struct device_n
 unsigned int gef_pic_get_irq(void)
 {
 	u32 cause, mask, active;
-	unsigned int virq = NO_IRQ;
+	unsigned int virq = 0;
 	int hwirq;

 	cause = in_be32(gef_pic_irq_reg_base + GEF_PIC_INTR_STATUS);
diff -u -p a/arch/powerpc/sysdev/mpic_u3msi.c b/arch/powerpc/sysdev/mpic_u3msi.c
--- a/arch/powerpc/sysdev/mpic_u3msi.c
+++ b/arch/powerpc/sysdev/mpic_u3msi.c
@@ -110,7 +110,7 @@ static void u3msi_teardown_msi_irqs(stru
 	irq_hw_number_t hwirq;

 	for_each_pci_msi_entry(entry, pdev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		hwirq = virq_to_hw(entry->irq);
@@ -155,7 +155,7 @@ static int u3msi_setup_msi_irqs(struct p
 		msg.address_hi = addr >> 32;

 		virq = irq_create_mapping(msi_mpic->irqhost, hwirq);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			pr_debug("u3msi: failed mapping hwirq 0x%x\n", hwirq);
 			msi_bitmap_free_hwirqs(&msi_mpic->msi_bitmap, hwirq, 1);
 			return -ENOSPC;
diff -u -p a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1649,7 +1649,7 @@ void __init mpic_init(struct mpic *mpic)
 	/* Check if this MPIC is chained from a parent interrupt controller */
 	if (mpic->flags & MPIC_SECONDARY) {
 		int virq = irq_of_parse_and_map(mpic->node, 0);
-		if (virq != NO_IRQ) {
+		if (virq) {
 			printk(KERN_INFO "%s: hooking up to IRQ %d\n",
 					mpic->node->full_name, virq);
 			irq_set_handler_data(virq, mpic);
@@ -1778,13 +1778,13 @@ static unsigned int _mpic_get_one_irq(st
 	if (unlikely(src == mpic->spurious_vec)) {
 		if (mpic->flags & MPIC_SPV_EOI)
 			mpic_eoi(mpic);
-		return NO_IRQ;
+		return 0;
 	}
 	if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
 		printk_ratelimited(KERN_WARNING "%s: Got protected source %d !\n",
 				   mpic->name, (int)src);
 		mpic_eoi(mpic);
-		return NO_IRQ;
+		return 0;
 	}

 	return irq_linear_revmap(mpic->irqhost, src);
@@ -1817,17 +1817,17 @@ unsigned int mpic_get_coreint_irq(void)
 	if (unlikely(src == mpic->spurious_vec)) {
 		if (mpic->flags & MPIC_SPV_EOI)
 			mpic_eoi(mpic);
-		return NO_IRQ;
+		return 0;
 	}
 	if (unlikely(mpic->protected && test_bit(src, mpic->protected))) {
 		printk_ratelimited(KERN_WARNING "%s: Got protected source %d !\n",
 				   mpic->name, (int)src);
-		return NO_IRQ;
+		return 0;
 	}

 	return irq_linear_revmap(mpic->irqhost, src);
 #else
-	return NO_IRQ;
+	return 0;
 #endif
 }

@@ -1852,7 +1852,7 @@ void mpic_request_ipis(void)
 	for (i = 0; i < 4; i++) {
 		unsigned int vipi = irq_create_mapping(mpic->irqhost,
 						       mpic->ipi_vecs[0] + i);
-		if (vipi == NO_IRQ) {
+		if (!vipi) {
 			printk(KERN_ERR "Failed to map %s\n", smp_ipi_name[i]);
 			continue;
 		}
diff -u -p a/arch/powerpc/sysdev/ppc4xx_msi.c b/arch/powerpc/sysdev/ppc4xx_msi.c
--- a/arch/powerpc/sysdev/ppc4xx_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_msi.c
@@ -102,7 +102,7 @@ static int ppc4xx_setup_msi_irqs(struct
 					__func__);
 		}
 		virq = irq_of_parse_and_map(msi_data->msi_dev, int_no);
-		if (virq == NO_IRQ) {
+		if (!virq) {
 			dev_err(&dev->dev, "%s: fail mapping irq\n", __func__);
 			msi_bitmap_free_hwirqs(&msi_data->bitmap, int_no, 1);
 			return -ENOSPC;
@@ -129,7 +129,7 @@ void ppc4xx_teardown_msi_irqs(struct pci
 	dev_dbg(&dev->dev, "PCIE-MSI: tearing down msi irqs\n");

 	for_each_pci_msi_entry(entry, dev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;
 		hwirq = virq_to_hw(entry->irq);
 		irq_set_msi_desc(entry->irq, NULL);
@@ -201,7 +201,7 @@ static int ppc4xx_of_msi_remove(struct p

 	for (i = 0; i < msi_irqs; i++) {
 		virq = msi->msi_virqs[i];
-		if (virq != NO_IRQ)
+		if (virq)
 			irq_dispose_mapping(virq);
 	}

diff -u -p a/arch/powerpc/sysdev/fsl_mpic_err.c b/arch/powerpc/sysdev/fsl_mpic_err.c
--- a/arch/powerpc/sysdev/fsl_mpic_err.c
+++ b/arch/powerpc/sysdev/fsl_mpic_err.c
@@ -115,8 +115,8 @@ static irqreturn_t fsl_error_int_handler
 		errint = __builtin_clz(eisr);
 		cascade_irq = irq_linear_revmap(mpic->irqhost,
 				 mpic->err_int_vecs[errint]);
-		WARN_ON(cascade_irq == NO_IRQ);
-		if (cascade_irq != NO_IRQ) {
+		WARN_ON(!cascade_irq);
+		if (cascade_irq) {
 			generic_handle_irq(cascade_irq);
 		} else {
 			eimr |=  1 << (31 - errint);
@@ -134,7 +134,7 @@ void mpic_err_int_init(struct mpic *mpic
 	int ret;

 	virq = irq_create_mapping(mpic->irqhost, irqnum);
-	if (virq == NO_IRQ) {
+	if (!virq) {
 		pr_err("Error interrupt setup failed\n");
 		return;
 	}
diff -u -p a/arch/powerpc/sysdev/i8259.c b/arch/powerpc/sysdev/i8259.c
--- a/arch/powerpc/sysdev/i8259.c
+++ b/arch/powerpc/sysdev/i8259.c
@@ -68,9 +68,9 @@ unsigned int i8259_irq(void)
 		if (!pci_intack)
 			outb(0x0B, 0x20);	/* ISR register */
 		if(~inb(0x20) & 0x80)
-			irq = NO_IRQ;
+			irq = 0;
 	} else if (irq == 0xff)
-		irq = NO_IRQ;
+		irq = 0;

 	if (lock)
 		raw_spin_unlock(&i8259_lock);
diff -u -p a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
--- a/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
+++ b/arch/powerpc/sysdev/ppc4xx_hsta_msi.c
@@ -60,7 +60,7 @@ static int hsta_setup_msi_irqs(struct pc
 		}

 		hwirq = ppc4xx_hsta_msi.irq_map[irq];
-		if (hwirq == NO_IRQ) {
+		if (!hwirq) {
 			pr_err("%s: Failed mapping irq %d\n", __func__, irq);
 			return -EINVAL;
 		}
@@ -110,7 +110,7 @@ static void hsta_teardown_msi_irqs(struc
 	int irq;

 	for_each_pci_msi_entry(entry, dev) {
-		if (entry->irq == NO_IRQ)
+		if (!entry->irq)
 			continue;

 		irq = hsta_find_hwirq_offset(entry->irq);
@@ -166,7 +166,7 @@ static int hsta_msi_probe(struct platfor
 	for (irq = 0; irq < irq_count; irq++) {
 		ppc4xx_hsta_msi.irq_map[irq] =
 			irq_of_parse_and_map(dev->of_node, irq);
-		if (ppc4xx_hsta_msi.irq_map[irq] == NO_IRQ) {
+		if (!ppc4xx_hsta_msi.irq_map[irq]) {
 			dev_err(dev, "Unable to map IRQ\n");
 			ret = -EINVAL;
 			goto out2;
diff -u -p a/arch/powerpc/sysdev/axonram.c b/arch/powerpc/sysdev/axonram.c
--- a/arch/powerpc/sysdev/axonram.c
+++ b/arch/powerpc/sysdev/axonram.c
@@ -240,7 +240,7 @@ static int axon_ram_probe(struct platfor
 	device_add_disk(&device->dev, bank->disk);

 	bank->irq_id = irq_of_parse_and_map(device->dev.of_node, 0);
-	if (bank->irq_id == NO_IRQ) {
+	if (!bank->irq_id) {
 		dev_err(&device->dev, "Cannot access ECC interrupt ID\n");
 		rc = -EFAULT;
 		goto failed;
@@ -250,7 +250,7 @@ static int axon_ram_probe(struct platfor
 			AXON_RAM_IRQ_FLAGS, bank->disk->disk_name, device);
 	if (rc != 0) {
 		dev_err(&device->dev, "Cannot register ECC interrupt handler\n");
-		bank->irq_id = NO_IRQ;
+		bank->irq_id = 0;
 		rc = -EFAULT;
 		goto failed;
 	}
@@ -268,7 +268,7 @@ static int axon_ram_probe(struct platfor

 failed:
 	if (bank != NULL) {
-		if (bank->irq_id != NO_IRQ)
+		if (bank->irq_id)
 			free_irq(bank->irq_id, device);
 		if (bank->disk != NULL) {
 			if (bank->disk->major > 0)
diff -u -p a/arch/powerpc/sysdev/fsl_gtm.c b/arch/powerpc/sysdev/fsl_gtm.c
--- a/arch/powerpc/sysdev/fsl_gtm.c
+++ b/arch/powerpc/sysdev/fsl_gtm.c
@@ -406,7 +406,7 @@ static int __init fsl_gtm_init(void)
 			unsigned int irq;

 			irq = irq_of_parse_and_map(np, i);
-			if (irq == NO_IRQ) {
+			if (!irq) {
 				pr_err("%s: not enough interrupts specified\n",
 				       np->full_name);
 				goto err;
diff -u -p a/arch/powerpc/sysdev/pmi.c b/arch/powerpc/sysdev/pmi.c
--- a/arch/powerpc/sysdev/pmi.c
+++ b/arch/powerpc/sysdev/pmi.c
@@ -158,7 +158,7 @@ static int pmi_of_probe(struct platform_
 	data->dev = dev;

 	data->irq = irq_of_parse_and_map(np, 0);
-	if (data->irq == NO_IRQ) {
+	if (!data->irq) {
 		printk(KERN_ERR "pmi: invalid interrupt.\n");
 		rc = -EFAULT;
 		goto error_cleanup_iomap;
diff -u -p a/arch/powerpc/sysdev/cpm1.c b/arch/powerpc/sysdev/cpm1.c
--- a/arch/powerpc/sysdev/cpm1.c
+++ b/arch/powerpc/sysdev/cpm1.c
@@ -132,7 +132,7 @@ unsigned int cpm_pic_init(void)
 {
 	struct device_node *np = NULL;
 	struct resource res;
-	unsigned int sirq = NO_IRQ, hwirq, eirq;
+	unsigned int sirq = 0, hwirq, eirq;
 	int ret;

 	pr_debug("cpm_pic_init\n");
@@ -154,7 +154,7 @@ unsigned int cpm_pic_init(void)
 		goto end;

 	sirq = irq_of_parse_and_map(np, 0);
-	if (sirq == NO_IRQ)
+	if (!sirq)
 		goto end;

 	/* Initialize the CPM interrupt controller. */
@@ -168,7 +168,7 @@ unsigned int cpm_pic_init(void)
 	cpm_pic_host = irq_domain_add_linear(np, 64, &cpm_pic_host_ops, NULL);
 	if (cpm_pic_host == NULL) {
 		printk(KERN_ERR "CPM2 PIC: failed to allocate irq host!\n");
-		sirq = NO_IRQ;
+		sirq = 0;
 		goto end;
 	}

@@ -182,7 +182,7 @@ unsigned int cpm_pic_init(void)
 	}

 	eirq = irq_of_parse_and_map(np, 0);
-	if (eirq == NO_IRQ)
+	if (!eirq)
 		goto end;

 	if (setup_irq(eirq, &cpm_error_irqaction))
diff -u -p a/arch/powerpc/sysdev/ppc4xx_soc.c b/arch/powerpc/sysdev/ppc4xx_soc.c
--- a/arch/powerpc/sysdev/ppc4xx_soc.c
+++ b/arch/powerpc/sysdev/ppc4xx_soc.c
@@ -109,7 +109,7 @@ static int __init ppc4xx_l2c_probe(void)

 	/* Get and map irq number from device tree */
 	irq = irq_of_parse_and_map(np, 0);
-	if (irq == NO_IRQ) {
+	if (!irq) {
 		printk(KERN_ERR "irq_of_parse_and_map failed\n");
 		of_node_put(np);
 		return -ENODEV;
diff -u -p a/arch/powerpc/sysdev/ipic.c b/arch/powerpc/sysdev/ipic.c
--- a/arch/powerpc/sysdev/ipic.c
+++ b/arch/powerpc/sysdev/ipic.c
@@ -864,7 +864,7 @@ unsigned int ipic_get_irq(void)
 	irq = ipic_read(primary_ipic->regs, IPIC_SIVCR) & IPIC_SIVCR_VECTOR_MASK;

 	if (irq == 0)    /* 0 --> no irq is pending */
-		return NO_IRQ;
+		return 0;

 	return irq_linear_revmap(primary_ipic->irqhost, irq);
 }
diff -u -p a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -193,10 +193,10 @@ static int __init add_legacy_soc_port(st
 	 */
 	if (tsi && !strcmp(tsi->type, "tsi-bridge"))
 		return add_legacy_port(np, -1, UPIO_TSI, addr, addr,
-				       NO_IRQ, legacy_port_flags, 0);
+				       0, legacy_port_flags, 0);
 	else
 		return add_legacy_port(np, -1, UPIO_MEM, addr, addr,
-				       NO_IRQ, legacy_port_flags, 0);
+				       0, legacy_port_flags, 0);
 }

 static int __init add_legacy_isa_port(struct device_node *np,
@@ -242,7 +242,7 @@ static int __init add_legacy_isa_port(st

 	/* Add port, irq will be dealt with later */
 	return add_legacy_port(np, index, UPIO_PORT, be32_to_cpu(reg[1]),
-			       taddr, NO_IRQ, legacy_port_flags, 0);
+			       taddr, 0, legacy_port_flags, 0);

 }

@@ -314,7 +314,7 @@ static int __init add_legacy_pci_port(st
 	/* Add port, irq will be dealt with later. We passed a translated
 	 * IO port value. It will be fixed up later along with the irq
 	 */
-	return add_legacy_port(np, index, iotype, base, addr, NO_IRQ,
+	return add_legacy_port(np, index, iotype, base, addr, 0,
 			       legacy_port_flags, np != pci_dev);
 }
 #endif
@@ -462,14 +462,14 @@ static void __init fixup_port_irq(int in
 	DBG("fixup_port_irq(%d)\n", index);

 	virq = irq_of_parse_and_map(np, 0);
-	if (virq == NO_IRQ && legacy_serial_infos[index].irq_check_parent) {
+	if (!virq && legacy_serial_infos[index].irq_check_parent) {
 		np = of_get_parent(np);
 		if (np == NULL)
 			return;
 		virq = irq_of_parse_and_map(np, 0);
 		of_node_put(np);
 	}
-	if (virq == NO_IRQ)
+	if (!virq)
 		return;

 	port->irq = virq;
@@ -543,7 +543,7 @@ static int __init serial_dev_init(void)
 		struct plat_serial8250_port *port = &legacy_serial_ports[i];
 		struct device_node *np = legacy_serial_infos[i].np;

-		if (port->irq == NO_IRQ)
+		if (!port->irq)
 			fixup_port_irq(i, np, port);
 		if (port->iotype == UPIO_PORT)
 			fixup_port_pio(i, np, port);
diff -u -p a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -178,7 +178,7 @@ struct pci_dev *of_create_pci_dev(struct
 		dev->hdr_type = PCI_HEADER_TYPE_NORMAL;
 		dev->rom_base_reg = PCI_ROM_ADDRESS;
 		/* Maybe do a default OF mapping here */
-		dev->irq = NO_IRQ;
+		dev->irq = 0;
 	}

 	of_pci_parse_addrs(node, dev);
diff -u -p a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -324,7 +324,7 @@ static int pci_read_irq_line(struct pci_
 			 line, pin);

 		virq = irq_create_mapping(NULL, line);
-		if (virq != NO_IRQ)
+		if (virq)
 			irq_set_irq_type(virq, IRQ_TYPE_LEVEL_LOW);
 	} else {
 		pr_debug(" Got one, spec %d cells (0x%08x 0x%08x...) on %s\n",
@@ -333,7 +333,7 @@ static int pci_read_irq_line(struct pci_

 		virq = irq_create_of_mapping(&oirq);
 	}
-	if(virq == NO_IRQ) {
+	if(!virq) {
 		pr_debug(" Failed to map !\n");
 		return -1;
 	}
diff -u -p a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -514,7 +514,7 @@ void __do_irq(struct pt_regs *regs)
 	may_hard_irq_enable();

 	/* And finally process it */
-	if (unlikely(irq == NO_IRQ))
+	if (unlikely(!irq))
 		__this_cpu_inc(irq_stat.spurious_irqs);
 	else
 		generic_handle_irq(irq);
diff -u -p a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -227,7 +227,7 @@ int ibmebus_request_irq(u32 ist, irq_han
 {
 	unsigned int irq = irq_create_mapping(NULL, ist);

-	if (irq == NO_IRQ)
+	if (!irq)
 		return -EINVAL;

 	return request_irq(irq, handler, irq_flags, devname, dev_id);

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Linus Torvalds]

On Fri, Sep 2, 2016 at 1:43 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
> Like this?

Sure.

> Is it always correct to replace return NO_IRQ by return 0?

On platforms that define it to 0, like powerpc, yes.

On arm, c6x, mn10300, parisc and sparc it would need more work.

> Completely untested patch below.

Looks fine, but the ppc people should test it (although it really
should generate the exact same code, unless there was some odd
conversion case).

                 Linus

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Linus Torvalds]

On Fri, Sep 2, 2016 at 1:43 PM, Julia Lawall <julia.lawall@lip6.fr> wrote:
>
> Like this?

Sure.

> Is it always correct to replace return NO_IRQ by return 0?

On platforms that define it to 0, like powerpc, yes.

On arm, c6x, mn10300, parisc and sparc it would need more work.

> Completely untested patch below.

Looks fine, but the ppc people should test it (although it really
should generate the exact same code, unless there was some odd
conversion case).

                 Linus

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Benjamin Herrenschmidt]

On Fri, 2016-09-02 at 13:26 -0700, Linus Torvalds wrote:
> On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > 
> > 
> > When I once looked, I thought all drivers using NO_IRQ were
> > specific
> > to powerpc or one of the less common architectures.

We deprecated NO_IRQ ages ago, it's 0 like it should be, but yes we may
have forgotten to "cleanup" the old users.
 
> powerpc definitely does seem to be the biggest case, with about half
> the instances of NO_IRQ being under arch/powerpc/ (and a few more in
> ppc-specific drivers).
> 
> Adding the powerpc maintainers to the list - because it would really
> be nice to get rid of it, or at least make it *so* rare that we don't
> have people re-introducing it again because they thought it was the
> right thing to do.

Right. Originally it was -1 for us which causes the whole problem. I
changed it to be 0 after doing the whole irq domain remapping thing.
That was a loooong time ago.

> A fair amount of of it could even be done by some trivial scripting.
> Something like
> 
>   git grep -wl NO_IRQ arch/powerpc/ | while read a
>   do
>       sed 's/(\([a-z_]*irq\) != NO_IRQ)/(\1)/' < $a > $a.new
>       sed 's/(\([a-z_]*irq\) == NO_IRQ)/(!\1)/' < $a.new > $a
>   done
> 
> does fix at least a few of the cases. It still leaves several
> assignments and "return NO_IRQ;" statements, but a few more
> sed-scripts would take care of most of it. Then remove the #define,
> and do a full build to find any straggling cases.
> 
> Michael? Ben?

It can just be replaced with "0" in all powerpc related cases yes.

Cheers,
Ben.

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Benjamin Herrenschmidt]

On Fri, 2016-09-02 at 13:26 -0700, Linus Torvalds wrote:
> On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > 
> > 
> > When I once looked, I thought all drivers using NO_IRQ were
> > specific
> > to powerpc or one of the less common architectures.

We deprecated NO_IRQ ages ago, it's 0 like it should be, but yes we may
have forgotten to "cleanup" the old users.
 
> powerpc definitely does seem to be the biggest case, with about half
> the instances of NO_IRQ being under arch/powerpc/ (and a few more in
> ppc-specific drivers).
> 
> Adding the powerpc maintainers to the list - because it would really
> be nice to get rid of it, or at least make it *so* rare that we don't
> have people re-introducing it again because they thought it was the
> right thing to do.

Right. Originally it was -1 for us which causes the whole problem. I
changed it to be 0 after doing the whole irq domain remapping thing.
That was a loooong time ago.

> A fair amount of of it could even be done by some trivial scripting.
> Something like
> 
>   git grep -wl NO_IRQ arch/powerpc/ | while read a
>   do
>       sed 's/(\([a-z_]*irq\) != NO_IRQ)/(\1)/' < $a > $a.new
>       sed 's/(\([a-z_]*irq\) == NO_IRQ)/(!\1)/' < $a.new > $a
>   done
> 
> does fix at least a few of the cases. It still leaves several
> assignments and "return NO_IRQ;" statements, but a few more
> sed-scripts would take care of most of it. Then remove the #define,
> and do a full build to find any straggling cases.
> 
> Michael? Ben?

It can just be replaced with "0" in all powerpc related cases yes.

Cheers,
Ben.

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Michael Ellerman]

On 3 September 2016 06:26:08 GMT+10:00, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> When I once looked, I thought all drivers using NO_IRQ were specific
>> to powerpc or one of the less common architectures.
>
>powerpc definitely does seem to be the biggest case, with about half
>the instances of NO_IRQ being under arch/powerpc/ (and a few more in
>ppc-specific drivers).
>
>Adding the powerpc maintainers to the list - because it would really
>be nice to get rid of it, or at least make it *so* rare that we don't
>have people re-introducing it again because they thought it was the
>right thing to do.
>
>A fair amount of of it could even be done by some trivial scripting.
>Something like
>
>  git grep -wl NO_IRQ arch/powerpc/ | while read a
>  do
>      sed 's/(\([a-z_]*irq\) != NO_IRQ)/(\1)/' < $a > $a.new
>      sed 's/(\([a-z_]*irq\) == NO_IRQ)/(!\1)/' < $a.new > $a
>  done
>
>does fix at least a few of the cases. It still leaves several
>assignments and "return NO_IRQ;" statements, but a few more
>sed-scripts would take care of most of it. Then remove the #define,
>and do a full build to find any straggling cases.
>
>Michael? Ben?

Yeah sounds good. I'll do a patch on Monday and push it through the build farm.

cheers

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Michael Ellerman]

On 3 September 2016 06:26:08 GMT+10:00, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Fri, Sep 2, 2016 at 1:06 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> When I once looked, I thought all drivers using NO_IRQ were specific
>> to powerpc or one of the less common architectures.
>
>powerpc definitely does seem to be the biggest case, with about half
>the instances of NO_IRQ being under arch/powerpc/ (and a few more in
>ppc-specific drivers).
>
>Adding the powerpc maintainers to the list - because it would really
>be nice to get rid of it, or at least make it *so* rare that we don't
>have people re-introducing it again because they thought it was the
>right thing to do.
>
>A fair amount of of it could even be done by some trivial scripting.
>Something like
>
>  git grep -wl NO_IRQ arch/powerpc/ | while read a
>  do
>      sed 's/(\([a-z_]*irq\) != NO_IRQ)/(\1)/' < $a > $a.new
>      sed 's/(\([a-z_]*irq\) == NO_IRQ)/(!\1)/' < $a.new > $a
>  done
>
>does fix at least a few of the cases. It still leaves several
>assignments and "return NO_IRQ;" statements, but a few more
>sed-scripts would take care of most of it. Then remove the #define,
>and do a full build to find any straggling cases.
>
>Michael? Ben?

Yeah sounds good. I'll do a patch on Monday and push it through the build farm.

cheers

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Arnd Bergmann]

On Friday, September 2, 2016 10:06:02 PM CEST Arnd Bergmann wrote:
> I'll throw this patch at my randconfig builder and see what breaks:
> 

I found four dmaengine drivers that built on ARM, two of them were
actually incorrect, the other ones should work fine either way.
I've sent patches for those four now, and for the mv_cesa crypto driver
that was also incorrect.

I've also done patches for arch/arm/mach-{mmp,mv78xx0,orion5x}
and plat-orion, but these are more invasive and I'm still build
testing to ensure there were no obvious mistakes in my patches.

The only other drivers I found using NO_IRQ on ARM are
drivers/pcmcia/soc_common.c and drivers/mfd/ucb1x00-core.c.
I haven't looked at those yet, it's possible that the former
is still problematic as mach-pxa still uses '0' as a valid
interrupt.

	Arnd

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Geert Uytterhoeven]

Hi Linus,

On Fri, Sep 2, 2016 at 7:25 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Sep 2, 2016 at 3:46 AM, Vinod Koul <vinod.koul@intel.com> wrote:
>>
>> Arm seems to define NO_IRQ. This is not available in other arch and one
>> driver (moxart-dma) is using it. I don't see why this should be arm specific.
>
> NO_IRQ is broken. We long long since agreed that 0 is "no irq", and
> that the right way to test for it is just
>
>    if (!irq) ...
>
> which is what all the generic drivers use.

[...]

> Some people have said "..but but but I have a real irq that has the
> value 0", but that's irrelevant - the kernel "irq" value isn't
> necessarily the same as the value that an interrupt _controller_ sees,
> since the interrupt controller can be hiding behind various other
> nested controllers etc. So an architecture might need to translate
> "irq" into the actual hw interrupt controller value.

Let's bite ;-)

What about the legacy timer interrupt?

$ git grep 'setup_irq(0,'
arch/alpha/kernel/sys_ruffian.c:        setup_irq(0, &timer_irqaction);
arch/avr32/kernel/time.c:       ret = setup_irq(0, &timer_irqaction);
arch/mips/kernel/i8253.c:       setup_irq(0, &irq0);
arch/x86/kernel/time.c: setup_irq(0, &irq0);
$

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Linus Torvalds]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

On Sep 4, 2016 10:45, "Geert Uytterhoeven" <geert@linux-m68k.org> wrote:
>
> What about the legacy timer interrupt?

That's fine. No driver will ever see it. So it's OK to be zero.

That's obviously how x86 always worked.

And x86 always had "zero means no interrupt".

      Linus

[-- Attachment #2: Type: text/html, Size: 488 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

On Fri, Sep 02, 2016 at 04:16:20PM +0530, Vinod Koul wrote:
> On Mon, Aug 01, 2016 at 08:56:30AM +0200, Arnd Bergmann wrote:

> > Sounds good. Let me know if you end up having to add a 'depends on ARM'
> > dependency anywhere, as that might indicate that we are doing something
> > different on ARM that should be done in a more generic way.

> Only one thing :)

> Arm seems to define NO_IRQ. This is not available in other arch and one
> driver (moxart-dma) is using it. I don't see why this should be arm specific.

> FWIW, now I have a single arm config like x86, ppc, mips for my subsystem with
> this change.

The general direction here is to not use NO_IRQ in new code.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Daniel Vetter]

On Wed, Jul 27, 2016 at 5:04 AM, Vinod Koul <vinod.koul@intel.com> wrote:
> On Tue, Jul 26, 2016 at 09:45:35AM -0700, Olof Johansson wrote:
>> On Wed, Jul 20, 2016 at 5:11 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> > But I think the more interesting bits are why I decided to try this
>> > out, what I hoped would happen, what I feared might happen. And with 1
>> > year of experience, what actually happens and what I think is needed
>> > to make this work and an actual benefit over more traditional
>> > maintainer models. And of course I'd like to compare notes with other
>> > group maintainers.
>>
>> Very interested in participating here, for obvious reasons -- learning
>> from others how we can do things even better as well as sharing how
>> things are working for us, 5 years into the endeavor.
>
> Am interested in this discussion as well for very obvious reasons
>
>> One thing we're low on for arm-soc is tooling, I know the x86 guys
>> have quite a bit more than we do in this area, so ideas on what we can
>> do to make our own lives easier is valuable.
>
> Okay one of the gripes I have is that it is a bit hard to compile arm
> drivers. I regularly compile all drivers in subsystem I maintain and arm
> ones are not always straightforward. Figuring our which config to use
> for compile testing involves a bit of time, which I would like to avoid.
>
> Having said that stuff like multi_xx_defconfig has improved a bit and
> seem to be in right direction (not an expert at arm arch's) but doesn't
> seem to cover all. Right now I am manually maintaining 4 different arm
> configs to compile test all the drivers in dmaengine subsystem which
> isn't a very big subsystem. For other arch's it is one config per
> subsystem.
>
> So if you have suggestions to improve my flow, I would like to hear
> that, maybe I am doing something not right here...

Since we're rolling out the drm/i915 group maintainership to the
drm-misc tree now as another experiment we've had to solve this for
the drm subsystem somehow:
- We track one arm multiplatform and one x86 config in the
rerere-cache branch we use:

https://cgit.freedesktop.org/drm-intel/tree/?h=rerere-cache

- Developers integrate that into into their compile-test environment
to make sure nothing breaks before pushing. Atm the compile-test stuff
isn't implemented in shared tooling.

- DRM doesn't have any drivers any more which can't be covered with
these too. For new drivers we require multiplatform support, at least
for compile testing. But I guess that's not a solution for everyone :(

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Daniel Vetter]

On Tue, Jul 26, 2016 at 6:45 PM, Olof Johansson <olof@lixom.net> wrote:
> On Wed, Jul 20, 2016 at 5:11 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>> In my very first KS I found the maintainership model presentations
>> (x86-tip & armsoc) rather interesting. And last year we've had an
>> ad-hoc discussion about group maintainership again. I think drm&i915
>> would be an interesting case since over the past year I've done some
>> changes which are at the edge of what's common in the kernel, and it
>> seems to work (at least for us) fairly well. I discussed this a bit
>> with a few folks at ELC San Diego too.
>>
>> Short summary: i915 has now a two-level maintenance model with 2
>> maintainers (who take the blame) and 15 people who can push patches.
>> In a way a rather big group, but not so big that people don't all know
>> each another any more personally. We have some detailed docs about the
>> patch flow and expectations:
>>
>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
>>
>> and about the dim tool used to support this all
>>
>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html
>>
>> But I think the more interesting bits are why I decided to try this
>> out, what I hoped would happen, what I feared might happen. And with 1
>> year of experience, what actually happens and what I think is needed
>> to make this work and an actual benefit over more traditional
>> maintainer models. And of course I'd like to compare notes with other
>> group maintainers.
>
> Very interested in participating here, for obvious reasons -- learning
> from others how we can do things even better as well as sharing how
> things are working for us, 5 years into the endeavor.
>
> One thing we're low on for arm-soc is tooling, I know the x86 guys
> have quite a bit more than we do in this area, so ideas on what we can
> do to make our own lives easier is valuable.

drm group maintainer tooling is fairly low-key. The one interesting
bit is that the overall integration tree is regenerated every time you
push a patch (to scale out conflict resolution to committers too).
Conflict resolutions are tracked using git rerere and optional manual
fixup patches in a shared branch. There's also a setup command to get
it all started. I think that's probably the most interesting part of
our tooling.

One thing that's kinda annoying is how bad git rerere is at reapplying
stored resolutions with slightly changed context, or when merging the
other way round. But it's not yet bad enough that I've sat down and
fixed it ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Jani Nikula]

On Wed, 20 Jul 2016, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> In my very first KS I found the maintainership model presentations
> (x86-tip & armsoc) rather interesting. And last year we've had an
> ad-hoc discussion about group maintainership again. I think drm&i915
> would be an interesting case since over the past year I've done some
> changes which are at the edge of what's common in the kernel, and it
> seems to work (at least for us) fairly well. I discussed this a bit
> with a few folks at ELC San Diego too.
>
> Short summary: i915 has now a two-level maintenance model with 2
> maintainers (who take the blame) and 15 people who can push patches.

Having joined this particular ride at the point of going from one to two
maintainers (which was really a bigger workflow and tooling change than
adding the rest), I'd like to join the discussion.

BR,
Jani.

> In a way a rather big group, but not so big that people don't all know
> each another any more personally. We have some detailed docs about the
> patch flow and expectations:
>
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
>
> and about the dim tool used to support this all
>
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html
>
> But I think the more interesting bits are why I decided to try this
> out, what I hoped would happen, what I feared might happen. And with 1
> year of experience, what actually happens and what I think is needed
> to make this work and an actual benefit over more traditional
> maintainer models. And of course I'd like to compare notes with other
> group maintainers.
>
> Cheers, Daniel

-- 
Jani Nikula, Intel Open Source Technology Center

[Ksummit-discuss] [CORE TOPIC] (group) maintainership models

[Leon Romanovsky]

Hi,

Sorry for my late reply to this thread and I hope that it is not too
late to join this topic.

We are in RDMA subsystem in the process of unifying our user-space
parts of RDMA stack to be similar in structure and schedules to
kernel. There is over all consensus that current kernel maintainer
(Doug Ledford) will take responsibility of this meta-bundle [1]
(initial stage, WIP).

However, in the last year, we saw increasing interest in RDMA
technology and steady stream of new drivers and features, including
ABI redesign. The next year is expecting to be more challenging, so it
is vital to us to rethink our maintainership model, before everything
collapse :).

We (me and Doug, if he didn't register to this yet) would be very
interesting to join and discuss different models to manage RDMA stack.

Thanks

[1] https://github.com/jgunthorpe/rdma-plumbing/