Docs/releases: Update 4.17 & 4.18 notes to remove RESOURCE_ALLOCATOR_V3

This removal was announced in 4.16, but didn't make it into the 4.17 or
4.18 release notes.

Those platforms have now been removed.

Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I35607a86242c37e1578874b3a79ff0387a55b146
Reviewed-on: https://review.coreboot.org/c/coreboot/+/71581
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>

2 files changed, 60 insertions, 0 deletions

diff --git a/Documentation/releases/coreboot-4.17-relnotes.md b/Documentation/releases/coreboot-4.17-relnotes.md
index 1f868838eb..eb136f42fc 100644
--- a/Documentation/releases/coreboot-4.17-relnotes.md
+++ b/Documentation/releases/coreboot-4.17-relnotes.md
@@ -296,6 +296,36 @@ noting, but not needing a full description.
 * sandybridge & gm45: Support setting PCI bars above 4G
 
 
+Plans to move platform support to a branch:
+-------------------------------------------
+After the 4.18 release in November 2022, we plan to move support for any
+boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch.  V4 was
+introduced more than a year ago and with minor changes most platforms
+were able to work just fine with it. A major difference is that V3 uses
+just one continuous region below 4G to allocate all PCI memory BAR's. V4
+uses all available space below 4G and if asked to, also above 4G too.
+This makes it important that SoC code properly reports all fixed
+resources.
+
+Currently only AGESA platforms have issues with it. On Gerrit both
+attempts to fix AMD AGESA codebases to use V4 and compatibility modes
+inside the V4 allocator have been proposed, but both efforts seem
+stalled. See the (not yet merged) documentation
+[CR:43603](https://review.coreboot.org/c/coreboot/+/43603) on it's
+details. It looks like properly reporting all fixed resources is the
+issue.
+
+At this point, we are not specifying which platforms this will include
+as there are a number of patches to fix these issues in flight.
+Hopefully, all platforms will end up being migrated to the V4 resource
+allocator so that none of the platforms need to be supported on the
+branch.
+
+Additionally, even if the support for the platform is moved to a branch,
+it can be brought back to ToT if they're fixed to support the V4
+allocator.
+
+
 Plans for Code Deprecation
 --------------------------
 
diff --git a/Documentation/releases/coreboot-4.18-relnotes.md b/Documentation/releases/coreboot-4.18-relnotes.md
index d4bfa0ee81..a77919202f 100644
--- a/Documentation/releases/coreboot-4.18-relnotes.md
+++ b/Documentation/releases/coreboot-4.18-relnotes.md
@@ -195,6 +195,36 @@ the same increases maintenance burden on the community a lot, while also
 being rather confusing.
 
 
+Plans to move platform support to a branch:
+-------------------------------------------
+After the 4.18 release in November 2022, we plan to move support for any
+boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch.  V4 was
+introduced more than a year ago and with minor changes most platforms
+were able to work just fine with it. A major difference is that V3 uses
+just one continuous region below 4G to allocate all PCI memory BAR's. V4
+uses all available space below 4G and if asked to, also above 4G too.
+This makes it important that SoC code properly reports all fixed
+resources.
+
+Currently only AGESA platforms have issues with it. On Gerrit both
+attempts to fix AMD AGESA codebases to use V4 and compatibility modes
+inside the V4 allocator have been proposed, but both efforts seem
+stalled. See the (not yet merged) documentation
+[CR:43603](https://review.coreboot.org/c/coreboot/+/43603) on it's
+details. It looks like properly reporting all fixed resources is the
+issue.
+
+At this point, we are not specifying which platforms this will include
+as there are a number of patches to fix these issues in flight.
+Hopefully, all platforms will end up being migrated to the v4 resource
+allocator so that none of the platforms need to be supported on the
+branch.
+
+Additionally, even if the support for the platform is moved to a branch,
+it can be brought back to ToT if they're fixed to support the v4
+allocator.
+
+
 ### Intel Icelake SoC & Icelake RVP mainboard
 
 Intel Icelake is unmaintained. Also, the only user of this platform ever