From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Subject: Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle Date: Thu, 06 Apr 2017 06:58:01 +1000 Message-ID: <1491425881.4166.90.camel@kernel.crashing.org> References: <20170405123706.6081-1-npiggin@gmail.com> <20170405123706.6081-3-npiggin@gmail.com> <20170406003251.533e2845@roar.ozlabs.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring , Nicholas Piggin Cc: Michael Ellerman , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , linuxppc-dev , Frank Rowand List-Id: devicetree@vger.kernel.org On Wed, 2017-04-05 at 10:58 -0500, Rob Herring wrote: > Well, I'd like to avoid expanding usage of flat DT parsing in the > kernel. But you could just put this function into arch/powerpc and I'd > never see it, but I like that even less. Mainly, I just wanted to > raise the point. > > Your argument works until you need that setup in assembly code, then > you are in the situation that you need to either handle the setup in > bootloader/firmware or have an simple way to determine that condition. The main issue is that changing that is a very very invasive change in an extremely fragile and rather nasty area of code shared by 32 and 64- bit for which we don't even have easy access to all the machines to test with anymore :) It's probably not impossible, but it would delay the new cpu feature stuff that Nick is making by a lot, probably monthes, making it nearly impossible to get back into distros etc... So while it might be something to consider, I would definitely keep that as a separate unit of work to do later. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3vyyqG0hsGzDqJ9 for ; Thu, 6 Apr 2017 06:58:17 +1000 (AEST) Message-ID: <1491425881.4166.90.camel@kernel.crashing.org> Subject: Re: [PATCH 2/3] of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle From: Benjamin Herrenschmidt To: Rob Herring , Nicholas Piggin Cc: Michael Ellerman , "devicetree@vger.kernel.org" , linuxppc-dev , Frank Rowand Date: Thu, 06 Apr 2017 06:58:01 +1000 In-Reply-To: References: <20170405123706.6081-1-npiggin@gmail.com> <20170405123706.6081-3-npiggin@gmail.com> <20170406003251.533e2845@roar.ozlabs.ibm.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2017-04-05 at 10:58 -0500, Rob Herring wrote: > Well, I'd like to avoid expanding usage of flat DT parsing in the > kernel. But you could just put this function into arch/powerpc and I'd > never see it, but I like that even less. Mainly, I just wanted to > raise the point. > > Your argument works until you need that setup in assembly code, then > you are in the situation that you need to either handle the setup in > bootloader/firmware or have an simple way to determine that condition. The main issue is that changing that is a very very invasive change in an extremely fragile and rather nasty area of code shared by 32 and 64- bit for which we don't even have easy access to all the machines to test with anymore :) It's probably not impossible, but it would delay the new cpu feature stuff that Nick is making by a lot, probably monthes, making it nearly impossible to get back into distros etc... So while it might be something to consider, I would definitely keep that as a separate unit of work to do later. Cheers, Ben.