From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752450AbcAFVMe (ORCPT ); Wed, 6 Jan 2016 16:12:34 -0500 Received: from down.free-electrons.com ([37.187.137.238]:59419 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752082AbcAFVMc (ORCPT ); Wed, 6 Jan 2016 16:12:32 -0500 Date: Wed, 6 Jan 2016 22:12:29 +0100 From: Maxime Ripard To: Andre Przywara Cc: Vishnu Patekar , Linus Walleij , Chen-Yu Tsai , Hans de Goede , Catalin Marinas , will.deacon@arm.com, "linux-arm-kernel@lists.infradead.org" , linux-gpio@vger.kernel.org, "linux-sunxi@googlegroups.com" , linux-kernel@vger.kernel.org Subject: Re: [linux-sunxi] [RFC PATCH] drivers: pinctrl: add driver for Allwinner A64 SoC Message-ID: <20160106211229.GC9631@lukather> References: <1451582246-32373-1-git-send-email-andre.przywara@arm.com> <568A4972.8030602@arm.com> <20160104203059.GG11722@lukather> <568BB04B.30100@arm.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Content-Disposition: inline In-Reply-To: <568BB04B.30100@arm.com> 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 --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Andre, On Tue, Jan 05, 2016 at 12:00:11PM +0000, Andre Przywara wrote: > Hi Maxime, >=20 > On 04/01/16 20:30, Maxime Ripard wrote: > > Hi Andre, > >=20 > > On Mon, Jan 04, 2016 at 10:29:06AM +0000, Andre Przywara wrote: > >>>> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/= Makefile > >>>> index e080290..130e7bc 100644 > >>>> --- a/drivers/pinctrl/sunxi/Makefile > >>>> +++ b/drivers/pinctrl/sunxi/Makefile > >>>> @@ -12,5 +12,6 @@ obj-$(CONFIG_PINCTRL_SUN7I_A20) +=3D= pinctrl-sun7i-a20.o > >>>> obj-$(CONFIG_PINCTRL_SUN8I_A23) +=3D pinctrl-sun8i-a= 23.o > >>>> obj-$(CONFIG_PINCTRL_SUN8I_A23_R) +=3D pinctrl-sun8i-a23-r.o > >>>> obj-$(CONFIG_PINCTRL_SUN8I_A33) +=3D pinctrl-sun8i-a= 33.o > >>>> +obj-$(CONFIG_PINCTRL_A64) +=3D pinctrl-a64.o > >>> > >>> Shouldn't this follow pinctrl config name like other sunXi SOCs? > >>> This should be PINCTRL_SUN??_A64. > >> > >> I never really got the reason we use those sunxi names in addition to > >> the SoC name in the first place, maybe apart from copying from some > >> Allwinner code. > >> Since I decided to not look at Allwinner's BSP at all (if avoidable), I > >> also thought it would be time to drop that sunxi naming, which looks > >> redundant to me. > >> Is there any reason why we would need this (beside having a rather > >> unique identifier prefix)? > >=20 > > It's mostly historical. > >=20 > >=20 > > Back when we started this, There was a few SoCs already out: A10, > > A10s, A12 and A13, which was very similar to the Cortex-A naming > > scheme (and I think the Cortex-A12 was also announced at the time). > >=20 > > We couldn't really use the SoC family either, since there was already > > multiple SoCs that were part of the same family (the A10s, A12 and > > A13, part of the sun5i family). > >=20 > > In order to avoid any confusion, we chose to go with both to uniquely > > and without any confusion possible, and we just went on with that > > naming scheme for consistency. >=20 > I see, thanks for the explanation. > I was wondering since we now move to a new architecture as well to avoid > this historic "ballast", but I have no problems with adding "_sun50i_" > to the identifiers and file names. > To me as only a casual sunxi user I found it mostly hard to memorize the > connections between the sunxi numbering and the SoC names (I just know > that the A20 is sun7i ;-). So for finding a specific dts for instance, > you have to start with the sunxi number to get it TAB completed ... I guess it doesn't really matter for arm64, since it seems like there's a sub-folder per SoC family. However, having an a12.dtsi in arch/arm/boot/dts will probably bring a lot of confusion :) I still think that we should maintain the current compatible scheme though, in order to keep consistency. > With that being said: Would you prefer to have a sun50i prefix? I see > that having just "a64" on itself is not very specific. I'd say that having a DTSI in arch/arm64/boot/dts/sunxi/a64.dtsi would not bring a lot of confusion. If you're there, you know what you're dealing with already. If you feel like it makes the life easier to new or casual users, go ahead. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWjYM9AAoJEBx+YmzsjxAgHXgQAJylBvPpR/LOT95ZudGnV9Od jdntK0SEu/vsEyih7Y8akdxHcZbmXPPJqRtBmmSUArVdtf3VrKMXaz0qCW+BwOon zvMtUk7t5QUm2OnOcANSF+lIKFdBt8Pbceh55yg2gWO0Ns1gjQPPOzXUqYTymyXD AvqJGDz6bluqHec7CwibNcwXKn0Nc3f4LCj2IT5Flymh+drj6vDVm3NzCgNhKfrT INMusT5tc7Tx3vf7uLuj9RtMWScEa9F4TtR02aMwEaEFRMZFQuOtYMUnaPi9nbKc kJ5egJD7oxaU8kX0QcG1Nh5VSbYuFD78XPSQQ/bcZzYLzLaZ8KdFghuV/FeT/o54 j0QNixJvH4BfX6AX6RDarTv0BZSYJL3wzjnGAGYMvjDeoBFWDc0h1PFKRqPb/RP3 NvEjCDF7JIp0v7+IEWxVrJuIFUMY8/8zINaCEyx02CnUERZsTJzRXpuFV3KPxUjR bND40Im+f5S9dLHDvYRjML9l8rbsSsBofBcoHha6QT9VxTSa6MHlTDEet6oaopsa vLzcf0jL3Hb0T/oTPOHcTn1H/iGj8CWW55Dfvr3aad/LQTOtkoAjx5252G4Sdt1+ m5Y6z6q3XIA7vfDNwNaf6O2lXtllajqhWQtP/IHCnNUgmLB9FGDo99ar+xcVjmrx QbP+TAYR7kI+BKhL0f4e =K7C3 -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT--