[U-Boot] [PATCH 1/2] arm: Remove unofficial mach-type number uses

[Igor Grinberg <grinberg@compulab.co.il>]

Hi guys,

On 01/25/17 03:34, Vladimir Zapolskiy wrote:
> On 01/25/2017 01:13 AM, Tom Rini wrote:
>> [re-sending without a URL in it]
>>
>> On Wed, Jan 25, 2017 at 12:28:47AM +0200, Vladimir Zapolskiy wrote:
>>> Hi Tom,
>>>
>>> On 01/24/2017 11:31 PM, Tom Rini wrote:
>>>> We have a number of instances of platforms that define a MACH_TYPE_xxx
>>>> value and number.  We are currently synced with the latest vales from
>>>> the Linux Kernel and in turn if numbers are not used there it is because
>>>> they were never officially used anywhere.  We drop all our instances of
>>>> these numbers.
>>>
>>> [snip]

[...]

>> So I talked with rmk about this quickly and the reduced list, which is
>> what the kernel uses and I also wish to use is the reduced list of
>> MACH_TYPE_xxx and the short version is that the reduced list only
>> includes the MACH_TYPE_xxx values that were used in mainline rather than
>> just registered.  Perhaps instead of saying "officially used" I should
>> make it clearer that it means used in the upstream linux kernel?
>>
> 
> Right, just the usage of the list in the upstream Linux kernel is assumed.
> 
> I see a few more points for consideration.
> 
> 1) From Documentation/arm/README the list of machine type IDs is only
> usable for non-DT machines and combined DT/non-DT machines. I suppose it
> should be rather safe to remove mach types from U-Boot board files for
> all archs/boards with CONFIG_OF_LIBFDT build option selected, for example
> the DevKit3250 board falls into this category. By this criterion you may
> consider to split the change into two -- one change is safe, another
> change updates legacy or badly maintained boards.
> 
> 2) The reduced mach-types list is used by Linux, I'm not sure and it
> may happen that other OS kernels recognize the complete list. Also if
> by chance someone wants to update a U-Boot image and keep the old Linux
> kernel, there is a possibility that the old kernel won't boot.

cm-t335 is an example of such machine.
Most of our cm-t335 customers use non-DT kernel 3.2 in their production.
Removing cm-t335 mach type will prevent us to provide them with an
updated bootloader, or will force us to maintain an out of tree patch...

> 
> 3) From header info in the Russell's mach-types file, the reduced list
> enumerates machines found in vanilla or machines with information not
> edited for one year. Generally this is a soft enforcement to push machine
> support to the kernel officially (or better switch it to DT), because
> unlikely once correctly added information needs any further updates,
> and most of the entries are removed due to this reason.
> 
> Hypothetically it could be possible that a machine maintainer finds that
> after rebasing private changes on top of the latest Linux release, a board
> mach type is not recognized by the Linux kernel due to an expired and
> removed entry in mach-types, then s/he updates a record in Russell's DB
> to get the old machine type ID again. However a counterpart change in
> U-boot board config won't be synced automatically, and IMHO it should be
> stated that this problem is neglected, obviously because it causes
> maintenance burden for no gain.
> 
> That said, your change is good, it may produce a discontent in particular
> cases, but it won't be problematic to remove it by partial commit
> reverting and adding an explanatory comment into the code.
> 
> --
> With best wishes,
> Vladimir
> 

-- 
Regards,
Igor.