[Skiboot] [PATCH 2/2] platform/witherspoon: Fix opencapi lane-mask used on GPU0

[Frederic Barrat]

When an opencapi device is used via the Acorn adapter, the link used
is connected to the "middle" group of lanes of the obus. We were using
the wrong set of lanes. The link was somehow still training, likely
because the default settings at power-on were good enough, but it's
still wrong.

Signed-off-by: Frederic Barrat <fbarrat at linux.ibm.com>
---

ajd: this is actually easy to test. During the PHY reset, we can leave the lanes in reset, which will fail link training. So we know we're using the correct lanes.

 platforms/astbmc/witherspoon.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/platforms/astbmc/witherspoon.c b/platforms/astbmc/witherspoon.c
index 772a7199..fe138991 100644
--- a/platforms/astbmc/witherspoon.c
+++ b/platforms/astbmc/witherspoon.c
@@ -300,11 +300,11 @@ static void witherspoon_npu2_device_detect(struct npu2 *npu)
 			      chip->id);
 			/*
 			 * On witherspoon, bricks 2 and 3 are connected to
-			 * the lanes matching links 1 and 0 in OpenCAPI mode.
+			 * the lanes matching links 0 and 1 in OpenCAPI mode.
 			 */
-			set_link_details(npu, 0, 3, NPU2_DEV_TYPE_OPENCAPI);
+			set_link_details(npu, 1, 3, NPU2_DEV_TYPE_OPENCAPI);
 			/* We current don't support using the second link */
-			set_link_details(npu, 1, 2, NPU2_DEV_TYPE_UNKNOWN);
+			set_link_details(npu, 0, 2, NPU2_DEV_TYPE_UNKNOWN);
 		} else {
 			prlog(PR_DEBUG, "PLAT: Chip %d GPU#0 is NVLink\n",
 			      chip->id);
-- 
2.17.1