[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a6a4ed23-696c-ae2d-9b6a-c2578372b1aa@amlogic.com>
Date: Wed, 10 Jan 2018 10:12:38 +0800
From: Yixun Lan <yixun.lan@...ogic.com>
To: Jerome Brunet <jbrunet@...libre.com>,
Linus Walleij <linus.walleij@...aro.org>
CC: <yixun.lan@...ogic.com>, Neil Armstrong <narmstrong@...libre.com>,
Kevin Hilman <khilman@...libre.com>,
Carlo Caione <carlo@...one.org>,
Xingyu Chen <xingyu.chen@...ogic.com>,
Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
<linux-gpio@...r.kernel.org>, <linux-amlogic@...ts.infradead.org>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] pinctrl: meson: use one uniform 'function' name
On 01/08/18 16:52, Jerome Brunet wrote:
> On Mon, 2018-01-08 at 15:33 +0800, Yixun Lan wrote:
>> These two patches are general improvement for meson pinctrl driver.
>> It make the two pinctrl trees (ee/ao) to share one uniform 'function' name for
>> one hardware block even its pin groups live inside two differet hardware domains,
>> which for example EE vs AO domain here.
>>
>> This idea is motivated by Martin's question at [1]
>>
>> [1]
>> http://lkml.kernel.org/r/CAFBinCCuQ-NK747+GHDkhZty_UMMgzCYOYFcNTrRDJgU8OM=Gw@mail.gmail.com
>>
>>
>> Yixun Lan (2):
>> pinctrl: meson: introduce a macro to have name/groups seperated
>> pinctrl: meson-axg: correct the pin expansion of UART_AO_B
>>
>> drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
>> drivers/pinctrl/meson/pinctrl-meson.h | 8 +++++---
>> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> Hi Yixun,
>
> Honestly, I don't like the idea. I think it adds an unnecessary complexity.
> I don't see the point of FUNCTION_EX(uart_ao_b, _z) when you could simply write
> FUNCTION(uart_ao_b_z) ... especially when there is just a couple of function per
> SoC available on different domains.
>
> A pinctrl driver can already be challenging to understand at first, let's keep
> it simple and avoid adding more macros.
>
Hi Jeromeļ¼
In my opinion, the idea of keeping one uniform 'function' in DT (thus
introducing another macro) is worth considering. It would make the DT
part much clean.
And yes, it's a trade-off here, either we 1) do more in code to make
DT clean or 2) do nothing in the code level to make DT live with it.
Yixun
Powered by blists - more mailing lists