Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757340AbbKFQmU (ORCPT ); Fri, 6 Nov 2015 11:42:20 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:55473 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbbKFQmS (ORCPT ); Fri, 6 Nov 2015 11:42:18 -0500 From: Arnd Bergmann To: Moritz Fischer Cc: Linus Walleij , linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, Rob Herring , "pawel.moll@arm.com" , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org Subject: Re: [RFC 3/3] ARM: e3xx: Add header file for pinctrl constants Date: Fri, 06 Nov 2015 17:42:02 +0100 Message-ID: <4813305.v3X2DlHJmB@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1446766883-25703-1-git-send-email-moritz.fischer@ettus.com> <3715539.QztuvljIIp@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:hW5sGTisiw2jOyPfR2RM9d/Y+uof7FkEd/7f7KtmOWDmU+pYC/u XJNtfJfxa/5I0pT9y80xmsM96ZQHWsQlyoKwg33ruh9BM0Rqbncv8gnoya3FidZuk+ctG56 W6dU90UjwtaqMMEP8yzNDhZLxslngbGEv/QMtiT2u7QU0466qpwY/yWikJvmq5WhdrOy1xA flN6eIYqT2Dew0IjUedNA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Plc/UyfNsug=:LXxkiUZt19J0/x76lbzgpW FEEnQPG/BuW1wcahqQZKoW3UeKTyvzDl0bpLq2SDJdoNBB2mc8+DlERJ9hK4wDWF4mUcLWR5R 1eDwLMf+VM2bewCOhRzUbScqYxIPHArf/y/WpEFdRBbZAH6iQCv/03lY61PEkSd8nO16OKYOE EViLgnKQnA188qFQtR0HPREbTjda2fwS6rvuJJ2HP9vKT8y+/oZpymFNmK5btRlZZTtHKvSOS 7mK5L/ad+A8VRX53faG9FSZIDDx5sNUERZkQGTa68ebYiko2mDo2CdTT9QA6gqgByzsDFmIjg 9hSIyqCJEphBqEmKq+cZox+G3QvzO4dHuBYF0Mtqp/qCWqW6ZR6GvjMk2hI4RPzpsYB8Sn4B/ QO5FAg4yG88VD1gaZqpz42J5OpNW8li2//4ECTY/8dKGxHxVX6NeyomGSeQK41XwsiMtoTK6Y tbHMRxBv3xSb47xfgQuQhVUGmCkyXRcsp29yifBd2RQvZAa/4MB0zAjqJJAOkJ/6avK1EPcBZ rsh/VwmRLPKL5glIjbgnDwEuv7q1qcTriVcyhgQcq7innCcxXv9pT21N5BP1CGQ5pWyPtLgLT 9faigS9m3pOMI4C6oWZOhMgm3LLpFrojKGOC/CImkjWvEYCaUfPj6be0YiX3sWTDnIoqhBMvv B3OmvhN6dQct4TczA+z2Fx2A4TabJ+Jk28VsiyxAX+QvCDkRjo2z1ogjGk1DApqlbPaIGdjv0 WW3AII5LTlHPVHS/ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2404 Lines: 64 On Friday 06 November 2015 08:01:25 Moritz Fischer wrote: > Hi Arnd, > > On Fri, Nov 6, 2015 at 12:54 AM, Arnd Bergmann wrote: > > On Thursday 05 November 2015 15:41:23 Moritz Fischer wrote: > >> +/* Pin names for the E31x usecase */ > >> +#define E31X_TX_BANDSEL_2 "DB_1" > >> +#define E31X_RX1B_BANDSEL_0 "DB_3" > >> +#define E31X_RX1B_BANDSEL_1 "DB_5" > >> +#define E31X_VCTXRX2_V2 "DB_7" > >> +#define E31X_TX_ENABLE1A "DB_9" > >> +#define E31X_TX_ENABLE2A "DB_11" > >> +#define E31X_TX_BANDSEL_0 "DB_12" > > > > Why not put the strings directly into the .dts files and change the > > lookup table in the driver accordingly: > > > > +static const struct pinctrl_pin_desc e3xx_pins[] = { > > + /* pin0 doesn't exist */ > > + PINCTRL_PIN(1, "TX_BANDSEL_2"), > > + PINCTRL_PIN(3, "RX1B_BANDSEL_0"), > > + PINCTRL_PIN(5, "RX1B_BANDSEL_1"), > > + PINCTRL_PIN(7, "VCTXRX2_V2"), > > That's actually the way I initially had it, however the pin names > literally changed > in the schematic depending on which daughter-board you stick into the slot. > So my plan was to add the #defines for the second daughter-board in a > follow up patch > once the pin assignment is final. This would allow me to have something like: > > pins = E31X_TX_BANDSEL_2; > output-low; > > in one .dts, while having something like > > pins = E33X_TX_BANDSEL_2 > output low; > > in the second dts That doesn't seem helpful though, because the assignment of the pins is not hidden from the source file that should be documenting it: if someone wants to know how the pins are muxed, they now have to cross-reference the dts file with the header. If you just put the pin number directly into the dts, it becomes completely clear what the setting is. > The other option would have been to stick a e31x_pins and a e33x_pins > into the driver, > and set them according to a compatible string or "ettus,daughterboard" > property on probe. > > Does that make sense, or do you think there's a cleaner / better way > to achieve this sort of behavior? The driver should not be board specific. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/