KS2012: ARM: Stale platform deprecation

There are a handful of "minor" ARM platforms in the mainline that haven't been touched for as many as five years, Olof Johansson said in kicking off a discussion of perhaps deprecating some of those platforms. The code for those platforms gets updated whenever there are sweeping changes, but they may not have been tested in years. They build just fine, but no active developers have the hardware to actually test them. He wondered when or if those platforms can ever be removed from the tree.

He suggested that once device tree has been proven as a solution for reining in the explosion of board files in the ARM tree, perhaps a one or two-year deadline could be set. Those platforms that don't update to use device tree could then be dropped.

There are still lots of older ARM platforms that are supported; OMAP 1 was cited as an example. Even though some in the discussion were a bit skeptical about older chips running mainline kernels, that does happen. There are hobbyists or others who keep the older chips working. Thus, those are not targets for deprecation.

But, Tony Lindgren noted that OMAP 2 has some 30 different board files and that there is "no way" those can all be converted to device tree. Arnd Bergmann suggested that in cases like that, the drivers should be converted to work with device tree and the board files should just be removed from the tree. Users of those platforms can either continue using older kernels or create device tree descriptions using the updated drivers.

That may not be possible in all cases. Lindgren mentioned that ARM maintainer Russell King has an automated board test setup that could be affected if those board files are removed. On some platforms, it may require major work to get power management and other features working with device trees. For legacy boards, it is unlikely that anyone will actually do that work.

There is a question of how to decide which board files should be deprecated, Lindgren said. A list of proposed deprecations should be created. Some kind of tool that uses Git to find which platforms have not been updated recently would be useful here.

In the discussion that followed, several different boards were mentioned as candidates for deprecation. Some participants spoke up for specific boards or noted that King used them in his testing. That led to a joking suggestion that someone find a way to surreptitiously relieve King of the burden of some of those boards.

The bcmring platform is particularly problematic because it was completely broken for roughly two years, but has recently been picked up by some hobbyists (who happen to work for Broadcom, creator of the platform). It has a "horrible" OS abstraction layer, so it doesn't really belong in the mainline in its present form. Will Deacon suggested that perhaps the platform could be moved to the staging tree; a checklist could be provided for what is needed before it would be acceptable in the mainline.

For defconfig files, Johansson proposed that "superset configurations" be created, which turn on every driver and feature that could be present on a platform. Those can then be "whittled down" by board or SoC vendors as needed. That will help increase the amount of build testing. Bergmann agreed, saying that having 30 defconfigs was not really a problem, even if only five are being used in practice. That would be a big improvement over the 130 or more defconfigs that are currently in the tree, Johansson said.

Specific platforms that were mentioned as targets for deprecation included ks8695, h720x, l7200, netx, w90x900. In addition, ixp4xx was targeted for deprecation, but that may still be a ways off.