Hi Mario,
On 18 April 2018 at 02:20, Mario Six mario.six@gdsys.cc wrote:
Hi Simon,
On Thu, Apr 12, 2018 at 6:42 PM, Simon Glass sjg@chromium.org wrote:
Hi Mario,
On 10 April 2018 at 05:34, Mario Six mario.six@gdsys.cc wrote:
Hi Simon,
On Fri, Mar 30, 2018 at 12:43 AM, Simon Glass sjg@chromium.org wrote:
Hi Mario,
On 28 March 2018 at 20:37, Mario Six mario.six@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.
That seems to be a different topic.
Fundamentally I don't see the difference between uclass_find_device_by_ofnode() and your ofnode_dev().
If you want to enable something after probing you will have to call device_bind() or similar. If that is your intent, I think you need a different function from ofnode_dev(), since it also relies on the device already being bound.
Regards, Simon