[PATCH v8 00/10] arm64: lan969x: Add support for Microchip LAN969x SoC

[PATCH v8 00/10] arm64: lan969x: Add support for Microchip LAN969x SoC

[Robert Marko]

This patch series adds basic support for Microchip LAN969x SoC.

It introduces the SoC ARCH symbol itself under the ARCH_MICROCHIP symbol
which allows to avoid the need to change dependencies of the drivers that
are shared for Microchip SoC-s in the future.

DTS and further driver will be added in follow-up series.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v8:
* Move to using ARCH_MICROCHIP as suggested by Arnd
* Dropped any review tags due to changes

Robert Marko (10):
  arm64: Add config for Microchip SoC platforms
  ARM: at91: select ARCH_MICROCHIP
  arm64: lan969x: Add support for Microchip LAN969x SoC
  mfd: at91-usart: Make it selectable for ARCH_MICROCHIP
  tty: serial: atmel: make it selectable for ARCH_MICROCHIP
  spi: atmel: make it selectable for ARCH_MICROCHIP
  i2c: at91: make it selectable for ARCH_MICROCHIP
  dma: xdmac: make it selectable for ARCH_MICROCHIP
  char: hw_random: atmel: make it selectable for ARCH_MICROCHIP
  crypto: atmel-aes: make it selectable for ARCH_MICROCHIP

 arch/arm/mach-at91/Kconfig     |  4 +++
 arch/arm64/Kconfig.platforms   | 49 ++++++++++++++++++++++++----------
 drivers/char/hw_random/Kconfig |  2 +-
 drivers/crypto/Kconfig         |  2 +-
 drivers/dma/Kconfig            |  2 +-
 drivers/i2c/busses/Kconfig     |  2 +-
 drivers/mfd/Kconfig            |  2 +-
 drivers/spi/Kconfig            |  2 +-
 drivers/tty/serial/Kconfig     |  2 +-
 9 files changed, 46 insertions(+), 21 deletions(-)

-- 
2.50.0

[PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

[Robert Marko]

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.0

[PATCH v8 02/10] ARM: at91: select ARCH_MICROCHIP

[Robert Marko]

Like with the ARM64 Microchip platforms, lets add a generic ARCH_MICROCHIP
symbol and select it so that drivers that are reused for multiple product
generation or lines, can just depend on it instead of adding each SoC
symbol as their dependencies.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
 arch/arm/mach-at91/Kconfig | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 04bd91c72521..c5ef27e3cd8f 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -1,4 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
+config ARCH_MICROCHIP
+	bool
+
 menuconfig ARCH_AT91
 	bool "AT91/Microchip SoCs"
 	depends on (CPU_LITTLE_ENDIAN && (ARCH_MULTI_V4T || ARCH_MULTI_V5)) || \
@@ -8,6 +11,7 @@ menuconfig ARCH_AT91
 	select GPIOLIB
 	select PINCTRL
 	select SOC_BUS
+	select ARCH_MICROCHIP
 
 if ARCH_AT91
 config SOC_SAMV7
-- 
2.50.0

[PATCH v8 03/10] arm64: lan969x: Add support for Microchip LAN969x SoC

[Robert Marko]

This adds support for the Microchip LAN969x ARMv8-based SoC switch family.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v8:
* Place LAN969x under ARCH_MICROCHIP as suggested by Arnd and drop review
tags due to this

 arch/arm64/Kconfig.platforms | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index f2d5d7af89bf..083e9815259c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -165,6 +165,20 @@ menuconfig ARCH_MICROCHIP
 
 if ARCH_MICROCHIP
 
+config ARCH_LAN969X
+	bool "Microchip LAN969X SoC family"
+	select PINCTRL
+	select DW_APB_TIMER_OF
+	help
+	  This enables support for the Microchip LAN969X ARMv8-based
+	  SoC family of TSN-capable gigabit switches.
+
+	  The LAN969X 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_SPARX5
 	bool "Microchip Sparx5 SoC family"
 	select PINCTRL
-- 
2.50.0

[PATCH v8 04/10] mfd: at91-usart: Make it selectable for ARCH_MICROCHIP

[Robert Marko]

LAN969x uses the Atmel USART, so make it selectable for ARCH_MICROCHIP to
avoid needing to update depends in future if other Microchip SoC-s use it
as well.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
 drivers/mfd/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6fb3768e3d71..0ea3a97bb93d 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -138,7 +138,7 @@ config MFD_AAT2870_CORE
 config MFD_AT91_USART
 	tristate "AT91 USART Driver"
 	select MFD_CORE
-	depends on ARCH_AT91 || ARCH_LAN969X || COMPILE_TEST
+	depends on ARCH_MICROCHIP || COMPILE_TEST
 	help
 	  Select this to get support for AT91 USART IP. This is a wrapper
 	  over at91-usart-serial driver and usart-spi-driver. Only one function
-- 
2.50.0

[PATCH v8 05/10] tty: serial: atmel: make it selectable for ARCH_MICROCHIP

[Robert Marko]

LAN969x uses the Atmel USART serial, so make it selectable for
ARCH_MICROCHIP to avoid needing to update depends in future if other
Microchip SoC-s use it as well.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
 drivers/tty/serial/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 79a8186d3361..c33fc6f16d31 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -128,7 +128,7 @@ config SERIAL_SB1250_DUART_CONSOLE
 config SERIAL_ATMEL
 	bool "AT91 on-chip serial port support"
 	depends on COMMON_CLK
-	depends on ARCH_AT91 || ARCH_LAN969X || COMPILE_TEST
+	depends on ARCH_MICROCHIP || COMPILE_TEST
 	select SERIAL_CORE
 	select SERIAL_MCTRL_GPIO if GPIOLIB
 	select MFD_AT91_USART
-- 
2.50.0

[PATCH v8 06/10] spi: atmel: make it selectable for ARCH_MICROCHIP

[Robert Marko]

LAN969x uses the Atmel SPI, so make it selectable for ARCH_MICROCHIP to
avoid needing to update depends in future if other Microchip SoC-s use it
as well.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v8:
* Use ARCH_MICROCHIP for depends as its now selected by both ARM and ARM64
Microchip SoC-s

 drivers/spi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index f2d2295a5501..a7ca7cd9648f 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -145,7 +145,7 @@ config SPI_ASPEED_SMC
 
 config SPI_ATMEL
 	tristate "Atmel SPI Controller"
-	depends on ARCH_AT91 || COMPILE_TEST
+	depends on ARCH_MICROCHIP || COMPILE_TEST
 	depends on OF
 	help
 	  This selects a driver for the Atmel SPI Controller, present on
-- 
2.50.0

[PATCH v8 07/10] i2c: at91: make it selectable for ARCH_MICROCHIP

[Robert Marko]

LAN969x uses the Atmel TWI I2C, so make it selectable for ARCH_MICROCHIP to
avoid needing to update depends in future if other Microchip SoC-s use it
as well.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v8:
* Use ARCH_MICROCHIP for depends as its now selected by both ARM and ARM64
Microchip SoC-s

 drivers/i2c/busses/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 0a4ecccd1851..0101529c80a9 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -414,7 +414,7 @@ config I2C_ASPEED
 
 config I2C_AT91
 	tristate "Atmel AT91 I2C Two-Wire interface (TWI)"
-	depends on ARCH_AT91 || COMPILE_TEST
+	depends on ARCH_MICROCHIP || COMPILE_TEST
 	help
 	  This supports the use of the I2C interface on Atmel AT91
 	  processors.
-- 
2.50.0

[PATCH v8 08/10] dma: xdmac: make it selectable for ARCH_MICROCHIP

[Robert Marko]

LAN969x uses the Atmel XDMAC, so make it selectable for ARCH_MICROCHIP to
avoid needing to update depends in future if other Microchip SoC-s use it
as well.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v8:
* Use ARCH_MICROCHIP for depends as its now selected by both ARM and ARM64
Microchip SoC-s

 drivers/dma/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 3bc79f320540..05c7c7d9e5a4 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -110,7 +110,7 @@ config AT_HDMAC
 
 config AT_XDMAC
 	tristate "Atmel XDMA support"
-	depends on ARCH_AT91
+	depends on ARCH_MICROCHIP
 	select DMA_ENGINE
 	help
 	  Support the Atmel XDMA controller.
-- 
2.50.0

[PATCH v8 09/10] char: hw_random: atmel: make it selectable for ARCH_MICROCHIP

[Robert Marko]

LAN969x uses the Atmel HWRNG, so make it selectable for ARCH_MICROCHIP to
avoid needing to update depends in future if other Microchip SoC-s use it
as well.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v8:
* Use ARCH_MICROCHIP for depends as its now selected by both ARM and ARM64
Microchip SoC-s

 drivers/char/hw_random/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index c85827843447..e316cbc5baa9 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -77,7 +77,7 @@ config HW_RANDOM_AIROHA
 
 config HW_RANDOM_ATMEL
 	tristate "Atmel Random Number Generator support"
-	depends on (ARCH_AT91 || COMPILE_TEST)
+	depends on (ARCH_MICROCHIP || COMPILE_TEST)
 	default HW_RANDOM
 	help
 	  This driver provides kernel-side support for the Random Number
-- 
2.50.0

[PATCH v8 10/10] crypto: atmel-aes: make it selectable for ARCH_MICROCHIP

[Robert Marko]

LAN969x uses the Atmel crypto, so make it selectable for ARCH_MICROCHIP to
avoid needing to update depends in future if other Microchip SoC-s use it
as well.

Signed-off-by: Robert Marko <robert.marko@sartura.hr>
---
Changes in v8:
* Use ARCH_MICROCHIP for depends as its now selected by both ARM and ARM64
Microchip SoC-s

 drivers/crypto/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 04b4c43b6bae..7c1717c35b76 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -439,7 +439,7 @@ config CRYPTO_DEV_ATMEL_AUTHENC
 
 config CRYPTO_DEV_ATMEL_AES
 	tristate "Support for Atmel AES hw accelerator"
-	depends on ARCH_AT91 || COMPILE_TEST
+	depends on ARCH_MICROCHIP || COMPILE_TEST
 	select CRYPTO_AES
 	select CRYPTO_AEAD
 	select CRYPTO_SKCIPHER
-- 
2.50.0

Re: [PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

[Arnd Bergmann]

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.

     Arnd

Re: [PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

[Robert Marko]

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

Re: [PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

[Nicolas Ferre]

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

Re: [PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 2150 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

[Robert Marko]

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

Re: (subset) [PATCH v8 00/10] arm64: lan969x: Add support for Microchip LAN969x SoC

[Vinod Koul]

On Wed, 02 Jul 2025 20:35:58 +0200, Robert Marko wrote:
> This patch series adds basic support for Microchip LAN969x SoC.
> 
> It introduces the SoC ARCH symbol itself under the ARCH_MICROCHIP symbol
> which allows to avoid the need to change dependencies of the drivers that
> are shared for Microchip SoC-s in the future.
> 
> DTS and further driver will be added in follow-up series.
> 
> [...]

Applied, thanks!

[08/10] dma: xdmac: make it selectable for ARCH_MICROCHIP
        commit: e56982021f5303b2523ac247e3c79b063459d012

Best regards,
-- 
~Vinod

Re: (subset) [PATCH v8 04/10] mfd: at91-usart: Make it selectable for ARCH_MICROCHIP

[Lee Jones]

On Wed, 23 Jul 2025, Lee Jones wrote:

> On Wed, 02 Jul 2025 20:36:02 +0200, Robert Marko wrote:
> > LAN969x uses the Atmel USART, so make it selectable for ARCH_MICROCHIP to
> > avoid needing to update depends in future if other Microchip SoC-s use it
> > as well.
> > 
> > 
> 
> Applied, thanks!
> 
> [04/10] mfd: at91-usart: Make it selectable for ARCH_MICROCHIP
>         commit: ef37a1e2485724f5287db1584d8aba48e8ba3f41

Reverted as it caused issues in -next.

https://lore.kernel.org/all/20250724115409.030d0d08@canb.auug.org.au/

-- 
Lee Jones [李琼斯]

Re: (subset) [PATCH v8 04/10] mfd: at91-usart: Make it selectable for ARCH_MICROCHIP

[Robert Marko]

On Thu, Jul 24, 2025 at 12:04 PM Lee Jones <lee@kernel.org> wrote:
>
> On Wed, 23 Jul 2025, Lee Jones wrote:
>
> > On Wed, 02 Jul 2025 20:36:02 +0200, Robert Marko wrote:
> > > LAN969x uses the Atmel USART, so make it selectable for ARCH_MICROCHIP to
> > > avoid needing to update depends in future if other Microchip SoC-s use it
> > > as well.
> > >
> > >
> >
> > Applied, thanks!
> >
> > [04/10] mfd: at91-usart: Make it selectable for ARCH_MICROCHIP
> >         commit: ef37a1e2485724f5287db1584d8aba48e8ba3f41
>
> Reverted as it caused issues in -next.
>
> https://lore.kernel.org/all/20250724115409.030d0d08@canb.auug.org.au/

Hi Lee,
This patch depends on the first 3 patches in the series, which have
not yet been merged.

Regards,
Robert
>
> --
> Lee Jones [李琼斯]



-- 
Robert Marko
Staff Embedded Linux Engineer
Sartura d.d.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@sartura.hr
Web: www.sartura.hr

Re: (subset) [PATCH v8 00/10] arm64: lan969x: Add support for Microchip LAN969x SoC

[Claudiu Beznea]

Hi, Vinod,

On 23.07.2025 15:29, Vinod Koul wrote:
> 
> On Wed, 02 Jul 2025 20:35:58 +0200, Robert Marko wrote:
>> This patch series adds basic support for Microchip LAN969x SoC.
>>
>> It introduces the SoC ARCH symbol itself under the ARCH_MICROCHIP symbol
>> which allows to avoid the need to change dependencies of the drivers that
>> are shared for Microchip SoC-s in the future.
>>
>> DTS and further driver will be added in follow-up series.
>>
>> [...]
> 
> Applied, thanks!
> 
> [08/10] dma: xdmac: make it selectable for ARCH_MICROCHIP
>         commit: e56982021f5303b2523ac247e3c79b063459d012

As this one depends, as well, on the first 3 patches in the series (Robert,
please correct me if I'm wrong), and there are still discussions ongoing,
can you please drop it until all is clear on the first 3 patches?

Otherwise, applying only this patch will lead to AT91 XDMAC driver not
being built for SAMA5{D2, D3, D4}, SAMA7{G5, D65} SoCs. Linux is not
booting on SAMA7G5 SoC only with this patch applied.

Thank you,
Claudiu

Re: [PATCH v8 01/10] arm64: Add config for Microchip SoC platforms

[Daniel Machon]

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

Re: (subset) [PATCH v8 00/10] arm64: lan969x: Add support for Microchip LAN969x SoC

[Alexander Dahl]

Hello,

Am Thu, Jul 31, 2025 at 11:05:07AM +0300 schrieb Claudiu Beznea:
> Hi, Vinod,
> 
> On 23.07.2025 15:29, Vinod Koul wrote:
> > 
> > On Wed, 02 Jul 2025 20:35:58 +0200, Robert Marko wrote:
> >> This patch series adds basic support for Microchip LAN969x SoC.
> >>
> >> It introduces the SoC ARCH symbol itself under the ARCH_MICROCHIP symbol
> >> which allows to avoid the need to change dependencies of the drivers that
> >> are shared for Microchip SoC-s in the future.
> >>
> >> DTS and further driver will be added in follow-up series.
> >>
> >> [...]
> > 
> > Applied, thanks!
> > 
> > [08/10] dma: xdmac: make it selectable for ARCH_MICROCHIP
> >         commit: e56982021f5303b2523ac247e3c79b063459d012
> 
> As this one depends, as well, on the first 3 patches in the series (Robert,
> please correct me if I'm wrong), and there are still discussions ongoing,
> can you please drop it until all is clear on the first 3 patches?
> 
> Otherwise, applying only this patch will lead to AT91 XDMAC driver not
> being built for SAMA5{D2, D3, D4}, SAMA7{G5, D65} SoCs. Linux is not
> booting on SAMA7G5 SoC only with this patch applied.

Second that.  Just tested v6.17-rc4 on sam9x60 and DMA is not working
at all because this driver can not be selected anymore.  This must be
fixed before v6.17 release please!

Greets
Alex

Re: (subset) [PATCH v8 00/10] arm64: lan969x: Add support for Microchip LAN969x SoC

[Nicolas Ferre]

On 03/09/2025 at 15:16, Alexander Dahl wrote:
> Hello,
> 
> Am Thu, Jul 31, 2025 at 11:05:07AM +0300 schrieb Claudiu Beznea:
>> Hi, Vinod,
>>
>> On 23.07.2025 15:29, Vinod Koul wrote:
>>>
>>> On Wed, 02 Jul 2025 20:35:58 +0200, Robert Marko wrote:
>>>> This patch series adds basic support for Microchip LAN969x SoC.
>>>>
>>>> It introduces the SoC ARCH symbol itself under the ARCH_MICROCHIP symbol
>>>> which allows to avoid the need to change dependencies of the drivers that
>>>> are shared for Microchip SoC-s in the future.
>>>>
>>>> DTS and further driver will be added in follow-up series.
>>>>
>>>> [...]
>>>
>>> Applied, thanks!
>>>
>>> [08/10] dma: xdmac: make it selectable for ARCH_MICROCHIP
>>>          commit: e56982021f5303b2523ac247e3c79b063459d012
>>
>> As this one depends, as well, on the first 3 patches in the series (Robert,
>> please correct me if I'm wrong), and there are still discussions ongoing,
>> can you please drop it until all is clear on the first 3 patches?
>>
>> Otherwise, applying only this patch will lead to AT91 XDMAC driver not
>> being built for SAMA5{D2, D3, D4}, SAMA7{G5, D65} SoCs. Linux is not
>> booting on SAMA7G5 SoC only with this patch applied.
> 
> Second that.  Just tested v6.17-rc4 on sam9x60 and DMA is not working
> at all because this driver can not be selected anymore.  This must be
> fixed before v6.17 release please!

Yep, I'll try to fast forward patch 02 of this series before 6.17-final 
(this instead of reverting XDMA patch).

Regards,
   Nicolas