X-Git-Url: https://git.sur5r.net/?a=blobdiff_plain;f=doc%2Ffeature-removal-schedule.txt;h=d9a0cc267beaa1029b3403fb19654cc33cc3855e;hb=98f92001b3af0748d02e36b515a59865fb187415;hp=180ead5d81bed77352ce6f3995b8c7ffd4d7fc7c;hpb=1032d97496f6d534bf0030a5779ff1cb38cc9ebf;p=u-boot diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt index 180ead5d81..d9a0cc267b 100644 --- a/doc/feature-removal-schedule.txt +++ b/doc/feature-removal-schedule.txt @@ -7,22 +7,47 @@ file. --------------------------- -What: CONFIG_NET_MULTI option -When: Release 2009-11 - -Why: U-boot currently implements two network driver APIs. New drivers with - the older-style implementation have not been accepted for a while, and - this parallel system makes the code confusing and hard to augment. - - All existing in-tree boards will be converted to use CONFIG_NET_MULTI - over the span of two releases (2009-07 and 2009-09). - In the 2009-11 release, all code that is compiled when CONFIG_NET_MULTI - is not set will be removed, and all references to CONFIG_NET_MULTI - will be removed, effectively making it the only API. This should - provide ample time for out-of-tree users to adjust, and for tools on - all architectures to be made to work with weak functions. - -Who: Ben Warren +What: Remove CONFIG_CMD_MEMTEST from default list +When: Release v2013.07 + +Why: The "mtest" command is of little practical use (if any), and + experience has shown that a large number of board configu- + rations define useless or even dangerous start and end + addresses. If not even the board maintainers are able to + figure out which memory range can be reliably tested, how can + we expect such from the end users? As this problem comes up + repeatedly, we rather do not enable this command by default, + so only people who know what they are doing will be confronted + with it. + +Who: Wolfgang Denk + +--------------------------- + +What: Users of the legacy miiphy_* code +When: undetermined + +Why: We now have a PHY library, which allows everyone to share PHY + drivers. All new drivers should use this infrastructure, and + all old drivers should get converted to use it. + +Who: Andy Fleming and driver maintainers + +--------------------------- + +What: boards with xxx_config targets in top level Makefile +When: Release v2012.03 + +Why: We have a boards.cfg file which the vast majority of boards have + converted over to. Boards that still manually run mkconfig in the + top level Makefile are either dead, or the maintainer doesn't care, + or they are doing something weird/wrong that should be fixed in a + different way, or they need to extend boards.cfg syntax (unlikely). + + In any case, if no one cares about these boards to figure out how + to make boards.cfg work, then we'll just punt them. + +Who: Mike Frysinger ---------------------------