From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36583) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJ2Kq-0004u0-PO for qemu-devel@nongnu.org; Tue, 12 Jan 2016 12:02:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJ2Km-0006i9-RM for qemu-devel@nongnu.org; Tue, 12 Jan 2016 12:02:20 -0500 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]:36397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJ2Kl-0006ho-J7 for qemu-devel@nongnu.org; Tue, 12 Jan 2016 12:02:16 -0500 Received: by mail-wm0-x235.google.com with SMTP id l65so260455777wmf.1 for ; Tue, 12 Jan 2016 09:02:15 -0800 (PST) References: <1452093205-30167-1-git-send-email-eric.auger@linaro.org> <1452093205-30167-4-git-send-email-eric.auger@linaro.org> <20160111023853.GB22925@voom.redhat.com> <56938586.5050503@linaro.org> <20160112042856.GQ22925@voom.redhat.com> From: Eric Auger Message-ID: <56953188.3040805@linaro.org> Date: Tue, 12 Jan 2016 18:02:00 +0100 MIME-Version: 1.0 In-Reply-To: <20160112042856.GQ22925@voom.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 3/7] device_tree: introduce qemu_fdt_node_path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: b.reynal@virtualopensystems.com, peter.maydell@linaro.org, thuth@redhat.com, eric.auger@st.com, patches@linaro.org, crosthwaitepeter@gmail.com, qemu-devel@nongnu.org, alex.williamson@redhat.com, qemu-arm@nongnu.org, suravee.suthikulpanit@amd.com, pbonzini@redhat.com, thomas.lendacky@amd.com, alex.bennee@linaro.org, christoffer.dall@linaro.org 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 Thanks! Eric >