[U-Boot] [PATCH 1/8] core: Add uclass_{first, next}_device_compat

[Simon Glass]

Hi Mario,

On 11 April 2018 at 01:15, Mario Six <mario.six at gdsys.cc> wrote:
> Hi Simon,
>
> On Fri, Mar 30, 2018 at 10:41 AM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Mario,
>>
>> On 28 March 2018 at 20:38, Mario Six <mario.six at gdsys.cc> wrote:
>>> A lot of times one wants to cycle through the devices in a uclass, but
>>> only certain ones, especially ones identified by their compatibility
>>> string, and ignore all others (in the best case this procedure should
>>> not even activate the devices one is not interested in).
>>>
>>> Hence, we add a pair of functions similar to uclass_{first,next}_device,
>>> but taking a compatibility string as an additional argument, which cycle
>>> through the devices of a uclass that conform to this compatibility
>>> string.
>>
>> Can we not use a phandle to find the device? Using raw compatible
>> strings feel bad (and slow to me).
>>
>> If not, a please add a sandbox test.
>>
>
> A phandle would indeed be the cleaner solution, but it won't work if you have
> to get device handles in board files, since there is no device for a board you
> could query for a phandle. And the MPC83xx board this series leads up to needs
> to gather numerous device handles for configuration and querying purposes.
>
> If there was a underlying device for the board functions there would be no
> issue with using a phandle, but as it is, it sadly won't work.

Yes, actually this comes up a lot. Perhaps we should support a 'board'
device which can have phandles pointing to things? It would be easy to
implement. I'm not sure how Linux handles this stuff?

Regards,
Simon