Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161475AbbKFM5f (ORCPT ); Fri, 6 Nov 2015 07:57:35 -0500 Received: from mail-qk0-f172.google.com ([209.85.220.172]:34858 "EHLO mail-qk0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161368AbbKFM5d (ORCPT ); Fri, 6 Nov 2015 07:57:33 -0500 MIME-Version: 1.0 In-Reply-To: References: <1445102604-11502-1-git-send-email-mcoquelin.stm32@gmail.com> <1445102604-11502-4-git-send-email-mcoquelin.stm32@gmail.com> <56261239.5030007@linaro.org> Date: Fri, 6 Nov 2015 13:57:32 +0100 Message-ID: Subject: Re: [PATCH v2 3/9] includes: dt-bindings: Add STM32F429 pinctrl DT bindings From: Maxime Coquelin To: Linus Walleij Cc: Sascha Hauer , Daniel Thompson , Mark Rutland , Rob Herring , "linux-gpio@vger.kernel.org" , Arnd Bergmann , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , =?UTF-8?Q?Andreas_F=C3=A4rber?= , "devicetree@vger.kernel.org" , Bruno Herrera Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2343 Lines: 61 2015-10-22 14:35 GMT+02:00 Linus Walleij : > On Tue, Oct 20, 2015 at 6:32 PM, Maxime Coquelin > wrote: >> 2015-10-20 12:06 GMT+02:00 Daniel Thompson : >>> 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. Thinking again at it, I persist to believe have the defines makes it easier to use. With auto-completion, it makes it faster and less error prone to select the right alternate function without parsing the datasheet. But as these defines are not actually used on driver side, maybe I could just move them to the dts directory? Regards, Maxime -- 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/