Hi Simon and Marek,
From: Simon Glass sjg@chromium.org Sent: mardi 31 mars 2020 18:08
Hi,
On Mon, 30 Mar 2020 at 20:51, Marek Vasut marex@denx.de 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.
Right. You are not allowed to have a driver without operations unless the uclass defines none.
Agree,
it was a dirty patch to reduce the SPL size for one MCU board stm32f7... It is no more needed today: all MCU board compile without this patch.
Moreover, this patch can cause issues for stm32mp1 (crashes).
For example on STM32MP157-EV1, when SD card detect is added in device tree, this opt is required (and it should be the case after the next device tree allignment).
A patch to reactivate this opts was in my backlog to prepare this DT update,
I sent it today to solve the issue: "[13/16] gpio: stm32: support gpio ops in SPL" http://patchwork.ozlabs.org/patch/1264836/
regards
Patrick