On Mon, Jun 28, 2021 at 11:48:00AM +0200, Heinrich Schuchardt wrote:
> On 6/28/21 3:48 AM, Simon Glass wrote:
> > Add a new Kconfig option for EBBR so that the naming is more explicit.
> > Make EFI_LOADER depend on it.
> > 
> > Avoid enabling the options (EBBR / EFI_LOADER) by default, to save space.
> 
> NAK
> 
> Operating systems like Fedora, OpenBSD, FreeBSD require UEFI support.
> 
> See discussion in
> https://lists.denx.de/pipermail/u-boot/2021-June/452947.html

I also think this is taking things in the wrong direction.  It was an
intentional "make EFI_LOADER default when supported" when we introduced
it, and I still think that's the right overall choice.  There's a whole
lot of non-customization going on when reference designs are converted
to products or other reference designs.

> > Also add dependencies on driver model and OF_CONTROL, since boards which
> > have not migrated to these should not be using new features like EBBR.
> 
> Only supporting devices using the driver model in the UEFI sub-system is
> fine with me. CONFIG_BLK=y is another possible requirement.

Adding these would be good.  And may allow for the code to be
simplified?

> We still have 101 defconfigs not using CONFIG_DM=y. Shouldn't they be
> eliminated?

They will be eliminated after v2022.01, following the same 2 years of
"the deadline has passed" that's being used by the board removals I've
been posting so far this year.

> We have a low number of boards using CONFIG_DM=y and
> CONFIG_OF_CONTROL=n. Shouldn't they be moved to CONFIG_OF_CONTROL=y and
> that symbol be eliminated?

No, we don't require OF_CONTROL intentionally so that other smaller
mechanisms can be used.

[snip]
> We have 274 defconfigs with CONFIG_PARTITIONS=y and CONFIG_BLK=n.
> Shouldn't they be converted or eliminated?

Some number of them will be, I think there's one or two actual funny
cases on how that code is used however.

-- 
Tom