[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+HBbNF6zfy=D=+34HXBPdzsfHo6aDbhcJa7Tf7YitYedK1a6A@mail.gmail.com>
Date: Wed, 2 Jul 2025 13:07:23 +0200
From: Robert Marko <robert.marko@...tura.hr>
To: Arnd Bergmann <arnd@...db.de>
Cc: Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Olivia Mackall <olivia@...enic.com>, Herbert Xu <herbert@...dor.apana.org.au>,
"David S . Miller" <davem@...emloft.net>, Vinod Koul <vkoul@...nel.org>,
Andi Shyti <andi.shyti@...nel.org>, Mark Brown <broonie@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-crypto@...r.kernel.org, dmaengine@...r.kernel.org,
linux-i2c@...r.kernel.org, linux-spi@...r.kernel.org,
Pengutronix Kernel Team <kernel@...gutronix.de>, ore@...gutronix.de, luka.perkov@...tura.hr,
Daniel Machon <daniel.machon@...rochip.com>
Subject: Re: [PATCH v7 0/6] arm64: lan969x: Add support for Microchip LAN969x SoC
On Mon, Jun 30, 2025 at 3:54 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Mon, Jun 30, 2025, at 15:21, Robert Marko wrote:
> > On Mon, Jun 16, 2025 at 8:34 PM Arnd Bergmann <arnd@...db.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.
Ok, I get the idea, I will rework the series to pivot to ARCH_MICROCHIP.
Regards,
Robert
>
> 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
--
Robert Marko
Staff Embedded Linux Engineer
Sartura d.d.
Lendavska ulica 16a
10000 Zagreb, Croatia
Email: robert.marko@...tura.hr
Web: www.sartura.hr
Powered by blists - more mailing lists