* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Uwe Kleine-König @ 2011-12-06 20:59 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Ingo Molnar, LKML, linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
linux-next-u79uwXL29TY76Z2rM5mHXA, Alan Cox, Anton Vorontsov,
Andrew Morton, Jeff Garzik,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <CA+55aFwZBr+3_S9kU-+m8zN8iwOvn2miuuAy-zt7sUjW_+abBg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hello Linus,
On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
> On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
> <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org> wrote:
> >
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used. Let's be crystal clear: even x86
> > uses IRQ0.
>
> Not for any device driver, though.
>
> It's used entirely internally, and it doesn't even use
> "request_irq()". It uses the magic internal "setup_irq()" and never
> *ever* exposes irq0 as anything that a driver can see.
>
> That's what matters. You can use irq0 in ARM land all you like, AS
> LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
> ever uses that absolutely *idiotic* NO_IRQ crap.
>
> In fact, you may be *forced* to use what is "physically" irq0 - it's
> just that you should never expose it as such to drivers. And x86
> doesn't.
>
> So Russell, if you think this has anything to do with NO_IRQ, and how
> x86 isn't doing things right, you're wrong. It's just like the
> internal exception thing, or the magical "cascade interrupt", or the
> "x87 exception mapped through the PIC". They are magic hidden
> interrupts that are set up in one place (well, one place *each*), and
> are never exposed anywhere else.
Well there is try_misrouted_irq in kernel/irq/spurious.c that assumes
irq0 to be something that it never is on ARM (and maybe all other
platforms apart from x86). So at least it's not internal to a single
(x86 specific) place.
I tried to patch that two years ago, but that only ended in people
saying "don't use irq0". I don't know if try_misrouted_irq sees hardware
irqs, but if it does it's a bug even on archs != X86 that use virtual
irqs.
(Note that this doesn't oppose to your statement that using NO_IRQ is
crap.)
> The problem with NO_IRQ is that stupid "we expose our mind-numbingly
> stupid interfaces across the whole kernel".
>
> x86 never did that. ARM still does. x86 doesn't have to fix anything. ARM does.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Russell King - ARM Linux @ 2011-12-06 20:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel
In-Reply-To: <CA+55aFwZBr+3_S9kU-+m8zN8iwOvn2miuuAy-zt7sUjW_+abBg@mail.gmail.com>
On Tue, Dec 06, 2011 at 11:20:49AM -0800, Linus Torvalds wrote:
> Not for any device driver, though.
>
> It's used entirely internally, and it doesn't even use
> "request_irq()". It uses the magic internal "setup_irq()" and never
> *ever* exposes irq0 as anything that a driver can see.
>
> That's what matters. You can use irq0 in ARM land all you like, AS
> LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
> ever uses that absolutely *idiotic* NO_IRQ crap.
>
> In fact, you may be *forced* to use what is "physically" irq0 - it's
> just that you should never expose it as such to drivers. And x86
> doesn't.
>
> So Russell, if you think this has anything to do with NO_IRQ, and how
> x86 isn't doing things right, you're wrong. It's just like the
> internal exception thing, or the magical "cascade interrupt", or the
> "x87 exception mapped through the PIC". They are magic hidden
> interrupts that are set up in one place (well, one place *each*), and
> are never exposed anywhere else.
>
> The problem with NO_IRQ is that stupid "we expose our mind-numbingly
> stupid interfaces across the whole kernel".
>
> x86 never did that. ARM still does. x86 doesn't have to fix anything. ARM does.
Remember you said that I shouldn't take things personally? Well,
this is one issue I really don't care about. I don't think any
platform I _actually_ have will be impacted by any change in this
area. Other platform maintainers may have their own issues but
that's not _my_ problem.
^ permalink raw reply
* Re: linux-next: Tree for Dec 6 (staging/vme)
From: Randy Dunlap @ 2011-12-06 20:58 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, LKML, devel@driverdev.osuosl.org, Martyn Welch
In-Reply-To: <20111206154450.5e2ef2baed27993b23a55802@canb.auug.org.au>
On 12/05/2011 08:44 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20111205:
When CONFIG_GPIOLIB is not enabled:
drivers/staging/vme/devices/vme_pio2.h:237:19: error: field 'gc' has incomplete type
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Rob Herring @ 2011-12-06 19:56 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Dave Martin, Nicolas Pitre, Stephen Rothwell, Pawel Moll,
Benjamin Herrenschmidt, devicetree-discuss, Ingo Molnar, LKML,
linux-ide, Randy Dunlap, linux-next, Alan Cox, Anton Vorontsov,
Andrew Morton, Linus Torvalds, Jeff Garzik, linux-arm-kernel
In-Reply-To: <20111206114952.GS14542@n2100.arm.linux.org.uk>
On 12/06/2011 05:49 AM, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
>> 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
>> for the no-interrupt case. Code which receives irq numbers directly
>> from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
>> needs to be fixed.
>>
>> 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
>> 0-15 to different software values. (This could be done using irq
>> domains, or not)
>
> No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
> an IRQ number.
The watchdog on VersatileAB is on Linux IRQ0. This is easily fixed with
VIC irqdomain patches which are queued up.
Rob
^ permalink raw reply
* Re: linux-next: Tree for Dec 6 (x86, not SMP)
From: Ingo Molnar @ 2011-12-06 19:53 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, x86 maintainers
In-Reply-To: <4EDE7EB7.7080507@xenotime.net>
* Randy Dunlap <rdunlap@xenotime.net> wrote:
> On 12/05/2011 08:44 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20111205:
>
>
> on x86, when CONFIG_SMP is not enabled:
>
> arch/x86/kernel/cpu/common.c:1149:2: error: 'struct cpuinfo_x86' has no member named 'phys_proc_id'
Yeah, all resolved already, next day's linux-next ought to fix
it.
Thanks,
Ingo
^ permalink raw reply
* Re: linux-next: Tree for Dec 6 (x86, not SMP)
From: Randy Dunlap @ 2011-12-06 20:44 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, LKML, x86 maintainers
In-Reply-To: <20111206154450.5e2ef2baed27993b23a55802@canb.auug.org.au>
On 12/05/2011 08:44 PM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20111205:
on x86, when CONFIG_SMP is not enabled:
arch/x86/kernel/cpu/common.c:1149:2: error: 'struct cpuinfo_x86' has no member named 'phys_proc_id'
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Linus Torvalds @ 2011-12-06 19:20 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel
In-Reply-To: <20111206104654.GN14542@n2100.arm.linux.org.uk>
On Tue, Dec 6, 2011 at 2:46 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
>
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used. Let's be crystal clear: even x86
> uses IRQ0.
Not for any device driver, though.
It's used entirely internally, and it doesn't even use
"request_irq()". It uses the magic internal "setup_irq()" and never
*ever* exposes irq0 as anything that a driver can see.
That's what matters. You can use irq0 in ARM land all you like, AS
LONG AS IT'S SOME HIDDEN INTERNAL USE. No drivers. No *nothing* that
ever uses that absolutely *idiotic* NO_IRQ crap.
In fact, you may be *forced* to use what is "physically" irq0 - it's
just that you should never expose it as such to drivers. And x86
doesn't.
So Russell, if you think this has anything to do with NO_IRQ, and how
x86 isn't doing things right, you're wrong. It's just like the
internal exception thing, or the magical "cascade interrupt", or the
"x87 exception mapped through the PIC". They are magic hidden
interrupts that are set up in one place (well, one place *each*), and
are never exposed anywhere else.
The problem with NO_IRQ is that stupid "we expose our mind-numbingly
stupid interfaces across the whole kernel".
x86 never did that. ARM still does. x86 doesn't have to fix anything. ARM does.
Linus
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Nicolas Pitre @ 2011-12-06 19:11 UTC (permalink / raw)
To: Dave Martin
Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel
In-Reply-To: <20111206093709.GB2274@linaro.org>
On Tue, 6 Dec 2011, Dave Martin wrote:
> On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:
>
> > No need to convert everything.
> >
> > First move is to make irq=0 meaning no IRQ. That means making things
> > like:
> >
> > if (irq < 0)
> > if (irq >= 0)
> >
> > into
> >
> > if (irq <= 0)
> > if (irq > 0)
> >
> > And replace NO_IRQ with 0.
> >
> > That change shouldn't break anything, except those drivers which are 1)
> > being passed an actual IRQ #0 and 2) testing for no IRQ. I suspect that
> > those conditions aren't very common together.
>
> To clarify, you're suggesting that the meanings of all other IRQ values
> would not change initially?
Initially, or even ever.
> (i.e., we remap HW irq 0, if there is one,
> to some other random number but have a 1:1 mapping for everything else).
Exact.
> That could make sense as an approach.
You might notice that a true IRQ #0 passed to generic drivers is not
really frequent.
Nicolas
^ permalink raw reply
* Re: linux-next: build failure after merge of the pci tree
From: Jesse Barnes @ 2011-12-06 17:28 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <CAErSpo6YrEZZjd=j6xoUfSvDHTT+-9g0zAb=ff2F1jA-0V9rHw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2927 bytes --]
On Mon, 5 Dec 2011 20:16:54 -0700
Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Mon, Dec 5, 2011 at 5:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > Hi Jesse,
> >
> > After merging the pci tree, today's linux-next build
> > (powerpc_ppc64_defconfig) failed like this:
> >
> > arch/powerpc/kernel/pci_64.c: In function 'pcibios_map_io_space':
> > arch/powerpc/kernel/pci_64.c:201:2: error: implicit declaration of function 'pcibios_phb_map_phb_io_space' [-Werror=implicit-function-declaration]
> >
> > Caused by commit fb8fca4ff3f7 ("powerpc/PCI: split PHB part out of
> > pcibios_map_io_space()").
> >
> > arch/powerpc/kernel/pci-common.c: In function 'pcibios_scan_phb':
> > arch/powerpc/kernel/pci-common.c:1726:7: error: incompatible type for argument 5 of 'pci_create_root_bus'
> > include/linux/pci.h:665:17: note: expected 'struct list_head *' but argument is of type 'struct list_head'
> >
> > Caused by commit 3c73944e7ace ("powerpc/PCI: convert to
> > pci_create_root_bus()").
> >
> > I have used the pci tree from next-20111205 for today.
> > --
> > Cheers,
> > Stephen Rothwell sfr@canb.auug.org.au
> > http://www.canb.auug.org.au/~sfr/
>
> I fixed these; the updated patches are on
> git://github.com/bjorn-helgaas/linux.git on
> the "pci-scan-v4" branch (head f9da8b214fef1ac4072e4af2a663293ab965f796).
>
> Here's the incremental diff from v3 to v4 (hand-created and whitespace-damaged):
>
> diff --git a/c4677881a:arch/powerpc/kernel/pci_64.c
> b/f9da8b214:arch/powerpc/kernel/pci_64.c
> index 4401425..3318d39 100644
> --- a/c4677881a:arch/powerpc/kernel/pci_64.c
> +++ b/f9da8b214:arch/powerpc/kernel/pci_64.c
> @@ -197,7 +198,7 @@ int __devinit pcibios_map_io_space(struct pci_bus *bus)
> return 0;
> }
>
> - return pcibios_phb_map_phb_io_space(pci_bus_to_host(bus));
> + return pcibios_map_phb_io_space(pci_bus_to_host(bus));
> }
> EXPORT_SYMBOL_GPL(pcibios_map_io_space);
>
> diff --git a/c4677881a:arch/powerpc/kernel/pci-common.c
> b/f9da8b214:arch/powerpc/kernel/pci-common.c
> index 8c47c57..2aa707b 100644
> --- a/c4677881a:arch/powerpc/kernel/pci-common.c
> +++ b/f9da8b214:arch/powerpc/kernel/pci-common.c
> @@ -1711,7 +1712,7 @@ void __devinit pcibios_scan_phb(struct
> pci_controller *hose)
>
> /* Create an empty bus for the toplevel */
> bus = pci_create_root_bus(hose->parent, hose->first_busno,
> - hose->ops, hose, resources);
> + hose->ops, hose, &resources);
> if (bus == NULL) {
> pr_err("Failed to create bus for PCI domain %04x\n",
> hose->global_number);
>
I merged this fix into the original commit as a v2 patch, hope today's
linux-next builds.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Dave Martin @ 2011-12-06 13:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
Benjamin Herrenschmidt, devicetree-discuss, LKML, Jeff Garzik,
linux-ide, Randy Dunlap, linux-next, linux-arm-kernel,
Anton Vorontsov, Andrew Morton, Linus Torvalds, Ingo Molnar,
Alan Cox
In-Reply-To: <20111206114952.GS14542@n2100.arm.linux.org.uk>
On Tue, Dec 06, 2011 at 11:49:52AM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
> > 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
> > for the no-interrupt case. Code which receives irq numbers directly
> > from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
> > needs to be fixed.
> >
> > 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
> > 0-15 to different software values. (This could be done using irq
> > domains, or not)
>
> No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
> an IRQ number.
OK, hopefully we can safely ignore that case, then.
But other than that, you're in agreement?
Cheers
---Dave
^ permalink raw reply
* [PATCH] x86, intel_mid: Kconfig select fix
From: Alan Cox @ 2011-12-06 13:28 UTC (permalink / raw)
To: mingo, linux-next
From: Alan Cox <alan@linux.intel.com>
If we select a symbol it should have a type declared first otherwise in
some situations the config tools get upset. They are currently perhaps a
bit too resilient which is why this wasn't noticed initially.
Signed-off-by: Alan Cox <alan@linux.intel.com>
---
arch/x86/Kconfig | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b884f4c..d48585b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -406,6 +406,9 @@ config X86_WANT_INTEL_MID
if X86_WANT_INTEL_MID
+config X86_INTEL_MID
+ bool
+
config X86_MRST
bool "Moorestown MID platform"
depends on PCI
^ permalink raw reply related
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Alan Cox @ 2011-12-06 12:11 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
Linus Torvalds, Anton Vorontsov, Stephen Rothwell, Andrew Morton,
devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel
In-Reply-To: <20111206112545.GQ14542@n2100.arm.linux.org.uk>
> However, I have suggested in the past that new platforms _should_ avoid
> not just IRQ0 but IRQ0-15 (for a completely different reason to that of
> 'IRQ0 means no IRQ'.) But such comments just get ignored, so I just
> don't see the point in doing anything about this. If people experience
> breakage, so be it. I too will have little sympathy but not for the same
> reason.
The one I can think of that is capable of taking EISA/ISA cards but has
differently IRQ plumbing arrangements is PA-RISC, and they do exactly
this.
Beyond that it probably doesn't come up except in the weird world of PCI
legacy compatibility for legacy IDE and VGA vertical interrupt routing.
In those cases we fix up the PCI config space so the platform in turn can
do proper IRQ plumbing.
Alan
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Russell King - ARM Linux @ 2011-12-06 11:49 UTC (permalink / raw)
To: Dave Martin
Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
Benjamin Herrenschmidt, devicetree-discuss, LKML, Jeff Garzik,
linux-ide, Randy Dunlap, linux-next, linux-arm-kernel,
Anton Vorontsov, Andrew Morton, Linus Torvalds, Ingo Molnar,
Alan Cox
In-Reply-To: <20111206113735.GC2274@linaro.org>
On Tue, Dec 06, 2011 at 11:37:35AM +0000, Dave Martin wrote:
> 1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
> for the no-interrupt case. Code which receives irq numbers directly
> from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
> needs to be fixed.
>
> 2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
> 0-15 to different software values. (This could be done using irq
> domains, or not)
No AMBA driver I'm aware of ever uses an IRQ number 0 or is passed such
an IRQ number.
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Dave Martin @ 2011-12-06 11:37 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
Benjamin Herrenschmidt, devicetree-discuss, LKML, Jeff Garzik,
linux-ide, Randy Dunlap, linux-next, linux-arm-kernel,
Anton Vorontsov, Andrew Morton, Linus Torvalds, Ingo Molnar,
Alan Cox
In-Reply-To: <20111206104654.GN14542@n2100.arm.linux.org.uk>
On Tue, Dec 06, 2011 at 10:46:54AM +0000, Russell King - ARM Linux wrote:
> On Tue, Dec 06, 2011 at 09:37:09AM +0000, Dave Martin wrote:
> > To clarify, you're suggesting that the meanings of all other IRQ values
> > would not change initially? (i.e., we remap HW irq 0, if there is one,
> > to some other random number but have a 1:1 mapping for everything else).
>
> Even better. Avoid the first 16 IRQ numbers altogether - so that ISA
> drivers which have these numbers hard-encoded in them will see failures
> if they're expecting standard ISA IRQ numbering.
>
> We already do that with the GIC, partly because of the hardware design.
> We do that on Footbridge based systems, because they may or may not have
> a real ISA IRQ controller.
>
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used. Let's be crystal clear: even x86
> uses IRQ0. It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot. So please don't tell me that x86 avoids IRQ0.
> It doesn't. It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.
>
> So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> I bet that there'd be absolute fury at such a suggestion.
>
> When x86 sorts this out, there _might_ be some more motivation to take
> such comments seriously. Until then it's more like a joke.
OK -- but the situation is breaking OF-based drivers on ARM platforms
today.
Based on what you've suggested, does the following policy sound
reasonable for resolving that deadlock?
1) All OF code and drivers should be migrating to use 0 instead of NO_IRQ
for the no-interrupt case. Code which receives irq numbers directly
from the OF framework and refers to NO_IRQ, or expects 0 to be a valid
needs to be fixed.
2) Where we hit a problem, board code needs to be adapted to remap HW IRQs
0-15 to different software values. (This could be done using irq
domains, or not)
I'm still not sure what the correct approach is for drivers which get
irq numbers from OF indirectly -- this particularly applies to platform
and AMBA devices.
If we expect board code to start populating platform data based on
information from the OF code, we need to fix the board not to use linux
irq 0 to describe a real HW interrupt, if it matters (as in (2)).
AMBA devices registered via of_platform_populate() already get their
irq numbers from OF. So long as OF used to explicitly return NO_IRQ
there was no problem -- but if OF is moving to return 0 instead, we have
a potential problem for each AMBA driver which may be used by a board
which can boot without DT... if we have any scenarios where that driver
is given real irq 0.
Maybe we can fix these breakages as they occur -- I don't really know
the scale of the impact.
What are your thoughts on this?
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Alan Cox @ 2011-12-06 11:34 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Ingo Molnar, LKML, linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov, Andrew Morton,
Linus Torvalds, Jeff Garzik,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20111206061321.GH9192-RQcB7r2h9QmfDR2tN2SG5Ni2O/JbrIOy@public.gmane.org>
> can we sinply introduce a macro irq_is_valid
See the 2005, 2006 and 2008 discussion.
if (!dev->irq)
is the proper test.
The <= is just a temporary thing while ARM gets its publically visible
house in order so it can be done without breakage.
Alan
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Russell King - ARM Linux @ 2011-12-06 11:25 UTC (permalink / raw)
To: Alan Cox
Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML, Jeff Garzik,
linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov, Andrew Morton,
Linus Torvalds, Ingo Molnar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20111206110554.53bddd14-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
On Tue, Dec 06, 2011 at 11:05:54AM +0000, Alan Cox wrote:
> > Even better. Avoid the first 16 IRQ numbers altogether - so that ISA
> > drivers which have these numbers hard-encoded in them will see failures
> > if they're expecting standard ISA IRQ numbering.
>
> The ISA bus space is non-discoverable so that doesn't make any sense.
>
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used. Let's be crystal clear: even x86
> > uses IRQ0. It happens to be the PIC timer, and that gets claimed early
> > on during the x86 boot. So please don't tell me that x86 avoids IRQ0.
> > It doesn't. It just happens that x86 never shows IRQ0 to anything but
> > the i8253 PIC driver.
>
> x86 has an internal invisible IRQ 0 on some platforms. It's never exposed
> beyond the arch code.
>
> > So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> > I bet that there'd be absolute fury at such a suggestion.
>
> Actually it would be about ten minutes work to remap it to some other
> number that isn't used. It never goes via request_irq or via any core or
> driver layer code however.
>
> In the ARM case the same is going to be true. If you have IRQ 0 plumbing
> that only goes internally in the arch/arm code - eg an ARM with IRQ 0
> wired to something totally arch specific and non-driver then it's not
> going to break and like the internals of x86 doesn't matter.
>
> > When x86 sorts this out, there _might_ be some more motivation to take
> > such comments seriously. Until then it's more like a joke.
>
> Pity you feel that way, but if ARM wants to continue to break more and
> more as we clean up NO_IRQ for everything else that's your privilege, but
> don't expect any sympathy.
For the platforms I care about, it probably won't break. For those which
do break, it's a matter of fixing their include/mach/irqs.h and the code
in their irqchips to convert the IRQ number to the correct bitmask for
the register.
However, I have suggested in the past that new platforms _should_ avoid
not just IRQ0 but IRQ0-15 (for a completely different reason to that of
'IRQ0 means no IRQ'.) But such comments just get ignored, so I just
don't see the point in doing anything about this. If people experience
breakage, so be it. I too will have little sympathy but not for the same
reason.
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Alan Cox @ 2011-12-06 11:10 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Russell King - ARM Linux, Dave Martin, Nicolas Pitre,
Benjamin Herrenschmidt, Linus Torvalds, Anton Vorontsov,
Stephen Rothwell, Andrew Morton, devicetree-discuss, LKML,
linux-ide, Randy Dunlap, linux-next, Ingo Molnar, Jeff Garzik,
Pawel Moll, linux-arm-kernel
In-Reply-To: <CAMuHMdXvuwXps7j2jz18aB1VueLh5Vn0m94jLvBEO-CmsG1JxQ@mail.gmail.com>
> It's shown in /proc/interrupts due to a "bug" in show_interrupts().
> The (gmail damaged) patch below fixes this bug.
We get API breakage then. Which is a pain of course because debug tools
and the like which think IRQ 0 is "timer ticks" are somewhat broken.
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Alan Cox @ 2011-12-06 11:05 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
Linus Torvalds, Anton Vorontsov, Stephen Rothwell, Andrew Morton,
devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel
In-Reply-To: <20111206104654.GN14542@n2100.arm.linux.org.uk>
> Even better. Avoid the first 16 IRQ numbers altogether - so that ISA
> drivers which have these numbers hard-encoded in them will see failures
> if they're expecting standard ISA IRQ numbering.
The ISA bus space is non-discoverable so that doesn't make any sense.
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used. Let's be crystal clear: even x86
> uses IRQ0. It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot. So please don't tell me that x86 avoids IRQ0.
> It doesn't. It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.
x86 has an internal invisible IRQ 0 on some platforms. It's never exposed
beyond the arch code.
> So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
> I bet that there'd be absolute fury at such a suggestion.
Actually it would be about ten minutes work to remap it to some other
number that isn't used. It never goes via request_irq or via any core or
driver layer code however.
In the ARM case the same is going to be true. If you have IRQ 0 plumbing
that only goes internally in the arch/arm code - eg an ARM with IRQ 0
wired to something totally arch specific and non-driver then it's not
going to break and like the internals of x86 doesn't matter.
> When x86 sorts this out, there _might_ be some more motivation to take
> such comments seriously. Until then it's more like a joke.
Pity you feel that way, but if ARM wants to continue to break more and
more as we clean up NO_IRQ for everything else that's your privilege, but
don't expect any sympathy.
Alan
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Russell King - ARM Linux @ 2011-12-06 11:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
Linus Torvalds, Anton Vorontsov, Alan Cox, Stephen Rothwell,
Andrew Morton, devicetree-discuss, LKML, linux-ide, Randy Dunlap,
linux-next, Ingo Molnar, Jeff Garzik, Pawel Moll,
linux-arm-kernel
In-Reply-To: <CAMuHMdXvuwXps7j2jz18aB1VueLh5Vn0m94jLvBEO-CmsG1JxQ@mail.gmail.com>
On Tue, Dec 06, 2011 at 12:00:12PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > But.. let's make one thing clear: Alan Cox and Linus have been going on
> > about how IRQ0 should not be used. Let's be crystal clear: even x86
> > uses IRQ0. It happens to be the PIC timer, and that gets claimed early
> > on during the x86 boot. So please don't tell me that x86 avoids IRQ0.
> > It doesn't. It just happens that x86 never shows IRQ0 to anything but
> > the i8253 PIC driver.
>
> It's shown in /proc/interrupts due to a "bug" in show_interrupts().
> The (gmail damaged) patch below fixes this bug.
So we now try to hide the fact that there _is_ an interrupt called 0
on x86 systems? Sorry, I can't that that seriously in any way.
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Geert Uytterhoeven @ 2011-12-06 11:00 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Dave Martin, Nicolas Pitre, Benjamin Herrenschmidt,
Linus Torvalds, Anton Vorontsov, Alan Cox, Stephen Rothwell,
Andrew Morton, devicetree-discuss, LKML, linux-ide, Randy Dunlap,
linux-next, Ingo Molnar, Jeff Garzik, Pawel Moll,
linux-arm-kernel
In-Reply-To: <20111206104654.GN14542@n2100.arm.linux.org.uk>
On Tue, Dec 6, 2011 at 11:46, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> But.. let's make one thing clear: Alan Cox and Linus have been going on
> about how IRQ0 should not be used. Let's be crystal clear: even x86
> uses IRQ0. It happens to be the PIC timer, and that gets claimed early
> on during the x86 boot. So please don't tell me that x86 avoids IRQ0.
> It doesn't. It just happens that x86 never shows IRQ0 to anything but
> the i8253 PIC driver.
It's shown in /proc/interrupts due to a "bug" in show_interrupts().
The (gmail damaged) patch below fixes this bug.
From 46f51a2d42548358868a34df00c2a4e47bbdf691 Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <Geert.Uytterhoeven@eu.sony.com>
Date: Tue, 6 Dec 2011 11:55:05 +0100
Subject: [PATCH] /proc/interrupts: irq zero is invalid
As zero is an invalid irq number, show_interrupts() should not try to
print it. Just return after printing the header for i == 0.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
kernel/irq/proc.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/kernel/irq/proc.c b/kernel/irq/proc.c
index 4bd4faa..5b8bbf0 100644
--- a/kernel/irq/proc.c
+++ b/kernel/irq/proc.c
@@ -439,6 +439,7 @@ int show_interrupts(struct seq_file *p, void *v)
for_each_online_cpu(j)
seq_printf(p, "CPU%-8d", j);
seq_putc(p, '\n');
+ return 0;
}
desc = irq_to_desc(i);
--
1.7.0.4
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
^ permalink raw reply related
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Russell King - ARM Linux @ 2011-12-06 10:55 UTC (permalink / raw)
To: Dave Martin
Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Ingo Molnar, LKML,
linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
linux-next-u79uwXL29TY76Z2rM5mHXA, Alan Cox, Anton Vorontsov,
Andrew Morton, Linus Torvalds, Jeff Garzik,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20111206093000.GA2274-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Dec 06, 2011 at 09:30:00AM +0000, Dave Martin wrote:
> Do we expect there to be any platform drivers which are shared between
> legacy platforms and newer DT-ised platforms?
>
> Those drivers would be pain points since they would need to understand
> both conventions.
>
> So far as I can see, only boards which are not DT-ised, which do not use
> DT-ised drivers and which do not use drivers which use interrupts and
> are either used by DT-ised boards or by arches with a non-zero NO_IRQ
> could safely carry on using a non-zero NO_IRQ. Tracking down exactly
> which boards and drivers this applies to could be hard. We could have a
> CONFIG_NO_IRQ and make them depend on it, but we still have to find that
> list of boards and drivers in the first place.
You're digging too deeply into this.
Drivers which need to know whether an IRQ is valid need to know this if
they wish to do something different for 'this device doesn't have an IRQ
wired'. These are the drivers which have problems because of the -1 vs
0 thing.
That is different from 'this is an invalid IRQ number', which is what
you find out when you call request_irq().
So please, stop thinking 'we need to convert drivers to check for <= 0'.
We don't. We just need to make sure that we're not passing a zero IRQ
number to any driver.
On platforms where IRQ0 is special like x86, request_irq() will fail
with -EBUSY on drivers which don't care (or other kind of refusal to
initialize), and will cause 'polling mode' with the 8250 driver.
So, all that we need to do is to ensure that all the IRQ chip stuff is
fixed up so that IRQ0 is only used for the same purpose as x86 - the
PIC timer on systems with an ISA 8253 timer. Everything else should
not pass IRQ0 outside core platform code.
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Russell King - ARM Linux @ 2011-12-06 10:46 UTC (permalink / raw)
To: Dave Martin
Cc: Nicolas Pitre, Stephen Rothwell, Pawel Moll,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, LKML, Jeff Garzik,
linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
linux-next-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Anton Vorontsov, Andrew Morton, Linus Torvalds, Ingo Molnar,
Alan Cox
In-Reply-To: <20111206093709.GB2274-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, Dec 06, 2011 at 09:37:09AM +0000, Dave Martin wrote:
> To clarify, you're suggesting that the meanings of all other IRQ values
> would not change initially? (i.e., we remap HW irq 0, if there is one,
> to some other random number but have a 1:1 mapping for everything else).
Even better. Avoid the first 16 IRQ numbers altogether - so that ISA
drivers which have these numbers hard-encoded in them will see failures
if they're expecting standard ISA IRQ numbering.
We already do that with the GIC, partly because of the hardware design.
We do that on Footbridge based systems, because they may or may not have
a real ISA IRQ controller.
But.. let's make one thing clear: Alan Cox and Linus have been going on
about how IRQ0 should not be used. Let's be crystal clear: even x86
uses IRQ0. It happens to be the PIC timer, and that gets claimed early
on during the x86 boot. So please don't tell me that x86 avoids IRQ0.
It doesn't. It just happens that x86 never shows IRQ0 to anything but
the i8253 PIC driver.
So lets see how x86 squeels if we make the i8253 PIC driver reject IRQ0.
I bet that there'd be absolute fury at such a suggestion.
When x86 sorts this out, there _might_ be some more motivation to take
such comments seriously. Until then it's more like a joke.
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Alan Cox @ 2011-12-06 10:34 UTC (permalink / raw)
To: Dave Martin
Cc: Nicolas Pitre, Stephen Rothwell, Russell King - ARM Linux,
Pawel Moll, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
Ingo Molnar, LKML, linux-ide-u79uwXL29TY76Z2rM5mHXA, Randy Dunlap,
linux-next-u79uwXL29TY76Z2rM5mHXA, Anton Vorontsov, Andrew Morton,
Linus Torvalds, Jeff Garzik,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20111206093000.GA2274-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Otherwise, it feels like we might need a strategy for migrating pretty
> much everything if we don't want to end up in a mess.
You really do anyway - lots of generic driver code knows !dev->irq is a
valid test. That covers things like 8250 based UART hardware, network phy
layer code and vast amounts more.
The bugs will already be there because ARM isn't using 0, they just
aren't getting seen or aren't getting hit.
Alan
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Dave Martin @ 2011-12-06 9:37 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Russell King - ARM Linux, Benjamin Herrenschmidt, Linus Torvalds,
Anton Vorontsov, Alan Cox, Stephen Rothwell, Andrew Morton,
devicetree-discuss, LKML, linux-ide, Randy Dunlap, linux-next,
Ingo Molnar, Jeff Garzik, Pawel Moll, linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1112051443190.2357@xanadu.home>
On Mon, Dec 05, 2011 at 02:49:01PM -0500, Nicolas Pitre wrote:
[...]
> > > > Unfortunately, NO_IRQ is often not spelled "NO_IRQ". It looks like the assumption
> > > > "irq < 0 === no irq" may be quite a lot more widespread than "NO_IRQ === no irq".
> > > > Since there's no specific thing we can grep for (and simply due to volume)
> > > > finding all such instances may be quite a bit harder.
> > > [...]
> > >
> > > ARgh.
> > >
> > > My point was about current actual usage of the IRQ numbered 0 which
> > > probably prompted the introduction of NO_IRQ in the first place. What I
> > > was saying is that the number of occurrences where IRQ #0 is currently
> > > used into drivers that would get confused if 0 would mean no IRQ is
> > > probably quite small.
> >
> > Ah, I misunderstood -- that's a separate issue, but also an important one.
> > I guess this applies to a fair number of older boards. One way of fixing
> > this would be to migrate those boards to use irq domains -- but those boards
> > may be sporadically maintained.
> >
> > > But as you illustrated, there is a large number of drivers that already
> > > assume no IRQ is < 0, even if they don't use any IRQ #0 themselves.
> > > That is a much bigger problem to fix.
> >
> > My concern is that as soon as we start to change this in significant
> > volume, a _lot_ of stuff is going to break. Everywhere that an irq value
> > is passed from one piece of code to another, there is a potential
> > interface mismatch -- there seems to be no single place where we can
> > apply a conversion and fix everything.
>
> No need to convert everything.
>
> First move is to make irq=0 meaning no IRQ. That means making things
> like:
>
> if (irq < 0)
> if (irq >= 0)
>
> into
>
> if (irq <= 0)
> if (irq > 0)
>
> And replace NO_IRQ with 0.
>
> That change shouldn't break anything, except those drivers which are 1)
> being passed an actual IRQ #0 and 2) testing for no IRQ. I suspect that
> those conditions aren't very common together.
To clarify, you're suggesting that the meanings of all other IRQ values
would not change initially? (i.e., we remap HW irq 0, if there is one,
to some other random number but have a 1:1 mapping for everything else).
That could make sense as an approach.
Cheers
---Dave
^ permalink raw reply
* Re: [PATCH] ata: Don't use NO_IRQ in pata_of_platform driver
From: Dave Martin @ 2011-12-06 9:30 UTC (permalink / raw)
To: Rob Herring
Cc: Anton Vorontsov, Nicolas Pitre, Stephen Rothwell,
Russell King - ARM Linux, Pawel Moll, devicetree-discuss, LKML,
Jeff Garzik, linux-ide, Randy Dunlap, linux-next,
linux-arm-kernel, Andrew Morton, Linus Torvalds, Ingo Molnar,
Alan Cox, Jonas Bonn, Michal Simek, Grant Likely
In-Reply-To: <4EDD2DE1.1050606@gmail.com>
On Mon, Dec 05, 2011 at 02:47:29PM -0600, Rob Herring wrote:
> On 12/05/2011 02:21 PM, Anton Vorontsov wrote:
> > On Mon, Dec 05, 2011 at 01:16:39PM -0600, Rob Herring wrote:
> > [...]
> >> At least for DT enabled platforms, we could force "no irq" to be 0 in
> >> the DT irq code. Searching the dts files, I found 2 occurrences of IRQ0.
> >
> > Please note that there are HW IRQ numbers and "Virtual" IRQ numbers.
> > dev->irq and thus the thing that we pass into request_irq() is a
> > virtual IRQ thing, a "cookie".
> >
> > While in device tree you see real HW IRQ numbers.
> >
> > Legal VIRQ is always > 0, while HW IRQ could be >= 0.
> >
>
> If this was all true, then there would be no discussion.
>
> This is what we are working towards, but irq_chips all over the arm tree
> do not support any translation or have base fixed at compile time. Only
> a few have been converted. And some ARM platforms may never get
> converted to DT.
>
> >> Prima2 has timer on IRQ0, and VersatileAB has watchdog on IRQ0. Prima2
> >> should be fine currently as it doesn't use the of_irq_* functions to get
> >> the timer irq, but that is an issue as it skips any translation.
> >> VersatileAB should be okay with the VIC irqdomain support.
> >
> > It shouldn't be an issue to use of_irq_*() functions for these IRQs.
> > of_irq_*() will remap HW IRQ 0 to some other VIRQ. If it does not do
> > this currently, then it's a bug and should be fixed.
>
> I think that's what I'm saying. It's either a bug or incomplete DT
> conversion for the platform. Either way, those should get fixed first.
Do we expect there to be any platform drivers which are shared between
legacy platforms and newer DT-ised platforms?
Those drivers would be pain points since they would need to understand
both conventions.
So far as I can see, only boards which are not DT-ised, which do not use
DT-ised drivers and which do not use drivers which use interrupts and
are either used by DT-ised boards or by arches with a non-zero NO_IRQ
could safely carry on using a non-zero NO_IRQ. Tracking down exactly
which boards and drivers this applies to could be hard. We could have a
CONFIG_NO_IRQ and make them depend on it, but we still have to find that
list of boards and drivers in the first place.
Otherwise, it feels like we might need a strategy for migrating pretty
much everything if we don't want to end up in a mess.
Cheers
---Dave
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox