[parisc-linux-cvs] linux tsbogend

[Matthew Wilcox]

On Sat, Jan 05, 2002 at 12:38:26AM -0700, Grant Grundler wrote:
> hmmm...that's not a fair assesment. bus_devices stuff was only intended
> to support LASI. I thought it could be used to support dino auxilary
> devices as well.  This was all before rbrad and yourself implemented
> the PA devices IO tree.  The I/O Tree will obsolete many of the things
> we've done. Perhaps bus_devices support can completely go away in the
> future or change to use the IO tree like dino does.

i wasn't specifically referring to the busdevice code but to all the PA
device code.  i'm still dissatisfied with it, but i really don't have
time to fix it.

> It wasn't until you explained fixup_child_irqs() initializes IRQ values
> for dino's "children" (serial and PS/2). Those "children" are only
> present when PDC tells us about them and we depend on PDC to only provide
> pseudo entries for usable devices. I really hope this works as it shows
> how the IO Tree is useful for more than just DMA services.

unfortunately, the bogus devices are an orthogonal problem.  they appear
during the buswalk of the gsc bus.  Here's an example culled from
http://lists.parisc-linux.org/hypermail/parisc-linux/7139.html
It's kernel 2.4.9-32

1. U2-IOA BC Runway Port (12) at 0xfff88000 [8], versions 0x580, 0xf, 0xb
2. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions 0x680, 0x3, 0xa
3. Raven U/L2 Dino RS-232 (10) at 0xf2003000 [8/0/63], versions 0x6, 0x0, 0x8c 
...
12. U2-IOA BC Runway Port (12) at 0xfff8a000 [10], versions 0x580, 0xf, 0xb
13. Cujo PCI Bridge (13) at 0xf1000000 [10/0], versions 0x682, 0x1, 0xa, additional addresses: 0xf6000000 

then we walk the busses and get:

17. Dino PCI Bridge (13) at 0xf2000000 [8/0], versions 0x680, 0x3, 0xa
18. Raven U/L2 Dino RS-232 (10) at 0xf2003000 [8/0/63], versions 0x6, 0x0, 0x8c
19. Raven U/L2 Dino PS/2 Port (10) at 0xf2001000 [8/1], versions 0x6, 0x0, 0x96 
...
28. Cujo PCI Bridge (13) at 0xf1000000 [10/0], versions 0x682, 0x1, 0xa, additional addresses: 0xf6000000
29. Dino RS-232 (10) at 0xf1003000 [10/3], versions 0x7, 0x0, 0x8c 

The additional PS/2 port (19) and RS-232 port (29) aren't reported by
firmware, so we can assume they're not connected.  Theoretically they
shouldn't get assigned an IRQ (because they appear as siblings of
dino/cujo, not children) so we can choose to ignore them.  I don't
remember how far through cleanup we'd got by 2.4.9-pa32 -- we might not
assign an IRQ to that serial port now, but we certainly did in 2.4.9-pa32.

-- 
Revolutions do not require corporate support.