Hi Simon and Marek,
> From: Simon Glass <s...@chromium.org>
> Sent: mardi 31 mars 2020 18:08
>
> Hi,
>
> On Mon, 30 Mar 2020 at 20:51, Marek Vasut <ma...@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
