On Wed, Nov 29, 2023 at 01:55:04PM +0100, Lorenzo Pieralisi wrote: > I don't think it should be done this way. Is the goal compile testing > IORT code ? Yes > If so, why are we forcing it through the SMMU (only because > it can be compile tested while eg SMMUv3 driver can't ?) menu entry ? Because something needs to select it, and SMMU is one of the places that are implicitly using it. It isn't (and shouldn't be) a user selectable kconfig. Currently the only thing that selects it is the ARM64 master kconfig. > This looks a bit artificial (and it is unclear from the Kconfig > file why only that driver selects IORT, it looks like eg the SMMUv3 > does not have the same dependency - there is also the SMMUv3 perf > driver to consider). SMMUv3 doesn't COMPILE_TEST so it picks up the dependency transitivity through ARM64. I'm not sure why IORT was put as a global ARM64 kconfig dependency and not put in the places that directly need it. "perf driver" ? There is a bunch of GIC stuff that uses this too but I don't know if it compile tests. > Maybe we can move IORT code into drivers/acpi and add a silent config > option there with a dependency on ARM64 || COMPILE_TEST. That seems pretty weird to me, this is the right way to approach it, IMHO. Making an entire directory condition is pretty incompatible with COMPILE_TEST as a philosophy. > Don't know but at least it is clearer. As for the benefits of compile > testing IORT code - yes the previous patch is a warning to fix but > I am not so sure about the actual benefits. IMHO COMPILE_TEST is an inherently good thing. It makes development easier for everyone because you have a less fractured code base to work with. Jason
