On 2025-06-21 5:01 pm, Sven Peter wrote:

On 13.06.25 18:50, Robin Murphy wrote:

quoted

On 2025-06-12 10:11 pm, Sven Peter wrote:

quoted

Enable drivers for hardware present on Apple Silicon machines.
The power domain and interrupt driver should be built-it since these are
critical for the system to boot, the rest can be build as modules.

Nit: I'd be tempted to put this patch first, just in case anyone 
bisecting with "make defconfig" in their process lands in the middle 
and suddenly loses some drivers (although arguably them going from 
"=y" to "=m" could still be a surprise, but at least a bit less so).

Ah, that's a good point that I hadn't even thought about.
Now that most of these have already been merged into different trees 
that ship has sailed though.

Yeah, like I say it's only minor and rather contrived anyway. Not a big 
worry.

quoted

[...]

quoted

@@ -1504,6 +1520,7 @@ CONFIG_ARCH_TEGRA_194_SOC=y

  CONFIG_ARCH_TEGRA_234_SOC=y
  CONFIG_TI_PRUSS=m
  CONFIG_OWL_PM_DOMAINS=y
+CONFIG_APPLE_PMGR_PWRSTATE=y

If this is critical for any Apple platform to work then it would 
probably make sense to explicitly select it from ARCH_APPLE, as is 
done for APPLE_AIC...

Documentation/kbuild/kconfig-language.rst:

   select should be used with care. select will force a symbol to a value
   without visiting the dependencies. By abusing select you are able to
   select a symbol FOO even if FOO depends on BAR that is not set. In
   general use select only for non-visible symbols (no prompts anywhere)
   and for symbols with no dependencies. That will limit the usefulness
   but on the other hand avoid the illegal configurations all over.


That's probably fine for APPLE_AIC which only depends on ARM64 (and 
ARCH_APPLE) which is guaranteed to be set when ARCH_APPLE is set anyway.
APPLE_PMGR_PWRSTATE also has an additional dependency on PM so it should 
probably remain in defconfig and not use select.

Sorry if the implication wasn't clear, but I did mean "select it" in the 
sense of "select it and all of its necessary dependencies in a manner 
that works correctly". The same argument applies all the way down - if a 
!PM config will not be able to boot on ARCH_APPLE platforms due to 
forcibly deselecting APPLE_PMGR_PWRSTATE, then there is little point in 
permitting that combination. Which of course the user would already have 
to disable at least ARCH_MXC, ARCH_ROCKCHIP, ARCH_TEGRA and 
ARCH_VEXPRESS to achieve in the first place ;)

Thanks,
Robin.