From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Brown Subject: Re: ARM clock API to PowerPC Date: Wed, 12 Aug 2009 23:45:07 +0100 Message-ID: <20090812224506.GA7519@sirena.org.uk> References: <1250063825.15143.43.camel@pasglop> <20090812123551.GC11227@sirena.org.uk> <1250112847.3587.26.camel@pasglop> <20090812214444.GA4731@sirena.org.uk> <1250114192.3587.41.camel@pasglop> <20090812222843.GA7118@flint.arm.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20090812222843.GA7118@flint.arm.linux.org.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+glppd-linuxppc64-dev=m.gmane.org@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+glppd-linuxppc64-dev=m.gmane.org@lists.ozlabs.org To: Russell King Cc: John Jacques , devicetree-discuss@lists.ozlabs.org, Torez Smith , linuxppc-dev list List-Id: devicetree@vger.kernel.org On Wed, Aug 12, 2009 at 11:28:43PM +0100, Russell King wrote: > We used to pass names. Everyone got the idea that they could ignore > the struct device argument, and chaos ensued in drivers - people wanted > to name each of their individual clk structures uniquely, and pass > clock names, or even struct clk pointers into drivers via platform data. > Some drivers conditionalized the clock name depending on the SoC they > were built for in the driver code. Yes, that sort of stuff is obviously crazy - you just end up with more code to pass the name/pointer around than you have to register things at init time. > What I'm saying is that always passing a bunch of names has been well > proven to lead people down the wrong path of matching only by names > and then running into problems later. We need drivers passing a NULL > name to ensure that people get the right idea. Comments in code/headers > don't seem to work. ;( I always suspected half the problem with people getting the wrong idea is that having to implement the lookup and mapping stuff (which clkdev now provides) seemed like too much work.