[PATCH] ipq95xx: Add support for IPQ9574 RDP433

[Elliott Mitchell]

On Fri, Dec 08, 2023 at 11:14:38AM +0100, Robert Marko wrote:
> On Fri, 8 Dec 2023 at 11:13, Piotr Dymacz <pepe2k at gmail.com> wrote:
> >
> > On 8.12.2023 11:02, Robert Marko wrote:
> > > On Fri, 8 Dec 2023 at 11:01, Piotr Dymacz <pepe2k at gmail.com> wrote:
> > >>
> > >> Would it make sense to rename qualcommax to qualcomm and make ipq95xx
> > >> just another subtarget of it (I'm aware of A53 vs. A73)?
> > >
> > > That depends on how much is shared between the AX SoC-s and the BE
> > > ones(IPQ95xx and IPQ53xx).
> >
> > I would say enough to keep them together.
> >
> > > But, I would prefer that or qualcommbe target where new BE SoC-s will
> > > be subtargets.
> >
> > I'm personally more a fan of limiting number of top targets and deal
> > with differences under subtargets.
> 
> Same here, better than to add more targets especially since a lot is shared.

This leads to needing more levels of organization.  Instead of simply
TARGET/SUBTARGET, you end up needing TARGET/SUBTARGET/SUBSUBTARGET.  If
this is going to be done, then the implementation should allow for an
arbitrary number of levels.

A makefile fragment I created for testing:

foo := foo0
SUBfoo := foo1
SUBSUBfoo := foo2

define recur
$(info current is $(1), value is $($(1))))
ignore := $(if $(filter $(flavor SUB$(1)),undefined),,$(call recur,SUB$(1)))
endef

ignore := $(call recur,foo)

all: test.make
	@true

So an arbitrary number of levels seems doable.  Will mean rather
substantial changes to the build system though.  I tend to favor this
as the 2 level limitation is already placing restrictions on the scaling
of the build count.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445