On Mon, Jun 30, 2025 at 3:54 PM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Mon, Jun 30, 2025, at 15:21, Robert Marko wrote: > > On Mon, Jun 16, 2025 at 8:34 PM Arnd Bergmann <arnd@xxxxxxxx> 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@xxxxxxxxxx Web: www.sartura.hr
