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

[Patrick DELAUNAY]

Hi Simon and Marek,

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