From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roy Franz Subject: Re: [Linaro-uefi] [PATCH V2 11/12] Add fdt_create_empty_tree() function. Date: Wed, 23 Jul 2014 09:15:00 -0700 Message-ID: References: <1405989815-25236-1-git-send-email-roy.franz@linaro.org> <1405989815-25236-12-git-send-email-roy.franz@linaro.org> <53CE92F9.30709@linaro.org> <53CE9C14.8010808@linaro.org> <1406109513.1351.40.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8035228367282017267==" Return-path: In-Reply-To: <1406109513.1351.40.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: keir , Julien Grall , tim , xen-devel , Stefano Stabellini , Jan Beulich , linaro-uefi List-Id: xen-devel@lists.xenproject.org --===============8035228367282017267== Content-Type: multipart/alternative; boundary=001a1133fd6658b29504fedea408 --001a1133fd6658b29504fedea408 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 23, 2014 at 2:58 AM, Ian Campbell wrote: > On Tue, 2014-07-22 at 18:15 +0100, Julien Grall wrote: > > On 07/22/2014 06:12 PM, Roy Franz wrote: > > > On Tue, Jul 22, 2014 at 9:36 AM, Julien Grall > wrote: > > >> On 07/22/2014 01:43 AM, Roy Franz wrote: > > >>> Add fdt_create_empty_tree() function from v1.4.0 of libfdt taken from > > >>> git://git.jdl.com/software/dtc.git > > >>> This function was not present in v1.3.0, but is a relatively simple > > >>> helper function, and appears to work fine with the v1.3.0 that is > > >>> currently present in XEN. > > >> > > >> Shouldn't we update our internal libfdt to v1.4.0 rather than taking > > >> only the new file? > > >> > > >> Regards, > > > > > > I can certainly do that - I was simply being conservative. > > > > It's better to update the whole library to keep track of change. Ian, > > Stefano, any thoughts? > > Updating the library would certainly be preferable if Roy is willing. > > > > Should I prepare an patch independent of the EFI stub series to > > > just update the libfdt, or would you like it kept as part of the > current > > > series? > > > > I'm fine if you let the libfdt change in this series. > > Yeah, that's fine. > > Ian. > > I'll do this in my next version. I'm on vacation until August 4th (starting tomorrow), so my next version won't be until early August. Roy --001a1133fd6658b29504fedea408 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 23, 2014 at 2:58 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
On Tue, 2014-07-22 at 18:15 = +0100, Julien Grall wrote:
> On 07/22/2014 06:12 PM, Roy Franz wrote:
> > On Tue, Jul 22, 2014 at 9:36 AM, Julien Grall <julien.grall@linaro.org> wrote:
> >> On 07/22/2014 01:43 AM, Roy Franz wrote:
> >>> Add fdt_create_empty_tree() function from v1.4.0 of libfd= t taken from
> >>> git://git.jdl.com/software/dtc.git
> >>> This function was not present in v1.3.0, but is a relativ= ely simple
> >>> helper function, and appears to work fine with the v1.3.0= that is
> >>> currently present in XEN.
> >>
> >> Shouldn't we update our internal libfdt to v1.4.0 rather = than taking
> >> only the new file?
> >>
> >> Regards,
> >
> > I can certainly do that - I was simply being conservative.
>
> It's better to update the whole library to keep track of change. I= an,
> Stefano, any thoughts?

Updating the library would certainly be preferable if Roy is willing.=

> > Should I prepare an patch independent of the EFI stub series to > > just update the libfdt, or would you like it kept as part of the = current
> > series?
>
> I'm fine if you let the libfdt change in this series.

Yeah, that's fine.

Ian.

I'll do this in my next version. =C2= =A0I'm on vacation until August 4th (starting tomorrow), so my next ver= sion
won't be until early August.
=

Roy
--001a1133fd6658b29504fedea408-- --===============8035228367282017267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8035228367282017267==--