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

[Vladimir Zapolskiy]

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]
>>
>>> diff --git a/include/configs/devkit3250.h b/include/configs/devkit3250.h
>>> index a71f67c352bb..f9066e7521a1 100644
>>> --- a/include/configs/devkit3250.h
>>> +++ b/include/configs/devkit3250.h
>>> @@ -13,12 +13,6 @@
>>>  #include <linux/sizes.h>
>>>  #include <asm/arch/cpu.h>
>>>  
>>> -/*
>>> - * Define DevKit3250 machine type by hand until it lands in mach-types
>>> - */
>>> -#define MACH_TYPE_DEVKIT3250		3697
>>> -#define CONFIG_MACH_TYPE		MACH_TYPE_DEVKIT3250
>>> -
>>
>> in fact this is a registered ARM machine type for the board, please

Here I'm cutting off the link sent to the mailing list.

> 
> 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.

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