[RFC] AmigaOne device tree source v2

Segher Boessenkool segher at kernel.crashing.org
Mon Sep 3 20:02:58 EST 2007

>>> 		host at 0 {
>> The unit address (after the @) should be derived from the first range
>> listed in the 'reg' property.  It's a bus address, not a slot number.
> Actually... on PCI, the unit address is often the slot number, or
> rather, "slot,function" with the second part ommited for non
> multifunction devices.

Not slot number, but "device-id".  Like, if you have actual
PCI plugin slots on your board, they likely have device ids
16,17,...; but slot numbers 1, 2, 3 (little labels on the box).

David's point is that unit addresses are not random numbers.

>> All these devices should have unit addresses.
>  ... which for ISA are generally in the form iPORT (8242 at i60 for
> example) though I've seen the "i" ommited. Not terribly important I
> would say but better to follow the spec.

Omitting the "i" is perfectly in line with the spec :-)

>>> 		ide at 7,1 {
>> This will need a compatible property, at least.
> Actually, it's a PCI device, it can have a compatible property based on
> the generic PCI device compatible property generation as defined in the
> OF PCI binding. Since that's just derived from other fields, I suppose
> it can be omitted in a flat DT. It would be -nice- to have a more
> explicit cpmpatible property but in that case, not absolutely necessary
> since that device will be probed as PCI anyway.

Yeah, PCI is a special case for Linux.  Maybe add a "pciclass,XXXX"
compatible property though, for good measure.  Anything else isn't
all that useful I think.


More information about the Linuxppc-dev mailing list