From owner-freebsd-current@FreeBSD.ORG Sat Oct 15 17:12:16 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3A99106566B; Sat, 15 Oct 2011 17:12:16 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 289438FC16; Sat, 15 Oct 2011 17:12:15 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id E592BD9C47; Sat, 15 Oct 2011 18:55:25 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id SMT8po5yKUqL; Sat, 15 Oct 2011 18:55:25 +0200 (CEST) Received: from [10.0.0.112] (nat3-133.ghnet.pl [91.150.222.133]) by smtp.semihalf.com (Postfix) with ESMTPSA id C51D2D9C42; Sat, 15 Oct 2011 18:55:24 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Rafal Jaworowski In-Reply-To: <82FC5404-7B93-426B-9303-14BD8BC37542@xcllnt.net> Date: Sat, 15 Oct 2011 18:55:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E989C28.3030606@freebsd.org> <4E99A319.20801@freebsd.org> <82FC5404-7B93-426B-9303-14BD8BC37542@xcllnt.net> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1084) Cc: "Jayachandran C." , FreeBSD Current , Nathan Whitehorn , Andrew Duane Subject: Re: [RFC] FDT fix for 64 bit platforms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 17:12:16 -0000 On 2011-10-15, at 18:48, Marcel Moolenaar wrote: >=20 > On Oct 15, 2011, at 9:33 AM, Jayachandran C. wrote: >=20 >> On Sat, Oct 15, 2011 at 8:43 PM, Nathan Whitehorn >> wrote: >>> On 10/15/11 01:12, Jayachandran C. wrote: >>>>=20 >>>> On Sat, Oct 15, 2011 at 2:01 AM, Nathan Whitehorn >>>> wrote: >>>>>=20 >>>>> On 10/14/11 14:10, Jayachandran C. wrote: >>>>>>=20 >>>>>> I'm planning commit this -CURRENT if there an no objections. >>>>>>=20 >>>>>> In the current implementation, phandle is used to store a pointer = to >>>>>> the location inside the device tree. Since phandle_t is u32, = this >>>>>> will not work on 64 bit platforms. With this fix, the phandle is = the >>>>>> offset from the start of device tree pointer 'fdtp', which will = be 32 >>>>>> bit. >>>>>>=20 >>>>>> Review or testing from device tree users will be welcome. >>>>>>=20 >>>>>> JC. >>>>>=20 >>>>> Why not use offsets into the FDT rather than full pointers? I = believe >>>>> having >>>>> phandles greater than 32 bits violates the FDT spec, and declaring = that >>>>> the >>>>> FDT can't itself be larger than 4 GB seems reasonable. >>>>=20 >>>> I am actually using the offset from the beginning of FDT (fdtp) as >>>> phandle. I cannot use the usual fdt offset (after off_dt_struct) = as >>>> phandle, because in that case offset of 0 is valid, but phandle 0 >>>> should not be valid. >>>=20 >>> Why shouldn't phandle 0 be valid? The invalid phandle is -1. This is = one of >>> the problems with our existing FDT code -- it makes all kinds of = wrong >>> assumptions like this about IEEE 1275. >>=20 >> Well, the existing FDT code returns 0 as the invalid handle and I do >> not want to change that in this commit. >>=20 >> If the return value is really wrong, we will need a bigger exercise = to >> change the return value and fix any callers which are affected by = that >> change. >=20 > It should be fairly easy to change the base from fdtp to the "usual" > fdt offset, so let me propose the following: >=20 > 1. JC commits what he has and based on the current code. > 2. We get all the facts on the table. I say this because I > read different and contradictory things (0 being an > invalid phandle in OF, negative phandles exist, etc). > 3. We change the implementation, if such is warranted, in > a separate effort. >=20 > The point really is that 0 is an invalid phandle right now, > right or wrong, and JCs changes are based on that. I see no > problem proceeding on the path we're on, while we discuss > what's the correct implementation and whether or not we > should have a course change... >=20 > Thoughts? The patch looks fine to me, but we didn't have a chance yet to test it = on any PPC/ARM system, have you, Marcel? Regarding the phandle validity = I need to recall the context as this was a while back and I don't quite = remember all constraints and motivations. Rafal