From: Ivan Vecera ivecera@redhat.com
redhat: Enable support for SN2201 system
Enable support for platform devices used on Nvidia SN2201 switch system.
Signed-off-by: Ivan Vecera ivecera@redhat.com
diff --git a/redhat/configs/common/generic/CONFIG_NVSW_SN2201 b/redhat/configs/common/generic/CONFIG_NVSW_SN2201 index blahblah..blahblah 100644 --- a/redhat/configs/common/generic/CONFIG_NVSW_SN2201 +++ b/redhat/configs/common/generic/CONFIG_NVSW_SN2201 @@ -1 +1 @@ -# CONFIG_NVSW_SN2201 is not set +CONFIG_NVSW_SN2201=m
-- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2136
From: pbrobinson on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2136#note_1163208...
Why is this driver being enabled everywhere? From the Kconfig: "The processor used on SN2201 is Intel Atom®Processor C Series, C3338R which is one of the Denverton product families."
So it should just be enabled on x86.
Interestingly also it has deps on various REGMAP which while seemingly already enabled in ark/RHEL they're not enabled via the RHEL config so probably needs further explicit enablement so it's documented as such.
From: Mark Langsdorf on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2136#note_1164698...
The SN2201 enabling code is in drivers/platform, and it looks like it's an architecture independent management device for server racks. See 662f24826f9. Mellanox BlueField cards are specifically called out as "depends on ARM64", and the fact that this driver doesn't have a similar dependency makes me suspect it supports X86 and ARM64. But I could be wrong.
From: pbrobinson on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2136#note_1164786...
The SN2201 is a mutli port ethernet switch, while in theory it could be an "architecture independent management device" in practice it's a 1U switch and it's Kconfig help text indicates it's a x86 device. https://www.nvidia.com/en-us/networking/ethernet-switching/spectrum-sn2000/
kernel@lists.fedoraproject.org
-
Ivan Vecera (via Email Bridge) -
Mark Langsdorf (via Email Bridge)
-
pbrobinson (via Email Bridge)