From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SnAXt-0007Jc-Fs for qemu-devel@nongnu.org; Fri, 06 Jul 2012 11:34:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SnAXr-0005Sm-M0 for qemu-devel@nongnu.org; Fri, 06 Jul 2012 11:34:13 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:64797) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SnAXr-0005SY-Eb for qemu-devel@nongnu.org; Fri, 06 Jul 2012 11:34:11 -0400 Received: by bkcji1 with SMTP id ji1so1049120bkc.4 for ; Fri, 06 Jul 2012 08:34:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1341507652-22155-1-git-send-email-peter.maydell@linaro.org> <1341507652-22155-5-git-send-email-peter.maydell@linaro.org> Date: Fri, 6 Jul 2012 16:34:08 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 4/6] device_tree: Add support for reading device tree properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: qemu-devel@nongnu.org, patches@linaro.org On 6 July 2012 02:56, Peter Crosthwaite wrote: > Can we generalise and get functionality for reading cells with offsets > as well? Your function assumes (and asserts) that the property is a > single cell, but can we add a index parameter for reading a non-0th > property out of a multi-cell prop? Needed for reading things like > ranges, regs and interrupt properties. I was playing about with this and I'm really not sure that we should be providing a "read a single u32 from a u32 array property" at the device_tree.c layer. For example, for handling the ranges property what you really want to do is treat it as a list of tuples (including doing something sensible if it doesn't have the right length to be a complete list), so the code that knows the structure of the ranges property is better off calling qemu_devtree_getprop to get a uint32_t* for the whole array. Then it has the whole thing as a straightforward C array which will be much easier and more efficient to handle than constantly bouncing back into the fdt layer to read each uint32_t. I've also just realised that I'm assuming that the pointer returned by fdt_getprop() is naturally aligned for a 32 bit integer if the property is a 32 bit integer -- is that valid? -- PMM