From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from service87.mimecast.com ([91.220.42.44]:56338 "EHLO service87.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754125Ab3G2Ku5 convert rfc822-to-8bit (ORCPT ); Mon, 29 Jul 2013 06:50:57 -0400 Message-ID: <1375095053.3340.7.camel@hornet> Subject: Re: [PATCH 1/2] mmc: add Device Tree properties for UHS modes From: Pawel Moll Date: Mon, 29 Jul 2013 11:50:53 +0100 In-Reply-To: References: <51F2ADA2.2030503@wwwdotorg.org> <51F2EBD4.1060603@wwwdotorg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: devicetree-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: 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 ;-)