[U-Boot] [PATCH] pinctrl: renesas: Fix linker error when PINCTRL_PFC=n

[Marek Vasut]

On 4/2/19 7:58 PM, Dirk Behme wrote:
> On 02.04.19 17:40, Eugeniu Rosca wrote:
>> On Tue, Apr 02, 2019 at 05:28:43PM +0200, Marek Vasut wrote:
>>> On 4/2/19 5:17 PM, Dirk Behme wrote:
>>>> On 02.04.19 15:34, Marek Vasut wrote:
>>>>> On 4/2/19 3:18 PM, Eugeniu Rosca wrote:
>>>>>> With CONFIG_PINCTRL_PFC=n, aarch64-linux-gnu-ld reports:
>>>>>>
>>>>>> -----8<-----
>>>>>>     LD      u-boot
>>>>>> drivers/gpio/built-in.o: In function `rcar_gpio_request':
>>>>>> drivers/gpio/gpio-rcar.c:128: undefined reference to
>>>>>> `sh_pfc_config_mux_for_gpio'
>>>>>> -----8<-----
>>>>>>
>>>>>> Fix it in the least intrusive way and *avoid* ifdefs in the *.c code.
>>>>>>
>>>>>> Some recent Linux commits sharing the same approach:
>>>>>>    -
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23222f8f8dce
>>>>>>
>>>>>>
>>>>>>      ("acpi, nfit: Add function to look up nvdimm device and provide
>>>>>> SMBIOS handle")
>>>>>>    -
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5f143af7501e
>>>>>>
>>>>>>
>>>>>>      ("spi: make OF helper available for others")
>>>>>>    -
>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bccd06223f21
>>>>>>
>>>>>>
>>>>>>      ("IB/uverbs: Add UVERBS_ATTR_FLAGS_IN to the specs language")
>>>>>>
>>>>>> Fixes: f6e545a73f88 ("pfc: rmobile: Add hook to configure pin as
>>>>>> GPIO")
>>>>>> Reported-by: Dirk Behme <dirk.behme at de.bosch.com>
>>>>>> Signed-off-by: Eugeniu Rosca <erosca at de.adit-jv.com>
>>>>>
>>>>> Does CONFIG_PINCTRL_PFC=n produce a bootable binary ?
>>>>
>>>>
>>>> Why not? Main memory, boot device and UART are configured before
>>>> U-Boot,
>>>> no?
>>>
>>> It depends on what is running before U-Boot, so not necessarily.
>>>
>>> And speaking of boot device, consider the case where the system runs
>>> from eMMC and uses the HS200/HS400 modes, which need to switch bus mode
>>> using the pinmux driver.
>>>
>>> Is there a real-world use case where you would want to disable the
>>> pinmux driver ? And what is the benefit of that, except that it would
>>> cause all kinds of weird problems.
>>
>> My H3ULCB-KF boots just fine [1] with CONFIG_PINCTRL_PFC=n, but I
>> personally don't have any use-case which I need to fulfill on a
>> Renesas reference design by disabling PFC.
> 
> 
> What's about people needing to do products based on these reference
> designs which have boot time and by this size requirements?

You can boot Linux or other RTOS from ATF directly if boot time or size
is the requirement. That's basically what happens with OpTee OS already
today. Does that cover such requirements ?

But pulling out vital functionality out of U-Boot, which results in a
semi-broken build, is not a good way to optimize things. Can we agree on
that ?

> And having functions which are build time encapsulated with CONFIG_* but
> not their callers I simply would consider as a bug which needs to be
> fixed. Like you have done here, citing several kernel examples for this :)
I wonder if the fix shouldn't be in Kconfig, make the GPIO driver depend
on the PFC driver, because the GPIO driver cannot work properly without
the PFC driver ; and ultimately the system cannot work properly without
the PFC driver either.

-- 
Best regards,
Marek Vasut