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)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id AA259DE0FB for ; Thu, 23 Apr 2009 14:43:58 +1000 (EST) Message-Id: <49668C6D-3A6A-499E-A8AD-85B8E808F6CF@kernel.crashing.org> From: Kumar Gala To: David Gibson In-Reply-To: <20090423040642.GG19376@yookeroo.seuss> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: removing get_immrbase()?? Date: Wed, 22 Apr 2009 23:41:31 -0500 References: <49EF7B11.2000006@freescale.com> <49EF7B1C.2080105@freescale.com> <282847E1-AE1A-44EF-9D18-AF2884105FA5@kernel.crashing.org> <49EF8E3A.4060304@freescale.com> <5D0145E3-0A98-429E-8D53-1A8DF4216462@kernel.crashing.org> <20090423022610.GA19376@yookeroo.seuss> <80CA86D4-3DA5-4C28-AE7A-C03CE5758774@kernel.crashing.org> <20090423040642.GG19376@yookeroo.seuss> Cc: Scott Wood , Linuxppc-dev Development , Timur Tabi List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Apr 22, 2009, at 11:06 PM, David Gibson wrote: > Well, yes, I guess I agree. How immutable you consider the device > tree blob to be is a judgement call based on the specific details of > platform/board in question. If it is indeed a reference platform, in > the early stages of development where it's reasonably easy to change > the dtb, then it's probably best to change the dtb in sync with the > kernel to reduce long-term cruft build-up. But once the board is > sufficiently widely deployed, you want to stop doing that and include > backwards compatibility workarounds in the kernel to cope with the > widely deployed broken trees. I disagree with the point about providing workarounds to cope w/ deployed device trees (at least for the problems I'm thinking off in which nodes didn't exist). This just sounds like double work and is a disincentive to actually making such changes. Lets say I had an error driver for our MCM (core to soc coherency module). It was getting the base address by using get_immrbase(). Today I proposed a proper device node for the MCM block as it doesn't exist in .dts today. We add such a node into .dts and I can clean up my error driver to use proper device node information. However I've just broken any old .dts that didn't have this node. You are saying I need to add code into the kernel to create this new node and we have to keep that code around for ever in the kernel.. why would I ever bother to actually changing anything than. - k