[U-Boot] [U-Boot-Board-Maintainers] [U-Boot-Custodians] [RFC] Eliminate boards not using CONFIG_DM=y

[Tom Rini]

On Tue, Nov 26, 2019 at 05:31:26PM +0100, Lukasz Majewski wrote:
> Hi Tom,
> 
> > On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote:
> > > On 11/26/19 12:16 AM, Heinrich Schuchardt wrote:  
> > > > Dear maintainers,  
> > > 
> > > Hi,
> > >   
> > > > we have been trying to move to the driver model for several years
> > > > now. Starting in 2018 we have added warnings to the Makefile that
> > > > boards not supporting the driver model will be eliminated. Still
> > > > 24 % of the configuration files have not been converted and do
> > > > not even use CONFIG_DM=y.
> > > > 
> > > > If we want to get rid of legacy drivers, at some point we have to
> > > > remove the 347 configuration files in the list below not using
> > > > the driver model.
> > > > 
> > > > I suggest to do this directly after the release of v2020.01
> > > > scheduled January 6th.
> > > > 
> > > > This should not stop the maintainers from reinserting the boards
> > > > after conversion to the driver model.  
> > > 
> > > Some boards just cannot accommodate this DM stuff. For those boards,
> > > it's just bloat without any useful added value. Hence, these boards
> > > would be removed because they cannot accommodate arbitrary bloat.
> > > This makes U-Boot not-so-universal bootloader anymore, but rather a
> > > bloated one.
> > > 
> > > I don't think we can force boards out or impose DM on everyone
> > > unless we can solve this bloat issue first.  
> > 
> > As someone who was involved in creating this DM stuff, do you have
> > some ideas on addressing things?  Given that you're responsible for a
> > number of these platforms and can test out some ideas on them, what
> > are you suggesting?
> > 
> 
> I can speak of some i.MX28 board(s). If there is a will one can try to
> use OF_PLATDATA without the full blown support of FDT (patches recently
> added to not include some not necessary stuff).

Right, making use of OF_PLATDATA is one of the things to address bloat
and DM isn't _required_ in SPL.

> (The board which uses this approach still waits for SPL_DM_GPIO
> definition in Kconfig to be re-posted to ML)

Ah that patch.  Sorry it's taking so long, I need to put it back on my
to-grab list.

> However, I don't know if this would work for all kinds of _bloat_
> mentioned by Marek.

And "bloat" is something I'm actively looking for people to post some
RFCs on how to address.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191126/eea82dee/attachment.sig>