[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-arm] [PATCH v2 3/7] device_tree: introduce qemu_fdt_node_path

From: Eric Auger
Subject: Re: [Qemu-arm] [PATCH v2 3/7] device_tree: introduce qemu_fdt_node_path
Date: Tue, 12 Jan 2016 18:02:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

Hi David,
On 01/12/2016 05:28 AM, David Gibson wrote:
> On Mon, Jan 11, 2016 at 11:35:50AM +0100, Eric Auger wrote:
>> Hi David,
>> On 01/11/2016 03:38 AM, David Gibson wrote:
>>> On Wed, Jan 06, 2016 at 03:13:21PM +0000, Eric Auger wrote:
>>>> This new helper routine returns the node path of a device
>>>> referred to by its node name and compat string.
>>> What if there are multiple nodes matching the name and compat?
>> The function would return the first one. I can improve the doc comment.
>> Do you think it is a problem stopping at the first one? Is it a real
>> life test case I have to handle here?
> Well, I don't know of a specific system which will have this, but it's
> absolutely possible to get this situation:  e.g. two different PCI
> busses, both of which have their own slot 0 populated with different
> instances of the same device.
> Whether it's possible for platform devices will depend on the
> platform's specific bus toplogies, but you certainly can't rule it out
> in general.
OK I will handle that case then. I hope I will be able to test it.
> I could consider adding a new libfdt function like
> fdt_node_offset_by_compatible() that searches by name as well.  It's
> just I'm not sure that matching by name and compatible isn't a sign of
> a poor approach in the caller.
well I can't really comment. That looked the most straightforward to me
given the current libfdt API. But not sure it's worth to invest in a new
function in libfdt



reply via email to

[Prev in Thread] Current Thread [Next in Thread]