[PATCH v2 031/169] Correct SPL use of ATMEL_PIO4

[Eugen Hristev]

On 2/9/23 19:36, Tom Rini wrote:
> On Sun, Feb 05, 2023 at 03:36:17PM -0700, Simon Glass wrote:
> 
>> This converts 1 usage of this option to the non-SPL form, since there is
>> no SPL_ATMEL_PIO4 defined in Kconfig
>>
>> Signed-off-by: Simon Glass <sjg at chromium.org>
>> ---
>>
>> (no changes since v1)
>>
>>   drivers/pinctrl/pinctrl-at91-pio4.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c
>> index 50e3dd449ab..84b398619c4 100644
>> --- a/drivers/pinctrl/pinctrl-at91-pio4.c
>> +++ b/drivers/pinctrl/pinctrl-at91-pio4.c
>> @@ -271,7 +271,7 @@ static int atmel_pinctrl_bind(struct udevice *dev)
>>   	ofnode node = dev_ofnode(dev);
>>   	struct atmel_pinctrl_data *priv = (struct atmel_pinctrl_data *)dev_get_driver_data(dev);
>>   
>> -	if (!CONFIG_IS_ENABLED(ATMEL_PIO4))
>> +	if (!IS_ENABLED(CONFIG_ATMEL_PIO4))
>>   		return 0;
>>   
>>   	/* Obtain a handle to the GPIO driver */
> 
> This grows SPL in a number of platforms, so adding in Eugen to see if we
> really do want to omit this here in SPL on platforms that otherwise set
> the symbol.
> 

Hi Simon, Tom,

The growth is because the compiler will now include in SPL all the code 
below the check ? The respective code is not conditionally compiled, so 
I am trying to see why the growth. The solution would be to guard all 
the below code in the function (or the whole bind itself) by #ifndef 
CONFIG_SPL_BUILD ?

Eugen