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

Heinrich Schuchardt xypron.debian at gmx.de
Thu Nov 28 06:22:26 UTC 2019


On 11/26/19 6:07 PM, Marek Vasut wrote:
> On 11/26/19 5:52 PM, Tom Rini wrote:
>> On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote:
>>> On 11/26/19 5:26 PM, Tom Rini wrote:
>>>> 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?
>>>
>>> How about directly calling driver functions for drivers which have
>>> single instance only ? Then we could optimize out all the DM overhead
>>> for that.
>>
>> And when are you hoping to post an RFC / example?
>
> Currently I have zero time available. Maybe someone else can look into
> this option?

Dear Marex,

DM drivers make use of the DM infrastructure for instance for the
allocation of the private data area. The uclass files often include
common logic needed for accessing all drivers (see for example tpm_xfer()).

So which drivers do you think of that could be simplified?

I would also be interested to learn which of the 347 boards not using
CONFIG_DM=y are still actively maintained.

Best regards

Heinrich


More information about the U-Boot mailing list