linux-kernel - Re: [PATCH TIP 03/14] x86/dtb: Add a device tree for CE4100

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4D4B1EFD.4060305@firmworks.com>
Date:	Thu, 03 Feb 2011 11:32:45 -1000
From:	Mitch Bradley <wmb@...mworks.com>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	sodaville@...utronix.de, devicetree-discuss@...ts.ozlabs.org,
	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH TIP 03/14] x86/dtb: Add a device tree for CE4100

On 2/3/2011 10:59 AM, Grant Likely wrote:
> On Thu, Jan 27, 2011 at 02:41:47PM +0530, Sebastian Andrzej Siewior wrote:
>> * David Gibson | 2011-01-27 15:00:27 [+1000]:
>>>> +					>;
>>>> +
>>>> +				i2c-controller@...00,0,0 {
>>>
>>> Uh.. that unit address does not look right.  The encoding of PCI
>>> 3-cell addresses into a unit address string is not simply comma
>>> separated cells.  I forget the details, so you'll need to check the OF
>>> PCI binding.
>>
>> Grant wrote [0]:
>> |You'll also note that I added ',0,0' to the end of the address.
>> |That's because the node address reflects the parent bus address format
>> |which uses 3 cells in this case.
>
> It is quite possible I was mistaken on this point.  The PCI binding is
> not my area of strength.

In real OF, the unit address of a PCI device is the first entry in the 
reg property, which is the config space address.  For the config space 
address, only the most significant of the three cells is significant; 
the other two must be 0.

The numerical representation of that cell in binary is 
0000.0000.0000.0000.dddd.dfff.0000.0000, where d is the device number on 
its bus segment and fff is the function number.

The text representation is "D,F" , where D is the hexadecimal ASCII 
representation of the binary number ddddd and F is the hexadecimal ASCII 
representation of the binary number fff .  So "show-devs" will display 
names like  "/pci/ethernet@12,e" - device number 0x12, function number 
0xe.

(In the general case, there are more fields in both the numerical and 
text representations, but the unit address usage is restricted to just 
the device and function numbers.  Bus numbers are handled by the 
hierarchy of PCI-to-PCI bridges.)

In real OF, there are "encode-unit" and "decode-unit" methods in the 
parent (PCI bus) node to convert between the numerical and text 
representations.

I don't know how this plays out in the flattened DT world, but the above 
is a summary of what the PCI bus binding stipulates.

>
> g.
>
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss@...ts.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/