[RFC PATCH 01/23] sunxi: pinctrl: Create the driver skeleton

Samuel Holland samuel at sholland.org
Fri Oct 22 05:55:04 CEST 2021


Hi,

On 10/21/21 12:13 AM, Sean Anderson wrote:
> 
> On 10/21/21 12:55 AM, Samuel Holland wrote:
>> Create a do-nothing driver for each sunxi pin controller variant.
>>
>> Since only one driver can automatically bind to a DT node, since the
>> GPIO driver already requires a manual binding process, and since the
>> pinctrl driver needs access to some of the same information, refactor
>> the GPIO driver to be bound by the pinctrl driver. This commit should
>> cause no functional change.
>>
>> Signed-off-by: Samuel Holland <samuel at sholland.org>
>> ---
>>
>>   MAINTAINERS                                   |   1 +
>>   arch/arm/Kconfig                              |   1 +
>>   arch/arm/include/asm/arch-sunxi/gpio.h        |   5 +
>>   drivers/gpio/sunxi_gpio.c                     | 130 +-----------------
>>   drivers/pinctrl/Kconfig                       |   1 +
>>   drivers/pinctrl/Makefile                      |   2 +-
>>   drivers/pinctrl/sunxi/Kconfig                 | 120 ++++++++++++++++
>>   drivers/pinctrl/sunxi/Makefile                |  26 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun4i-a10.c     |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun50i-a64-r.c  |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun50i-a64.c    |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c     |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun50i-h6-r.c   |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun50i-h6.c     |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c   |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun5i-a13.c     |  33 +++++
>>   drivers/pinctrl/sunxi/pinctrl-sun6i-a31-r.c   |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun6i-a31.c     |  33 +++++
>>   drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c     |  33 +++++
>>   drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c   |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c     |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun8i-a33.c     |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun8i-a83t-r.c  |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun8i-a83t.c    |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun8i-h3-r.c    |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun8i-h3.c      |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun8i-v3s.c     |  33 +++++
>>   drivers/pinctrl/sunxi/pinctrl-sun9i-a80-r.c   |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sun9i-a80.c     |  29 ++++
>>   drivers/pinctrl/sunxi/pinctrl-sunxi.c         |  57 ++++++++
>>   drivers/pinctrl/sunxi/pinctrl-sunxi.h         |  14 ++
>>   32 files changed, 882 insertions(+), 129 deletions(-)
> 
> General question: why is this broken up into different U_BOOT_DRIVERs?
> Couldn't this be done with one driver and one array of udevice_ids?

It could be done with one driver, and that's how I originally did it.
But it required a large block of `extern` declarations in the local
header, and an #ifdef around each entry in .of_match, both of which
seemed less than ideal. (One example of this style is PINCTRL_PFC in
drivers/pinctrl/renesas.)

I do like the single-driver style from a memory usage perspective.

On the other hand, the one-driver-per-variant style is already used by
drivers/clk/sunxi.

I do not have a strong opinion either way; it is not much work to go
back to the single-driver style. I'll leave it up to the maintainers.

Regards,
Samuel


More information about the U-Boot mailing list