On Sat, 30 Sep 2006 11:43:32 +0300, Muli Ben-Yehuda said: > + * Each Calgary has four busses. The first four busses (first Calgary) > + * have RIO node ID 2, then the next four (second Calgary) have RIO > + * node ID 3, the next four (third Calgary) have node ID 2 again, etc. > + * We use a gross hack - relying on the dev->bus->number ordering, > + * modulo 14 - to decide which Calgary a given bus is on. Busses 0, 1, > + * 2 and 4 are on the first Calgary (id 2), 6, 8, a and c are on the > + * second (id 3), and then it repeats modulo 14. > + */ > + rionodeid = (dev->bus->number % 14 > 4) ? 3 : 2; A quick perusal of the pci-calgary.c in 2.6.18-mm2 doesn't find a single comment explaining where "6, 8, a, c" comes from, which makes that 14 seem "magical" - are the 3rd Calgary's busses e,f, 10, and 12? It makes me wonder why they didn't just blow 2 "reserved" numbers to make it mod 16 and an easier decode. ;)
Attachment:
pgpqcYQ7iR7MD.pgp
Description: PGP signature
- References:
- Prev by Date: Re: [PATCH] Remove logic error in /Documentation/devices.txt
- Next by Date: Re: How is Code in do_sys_settimeofday() safe in case of SMP and Nest Kernel Path?
- Previous by thread: [PATCH 4 of 4] x86-64: Calgary IOMMU: Fix off by one when calculating register space
- Next by thread: Re: [PATCH 0 of 4] x86-64: Calgary IOMMU updates
- Index(es):
 |