From: Stephen Warren <swarren@wwwdotorg.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC PATCH] dm: ensure device names are unique
Date: Fri, 29 Apr 2016 10:23:35 -0600 [thread overview]
Message-ID: <57238A87.5070603@wwwdotorg.org> (raw)
In-Reply-To: <CAPnjgZ13B=sAhYBpeyru4oQxF0ihUgPxhKKAxU-ym1Be6w6iyA@mail.gmail.com>
On 04/29/2016 07:23 AM, Simon Glass wrote:
> Hi Stephen,
>
> On 28 April 2016 at 09:55, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 04/27/2016 10:50 PM, Simon Glass wrote:
>>>
>>> Hi Stephen,
>>>
>>> On 26 April 2016 at 15:30, Stephen Warren wrote:
>>> > It is possible for HW to contain multiple instances of the same device.
>>> In
>>> > this case, the name passed to device_bind() may not be unique across
>>> all
>>> > devices within its uclass. One example is a system with multiple
>>> identical
>>> > PCI Ethernet devices. Another might be a system with multiple identical
>>> > I2C GPIO expanders, each connected to a separate I2C bus, yet using the
>>> > same I2C address on that bus and hence having the same DT node name.
>>> >
>>> > Enhance the code to detect this situation, and append a sequence
>>> number so
>>> > the device name to ensure uniqueness.
>>> >
>>> > Signed-off-by: Stephen Warren <swarren at nvidia.com <swarren@nvidia.com>>
>>>
>>> I would rather that the caller handles this. But failing this perhaps a
>>> new function that does it? Is this for the Ethernet use case?
>>
>>
>> Wouldn't all callers of this function simply call the new function? I'm not
>> aware of any case where the code to avoid duplicate names would not be
>> desired.
>>
>> I hit this for the Ethernet case, but I believe it applies to any type of
>> device at all; see another possible trigger case in the commit description.
>
> This does not happen with devices from the device tree. It only
> happens with auto-probed devices. Your I2C GPIO example is odd but I'd
> rather solve that by using the device tree node name.
DT itself imposes no such rule; node names must be unique only within
their parent node but there's no restriction on identical node names
appearing in different parts of the tree.
If U-Boot imposes that rule on DT, then there's no way in general that
we can guarantee U-Boot will be able to use standard DTs (i.e. identical
to those used by Linux or any other OS) for any platform; it'd be
another change someone would need to make to transform a DT to be
"U-Boot compatible", which rather reduces a potential benefit of DT for
U-Boot; being able to just drop a DT in and have it work.
It would be possible for U-Boot to decouple its internal device name
from the DT node name. In which case, your statement would work.
However, I don't think that's the case at the moment, and in fact it's
effectively what this patch is doing, although admittedly there are
other ways of doing this.
next prev parent reply other threads:[~2016-04-29 16:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 21:30 [U-Boot] [RFC PATCH] dm: ensure device names are unique Stephen Warren
2016-04-26 21:36 ` Stephen Warren
2016-04-27 18:40 ` Stephen Warren
2016-04-28 4:44 ` Joe Hershberger
2016-04-28 4:42 ` Joe Hershberger
2016-04-28 16:00 ` Stephen Warren
2016-04-29 13:24 ` Simon Glass
2016-04-28 4:50 ` Simon Glass
2016-04-28 15:55 ` Stephen Warren
2016-04-29 13:23 ` Simon Glass
2016-04-29 16:23 ` Stephen Warren [this message]
2016-04-29 16:28 ` Simon Glass
2016-04-29 16:30 ` Stephen Warren
2016-04-29 17:22 ` Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57238A87.5070603@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox