From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id D9D5FB7CED for ; Fri, 26 Mar 2010 03:36:52 +1100 (EST) Received: from de01smr01.freescale.net (de01smr01.freescale.net [10.208.0.31]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id o2PGaotW028750 for ; Thu, 25 Mar 2010 09:36:50 -0700 (MST) Received: from az33exm25.fsl.freescale.net (az33exm25.am.freescale.net [10.64.32.16]) by de01smr01.freescale.net (8.13.1/8.13.0) with ESMTP id o2PGjCbM001564 for ; Thu, 25 Mar 2010 11:45:12 -0500 (CDT) Message-ID: <4BAB9120.1060600@freescale.com> Date: Thu, 25 Mar 2010 11:36:48 -0500 From: Timur Tabi MIME-Version: 1.0 To: Grant Likely Subject: Re: [PATCH] powerpc/fsl: add device tree binding for QE firmware References: <1269380552-10418-1-git-send-email-timur@freescale.com> <90D93687-940F-47FB-8CEA-F3C065EA611D@kernel.crashing.org> <4BAA4C8A.70104@freescale.com> <65327.84.105.60.153.1269481760.squirrel@gate.crashing.org> <4BAB7E67.6040707@freescale.com> <4BAB816F.5060405@firmworks.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Cc: Mitch Bradley , Scott Wood , devicetree-discuss@lists.ozlabs.org, linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Grant Likely wrote: > On Thu, Mar 25, 2010 at 9:29 AM, Mitch Bradley wrote: >> It seems to me that there are plausible use cases for both direct-inclusion >> and indirection. I don't see any real problems with either, so I would vote >> for specifying both alternatives. > > Ugh. Then this one driver would need to implement both binding for > little, if any, actual benefit. Although I agree that I don't like supporting both bindings, we could encapsulate the locating of the firmware node in a function. The function will first look for a child firmware node, and if it doesn't find it, look for a fsl,firmware property. It will return a pointer to the firmware node regardless. > I'm sure we can come to an agreement > on one method if the firmware absolutely has to be in the tree. If we have to pick one, then I think the only viable choice is have a separate firmware node and a phandle pointer to it. Otherwise, I just don't see how we can handle multiple devices needing the same firmware. > Personally, my vote lies with direct-inclusion. However, if > indirection is used, then I think it would be wise to define where > data-only nodes like this should live. Under /chosen perhaps? I personally don't care that much; /chosen is okay with me, but .... > It > wouldn't be good to place it somewhere where it will be confused for > an actual device node. ... what's wrong with the root node? -- Timur Tabi Linux kernel developer at Freescale