On Wed, 14 May 2025, Orzel, Michal wrote: > > Sure. But my point is rather more that static memory is not a feature > > described by the Arm Arm. Instead, it is a feature of Xen that is ti to > > device-tree. So inherently there is no reason to be implemented in arch/arm. > I agree, it can and should be made common. But exposing only callers makes no > sense at all for me. Callers should be exposed together with feature code > movement.
[...] > >>> back to Arm for then moving back to common potentially in a few weeks > >>> time. > >> What about static memory code? With the recent Oleksii code movement, the > >> inline > >> helpers like allocate_static_memory() became unreachable when the feature > >> is > >> disabled and the main purpose for helpers was to avoid ifdefery. > > > > Sorry I am not sure which part you are referring to. > With the current code, allocate_static_memory(), assign_static_memory_11() > callers (that were moved to common) are protected with #ifdef. This causes the > helpers defined in case CONFIG_STATIC_MEMORY is not defined to be unreachable > (see static-memory.h). At a high level I agree with Julien, this is the kind of feature that should be common. In fact, I would even say that I consider the related device tree bindings common. But looking at the code movements and the #ifdef's, I think that as of today, this patch series is improving things. So my Ack was not at all a statement to say that the feature should be Arm-only. To the contrary. But it was only a practical consideration about the state of the code right now. I do think that RISC-V should gain support for it at some point and we should share the code as much as possible.
