13 Nov, 2008
1 commit
-
Commit 0c5d1eb77a8be917b638344a22afe1398236482b (genirq: record trigger
type) caused powerpc platforms that had no set_type() function in their
struct irq_chip to spew out warnings about "No set_type function for
IRQ...". This warning isn't necessarily justified though because the
generic powerpc platform code calls set_irq_type() (which in turn calls
__irq_set_trigger) with information from the device tree to establish
the interrupt mappings, regardless of whether the PIC can actually set
a type.A platform's irq_chip might not have a set_type function for a variety
of reasons, for example: the platform may have the type essentially
hard-coded, or as in the case for Cell interrupts are just messages
past around that have no real concept of type, or the platform
could even have a virtual PIC as on the PS3.Signed-off-by: Mark Nelson
Signed-off-by: Ingo Molnar
10 Nov, 2008
3 commits
-
Impact: build fix
fix build failure on UP.
Signed-off-by: Ingo Molnar
-
The affinity setting in setup irq is called before the NO_BALANCING
flag is checked and might therefore override affinity settings from the
calling code with the default setting.Move the NO_BALANCING flag check before the call to the affinity
setting.Signed-off-by: Thomas Gleixner
Signed-off-by: Ingo Molnar -
Impact: preserve user-modified affinities on interrupts
Kumar Galak noticed that commit
18404756765c713a0be4eb1082920c04822ce588 (genirq: Expose default irq
affinity mask (take 3))overrides an already set affinity setting across a free /
request_irq(). Happens e.g. with ifdown/ifup of a network device.Change the logic to mark the affinities as set and keep them
intact. This also fixes the unlocked access to irq_desc in
irq_select_affinity() when called from irq_affinity_proc_write()Signed-off-by: Thomas Gleixner
Signed-off-by: Ingo Molnar
22 Oct, 2008
1 commit
-
This variable is only used in the source file, so make it static.
Signed-off-by: Roel Kluin
Signed-off-by: Ingo Molnar
21 Oct, 2008
2 commits
-
If the member 'name' of the irq_desc structure happens to point to a
character string that is resident within a kernel module, problems ensue
if that module is rmmod'd (at which time dynamic_irq_cleanup() is called)
and then later show_interrupts() is called by someone.It is also not a good thing if the character string resided in kmalloc'd
space that has been kfree'd (after having called dynamic_irq_cleanup()).
dynamic_irq_cleanup() fails to NULL the 'name' member and
show_interrupts() references it on a few architectures (like h8300, sh and
x86).Signed-off-by: Dean Nelson
Signed-off-by: Ingo Molnar
Signed-off-by: Andrew Morton
Signed-off-by: Ingo Molnar -
Impact: fix boot hang on a G5
In set_irq_type() we want to pass the type rather than the current
interrupt state.Signed-off-by: Chris Friesen
Acked-by: Benjamin Herrenschmidt
Acked-by: David Brownell
Signed-off-by: Ingo Molnar
16 Oct, 2008
30 commits
-
probe_irq_off() is disfunctional as the local nr_irqs is referenced
instead of the global one for the for_each_irq_desc() iterator.Signed-off-by: Thomas Gleixner
-
Use for_each_irq_desc[_reverse] for all the iteration loops.
Signed-off-by: Thomas Gleixner
-
Signed-off-by: Thomas Gleixner
-
Revert the dynarray changes. They need more thought and polishing.
Signed-off-by: Thomas Gleixner
-
Remove the leftover of sparseirqs.
Signed-off-by: Thomas Gleixner
-
This code is not ready, but we need to rip it out instead of rebasing
as we would lose the APIC/IO_APIC unification otherwise.Signed-off-by: Thomas Gleixner
-
For the non sparse irq case an inline function is perfectly fine.
Signed-off-by: Thomas Gleixner
-
when SPARSE_IRQ is not used, should still use irq_desc->lock
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
caused by
commit a532e19680ada3b8579b81e67e76d3ebd19c340f
Author: Yinghai Lu
Date: Wed Aug 20 20:46:25 2008 -0700x86: sparse_irq needs spin_lock in allocations
Signed-off-by: Andrew Morton
Signed-off-by: Ingo Molnar -
Signed-off-by: Yinghai Lu
Cc: Yinghai Lu
Cc: Andrew Morton
Signed-off-by: Ingo Molnar -
Steven Noonan reported a boot hang when using irqpoll and
CONFIG_HAVE_SPARSE_IRQ=y.The irqpoll loop needs to be updated to not iterate from 1 to nr_irqs
but to iterate via for_each_irq_desc(). (in the former case desc can
be NULL which crashes the box)Reported-by: Steven Noonan
Tested-by: Steven Noonan
Signed-off-by: Ingo Molnar -
Change the IRQ affinity in the process context when the IRQ is disabled.
Signed-off-by: Venkatesh Pallipadi
Signed-off-by: Shaohua Li
Signed-off-by: Ingo Molnar -
Extraneous call to irq_to_desc().
Signed-off-by: Dean Nelson
Cc: Yinghai Lu
Signed-off-by: Ingo Molnar -
fix non-sparseirq architectures.
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
Suresh Siddha noticed that we should have a spinlock around it.
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
-tip testing found this lockdep splat:
[ 0.000000] Initializing CPU#0
[ 0.000000] found new irq_desc for irq 0
[ 0.000000] INFO: trying to register non-static key.
[ 0.000000] the code is fine but needs lockdep annotation.
[ 0.000000] turning off the locking correctness validator.
[ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.27-rc3-tip-00191-g98ccb89-dirty #1
[ 0.000000] [] register_lock_class+0x3d2/0x400
[ 0.000000] [] ? mcount_call+0x5/0xa
[ 0.000000] [] __lock_acquire+0x22a/0x5d0
[ 0.000000] [] ? mcount_call+0x5/0xa
[ 0.000000] [] lock_acquire+0x71/0xa0
[ 0.000000] [] ? set_irq_chip+0x3f/0x90
[ 0.000000] [] _spin_lock_irqsave+0x58/0x90
[ 0.000000] [] ? set_irq_chip+0x3f/0x90
[ 0.000000] [] set_irq_chip+0x3f/0x90
[ 0.000000] [] ? handle_level_irq+0x0/0xe0
[ 0.000000] [] set_irq_chip_and_handler_name+0x1a/0x40
[ 0.000000] [] init_ISA_irqs+0x51/0xa0
[ 0.000000] [] pre_intr_init_hook+0x25/0x30
[ 0.000000] [] native_init_IRQ+0x13/0x370
[ 0.000000] [] ? lock_release+0xcc/0x1d0
[ 0.000000] [] ? mcount_call+0x5/0xa
[ 0.000000] [] ? __mutex_unlock_slowpath+0x92/0x110
[ 0.000000] [] ? mutex_unlock+0xd/0x10
[ 0.000000] [] ? cpu_maps_update_done+0x12/0x20
[ 0.000000] [] ? register_cpu_notifier+0x23/0x30
[ 0.000000] [] init_IRQ+0xe/0x10
[ 0.000000] [] start_kernel+0x1c5/0x340
[ 0.000000] [] ? unknown_bootoption+0x0/0x210
[ 0.000000] [] i386_start_kernel+0x6b/0x80
[ 0.000000] =======================
[ 0.000000] found new irq_desc for irq 1
[ 0.000000] found new irq_desc for irq 2
[ 0.000000] found new irq_desc for irq 3this:
static void init_one_irq_desc(struct irq_desc *desc)
{
memcpy(desc, &irq_desc_init, sizeof(struct irq_desc));
#ifdef CONFIG_TRACE_IRQFLAGS
lockdep_set_class(&desc->lock, &irq_desc_lock_class);
#endif
}should be unconditional.
Signed-off-by: Ingo Molnar
-
This has been deprecated for years, the user space irqbalanced utility
works better with numa, has configurable policies, etc...Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
so later don't need compare with -1U
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
change names:
irq_desc() ==> irq_desc_alloc
__irq_desc() ==> irq_descAlso split a few of the uses in lowlevel x86 code.
v2: need to check if desc is null in smp_irq_move_cleanup
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
So we could remove some duplicated calling to irq_desc
v2: make sure irq_desc in init/main.c is not used without generic_hardirqs
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
remove irq limit checks - nr_irqs is dynamic and we expand anytime.
v2: fix checking about result irq_cfg_without_new, so could use msi again
v3: use irq_desc_without_new to check irq is validSigned-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
There are a handful of loops that go from 0 to nr_irqs and use
get_irq_desc() on them. These would allocate all the irq_desc
entries, regardless of the need for them.Use the smarter for_each_irq_desc() iterator that will only iterate
over the present ones.v2: make sure arch without GENERIC_HARDIRQS work too
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
add an irq_desc accessor that will not allocate any sparse entry
but returns failure if there's no entry present.Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
based on Eric's patch ...
together mold it with dyn_array for irq_desc, will allcate kstat_irqs for
nr_irq_desc alltogether if needed. -- at that point nr_cpus is known already.v2: make sure system without generic_hardirqs works they don't have irq_desc
v3: fix merging
v4: [mingo@elte.hu] fix typo[ mingo@elte.hu ] irq: build fix
fix:
arch/x86/xen/spinlock.c: In function 'xen_spin_lock_slow':
arch/x86/xen/spinlock.c:90: error: 'struct kernel_stat' has no member named 'irqs'Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
fix:
[ 10.631533] calling yenta_socket_init+0x0/0x20
[ 10.631533] Yenta: CardBus bridge found at 0000:15:00.0 [17aa:2012]
[ 10.631533] Yenta: Using INTVAL to route CSC interrupts to PCI
[ 10.631533] Yenta: Routing CardBus interrupts to PCI
[ 10.631533] Yenta TI: socket 0000:15:00.0, mfunc 0x01d01002, devctl 0x64
[ 10.731599] BUG: unable to handle kernel NULL pointer dereference at 00000040
[ 10.731838] IP: [] _spin_lock_irq+0xf/0x20
[ 10.732221] *pde = 00000000
[ 10.732741] Oops: 0002 [#1] SMP
[ 10.733453]
[ 10.734253] Pid: 1, comm: swapper Tainted: G W (2.6.27-rc3-tip-00173-gd7eaa4f-dirty #1)
[ 10.735188] EIP: 0060:[] EFLAGS: 00010002 CPU: 0
[ 10.735523] EIP is at _spin_lock_irq+0xf/0x20
[ 10.735523] EAX: 00000040 EBX: 00000000 ECX: f6e04c90 EDX: 00000100
[ 10.735523] ESI: 000000df EDI: f6e04c90 EBP: f7867df0 ESP: f7867df0
[ 10.735523] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 10.735523] Process swapper (pid: 1, ti=f7867000 task=f7870000 task.ti=f7867000)
[ 10.735523] Stack: f7867e04 c0155fbd 00000000 00000000 f6e04c90 f7867e5c c0c6e319 c0f6a074
[ 10.735523] f6e04c90 000017aa 00002012 c112b648 f791f240 c112b5e0 f7867e44 c010440b
[ 10.735523] f791f240 f791f29c c112b8ec f791f240 00000000 f7867e5c c048f893 03c0b648
[ 10.735523] Call Trace:
[ 10.735523] [] ? probe_irq_on+0x3d/0x140
[ 10.735523] [] ? yenta_probe+0x529/0x640
[ 10.735523] [] ? mcount_call+0x5/0xa
[ 10.735523] [] ? pci_match_device+0xa3/0xb0
[ 10.735523] [] ? pci_device_probe+0x5e/0x80
[ 10.735523] [] ? driver_probe_device+0x83/0x180
[ 10.735523] [] ? __driver_attach+0x74/0x80
[ 10.735523] [] ? bus_for_each_dev+0x49/0x70
[ 10.735523] [] ? driver_attach+0x1e/0x20
[ 10.735523] [] ? __driver_attach+0x0/0x80
[ 10.735523] [] ? bus_add_driver+0x1a3/0x220
[ 10.735523] [] ? pci_device_remove+0x0/0x40
[ 10.735523] [] ? driver_register+0x54/0x130
[ 10.735523] [] ? __pci_register_driver+0x4f/0x90
[ 10.735523] [] ? yenta_socket_init+0x19/0x20
[ 10.735523] [] ? do_one_initcall+0x35/0x160
[ 10.735523] [] ? yenta_socket_init+0x0/0x20
[ 10.735523] [] ? __queue_work+0x36/0x50
[ 10.735523] [] ? queue_work_on+0x3d/0x50
[ 10.735523] [] ? kernel_init+0x148/0x210
[ 10.735523] [] ? kernel_init+0x0/0x210
[ 10.735523] [] ? kernel_thread_helper+0x7/0x10
[ 10.735523] =======================
[ 10.735523] Code: 10 38 f2 74 06 f3 90 8a 10 eb f6 5d 89 c8 c3 8d b6 00 00 00 00 8d bc 27 00 00 00 00 55 89 e5 e8 a4 e8 46 ff fa ba 00 01 00 00 90 0f c1 10 38 f2 74 06 f3 90 8a 10 eb f6 5d c3 90 55 89 e5 53as auto-probing wants to iterate over existing irqs.
Signed-off-by: Ingo Molnar
-
add CONFIG_HAVE_SPARSE_IRQ to for use condensed array.
Get rid of irq_desc[] array assumptions.Preallocate 32 irq_desc, and irq_desc() will try to get more.
( No change in functionality is expected anywhere, except the odd build
failure where we missed a code site or where a crossing commit itroduces
new irq_desc[] usage. )v2: according to Eric, change get_irq_desc() to irq_desc()
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
fix:
Building modules, stage 2.
MODPOST 458 modules
ERROR: "nr_irqs" [drivers/serial/8250.ko] undefined!Signed-off-by: Ingo Molnar
-
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar -
at this point nr_irqs is equal NR_IRQS
convert a few easy users from NR_IRQS to dynamic nr_irqs.
v2: according to Eric, we need to take care of arch without generic_hardirqs
Signed-off-by: Yinghai Lu
Signed-off-by: Ingo Molnar
02 Oct, 2008
2 commits
-
Genirq hasn't previously recorded the trigger type used by any given IRQ,
although some irq_chip support has done so. That data can be useful when
troubleshooting. This patch records it in the relevant irq_desc.status
bits, and improves consistency between the two driver-visible calls
affected:- Make set_irq_type() usage match request_irq() usage:
* IRQ_TYPE_NONE should be a NOP; succeed, so irq_chip methods
won't have to handle that case any more (many do it wrong).
* IRQ_TYPE_PROBE is ignored; any buggy out-of-tree callers
might need to switch over to the real IRQ probing code.
* emit the same diagnostics (from shared utility code)- Their kerneldoc now reflects usage:
* request_irq() flags include IRQF_TRIGGER_* to specify
active edge(s)/level ... docs previously omitted that
* set_irq_type() is declared in so callers
should use the (bit-equivalent) IRQ_TYPE_* symbols thereAlso: adds a warning about shared IRQs that don't end up using the
requested trigger mode; and fix an unrelated "sparse" warning.Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Acked-by: Thomas Gleixner
Signed-off-by: Ingo Molnar
07 Sep, 2008
1 commit
-
This patch clarifies usage of irq_chip->startup() callback:
1. The "if (startup) startup(); else enabled();" code in setup_irq()
is unnecessary, as startup() falls back to enabled() via
default callbacks, set by irq_chip_set_defaults().2. When using set_irq_chained_handler() the startup() was never called,
which is not good at all... Fixed. And again - when startup() is not
defined the call will fall back to enable() than to unmask() via
default callbacks.Signed-off-by: Pawel Moll
Acked-by: Benjamin Herrenschmidt
Signed-off-by: Ingo Molnar
