>>> [EMAIL PROTECTED] {
>>
>> 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 ([EMAIL PROTECTED] 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 :-)
>>> [EMAIL PROTECTED],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.
Segher
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
