Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model

From: Simon Glass <sjg@chromium.org>
To: Tom Rini <trini@konsulko.com>
Cc: Soeren Moch <smoch@web.de>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	 Masami Hiramatsu <masami.hiramatsu@linaro.org>,
	U-Boot Mailing List <u-boot@lists.denx.de>,
	 Lukasz Majewski <lukma@denx.de>, Peng Fan <peng.fan@nxp.com>,
	Bin Meng <bmeng.cn@gmail.com>,
	 Jaehoon Chung <jh80.chung@samsung.com>,
	Stefan Roese <sr@denx.de>,
	 Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: Re: [PATCH v3 00/19] efi_loader: more tightly integrate UEFI disks to driver model
Date: Fri, 11 Mar 2022 11:26:08 -0700	[thread overview]
Message-ID: <CAPnjgZ0R0ZxN7tzQkzPF9_w+byS68V565Me2_3TKdGoLGXttBA@mail.gmail.com> (raw)
In-Reply-To: <CAPnjgZ2YCi8JEEuBxgd85oiQ_6gFTWTpfJaz6B0jSLx3StkwHg@mail.gmail.com>

Hi Tom, Takahiro,

On Wed, 9 Mar 2022 at 08:33, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Wed, 9 Mar 2022 at 07:25, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Tue, Mar 08, 2022 at 08:10:38PM -0700, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Tue, 8 Mar 2022 at 20:00, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Tue, Mar 08, 2022 at 07:32:59PM -0700, Simon Glass wrote:
> > > > >  Hi Tom,
> > > > >
> > > > > On Tue, 8 Mar 2022 at 17:13, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Mar 08, 2022 at 02:20:15PM -0700, Simon Glass wrote:
> > > > > > > Hi Soeren,
> > > > > > >
> > > > > > > On Tue, 8 Mar 2022 at 12:15, Soeren Moch <smoch@web.de> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On 08.03.22 17:56, Simon Glass wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > On Tue, 8 Mar 2022 at 09:49, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> > > > > > > > >>
> > > > > > > > >> On 3/8/22 12:36, AKASHI Takahiro wrote:
> > > > > > > > >>> With this patch set[1] applied, UEFI subsystem maintains a list of its
> > > > > > > > >>> disk objects dynamically at runtime based on block device's probing.
> > > > > > > > >>> (See "issues" below.)
> > > > > > > > >>>
> > > > > > > > >>> [1]https://github.com/t-akashi/u-boot/tree/efi/dm_disk
> > > > > > > > >>
> > > > > > > > >> This series together with Simon's series breaks multiple boards due to
> > > > > > > > >> size constraints:
> > > > > > > > >>
> > > > > > > > >> https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/11197
> > > > > > > > >>
> > > > > > > > >> Please, investigate how to work around this issue.
> > > > > > > > >
> > > > > > > > > tbs2910 - perhaps we should just drop this board? It doesn't use
> > > > > > > > > DM_SERIAL and still uses OF_EMBED
> > > > > > > >
> > > > > > > > Are we again at the same point? You are breaking working boards with
> > > > > > > > (for these boards) useless additions, and all you come up with is
> > > > > > > > "remove this board". Of course without adding the board maintainer.
> > > > > > >
> > > > > > > I'm just expressing reasonable frustration that this board uses
> > > > > > > OF_EMBED and does not use DM_SERIAL, after all of this time. Why
> > > > > > > should the rest of the U-Boot developers care more about this board
> > > > > > > than the maintainer?
> > > > > >
> > > > > > Please keep in mind Simon that we've had zero releases with the
> > > > > > DM_SERIAL migration warning being posted, v2022.04 will be the first
> > > > > > one.
> > > > >
> > > > > Yes, understood :-) For OF_EMBED though...?
> > > >
> > > > No deadline and 50 boards.
> > >
> > > Er, there has been a build message about that since the beginning, so
> > > people ignored it. Do we really need to make the build fail for these
> > > sorts of things? Perhaps so, but it is a sad situation.
> >
> > Yes, in hind-sight, "don't do that" wasn't the right path.  It would be
> > a good idea to start a different thread and see what / how the platforms
> > can be migrated away.
>
> I think there is a use case for it now - e.g. booting Apple M1 which
> uses a separate bootloader. IMO a .img or .fit file would be better in
> some cases but people seem to be allergic to implementing U-Boot
> things in their code bases. We have the same requirement for the EFI
> app since UEFI does not implement the U-Boot .img file.
>
> So if we are going to support this, perhaps we should create a new
> option for it. But honestly I am just too weary to consider yet
> another migration. We need to finish some, e.g. Kconfig.

Back to the original topic, I found that some partition code is
present in SPL and cannot be dropped. This is a long-standing thing
but matters a little more now that there is a driver and
blk_post_probe() contains some code.

This series is foundational in two ways:

- adding driver model support for partitions
- starting the clean-up of the EFI code to better use drive rmodel

Heinrich, can we please hold off on any new EFI changes in -next until
we can get this series landed? Any conflicts will set us back again.

I will see if I can send a little series to clean that up and to
reduce the board sizes for the non-SPL problems. With that, perhaps we
can apply both series within a few days?

[..]

Regards,
Simon