[U-Boot] [PATCH v1 2/2] gpio: stm32f7: Fix SPL code size

[Marek Vasut]

On 3/31/20 4:10 PM, Patrice CHOTARD wrote:
> 
> On 3/31/20 1:22 PM, Marek Vasut wrote:
>> On 3/31/20 10:12 AM, Patrice CHOTARD wrote:
>>> Hi Marek
>> Hi,
>>
>>> On 3/31/20 4:51 AM, Marek Vasut wrote:
>>>> On 1/4/19 10:55 AM, Patrice Chotard wrote:
>>>>
>>>> Hi,
>>>>
>>>>> @@ -215,7 +220,9 @@ U_BOOT_DRIVER(gpio_stm32) = {
>>>>>  	.id	= UCLASS_GPIO,
>>>>>  	.of_match = stm32_gpio_ids,
>>>>>  	.probe	= gpio_stm32_probe,
>>>>> +#ifndef CONFIG_SPL_BUILD
>>>>>  	.ops	= &gpio_stm32_ops,
>>>>> +#endif
>>>>>  	.flags	= DM_UC_FLAG_SEQ_ALIAS,
>>>>>  	.priv_auto_alloc_size	= sizeof(struct stm32_gpio_priv),
>>>>>  };
>>>> The U-Boot DM GPIO uclass code assumes the .ops is always non-NULL.
>>>> Hence, this patch breaks all GPIO access (actually crashes SPL) on STM32
>>>> in SPL.
>>> I suppose it breaks AV96 boot ?
>> No, it does not. I was trying to read GPIO value in SPL and found this.
>>
>>> On my side i have checked on v2020-04-rc4 U-boot release, by reverting "gpio: stm32f7: Fix SPL code size"
>>>
>>> the stm32f7 SPL code size is below the 32Kb limit.
>>>
>>> I will send a patch to revert it.
>> OK sure, does that apply to all the STM32 systems ?
> Yes, all STM32 based platforms (F4/F7/H7 and MP1) are using this gpio driver.

What I wanted to ask about is whether you're sure they don't overflow in
SPL. But I suspect CI would tell you by now.