From: Linus Walleij <linus.walleij@linaro.org> To: Andre Przywara <andre.przywara@arm.com>, Rob Herring <robh+dt@kernel.org> Cc: Maxime Ripard <maxime.ripard@free-electrons.com>, Chen-Yu Tsai <wens@csie.org>, linux-gpio@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>, devicetree@vger.kernel.org, Linux ARM <linux-arm-kernel@lists.infradead.org>, Arnd Bergmann <arnd@arndb.de>, Icenowy Zheng <icenowy@aosc.xyz> Subject: Re: [RFC PATCH 0/3] pinctrl: sunxi: Add DT-based generic pinctrl driver Date: Fri, 24 Nov 2017 11:28:36 +0100 [thread overview] Message-ID: <CACRpkdYFoUmGJYdKz0t9gsrkK=u8-oJjaRBXtNYHaUt9kSa3_g@mail.gmail.com> (raw) In-Reply-To: <20171113012523.2328-1-andre.przywara@arm.com> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara@arm.com> wrote: > so far the pinctrl driver for supporting a particular Allwinner SoC requires > a hardcoded table in the kernel code. (...) > This series here moves the data encoded in the table so far into the DT itself, > removing the need for a hardcoded table in the kernel. (...) The DT maintainers have been pretty clear on that they don't like using the the DT as a generic fit-all information dump. They prefer to look up hardware data from per-soc compatible strings. I have been sceptic about it too, on the grounds that I think it make configuration and multiplatform kernels easy, while making debugging and reading code+device tree hard, also affecting maintenance cost. I'd like to have Maxime's buy-in before we progress and also some discussion on these themes in general. > The approach taken here is to parse the DT and generate the table with > the help of additional properties, then hand this table over to the existing > driver. This is covered by three basic extensions to the DT binding: I adressed this in the bindings patch. > The benefit of this series is two-fold: > - Future SoCs don't need an in-kernel table anymore. They can describe > everything in the DT, It can be debated whether that is really a good thing or actually a bad thing for the reasons stated above. Also an additional bad thing is inconsistency between different SoCs. What we have in the kernel for all-DT is pinctrl-single.c. This exists for the case where there is exactly one register per pin and all you have is strange macro files from the ASIC people that noone understands. OMAP and HiSilicon is using this. It's a compromise, I'm not super-happy with that driver at all times but it is for a very strongly specified case. Would it be possible for you guys to simply use/embrace/extend pinctrl-single.c if you want to go this route? Any higher order of complexity than "one register per pin" I think is better handled by open coding it than trying to push things into the device tree, because of readability, debuggability and maintenance issues. Yours, Linus Walleij
WARNING: multiple messages have this Message-ID (diff)
From: linus.walleij@linaro.org (Linus Walleij) To: linux-arm-kernel@lists.infradead.org Subject: [RFC PATCH 0/3] pinctrl: sunxi: Add DT-based generic pinctrl driver Date: Fri, 24 Nov 2017 11:28:36 +0100 [thread overview] Message-ID: <CACRpkdYFoUmGJYdKz0t9gsrkK=u8-oJjaRBXtNYHaUt9kSa3_g@mail.gmail.com> (raw) In-Reply-To: <20171113012523.2328-1-andre.przywara@arm.com> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara@arm.com> wrote: > so far the pinctrl driver for supporting a particular Allwinner SoC requires > a hardcoded table in the kernel code. (...) > This series here moves the data encoded in the table so far into the DT itself, > removing the need for a hardcoded table in the kernel. (...) The DT maintainers have been pretty clear on that they don't like using the the DT as a generic fit-all information dump. They prefer to look up hardware data from per-soc compatible strings. I have been sceptic about it too, on the grounds that I think it make configuration and multiplatform kernels easy, while making debugging and reading code+device tree hard, also affecting maintenance cost. I'd like to have Maxime's buy-in before we progress and also some discussion on these themes in general. > The approach taken here is to parse the DT and generate the table with > the help of additional properties, then hand this table over to the existing > driver. This is covered by three basic extensions to the DT binding: I adressed this in the bindings patch. > The benefit of this series is two-fold: > - Future SoCs don't need an in-kernel table anymore. They can describe > everything in the DT, It can be debated whether that is really a good thing or actually a bad thing for the reasons stated above. Also an additional bad thing is inconsistency between different SoCs. What we have in the kernel for all-DT is pinctrl-single.c. This exists for the case where there is exactly one register per pin and all you have is strange macro files from the ASIC people that noone understands. OMAP and HiSilicon is using this. It's a compromise, I'm not super-happy with that driver at all times but it is for a very strongly specified case. Would it be possible for you guys to simply use/embrace/extend pinctrl-single.c if you want to go this route? Any higher order of complexity than "one register per pin" I think is better handled by open coding it than trying to push things into the device tree, because of readability, debuggability and maintenance issues. Yours, Linus Walleij
next prev parent reply other threads:[~2017-11-24 10:28 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-13 1:25 [RFC PATCH 0/3] pinctrl: sunxi: Add DT-based generic pinctrl driver Andre Przywara 2017-11-13 1:25 ` Andre Przywara [not found] ` <20171113012523.2328-1-andre.przywara-5wv7dgnIgG8@public.gmane.org> 2017-11-13 1:25 ` [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding Andre Przywara 2017-11-13 1:25 ` Andre Przywara 2017-11-20 18:52 ` Rob Herring 2017-11-20 18:52 ` Rob Herring 2017-11-24 10:19 ` Linus Walleij 2017-11-24 10:19 ` Linus Walleij 2017-11-24 10:52 ` Thierry Reding 2017-11-24 10:52 ` Thierry Reding 2017-11-24 12:04 ` Andre Przywara 2017-11-24 12:04 ` Andre Przywara [not found] ` <20efcf8f-85a5-3cad-a84b-434ee5cad68e-5wv7dgnIgG8@public.gmane.org> 2017-11-24 13:31 ` Thierry Reding 2017-11-24 13:31 ` Thierry Reding 2017-11-24 17:19 ` Andre Przywara 2017-11-24 17:19 ` Andre Przywara [not found] ` <0c8051e6-5d8c-32d6-97e4-11c2283da5b4-5wv7dgnIgG8@public.gmane.org> 2017-11-27 8:34 ` Maxime Ripard 2017-11-27 8:34 ` Maxime Ripard 2017-12-01 9:38 ` Linus Walleij 2017-12-01 9:38 ` Linus Walleij 2017-12-01 9:56 ` Linus Walleij 2017-12-01 9:56 ` Linus Walleij [not found] ` <CACRpkdZ70a7Vk1QPFhkms6ucWmSH6rOUD9_J0h=NjhK+vfXNAA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-12-06 0:55 ` André Przywara 2017-12-06 0:55 ` André Przywara [not found] ` <be52417d-9509-f638-65b6-f455fade0c39-5wv7dgnIgG8@public.gmane.org> 2017-12-12 10:52 ` Linus Walleij 2017-12-12 10:52 ` Linus Walleij 2017-11-24 11:58 ` Andre Przywara 2017-11-24 11:58 ` Andre Przywara [not found] ` <CACRpkdbpfkM4odz425+4qyUCF5vqPWBQ=F5Yk7AtJL5SqXghpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-11-24 12:03 ` Maxime Ripard 2017-11-24 12:03 ` Maxime Ripard 2017-11-13 1:25 ` [RFC PATCH 2/3] pinctrl: sunxi: introduce DT-based generic driver Andre Przywara 2017-11-13 1:25 ` Andre Przywara 2017-12-01 17:45 ` Tony Lindgren 2017-12-01 17:45 ` Tony Lindgren 2017-11-13 1:25 ` [RFC PATCH 3/3] arm64: dts: allwinner: enhance A64 .dtsi with new pinctrl binding Andre Przywara 2017-11-13 1:25 ` Andre Przywara 2017-11-24 10:28 ` Linus Walleij [this message] 2017-11-24 10:28 ` [RFC PATCH 0/3] pinctrl: sunxi: Add DT-based generic pinctrl driver Linus Walleij 2017-11-24 12:05 ` Andre Przywara 2017-11-24 12:05 ` Andre Przywara [not found] ` <54ecfdf7-cf4a-3eae-2661-47fa668a6066-5wv7dgnIgG8@public.gmane.org> 2017-11-30 15:20 ` Linus Walleij 2017-11-30 15:20 ` Linus Walleij [not found] ` <CACRpkdZQPspH79_nS-WgiSg6d2meXUztgocYbxO07vTgP1HehA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2017-11-30 15:55 ` Andre Przywara 2017-11-30 15:55 ` Andre Przywara
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='CACRpkdYFoUmGJYdKz0t9gsrkK=u8-oJjaRBXtNYHaUt9kSa3_g@mail.gmail.com' \ --to=linus.walleij@linaro.org \ --cc=andre.przywara@arm.com \ --cc=arnd@arndb.de \ --cc=devicetree@vger.kernel.org \ --cc=icenowy@aosc.xyz \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-gpio@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=maxime.ripard@free-electrons.com \ --cc=robh+dt@kernel.org \ --cc=wens@csie.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.