linux-kernel - Re: [PATCH v2 3/9] includes: dt-bindings: Add STM32F429 pinctrl DT bindings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACRpkdashSEWL+KFgD+MmdoZwjXnsXpxy-MPmDciO9n87+6BBQ@mail.gmail.com>
Date:	Thu, 22 Oct 2015 14:35:00 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Sascha Hauer <kernel@...gutronix.de>
Cc:	Daniel Thompson <daniel.thompson@...aro.org>,
	Mark Rutland <mark.rutland@....com>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Arnd Bergmann <arnd@...db.de>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andreas Färber <afaerber@...e.de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Bruno Herrera <bruherrera@...il.com>
Subject: Re: [PATCH v2 3/9] includes: dt-bindings: Add STM32F429 pinctrl DT bindings

On Tue, Oct 20, 2015 at 6:32 PM, Maxime Coquelin
<mcoquelin.stm32@...il.com> wrote:
> 2015-10-20 12:06 GMT+02:00 Daniel Thompson <daniel.thompson@...aro.org>:
>> On 17/10/15 18:23, Maxime Coquelin wrote:

>> I suggesting that, like with the clock driver, there is no need to the
>> STM32F429_PAXX_FUNC_YYY macros at all.
>>
>> Given the way you can enumerate pin config options in stm32f429.dtsi then I
>> think stm32f429.dtsi is the only file that will ever include this header? If
>> so then why not just plug the values directly into the pinmux fields. Its
>> not duplicative and is easier to map back to data sheets.
>>
>> ~~~
>> #define PIN_NO(x) ...
>> #define PIN_AF(x) ...
>>
>> usart1_pins_a: usart1@0 {
>>                                 pins1 {
>>                                         pinmux = PIN_NO(9) | PIN_AF(7);
>>                                         bias-disable;
>>                                         drive-push-pull;
>>                                         slew-rate = <0>;
>>                                 };
>>                                 ...
>>                         };
>> ~~~
>
> The advantage with the defines is that you can see easily which pin we
> are talking about.
> Moreover, the defines are generated from the datasheet, so it is
> painless to generate them.
> And it will be consistent with Mediatek implementation, on which I
> heavily inspired.
>
> Linus, what is your view?

I have no strong view of this at all.

I would ask the opinion of other people doing numbered muxes
to see what is generally best for everyone to use,
Sascha Hauer specifically, or the Mediatek people.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/