3 patches against linuxppc_dev-2.4.18-pre7
PATCH 1/1 3 patches against linuxppc_dev-2.4.18-pre7
Hello
The attached patch fixes the following issues:
- arch/ppc/kernel/ppc4xx_pic.c
fixed constant in ppc405_pic_get_irq() (should be NR_AIC_IRQS as in ppc403_pic_get_irq())
- arch/ppc/kernel/ppc_ksyms.c
added "consistent_sync_page"
- drivers/net/ppc405_enet.c
fixed old style register definitions in debug code
Dave
Quoted 8 lines · David Müller (ELSOFT AG)
Hello
The attached patch fixes the following issues:
-
arch/ppc/kernel/ppc4xx_pic.c
fixed constant inppc405_pic_get_irq()(should beNR_AIC_IRQSas inppc403_pic_get_irq())
David,
include/asm-ppc/irq.hNR_IRQS = (NR_AIC_IRQS + NR_BOARD_IRQS) and was defined to allow cascading UIC's.NR_BOARD_IRQS is defined in some of the board files and its default is in include/asm-ppc/ibm4xx.h
So i don't see the need to patch that file but the others look fine.
-- armin
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Hi
Quoted 13 lines · Armin Kuster
Quoted 8 lines · David Müller (ELSOFT AG)
Hello
The attached patch fixes the following issues:
-
arch/ppc/kernel/ppc4xx_pic.c
fixed constant inppc405_pic_get_irq()(should beNR_AIC_IRQSas inppc403_pic_get_irq())David,
Quoted 9 lines
include/asm-ppc/irq.hNR_IRQS= (NR_AIC_IRQS+NR_BOARD_IRQS) and was defined to allow cascading UIC's.NR_BOARD_IRQSis defined in some of the board files and its default is ininclude/asm-ppc/ibm4xx.hSo i don't see the need to patch that file but the others look fine.
Exactly, NR_IRQS is the the total number of irqs possible in the system as this number of irqs is reserved in the irq_desc table.
For example, we have a system with a PPC405GP and an additional PC like 8259 PIC pair, we have NR_AIC_IRQS (32) + NR_BOARD_IRQS (16) = NR_IRQS (48).
In ppc405_pic_get_irq() the following code is executed:
irq = 32 - ffs(bits); if (irq == NR_IRQS) irq = -1; return(irq);
with NR_IRQS equal 48 the condition is never true !
This results in an endless while-loop in do_IRQ() in arch/ppc/kernel/irq.c
Either this or my understanding how things are working is totally wrong. ;-) Additionally, i don't see me why ppc403_pic_get_irq() is using NC_AIC_IRQS while ppc405_pic_get_irq() is using NR_IRQS. Shouldn't they be "symmetric".
Dave
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 45 lines · David Müller (ELSOFT AG)
Hi
Quoted 13 lines · Armin Kuster
Quoted 8 lines · David Müller (ELSOFT AG)
Hello
The attached patch fixes the following issues:
-
arch/ppc/kernel/ppc4xx_pic.c
fixed constant inppc405_pic_get_irq()(should beNR_AIC_IRQSas inppc403_pic_get_irq())David,
Quoted 9 lines
include/asm-ppc/irq.hNR_IRQS= (NR_AIC_IRQS+NR_BOARD_IRQS) and was defined to allow cascading UIC's.NR_BOARD_IRQSis defined in some of the board files and its default is ininclude/asm-ppc/ibm4xx.hSo i don't see the need to patch that file but the others look fine.
Exactly,
NR_IRQSis the the total number of irqs possible in the system as this number of irqs is reserved in theirq_desctable.For example, we have a system with a PPC405GP and an additional PC like 8259 PIC pair, we have
NR_AIC_IRQS(32) +NR_BOARD_IRQS(16) =NR_IRQS(48).In
ppc405_pic_get_irq()the following code is executed:irq = 32 - ffs(bits); if (irq == NR_IRQS) irq = -1; return(irq);with
NR_IRQSequal 48 the condition is never true !
Quoted 7 lines
This results in an endless while-loop in
do_IRQ()inarch/ppc/kernel/irq.cEither this or my understanding how things are working is totally wrong. ;-) Additionally, i don't see me why
ppc403_pic_get_irq()is usingNC_AIC_IRQSwhileppc405_pic_get_irq()is usingNR_IRQS. Shouldn't they be "symmetric".Dave
David,
your right.
-- armin
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 6 lines
Quoted 6 lines
In
ppc405_pic_get_irq()the following code is executed:irq = 32 - ffs(bits);
Quoted 7 lines
Quoted 7 lines
if (irq == NR_IRQS) irq = -1; return(irq);with
NR_IRQSequal 48 the condition is never true !
You might check the actual code generated for ffs() and verify it works -- I ended up recoding this routine because ffs() wasn't working correctly ... [ I forget the particulars, but the code generated and behavior were not correct ];
Mark
--
Mark Pilon
Minolta-QMS
P.O. Box 37
Fallon, MT. 59326-0037
1-406-486-5539 (primary voice line)
1-406-853-0433 (cell)
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
Quoted 4 lines · Mark Pilon
You might check the actual code generated for
ffs()and verify it works -- I ended up recoding this routine becauseffs()wasn't working correctly ... [ I forget the particulars, but the code generated and behavior were not correct ];
It would be nice if you posted the particulars. This function is used in a variety of places, and it appears to work just fine.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/