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.
Regards, Simon
Best regards, Mario