On Fri, Dec 06, 2013 at 09:37:59PM +0100, Wolfgang Denk wrote:
Dear Tom,
In message 20131206162854.GX420@bill-the-cat you wrote:
But this is crap. The meaning of these variables has been wel-defined for a long, long time. "fdt_addr" is the FDT address in NOR flash (or similar memory except system RAM); "fdt_addr_r" is the FDT address when loaded to system RAM (hence the "_r" in the variable name).
It's a well defined and widely ignored in ARM convention then. We've got lots of 'fdt_addr' meaning RAM and no 'fdt_addr_r' and then in both ARM and PowerPC 'fdtaddr' being presumably RAM.
I think it's actually OK to omit the "_r" in NOR-less systems. The number of devices with actual NOT flash is decreasing, and if you can be sure that there is no such memory device available, then it is just overhead to always carry the "_r" suffice around, knowing all the time that there will never be any other option than RAM to store that data.
Right. So the rule is "fdt_addr means the [shipped] DT in NOR, if present. fdt_addr_r means the [shipped] DT in system RAM."
I do not complain if such systems use a simplified setup without the "_r".
What I don't like to see is to have "fdt_addr_r" and "fdt_addr" used with a new, totally different meaning.
Well, "fdt_addr" still means the shipped DT and "fdt_addr_r" still means a DT loaded into system RAM. The only change is that fdt_addr may also be a system RAM address.
I don't know where the spelling "fdtaddr" is coming from; I would consider it one of the many "non-standard" variants (assuming we agree that there is actually something like a "standard"). Note that there is no "fdtaddr_r" anywhere.
"fdtaddr" comes from somewhere along the line someone not going "Hey, you forgot a _ in your env" since it means what fdt_addr_r means or fdt_addr means when you lack NOR/similar flash for a DT.
I would say that 'fdt_addr' being the system provided DT, even when not found on memory-mapped flash and 'fdt_addr_r' being the user provided one is a logical extension.
Um... you enter completely new terms here - "system provided" and "user provided". I cannot see how a "user provided" DTB in NOR flash would fit in such a concept, nor how this would work on systems with NOR if a "system provided" DTB gets loaded into RAM from a DHCP server.
"system provided" or "shipped" or what have you for the vendor provided DT, which previously would have been in NOR, for fdt_addr when you also have fdt_addr_r. And I believe the answer to the second question is that yes, the shipped or system provided DTB would end up in fdt_addr, so long as whatever "grab the provided default DT" puts it there.
I understand that you are trying to give the old names a new definition that would magically cover the suggested use, but this is extremely thin ice. I recommend not to try that.
Well, lets see if we can't convince you around. Or get some better names to use for these use cases.