Re: [PATCH v7 0/6] arm64: lan969x: Add support for Microchip LAN969x SoC

["Arnd Bergmann" <arnd@arndb.de>]

On Mon, Jun 30, 2025, at 15:21, Robert Marko wrote:
> On Mon, Jun 16, 2025 at 8:34 PM Arnd Bergmann <arnd@arndb.de> wrote:
>> On Fri, Jun 13, 2025, at 13:39, Robert Marko wrote:
>>
>> If the drivers on ARCH_LAN969X are largely shared with those on
>> ARCH_AT91, should they perhaps depend on a common symbol?
>>
>> That could be either the existing ARCH_AT91 as we do with LAN966,
>> or perhaps ARCH_MICROCHIP, which is already used for riscv/polarfire.
>
> Hi Arnd, I thought about this, but I am not sure whether its worth it
> since we need LAN969x arch anyway for other drivers that currently
> depend on LAN966x or SparX-5 but will be extended for LAN969x (I have
> this already queued locally but need this to land first).

I think in that case we would want one symbol for all of the above.
We have a couple of cases where there multiple SoC product families
get handled by a shared config symbol to make life easier for the
kernel:

- ARCH_IMX contains multiple chip families that are now owned
  by NXP but that have a complex history with acquisitions and
  product families that mix-and-match IP blocks, similar to
  Microchip

- ARCH_EXYNOS contains chips from Samsung, Google, Tesla and Axis
  that all share a lot of components because they are all based on
  Samsung designs

- ARCH_BCM contains several chip families that all started out
  in Broadcom but actually share very few common components.

On the other hand, we have TI with its davinci, omap, omap2
keystone2 and k3 platforms, or Marvell with orion, mvebu,
pxa, mmp, octeon, octeontx, thunderx and thunderx2 platforms
that overlap to varying degrees but use separate Kconfig symbols.

Since you already have an ARCH_MICROCHIP used by one of the
microchip platforms, the simplest approach seems to me to
include at91, lan969x, lan966x and sparx-5 under that as well.
You could just select that symbol from each of the four
and then change any driver that is used by more than one of
these families to use 'depends on ARCH_MICROCHIP' instead of
listing them individually.

I assume the mips based PIC32 and VCOREIII (ocelot/jaguar)
are distant enough that they wouldn't share any drivers with
the other families any more, but they could be put into that
as well if that helps.

     Arnd