GIC irq_start detection breaks 3.2 boot on platforms without PPIs

[Will Deacon]

On Sun, Nov 27, 2011 at 01:00:16PM +0000, Will Deacon wrote:
> On Sat, Nov 26, 2011 at 10:08:34PM +0000, Russell King - ARM Linux wrote:
> > I've merged this into my fixes branch, but when I re-merge this with
> > Marc's irqchip consolidation, I get conflicts.  I think I've fixed it
> > correctly, but please check the result, which you'll find in my for-next
> > branch.
> 
> Thanks for merging this. I've just had a quick look and the resolution looks
> functionally correct to me (I'll try booting your for-next branch tomorrow).

I've tested on 1176, A8 and A9 platforms and your for-next branch seems to
be ok. I do get these compilation warnings on the UP CPUs:

arch/arm/mm/ioremap.c: In function ‘unmap_area_sections’:
arch/arm/mm/ioremap.c:80:3: warning: passing argument 1 of ‘pmd_offset’ from incompatible pointer type
/home/will/work/aarch32/linux/linux/arch/arm/include/asm/pgtable.h:181:22: note: expected ‘struct pud_t *’ but argument is of type ‘pmdval_t (*)[2]’
arch/arm/mm/ioremap.c: In function ‘remap_area_sections’:
arch/arm/mm/ioremap.c:130:3: warning: passing argument 1 of ‘pmd_offset’ from incompatible pointer type
/home/will/work/aarch32/linux/linux/arch/arm/include/asm/pgtable.h:181:22: note: expected ‘struct pud_t *’ but argument is of type ‘pmdval_t (*)[2]’
arch/arm/mm/ioremap.c: In function ‘remap_area_supersections’:
arch/arm/mm/ioremap.c:167:4: warning: passing argument 1 of ‘pmd_offset’ from incompatible pointer type
/home/will/work/aarch32/linux/linux/arch/arm/include/asm/pgtable.h:181:22: note: expected ‘struct pud_t *’ but argument is of type ‘pmdval_t (*)[2]’

and if I cat /proc/self/net/dev_mcast, then I get an OOPs:

[   41.771296] Unable to handle kernel NULL pointer dereference at virtual address 00000010
[   41.797076] pgd = c797c000
[   41.806863] [00000010] *pgd=070e7831, *pte=00000000, *ppte=00000000
[   41.827111] Internal error: Oops: 17 [#1] PREEMPT
[   41.841221] Modules linked in:
[   41.850392] CPU: 0    Tainted: G        W     (3.2.0-rc2+ #3)
[   41.867681] PC is at dev_seq_next+0x14c/0x1dc
[   41.880763] LR is at seq_read+0x43c/0x494
[   41.892798] pc : [<c024d564>]    lr : [<c00cee54>]    psr: 60000013
[   41.892826] sp : c79f3ed4  ip : 00006405  fp : 00008000
[   41.927254] r10: 00000010  r9 : c79f3f80  r8 : 00000010
[   41.942927] r7 : 00000000  r6 : 00000001  r5 : c041d100  r4 : 00000001
[   41.962512] r3 : c024d418  r2 : c79f3f08  r1 : 00000001  r0 : c70e5640
[   41.982100] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   42.003512] Control: 00c5387d  Table: 0797c008  DAC: 00000015
[   42.020750] Process cat (pid: 764, stack limit = 0xc79f22f0)
[   42.037728] Stack: (0xc79f3ed4 to 0xc79f4000)
[   42.050805] 3ec0:                                              00000000 00000001 c70e5640
[   42.075369] 3ee0: c7091b00 00000000 c79f3f80 c79f3f08 c03f07c4 0138a000 c70e5668 00000000
[   42.099931] 3f00: 00000000 400f1000 00000001 00000000 00000025 c7862000 c00cea18 0138a000
[   42.124493] 3f20: c79f3f80 c79f2000 c79f2000 00000000 00000000 c00f6c2c 000000c5 c7091b00
[   42.149059] 3f40: 0138a000 0138a000 c79f3f80 c7091b00 00008000 c00b0be8 00000003 c00a8124
[   42.173621] 3f60: 00000001 c7091b00 0138a000 00000000 00000000 00008000 00000000 c00b0cf8
[   42.198181] 3f80: 00000000 00000000 00000025 00000000 00008000 0138a000 00000003 00000003
[   42.222745] 3fa0: c000e344 c000e1c0 00008000 0138a000 00000003 0138a000 00008000 0138a000
[   42.247307] 3fc0: 00008000 0138a000 00000003 00000003 0138a000 00000000 400f1000 00000000
[   42.271869] 3fe0: 7fffe000 be951b50 0000dea0 401f8a7c 60000010 00000003 00000000 00000000
[   42.296468] [<c024d564>] (dev_seq_next+0x14c/0x1dc) from [<c03f07c4>] (0xc03f07c4)
[   42.319206] Code: eaffffee e590803c e59f508c e1a0a008 (e5984000) 
[   42.343526] ---[ end trace 1b75b31a2719ed1f ]---

but I don't think that's your fault (excuse the pun)!

Will