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. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
