From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752260AbcBJPHE (ORCPT ); Wed, 10 Feb 2016 10:07:04 -0500 Received: from down.free-electrons.com ([37.187.137.238]:59402 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751057AbcBJPGq (ORCPT ); Wed, 10 Feb 2016 10:06:46 -0500 Date: Wed, 10 Feb 2016 16:06:43 +0100 From: Maxime Ripard To: Krzysztof Adamski Cc: Jean-Francois Moine , Linus Walleij , Chen-Yu Tsai , Hans de Goede , Lee Jones , Rob Herring , Jens Kuske , Fabian Frederick , Vishnu Patekar , linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: Re: [linux-sunxi] Re: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3 Message-ID: <20160210150643.GG31506@lukather> References: <1454542430-16572-1-git-send-email-k@japko.eu> <1454542430-16572-2-git-send-email-k@japko.eu> <20160204154752.4df7808be3364a98c496c030@free.fr> <20160205111152.GA31506@lukather> <20160205115837.GD12071@box2.japko.eu> <20160209171040.GR31506@lukather> <20160210071713.GA19622@box2.japko.eu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k7W93gQNhKgsYkEv" Content-Disposition: inline In-Reply-To: <20160210071713.GA19622@box2.japko.eu> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --k7W93gQNhKgsYkEv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Wed, Feb 10, 2016 at 08:17:14AM +0100, Krzysztof Adamski wrote: > On Tue, Feb 09, 2016 at 06:10:40PM +0100, Maxime Ripard wrote: > >>>>It seems that the other compatible strings are there for historical > >>>>reasons. Why do you need a new one with such a specific name? > >>>> > >>>>It would have been more sensible to add a generic compatible string as > >>>>"allwinner,apb-gates", letting the removal of the other strings for a > >>>>later patch... > >>> > >>>Yeah, it's a good idea, and it's probably time that we move to that. > >>> > >>>However, I'd like to keep per-soc and per-clocks compatibles in the > >>>DT, in case we need to protect a clock in the future. That doesn't > >>>prevent to have two compatibles thoughe, the specific and the generic. > >>> > >> > >>So now I'm not sure what you mean. You suggest that I should keep using > >>specific (sun8i_h3_apb0) or change to generic (apb-gates) in my patch? > > > >Both. > > > >To have something like that: > > > >compatible =3D "allwinner,sun8i-h3-apb0-gates-clk", "allwinner,sun4i-a10= -gates-clk"; > > > >sun4i-a10-gates-clk being the generic compatible that we would use, > >and we can always match against the h3 specific compatible if we need > >to have a different behaviour. >=20 > This seems like a good idea to me but since this is new thing anyways (ot= her > sunxi SoCs don't do this right now) shouldn't we introduce other > more generic name for generic clock (like "allwinner,apb-gates" mentioned > earlier, or maybe "allwinner,simple-apb-gates")? This is not specific to the APB bus, and the earlier SoC that introduced those kind of clocks was the A10, hence why I was suggesting that compatible (since we generally try to use the SoC that introduced that hardware block in the compatible name). > Also, wouldn't this be cleaner if I use only specific compatible string > right now and provide separate patch that adds generic compatible string = to > all current SoCs at once? The downside of this is that it's easier to get > merge conflicts unless I wait for applying this patchset. I'd prefer if you added the generic one and were using it in your subsequent patches. We can always mass convert the existing drivers later on. Thanks! Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --k7W93gQNhKgsYkEv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWu1IDAAoJEBx+YmzsjxAgqHsP/RDK8yPY2E84ou5vN90NEka6 U2T31iUUa+oxWf9XUjDmfLZPewtzh5HqUXDm5XzCjIGH9BeGS2cI7mwh26Yvg7Pw Avb4ov13OTBn/vH9qZ0jgEsv8b8WcyUC7hd3KaKZF1dMM8542t9BVkNBeYmUhxb9 2Foq0gXXBXlgMiStY8237fESqFeqqO/ZUeh/D2Qo3E7596JIo25v2qhx3NO52ihH BrEh9NihBkwtYSdduJjGobD/AzhBM3hc51RdnBrhzrecaP63mDTqhnn9sq/DfygU w26cm1bYZz4ZyJs5fjjEon1v/nQbLvaSTJ9eKOaLlh6esH5Np81I6fVbABnj81wD FUPCy2Kwdzial6umey6+rMra0agoy3moj0dPHUOU6MNfNE6F74X7XQFiV+kZ/0oQ 3Uub7c0jfw1xJMeZ+y9uABb6VMddkADW8tGr4lGTbOBuViBEfHm0KXWu1r3mzhkm IlIREWAGlZzPc/Xy/glVP9rd8H8sr/NcfcUDjI0fxgzTeqY1IDuZw6gNoZr0XdRG MTO0IIKWRb52oRba8zlnngpevGq+hhFYqllX2tAvvNPW+dasnvLvZn9x/X2w4o5i 9whuVmZuanZDAPZquvD8m8isgWpgFiP/RYvG+JBJnNxp8x7hWEiaknALD8nbx4ha 1DfBciD46Yj6cjVE8YxW =cUJG -----END PGP SIGNATURE----- --k7W93gQNhKgsYkEv--