public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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:30:05 -0600	[thread overview]
Message-ID: <57238C0D.6060100@wwwdotorg.org> (raw)
In-Reply-To: <CAPnjgZ3QemVg5ti+i=AZNnHU0fEmkvjVYj4X7zRzonFFw=bj_w@mail.gmail.com>

On 04/29/2016 10:28 AM, Simon Glass wrote:
> Hi Stephen,
>
> On 29 April 2016 at 10:23, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> 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@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.
>
> U-Boot does not impose a rule. If you want duplicate device names you
> can have them. I think it is bad practice though.
>
>>
>> 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.
>
> Anyway I believe my point stands. Whereas users can edit the device
> tree and avoid conflicts they cannot do this with auto-probed devices.
> So for that case we should have a way of allocating a name before
> calling device_bind().

OK. I'm just going to solve this by unplugging the second Ethernet card, 
or holding this patch locally for the case when I need to test the PCIe 
port.

  reply	other threads:[~2016-04-29 16:30 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
2016-04-29 16:28         ` Simon Glass
2016-04-29 16:30           ` Stephen Warren [this message]
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=57238C0D.6060100@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