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

[Greg Kroah-Hartman]

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@xxxxxxxxxx>
> >> ---
> >>  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