From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pawel Moll Subject: Re: [PATCH 1/2] mmc: add Device Tree properties for UHS modes Date: Mon, 29 Jul 2013 11:50:53 +0100 Message-ID: <1375095053.3340.7.camel@hornet> References: <51F2ADA2.2030503@wwwdotorg.org> <51F2EBD4.1060603@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: Sender: linux-sh-owner@vger.kernel.org To: Guennadi Liakhovetski Cc: Stephen Warren , "linux-sh@vger.kernel.org" , "linux-mmc@vger.kernel.org" , Magnus Damm , Chris Ball , "devicetree@vger.kernel.org" , Simon Horman , Ian Campbell , Mark Rutland , "rob.herring@calxeda.com" List-Id: linux-mmc@vger.kernel.org On Mon, 2013-07-29 at 08:18 +0100, Guennadi Liakhovetski wrote: > A short addendum. At least with Renesas SoCs I see the situation in the > following way: new SoC versions appear relatively frequently. What frequency are we talking about? Once per year? Once per month? I'm not trying to be picky, it really makes a difference... > With compatibility strings we have to change _all_ Renesas drivers for _each_ > SoC version even if just to add a new struct of_device_id entry. This > doesn't seem very productive to me. There is at least precedence in the MMC world - have a look at drivers/mmc/host/mmci.c and the struct variant_data... There seem to be a new variant every 6 months or so (I must admit guilt of of making some of them ;-) coming from two different companies. And although it's a primecell (aka amba_bus) device, so the compatibilty string remains the same, the struct amba_id was being extended every time which is pretty much the same thing. Pawel PS. Having said all that I'm hoping the MMCI evolution has finally stopped so no new variants will be needed ;-)