Currently, Microchip SparX-5 SoC is supported and it has its own symbol.
However, this means that new Microchip platforms that share drivers need
to constantly keep updating depends on various drivers.
So, to try and reduce this lets add ARCH_MICROCHIP symbol that drivers
could instead depend on.
LAN969x is being worked on and it will be added under ARCH_MICROCHIP.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
arch/arm64/Kconfig.platforms | 35 +++++++++++++++++++++--------------
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index fc353dab2cf6..f2d5d7af89bf 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -119,20 +119,6 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.
-config ARCH_SPARX5
- bool "Microchip Sparx5 SoC family"
- select PINCTRL
- select DW_APB_TIMER_OF
- help
- This enables support for the Microchip Sparx5 ARMv8-based
- SoC family of TSN-capable gigabit switches.
-
- The SparX-5 Ethernet switch family provides a rich set of
- switching features such as advanced TCAM-based VLAN and QoS
- processing enabling delivery of differentiated services, and
- security through TCAM-based frame processing using versatile
- content aware processor (VCAP).
-
config ARCH_K3
bool "Texas Instruments Inc. K3 multicore SoC architecture"
select SOC_TI
@@ -174,6 +160,27 @@ config ARCH_MESON
This enables support for the arm64 based Amlogic SoCs
such as the s905, S905X/D, S912, A113X/D or S905X/D2
+menuconfig ARCH_MICROCHIP
+ bool "Microchip SoC support"
+
+if ARCH_MICROCHIP
+
+config ARCH_SPARX5
+ bool "Microchip Sparx5 SoC family"
+ select PINCTRL
+ select DW_APB_TIMER_OF
+ help
+ This enables support for the Microchip Sparx5 ARMv8-based
+ SoC family of TSN-capable gigabit switches.
+
+ The SparX-5 Ethernet switch family provides a rich set of
+ switching features such as advanced TCAM-based VLAN and QoS
+ processing enabling delivery of differentiated services, and
+ security through TCAM-based frame processing using versatile
+ content aware processor (VCAP).
+
+endif
+
config ARCH_MVEBU
bool "Marvell EBU SoC Family"
select ARMADA_AP806_SYSCON
--
2.50.0On Wed, Jul 2, 2025, at 20:35, Robert Marko wrote:
> Currently, Microchip SparX-5 SoC is supported and it has its own symbol.
>
> However, this means that new Microchip platforms that share drivers need
> to constantly keep updating depends on various drivers.
>
> So, to try and reduce this lets add ARCH_MICROCHIP symbol that drivers
> could instead depend on.
Thanks for updating the series to my suggestion!
> @@ -174,6 +160,27 @@ config ARCH_MESON
> This enables support for the arm64 based Amlogic SoCs
> such as the s905, S905X/D, S912, A113X/D or S905X/D2
>
> +menuconfig ARCH_MICROCHIP
> + bool "Microchip SoC support"
> +
> +if ARCH_MICROCHIP
> +
> +config ARCH_SPARX5
> + bool "Microchip Sparx5 SoC family"
This part is the one bit I'm not sure about: The user-visible
arm64 CONFIG_ARCH_* symbols are usually a little higher-level,
so I don't think we want both ARCH_MICROCHIP /and/ ARCH_SPARX5
here, or more generally speaking any of the nested ARCH_*
symbols.
This version of your patch is going to be slightly annoying
to existing sparx5 users because updating an old .config
breaks when ARCH_MICROCHIP is not enabled.
The two options that I would prefer here are
a) make ARCH_SPARX5 a hidden symbol in order to keep the
series bisectable, remove it entirely once all references
are moved over to ARCH_MICROCHIP
b) Make ARCH_MICROCHIP a hidden symbol that is selected by
ARCH_SPARX5 but keep the menu unchanged.
Let's see what the sparx5 and at91 maintainers think about
these options.
The other patches all look fine to me.
Arnd
On Wed, Jul 02, 2025 at 09:57:10PM +0200, Arnd Bergmann wrote: > On Wed, Jul 2, 2025, at 20:35, Robert Marko wrote: > > Currently, Microchip SparX-5 SoC is supported and it has its own symbol. > > > > However, this means that new Microchip platforms that share drivers need > > to constantly keep updating depends on various drivers. > > > > So, to try and reduce this lets add ARCH_MICROCHIP symbol that drivers > > could instead depend on. > > Thanks for updating the series to my suggestion! > > > @@ -174,6 +160,27 @@ config ARCH_MESON > > This enables support for the arm64 based Amlogic SoCs > > such as the s905, S905X/D, S912, A113X/D or S905X/D2 > > > > +menuconfig ARCH_MICROCHIP > > + bool "Microchip SoC support" > > + > > +if ARCH_MICROCHIP > > + > > +config ARCH_SPARX5 > > + bool "Microchip Sparx5 SoC family" > > This part is the one bit I'm not sure about: The user-visible > arm64 CONFIG_ARCH_* symbols are usually a little higher-level, > so I don't think we want both ARCH_MICROCHIP /and/ ARCH_SPARX5 > here, or more generally speaking any of the nested ARCH_* > symbols. > > This version of your patch is going to be slightly annoying > to existing sparx5 users because updating an old .config > breaks when ARCH_MICROCHIP is not enabled. > > The two options that I would prefer here are > > a) make ARCH_SPARX5 a hidden symbol in order to keep the > series bisectable, remove it entirely once all references > are moved over to ARCH_MICROCHIP > > b) Make ARCH_MICROCHIP a hidden symbol that is selected by > ARCH_SPARX5 but keep the menu unchanged. > > Let's see what the sparx5 and at91 maintainers think about > these options. > > The other patches all look fine to me. One more fun thing to consider is that we ended up defining ARCH_MICROCHIP on riscv because people didn't want to have an ARCH_MICROCHIP_POLARFIRE symbol enabling the pic64gx SoC. Therefore, anything that relies on CONFIG_AT91 to be only selectable by users on arm/arm64 when moved to CONFIG_ARCH_MICROCHIP (as this patch does) will become selectable on riscv as a result.
On Wed, Jul 2, 2025 at 9:57 PM Arnd Bergmann <arnd@kernel.org> wrote: > > On Wed, Jul 2, 2025, at 20:35, Robert Marko wrote: > > Currently, Microchip SparX-5 SoC is supported and it has its own symbol. > > > > However, this means that new Microchip platforms that share drivers need > > to constantly keep updating depends on various drivers. > > > > So, to try and reduce this lets add ARCH_MICROCHIP symbol that drivers > > could instead depend on. > > Thanks for updating the series to my suggestion! > > > @@ -174,6 +160,27 @@ config ARCH_MESON > > This enables support for the arm64 based Amlogic SoCs > > such as the s905, S905X/D, S912, A113X/D or S905X/D2 > > > > +menuconfig ARCH_MICROCHIP > > + bool "Microchip SoC support" > > + > > +if ARCH_MICROCHIP > > + > > +config ARCH_SPARX5 > > + bool "Microchip Sparx5 SoC family" > > This part is the one bit I'm not sure about: The user-visible > arm64 CONFIG_ARCH_* symbols are usually a little higher-level, > so I don't think we want both ARCH_MICROCHIP /and/ ARCH_SPARX5 > here, or more generally speaking any of the nested ARCH_* > symbols. > > This version of your patch is going to be slightly annoying > to existing sparx5 users because updating an old .config > breaks when ARCH_MICROCHIP is not enabled. > > The two options that I would prefer here are > > a) make ARCH_SPARX5 a hidden symbol in order to keep the > series bisectable, remove it entirely once all references > are moved over to ARCH_MICROCHIP > > b) Make ARCH_MICROCHIP a hidden symbol that is selected by > ARCH_SPARX5 but keep the menu unchanged. Hi Arnd, Ok, I see the issue, and I would prefer to go with option b and do what I did for AT91 with the hidden ARCH_MICROCHIP symbol to avoid breaking current configs. > > Let's see what the sparx5 and at91 maintainers think about > these options. Sounds good, let's give them some time before I respin this series. Regards, Robert > > The other patches all look fine to me. > > Arnd -- Robert Marko Staff Embedded Linux Engineer Sartura d.d. Lendavska ulica 16a 10000 Zagreb, Croatia Email: robert.marko@sartura.hr Web: www.sartura.hr
Robert, Arnd, On 03/07/2025 at 14:25, Robert Marko wrote: > On Wed, Jul 2, 2025 at 9:57 PM Arnd Bergmann <arnd@kernel.org> wrote: >> >> On Wed, Jul 2, 2025, at 20:35, Robert Marko wrote: >>> Currently, Microchip SparX-5 SoC is supported and it has its own symbol. >>> >>> However, this means that new Microchip platforms that share drivers need >>> to constantly keep updating depends on various drivers. >>> >>> So, to try and reduce this lets add ARCH_MICROCHIP symbol that drivers >>> could instead depend on. >> >> Thanks for updating the series to my suggestion! >> >>> @@ -174,6 +160,27 @@ config ARCH_MESON >>> This enables support for the arm64 based Amlogic SoCs >>> such as the s905, S905X/D, S912, A113X/D or S905X/D2 >>> >>> +menuconfig ARCH_MICROCHIP >>> + bool "Microchip SoC support" >>> + >>> +if ARCH_MICROCHIP >>> + >>> +config ARCH_SPARX5 >>> + bool "Microchip Sparx5 SoC family" >> >> This part is the one bit I'm not sure about: The user-visible >> arm64 CONFIG_ARCH_* symbols are usually a little higher-level, >> so I don't think we want both ARCH_MICROCHIP /and/ ARCH_SPARX5 >> here, or more generally speaking any of the nested ARCH_* >> symbols. Well, having a look at arch/arm64/Kconfig.platforms, I like how NXP is organized. SPARX5, LAN969x or other MPU platforms, even if they share some common IPs, are fairly different in terms of internal architecture or feature set. So, to me, different ARCH_SPARX5, ARCH_LAN969X (as Robert proposed) or future ones make a lot sense. It will help in selecting not only different device drivers but different PM architectures, cores or TrustZone implementation... >> This version of your patch is going to be slightly annoying >> to existing sparx5 users because updating an old .config >> breaks when ARCH_MICROCHIP is not enabled. Oh, yeah, indeed. Even if I find Robert's proposal ideal. Alexandre, Lars, can you evaluate this level of annoyance? >> The two options that I would prefer here are >> >> a) make ARCH_SPARX5 a hidden symbol in order to keep the >> series bisectable, remove it entirely once all references >> are moved over to ARCH_MICROCHIP >> >> b) Make ARCH_MICROCHIP a hidden symbol that is selected by >> ARCH_SPARX5 but keep the menu unchanged. > > Hi Arnd, > Ok, I see the issue, and I would prefer to go with option b and do > what I did for > AT91 with the hidden ARCH_MICROCHIP symbol to avoid breaking current configs. Yep, but at the cost of multiple entries for Microchip arm64 SoCs at the "Platform selection" menu level. Nuvoton or Cavium have this already, so it's probably fine. >> Let's see what the sparx5 and at91 maintainers think about >> these options. > > Sounds good, let's give them some time before I respin this series. Thanks to both of you. Best regards, Nicolas
On Thu, Jul 3, 2025 at 3:56 PM Nicolas Ferre <nicolas.ferre@microchip.com> wrote: > > Robert, Arnd, > > On 03/07/2025 at 14:25, Robert Marko wrote: > > On Wed, Jul 2, 2025 at 9:57 PM Arnd Bergmann <arnd@kernel.org> wrote: > >> > >> On Wed, Jul 2, 2025, at 20:35, Robert Marko wrote: > >>> Currently, Microchip SparX-5 SoC is supported and it has its own symbol. > >>> > >>> However, this means that new Microchip platforms that share drivers need > >>> to constantly keep updating depends on various drivers. > >>> > >>> So, to try and reduce this lets add ARCH_MICROCHIP symbol that drivers > >>> could instead depend on. > >> > >> Thanks for updating the series to my suggestion! > >> > >>> @@ -174,6 +160,27 @@ config ARCH_MESON > >>> This enables support for the arm64 based Amlogic SoCs > >>> such as the s905, S905X/D, S912, A113X/D or S905X/D2 > >>> > >>> +menuconfig ARCH_MICROCHIP > >>> + bool "Microchip SoC support" > >>> + > >>> +if ARCH_MICROCHIP > >>> + > >>> +config ARCH_SPARX5 > >>> + bool "Microchip Sparx5 SoC family" > >> > >> This part is the one bit I'm not sure about: The user-visible > >> arm64 CONFIG_ARCH_* symbols are usually a little higher-level, > >> so I don't think we want both ARCH_MICROCHIP /and/ ARCH_SPARX5 > >> here, or more generally speaking any of the nested ARCH_* > >> symbols. > > Well, having a look at arch/arm64/Kconfig.platforms, I like how NXP is > organized. > > SPARX5, LAN969x or other MPU platforms, even if they share some common > IPs, are fairly different in terms of internal architecture or feature set. > So, to me, different ARCH_SPARX5, ARCH_LAN969X (as Robert proposed) or > future ones make a lot sense. > It will help in selecting not only different device drivers but > different PM architectures, cores or TrustZone implementation... > > >> This version of your patch is going to be slightly annoying > >> to existing sparx5 users because updating an old .config > >> breaks when ARCH_MICROCHIP is not enabled. > > Oh, yeah, indeed. Even if I find Robert's proposal ideal. > > Alexandre, Lars, can you evaluate this level of annoyance? > > >> The two options that I would prefer here are > >> > >> a) make ARCH_SPARX5 a hidden symbol in order to keep the > >> series bisectable, remove it entirely once all references > >> are moved over to ARCH_MICROCHIP > >> > >> b) Make ARCH_MICROCHIP a hidden symbol that is selected by > >> ARCH_SPARX5 but keep the menu unchanged. > > > > Hi Arnd, > > Ok, I see the issue, and I would prefer to go with option b and do > > what I did for > > AT91 with the hidden ARCH_MICROCHIP symbol to avoid breaking current configs. > > Yep, but at the cost of multiple entries for Microchip arm64 SoCs at the > "Platform selection" menu level. Nuvoton or Cavium have this already, so > it's probably fine. Yes, this is why I went with a menu instead, to me it is much cleaner. So, how would you guys want me to proceed? a) Keep the menu-based config symbol or b) Like for AT91, add a hidden symbol and keep the individual SoC-s in the top level platform menu? Regards, Robert > > >> Let's see what the sparx5 and at91 maintainers think about > >> these options. > > > > Sounds good, let's give them some time before I respin this series. > > Thanks to both of you. Best regards, > Nicolas -- Robert Marko Staff Embedded Linux Engineer Sartura d.d. Lendavska ulica 16a 10000 Zagreb, Croatia Email: robert.marko@sartura.hr Web: www.sartura.hr
On Fri, Jul 04, 2025 at 07:36:06PM +0200, Robert Marko wrote: > > On Thu, Jul 3, 2025 at 3:56 PM Nicolas Ferre > <nicolas.ferre@microchip.com> wrote: > > > > Robert, Arnd, > > > > On 03/07/2025 at 14:25, Robert Marko wrote: > > > On Wed, Jul 2, 2025 at 9:57 PM Arnd Bergmann <arnd@kernel.org> wrote: > > >> > > >> On Wed, Jul 2, 2025, at 20:35, Robert Marko wrote: > > >>> Currently, Microchip SparX-5 SoC is supported and it has its own symbol. > > >>> > > >>> However, this means that new Microchip platforms that share drivers need > > >>> to constantly keep updating depends on various drivers. > > >>> > > >>> So, to try and reduce this lets add ARCH_MICROCHIP symbol that drivers > > >>> could instead depend on. > > >> > > >> Thanks for updating the series to my suggestion! > > >> > > >>> @@ -174,6 +160,27 @@ config ARCH_MESON > > >>> This enables support for the arm64 based Amlogic SoCs > > >>> such as the s905, S905X/D, S912, A113X/D or S905X/D2 > > >>> > > >>> +menuconfig ARCH_MICROCHIP > > >>> + bool "Microchip SoC support" > > >>> + > > >>> +if ARCH_MICROCHIP > > >>> + > > >>> +config ARCH_SPARX5 > > >>> + bool "Microchip Sparx5 SoC family" > > >> > > >> This part is the one bit I'm not sure about: The user-visible > > >> arm64 CONFIG_ARCH_* symbols are usually a little higher-level, > > >> so I don't think we want both ARCH_MICROCHIP /and/ ARCH_SPARX5 > > >> here, or more generally speaking any of the nested ARCH_* > > >> symbols. > > > > Well, having a look at arch/arm64/Kconfig.platforms, I like how NXP is > > organized. > > > > SPARX5, LAN969x or other MPU platforms, even if they share some common > > IPs, are fairly different in terms of internal architecture or feature set. > > So, to me, different ARCH_SPARX5, ARCH_LAN969X (as Robert proposed) or > > future ones make a lot sense. > > It will help in selecting not only different device drivers but > > different PM architectures, cores or TrustZone implementation... > > > > >> This version of your patch is going to be slightly annoying > > >> to existing sparx5 users because updating an old .config > > >> breaks when ARCH_MICROCHIP is not enabled. > > > > Oh, yeah, indeed. Even if I find Robert's proposal ideal. > > > > Alexandre, Lars, can you evaluate this level of annoyance? > > > > >> The two options that I would prefer here are > > >> > > >> a) make ARCH_SPARX5 a hidden symbol in order to keep the > > >> series bisectable, remove it entirely once all references > > >> are moved over to ARCH_MICROCHIP > > >> > > >> b) Make ARCH_MICROCHIP a hidden symbol that is selected by > > >> ARCH_SPARX5 but keep the menu unchanged. > > > > > > Hi Arnd, > > > Ok, I see the issue, and I would prefer to go with option b and do > > > what I did for > > > AT91 with the hidden ARCH_MICROCHIP symbol to avoid breaking current configs. > > > > Yep, but at the cost of multiple entries for Microchip arm64 SoCs at the > > "Platform selection" menu level. Nuvoton or Cavium have this already, so > > it's probably fine. > > Yes, this is why I went with a menu instead, to me it is much cleaner. > > So, how would you guys want me to proceed? > > a) Keep the menu-based config symbol > or > b) Like for AT91, add a hidden symbol and keep the individual SoC-s in > the top level > platform menu? > > Regards, > Robert Hi Robert, Sorry for the late reply. I appreciate the effort to make the addition of future symbols easier by using a common ARCH_MICROCHIP symbol — that makes sense to me. Regarding the actual symbols, I’m certainly no expert, but I agree with Nicolas, that having more granular control with separate ARCH_SPARX5 and ARCH_LAN969X could make sense, as opposed to only having ARCH_MICROCHIP, as Arnd mentioned. As for the goal of using a common symbol for drivers to depend on, while not breaking existing configs (are there any unwritten rules or practices about breaking existing configs?), I think option B will work fine. I dont mind the symbols being top-level. /Daniel
© 2016 - 2025 Red Hat, Inc.