Thread (40 messages) 40 messages, 12 authors, 2014-09-14

[PATCH 11/14] arm64: dts: Add initial device tree support for EXYNOS7

From: mark.rutland@arm.com (Mark Rutland)
Date: 2014-08-28 18:17:28
Also in: linux-devicetree, linux-samsung-soc

On Thu, Aug 28, 2014 at 06:47:00PM +0100, Geert Uytterhoeven wrote:
Hi Mark,

On Thu, Aug 28, 2014 at 7:39 PM, Mark Rutland [off-list ref] wrote:
quoted
quoted
quoted
quoted
Ok. If address-cells is kept at 2 the unit address needs to be changed
to "0,0". So one or the other has to be changed.
I'm happy either way.

I'm not sure the rest of the tree had "0," prefixes on all of the
unit-addresses for 64-bit addresses that were under 4GB, and I'm not
sure that existing dts consistently do that either.

Do we want to enforce that for all 64-bit unit-addresses?
Yeah, I believe that's the only valid format for a 2-address-cell unit address.
Fair enough. I didn't spot this explicitly mentioned anywhere in ePAPR,
but the examples match.
I couldn't find much about how the unit-addresses should really look like.

Power_ePAPR_APPROVED_v1.1.pdf:
"The unit-address component of the name is specific to the bus type on
which the node sits. It consists
of one or more ASCII characters from the set of characters in Table
2-1. The unit-address must
match the first address specified in the reg property of the node. If
the node has no reg property, the
@ and unit-address must be omitted and the node-name alone
differentiates the node from other nodes
at the same level in the tree. The binding for a particular bus may
specify additional, more specific
requirements for the format of reg and the unit-address."

"Table 2.1" contains lot of characters, definitely not limited to hex numbers.
Also nothing about (not) needing a "0x" prefix.
This is unfortunate. I guess this was assumed to be implied by way of
the examples. :/
quoted
I should probably re-jig that checkpatch test I had for unit-addresses.
It would be great if dtc started complaining about unit-addresses not
matching the first reg property.
Agreed.

When I last tried I thought that required more complex parsing than
could be done with a regex.

That said, I'd forgotten that properties must come before child nodes,
so I though I had to at least balance '{' and '}' for children. I guess
all we need to do is find a line beginning with '\s*reg\s*=\s*<' before
the next '{' or '}'.

Maybe this will be easier than previously thought. :)

Mark.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help