Hi Sean,
On Sat, 20 Jul 2024 at 17:11, Sean Anderson wrote:
>
> On 7/20/24 02:17, Simon Glass wrote:
> > Rather than having every caller set this up individually, create a
> > common init function. This allows new fields to be added without the
> > risk of them being left uninited.
> >
>
> What i
On 7/20/24 02:17, Simon Glass wrote:
Rather than having every caller set this up individually, create a
common init function. This allows new fields to be added without the
risk of them being left uninited.
What is the code size impact of this?
IIRC the reason why I didn't do this is to avoid
Hi
On Sat, Jul 20, 2024 at 8:20 AM Simon Glass wrote:
>
> Rather than having every caller set this up individually, create a
> common init function. This allows new fields to be added without the
> risk of them being left uninited.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/mach-imx/spl_
Rather than having every caller set this up individually, create a
common init function. This allows new fields to be added without the
risk of them being left uninited.
Signed-off-by: Simon Glass
---
arch/arm/mach-imx/spl_imx_romapi.c | 14 ++---
arch/arm/mach-sunxi/spl_spi_sunxi.c | 3 +
4 matches
Mail list logo