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.
>
