[RFC PATCH 2/2] board: ti: am65x: Move to using Extension framework

[Roger Quadros]

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.maincent at bootlin.com> wrote:
>>
>> On Wed, 4 Oct 2023 15:39:23 +0300
>> Roger Quadros <rogerq at 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