From: Stephen Warren <swarren@wwwdotorg.org>
To: boris brezillon <b.brezillon@overkiz.com>
Cc: Rob Herring <rob.herring@calxeda.com>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ian.campbell@citrix.com>,
Rob Landley <rob@landley.net>,
Russell King <linux@arm.linux.org.uk>,
Linus Walleij <linus.walleij@linaro.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Jiri Kosina <jkosina@suse.cz>,
Masanari Iida <standby24x7@gmail.com>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
Richard Genoud <richard.genoud@gmail.com>,
Heiko Stuebner <heiko@sntech.de>,
James Hogan <james.hogan@imgtec.com>,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf
Date: Tue, 27 Aug 2013 15:35:07 -0600 [thread overview]
Message-ID: <521D1B8B.7040803@wwwdotorg.org> (raw)
In-Reply-To: <521C49EF.5020403@overkiz.com>
On 08/27/2013 12:40 AM, boris brezillon wrote:
> On 27/08/2013 05:57, Stephen Warren wrote:
>> On 08/26/2013 11:17 AM, boris brezillon wrote:
>>> On 26/08/2013 18:53, Stephen Warren wrote:
>>>> On 08/24/2013 03:37 PM, Boris BREZILLON wrote:
>>>>> Add support for generic pin configuration to pinctrl-at91 driver.
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
>>>>> b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
>>>>> Required properties for iomux controller:
>>>>> -- compatible: "atmel,at91rm9200-pinctrl"
>>>>> +- compatible: "atmel,at91rm9200-pinctrl" or
>>>>> "atmel,at91sam9x5-pinctrl".
>>>> You seem to also be adding a second chip name to the list here,
>>>> which is
>>>> more than the patch subject/description imply you're doing...
>>> This is an update of the documentation:
>>> "atmel,at91sam9x5-pinctrl" compatible is already used in the pinctrl
>>> driver but the documention
>>> was not updated.
>>>
>>> But I agree, this should not be part of this series.
>>>
>>>>> + Add "generic-pinconf" to the compatible string list to use the
>>>>> generic pin
>>>>> + configuration syntax.
>>>> "generic-pinconf" is too generic of a compatible value for this binding
>>>> to define.
>>>>
>>>> Instead, I think you want to either:
>>>>
>>>> a)
>>>>
>>>> Use compatible="atmel,at91rm9200-pinctrl" for the old binding,
>>>> use compatible="atmel,at91rm9200-pinctrl-generic" for the new binding
>>>>
>>>> or:
>>>>
>>>> b)
>>>>
>>>> Define Boolean property atmel,generic-pinconf (perhaps a better name
>>>> could be chosen?). If it's not present, parse the node assuming the old
>>>> binding. If it is present, parse the node assuming the new binding.
>>>>
>>> Okay.
>>>
>>> I thought this property string could be generic as it may concern other
>>> drivers too
>>> (in order to keep compatibility with old dt ABI and add support the
>>> generic pinconf binding).
>>>
>>> Anyway, I prefer the first proposition.
>>>
>>> pinctrl single driver is already using these names:
>>>
>>> |compatible = "pinctrl-single" for non generic pinconf binding
>>> ||compatible = "pinconf-single" ||for generic pinconf binding|
>>>
>>> So I think we should use something similar:
>>>
>>> |compatible = "atmel,at91xx-pinctrl" for non generic pinconf binding
>>> ||compatible = "|||atmel,at91xx-|pinconf" ||for generic pinconf binding|
>>>
>>> What do you think ?
>> Hmmm. It is a little odd to switch out the compatible value and invent a
>> new binding for the same HW. Isn't it possible to define both sets of
>> properties in the binding, and have drivers look for either?
>>
>
> Do you mean something like:
>
> atmel,pins = <xxx>; /* current dt binding */
> atmel,generic-pins = <yyy>; /* new dt binding */
>
> If that's what you had in mind, it will be a little bit tricky to
> handle, because AFAIK the pinconf_ops
> callbacks do not give me any element I could use to deduce the type of
> pinconf (generic or
> native).
> This implies I have to know early during the probe process which kind of
> binding is in use.
>
> Please tell me if I missed some key points, and this can be easily done.
It's probably most compatible to keep all the existing properties, and
just add new properties for new features.
next prev parent reply other threads:[~2013-08-27 21:35 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-24 21:32 [RFC PATCH 0/3] pinctrl: at91: add support for generic pinconf Boris BREZILLON
2013-08-24 21:35 ` [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter Boris BREZILLON
2013-08-26 16:50 ` Stephen Warren
2013-08-26 17:01 ` boris brezillon
2013-08-27 3:55 ` Stephen Warren
2013-08-27 6:16 ` boris brezillon
2013-08-27 7:42 ` Nicolas Ferre
2013-08-27 8:28 ` boris brezillon
2013-08-27 21:33 ` Stephen Warren
2013-08-28 13:22 ` Linus Walleij
2013-08-28 13:13 ` Linus Walleij
2013-08-24 21:37 ` [RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf Boris BREZILLON
2013-08-26 16:53 ` Stephen Warren
2013-08-26 17:17 ` boris brezillon
2013-08-27 3:57 ` Stephen Warren
2013-08-27 6:40 ` boris brezillon
2013-08-27 21:35 ` Stephen Warren [this message]
2013-08-26 17:53 ` Jean-Christophe PLAGNIOL-VILLARD
2013-08-26 18:45 ` boris brezillon
2013-08-26 19:18 ` Jean-Christophe PLAGNIOL-VILLARD
2013-08-26 19:48 ` boris brezillon
2013-08-27 7:51 ` Nicolas Ferre
2013-08-27 3:54 ` Stephen Warren
2013-08-27 6:04 ` boris brezillon
2013-08-27 21:30 ` Stephen Warren
2013-08-24 21:40 ` [RFC PATCH 3/3] ARM: at91/dt: move sama5 to " Boris BREZILLON
2013-08-28 12:28 ` Linus Walleij
2013-08-28 12:52 ` boris brezillon
2013-08-24 21:43 ` [RFC PATCH 0/3] pinctrl: at91: add support for " boris brezillon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=521D1B8B.7040803@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=b.brezillon@overkiz.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=ian.campbell@citrix.com \
--cc=james.hogan@imgtec.com \
--cc=jkosina@suse.cz \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=nicolas.ferre@atmel.com \
--cc=pawel.moll@arm.com \
--cc=plagnioj@jcrosoft.com \
--cc=richard.genoud@gmail.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=standby24x7@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox