> That looks totally bogus. Unlike Segher, I think there are a few > cases where overlapping reg and ranges can make sense
That's not unlike me -- I may have lower tolerance for it though :-) > (PCI bridges > where config space is accessed indirectly via MMIO registers which lie > in the legacy ISA IO space is an example). That's a good example yes. > But this doesn't look like > such a case - it just looks like whoever did the device tree > misunderstood the distinction between reg and ranges. Indeed. >>> PCI legacy I/O is not direct mapped: there is no legacy I/O on a >>> PowerPC system bus. So, it can not be mentioned in the "ranges" >>> property, but the PHB registers used to access it should be shown >>> in the "reg" property. It could be a simple linear window (it >>> sounds like it is here?), but it could for example also be >>> implemented >>> via an address/data register pair. > > Err... huh? The legacy IO space is assigned a block of addresses in > 3-word "OF-PCI-space by the PCI binding. When that is translated into > an MMIO range by the bridge, there's no reason that can't be encoded > into the ranges property. Sure, it can be encoded like that. But does it make sense? You cannot use legacy I/O space as normal memory space. On an arch like x86, where "I/O addresses" exist on the system bus as well, it would make sense, since you can translate I/O addresses to I/O addresses that way (except on x86 even it cannot be done either, since I/O addresses cannot be encoded on the root bus -- at least not in existing device trees. There is no official x86 binding yet though). Also, from a driver standpoint, a PHB driver needs to find out two main things about the bridge: a) how and where to generate config cycles; b) how and where to generate legacy I/O cycles. It is told "how" by the "compatible" property, and "where" by the "reg" property, normally. But yes, you _can_ use "ranges" for this purpose on PHBs where legacy I/O is linearly mapped. It just doesn't make much sense. The binding for your specific PHB should tell you what to do. >> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it >> should >> be enough to check for the board type, but a compatible property >> doesn't >> hurt. > > The whole damn point of the device tree is to avoid using this kind of > non-local information "I know what the board type is over there, so it > must be this PCI bridge over here". The node should have a compatible > property which is sufficient to select the right bridge driver. Yeah. _Even if_ the kernel decides to cheat by hardcoding certain board information, that doesn't mean the device tree shouldn't encode that info, too. > I think this is typically badly done at the moment, simply because PCI > has historically been set up by the platform code, rather than by a > "host bridge driver" in the mould of other drivers. I don't see that > changing real soon, but that doesn't mean we shouldn't at least put > enough information in the device tree to make it possible. Exactly. Segher _______________________________________________ Linuxppc-dev mailing list [email protected] https://ozlabs.org/mailman/listinfo/linuxppc-dev
