I was trying to introduce the Kconfig before the code that depends on
it; is it kosher to have it in the other order, looking for CONFIG_
defines that don't exist yet?
Absolutely. The only requirement is to make sure that nothing breaks in
the middle of a series.
Though in this case the only user earlier in the series is the Samsung
stuff, which doesn't care about FIQs, so I can just sort things as
FIQ->ARCH_APPLE->samsung->AIC...
Seems fine to me. Sorting out the infrastructure first (FIQ, memory
attributes) first is a requirement anyway, so the ordering of the
series could reflect that priority.
I'm not sure about AIC vs. ARCH_APPLE though. Right now the pattern is
that AIC depends on ARCH_APPLE and also defaults to that. But then you
can build with ARCH_APPLE and AIC disabled if you so choose, which
does result in a broken system on these machines. AIC should build
without ARCH_APPLE (as long as we're on ARM64), so we could reverse
that.
As long as ARCH_APPLE selects AIC, you can make AIC selectable on
its own. What I'm trying to avoid is people ending up with an unbootable
system, and not having interrupts is one thing that makes it really hard
to debug...