From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Dooks Subject: Re: [PATCH v4 03/10] pinctrl: mvebu: kirkwood pinctrl driver Date: Fri, 21 Sep 2012 11:56:06 +0100 Message-ID: <505C47C6.3070907@codethink.co.uk> References: <1344689809-6223-1-git-send-email-sebastian.hesselbarth@gmail.com> <50559737.8000705@gmail.com> <201209201530.40974.arnd@arndb.de> <20120920213636.2ee27d41@skate> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120920213636.2ee27d41@skate> Sender: linux-kernel-owner@vger.kernel.org To: Thomas Petazzoni Cc: Linus Walleij , Arnd Bergmann , linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth , Andrew Lunn , Russell King , Jason Cooper , Stephen Warren , devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Rob Herring , Grant Likely , Lior Amsalem , Rob Landley , Gregory CLEMENT List-Id: devicetree@vger.kernel.org On 20/09/12 20:36, Thomas Petazzoni wrote: > Dear Linus Walleij, > > On Thu, 20 Sep 2012 21:28:20 +0200, Linus Walleij wrote: > >> So what I'm after is whether in this case statically encoding this >> onto the .dtsi files is the right thing to do, or whether the boot loader >> or kernel should runtime-modify the device tree, patching in >> the ASIC-specific info, just like device tree files can override >> properties from include files. >> >> Or if this is a bad idea. >> >> Nobody is doing that right now AFAICT, but it is surely possible.... > > If I understand correctly, we would like drivers to be able to read > some common "system" registers to figure out which SoC variant we are > running on. Such feature should normally be provided by code in > arch/arm/mach-*/ and called by drivers, but we are trying to eliminate > all dependencies of driver code on architecture code, correct? > > So, wouldn't we need a small, architecture-independent, infrastructure, > through which architecture-specific code could "register" at boot > time which SoC we are running on, and drivers could query this > information from the common infrastructure? > > Of course, the major problem is to figure out what is the good > representation for this SoC identifier. Do we need a big list of SoCs > like we had machine IDs? A simple string? Or maybe there is just no > good way, and the whole idea is moot. I think this is a bad idea, it means you can't try and re-use an older kernel on an newer SoC design which may be broadly compatible without changing the kernel source to add these flag checks. I also don't like information hidden away that the user cannot see. Having the device specifically named allows us to see from sysfs exactly what we are dealing with. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius