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? > 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. Regards,