[U-Boot] [PATCH 1/3] core: Add function to get device for ofnode

Mario Six mario.six at gdsys.cc
Wed Apr 18 08:20:41 UTC 2018


Hi Simon,

On Thu, Apr 12, 2018 at 6:42 PM, Simon Glass <sjg at chromium.org> wrote:
> Hi Mario,
>
> On 10 April 2018 at 05:34, Mario Six <mario.six at gdsys.cc> wrote:
>> Hi Simon,
>>
>> On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Mario,
>>>
>>> On 28 March 2018 at 20:37, Mario Six <mario.six at gdsys.cc> wrote:
>>>> It's sometimes useful to get the device associated with a given ofnode.
>>>> Implement a function to implement this lookup operation.
>>>
>>> Where would you use this? Can you not use phandles to find the device?
>>> Or uclass_get_device_by_ofnode() ?
>>>
>>
>> The function is used with the dev_{enable,disable}_by_path in the next patch:
>> If I used any of the uclass_* functions or similar, the device would be probed,
>> which is not what I want, since the device may not actually be physically
>> present.
>
> So how about using uclass_find_device_by_ofnode() ?
>

That would work for the disabling, true, but not for the enabling (which is
what is used in the upcoming board): Since the node is declared as disabled in
the DT, the device is not even bound (so uclass_find_device_by_ofnode) won't
return it.

A more elegant solution would be to have device_probe check again if the
underlying ofnode is disabled, and stop the probing if that's the case. In this
scenario the disabled devices would still be displayed in the tree, but never
probed, which is probably OK (I don't know if there would be any side effects
with iterating through devices, for example). But changing the behavior of such
elementary API functions is probably not a good idea.

> Regards,
> Simon

Best regards,
Mario


More information about the U-Boot mailing list