Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support

Greg Kroah-Hartman
2021-03-24T08:50:20Z

On Wed, Mar 24, 2021 at 09:29:12AM +0100, Michal Simek wrote:
> On 3/23/21 2:42 PM, Greg Kroah-Hartman wrote:
> > On Wed, Mar 17, 2021 at 01:55:16PM +0530, Sai Krishna Potthuri wrote:
> >> Adding pinctrl driver for Xilinx ZynqMP platform.
> >> This driver queries pin information from firmware and registers
> >> pin control accordingly.
> >>
> >> Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com>
> >> ---
> >> drivers/pinctrl/Kconfig | 13 +
> >> drivers/pinctrl/Makefile | 1 +
> >> drivers/pinctrl/pinctrl-zynqmp.c | 1030 ++++++++++++++++++++++++++++++
> >> 3 files changed, 1044 insertions(+)
> >> create mode 100644 drivers/pinctrl/pinctrl-zynqmp.c
> >>
> >> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> >> index 815095326e2d..25d3c7208975 100644
> >> --- a/drivers/pinctrl/Kconfig
> >> +++ b/drivers/pinctrl/Kconfig
> >> @@ -341,6 +341,19 @@ config PINCTRL_ZYNQ
> >> help
> >> This selects the pinctrl driver for Xilinx Zynq.
> >>
> >> +config PINCTRL_ZYNQMP
> >> + bool "Pinctrl driver for Xilinx ZynqMP"
> >
> > Please make this work as a module.
>
> The most of pinctrl drivers are builtin modules now which is not excuse
> it is just fact.
> $ git grep module_pla drivers/pinctrl/ | wc -l
> 40
> $ git grep builtin_pla drivers/pinctrl/ | wc -l
> 64

For new ones, we can do better, don't make us have to go back and fix
this up later.

> Also at least last 3 pinctrl drivers which have been merged are not modules.
> d4c34d09ab03 ("pinctrl: Add RISC-V Canaan Kendryte K210 FPIOA driver")
> 7e5ea974e61c ("pinctrl: pinctrl-microchip-sgpio: Add pinctrl driver for
> Microsemi Serial GPIO")
> a68a7844264e ("pinctrl: visconti: Add Toshiba Visconti SoCs pinctrl
> support")
>
> None is saying that it can't be done but that cases where you use
> pinctrl as module are really very limited. When you start to use pinctrl
> and its functionality you need to have it as the part of the kernel to
> be to get console, mmc, ethernet, usb, etc.
>
> That's why I would like to know what functionality and use case you have
> in mind that this driver should be made module.

The "functionality" of building a kernel image that works on all
hardware types. Just like x86-64 has been for a very long time :)

thanks,

greg k-h