linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
Date: Mon, 5 Dec 2011 16:11:57 +0000	[thread overview]
Message-ID: <20111205161157.GA27550@localhost.localdomain> (raw)
In-Reply-To: <1322867573.11728.22.camel@pasglop>

On Sat, Dec 03, 2011 at 10:12:53AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2011-12-02 at 11:28 -0800, Linus Torvalds wrote:
> > On Fri, Dec 2, 2011 at 11:26 AM, Dave Martin <dave.martin@linaro.org> wrote:
> > >
> > > This is now broken on ARM where, for good or bad, NO_IRQ currently is
> > > used and is -1.
> > >
> > > How do we resolve it?  If we are ready to eliminate NO_IRQ from
> > > drivers/of/irq.c (or indeed, all code that uses it) and just use 0 for
> > > that case, we should surely just do it... but I'm not confident I can
> > > judge on that.
> > 
> > Just stop using NO_IRQ. First in drivers/of/irq.c, then in any drivers
> > as you notice breakage.
> 
> Agreed. In fact the whole hack in drivers/of/irq.c was to accomodate ARM
> which still uses -1, powerpc changed to 0 a long time ago.
> 
> Now that we have a generic remapper between HW and "linux" IRQ numbers,
> there is no reason to stick to -1 even on ARM.
> 
> > Don't *change* NO_IRQ to zero (that whole #define is broken - leave it
> > around as a marker of brokenness), just start removing it from all the
> > ARM drivers that use the OF infrastructure. Which is presumably not
> > all that many yet.
> > 
> > So whenever you find breakage, the fix now is to just remove NO_IRQ
> > tests, and replace them with "!irq".
> 

Russell, do you know whether it would make sense to set a timeline for 
removing NO_IRQ from ARM platforms and migrating to 0 for the no-interrupt
case?  I'm assuming that this mainly involves migrating existing hard-wired
code that deals with interrupt numbers to use irq domains.

I worry that if we just change the convention for the OF case, we'll end
up with OF-ised platform drivers which have to deal with a different no-
irq convention depending on whether they are probed as platform drivers
or through the OF framework ... and these ported or semi-ported drivers
will be intermixed with unported drivers, confusing maintainers.
 
If board code starts initialising platform data for non-OF-ised platform
drivers based on IRQ numbers fetched via the OF code, things will get
even more confused...

Cheers
---Dave

  reply	other threads:[~2011-12-05 16:11 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20111110162859.GA7088@oksana.dev.rtsoft.ru>
     [not found] ` <20111202192618.GC3037@localhost.localdomain>
2011-12-02 19:28   ` [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver Linus Torvalds
2011-12-02 23:12     ` Benjamin Herrenschmidt
2011-12-05 16:11       ` Dave Martin [this message]
2011-12-05 17:40         ` Nicolas Pitre
2011-12-05 18:02           ` Dave Martin
2011-12-05 18:15             ` Geert Uytterhoeven
2011-12-05 18:18             ` Nicolas Pitre
2011-12-05 18:45               ` Alan Cox
2011-12-05 19:19                 ` James Bottomley
2011-12-06  6:13                 ` Jean-Christophe PLAGNIOL-VILLARD
2011-12-06 11:34                   ` Alan Cox
2011-12-05 19:16               ` Rob Herring
2011-12-05 20:21                 ` Anton Vorontsov
2011-12-05 20:47                   ` Rob Herring
2011-12-05 20:53                     ` Alan Cox
2011-12-06  9:30                     ` Dave Martin
2011-12-06 10:34                       ` Alan Cox
2011-12-06 10:55                       ` Russell King - ARM Linux
2011-12-05 19:26               ` Dave Martin
2011-12-05 19:49                 ` Nicolas Pitre
2011-12-06  9:37                   ` Dave Martin
2011-12-06 10:46                     ` Russell King - ARM Linux
2011-12-06 11:00                       ` Geert Uytterhoeven
2011-12-06 11:03                         ` Russell King - ARM Linux
2011-12-06 11:10                         ` Alan Cox
2011-12-06 11:05                       ` Alan Cox
2011-12-06 11:25                         ` Russell King - ARM Linux
2011-12-06 12:11                           ` Alan Cox
2011-12-06 11:37                       ` Dave Martin
2011-12-06 11:49                         ` Russell King - ARM Linux
2011-12-06 13:25                           ` Dave Martin
2011-12-06 19:56                           ` Rob Herring
2011-12-06 19:20                       ` Linus Torvalds
2011-12-06 20:00                         ` Russell King - ARM Linux
2011-12-06 20:59                         ` Uwe Kleine-König
2011-12-06 19:11                     ` Nicolas Pitre
2011-12-05 17:41         ` Alan Cox

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=20111205161157.GA27550@localhost.localdomain \
    --to=dave.martin@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

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

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).