Hi Köry, On 06/10/2023 19:47, Simon Glass wrote: > Hi Köry, > > On Fri, 6 Oct 2023 at 07:26, Köry Maincent <kory.mainc...@bootlin.com> wrote: >> >> On Wed, 4 Oct 2023 15:39:23 +0300 >> Roger Quadros <rog...@kernel.org> wrote: >> >> Hello, >> Thanks for adding me in cc. Also it seems I forgot to add myself to >> MAINTAINERS >> for the extension_board.c file. >> >>>>>> Before this goes too far I think this should move to using a linker >>>>>> list to declare the driver (or a driver-model driver if you prefer, >>>>>> but that might be overkill). >>> >>> So I've been working on this on the side and got linker list way working >>> with custom script booting but as soon as I move to standard boot flow >>> it no longer works. This is because there is no code in place to >>> apply the overlay and pass it to next stage e.g. EFI. >>> >>> I see the following note at >>> https://elixir.bootlin.com/u-boot/latest/source/boot/bootmeth_efi.c#L304 >>> >>> " >>> /* >>> * TODO: Apply extension overlay >>> * >>> * Here we need to load and apply the extension overlay. >>> This >>> is >>> * not implemented. See do_extension_apply(). The extension >>> * stuff needs an implementation in boot/extension.c so it >>> is >>> * separate from the command code. Really the extension >>> stuff >>> * should use the device tree and a uclass / driver >>> interface >>> * rather than implementing its own list >>> */ >>> " >> >> I agreed that the extension implementation should move in boot/extension.c or >> common for general use. I am wondering what the advantage of creating an >> uclass >> interface? >> I am not an uclass expert but there is no per driver ops and usage. What do >> you >> dislike about using its own list? > > I looked at this briefly for bootstd and left it alone, partly for this > reason. > > The operations I know about are: > - scan for extension boards to produce a list: needs to happen at > start of 'bootflow scan' I think) > - applying relevant overlays: needs to happen in the read_bootflow() > method perhaps > - listing available extensions > > I think a uclass makes sense, along with separating out the > 'extension' command from the actual functionality.
What do you think about this? OK to move extension card driver to uclass? > >> >>> Another note at >>> https://elixir.bootlin.com/u-boot/latest/source/cmd/extension_board.c#L198 >>> >>> "/* extensions should have a uclass - for now we use UCLASS_SIMPLE_BUS >>> uclass >>> */" >>> >>> So are we better off implementing a class driver for extension stuff? >> >> I think the first point should be to move it in common or boot and makes it >> generic for using the extension function everywhere. I will let Simon answer >> about the uclass part. > > I believe this relates to boot/ > >> >> Regards, > > Regards, > Simon -- cheers, -roger
