Re: [RFC/PATCH] of: platform: Remove unique device name enforcement

On Thu, 22 May 2014 13:31:37 -0500, Rob Herring [off-list ref] wrote:

On Wed, May 21, 2014 at 2:43 AM, Grant Likely [off-list ref] wrote:

quoted

On Wed, 21 May 2014 09:53:57 +0900, Grant Likely [off-list ref] wrote:

quoted

On Tue, 20 May 2014 13:30:02 -0500, Rob Herring [off-list ref] wrote:

quoted

On Tue, May 20, 2014 at 1:50 AM, Grant Likely [off-list ref] wrote:

[...]

quoted

quoted

quoted

quoted

Another way to handle it is to only add the suffix when a conflict
actually occurs. That requires checking first whether or not a name will
conflict and ammending it only when that happens. I don't know if that
can be done nicely. I'll take a look.

That was my idea as well and to move to a local number so you have
something like deviceA, deviceA.1, deviceB, deviceB.1 (maybe the
number is always appended). Perhaps a random number instead so no one
expects the names to be an ABI. ;)

Another idea: how about fix the name to alwasy be the final component of
the path name, followed by phandle. Anything that doesn't have a phandle
can be assigned one at boot. That would guarantee uniqueness without the
cost of trying to find duplicates.

for example:
      uart@10043000:0012

Yet another approach. How about this patch? If the unit address cannot
be translated, then append the translated name of the parent.

I Ilke this, but...

quoted

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 9c121819e813..e74fccbeb177 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
+               reg = of_get_property(node, "reg", NULL);
+               if (reg && of_can_translate_address(node)) {
                        addr = of_translate_address(node, reg);

This needs to be rebased on my fix and killing off of of_can_translate_address.

Done. I've rebased this and all the other stuff I've got queued up for
v3.16 on top of your for-next tree.

g.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html