On 23.07.2025 12:37, Grygorii Strashko wrote: > On 18.07.25 17:18, Jan Beulich wrote: >> On 18.07.2025 13:47, Grygorii Strashko wrote: >>> On 18.07.25 13:22, Jan Beulich wrote: >>>> On 18.07.2025 12:11, Grygorii Strashko wrote: >>>>> From: Grygorii Strashko <grygorii_stras...@epam.com> >>>>> >>>>> Hence all common PIRQ code is under CONFIG_HAS_PIRQ idefs corresponding >>>>> Arm >>>>> arch callbacks become unreachable, so drop them. >>>>> >>>>> Signed-off-by: Grygorii Strashko <grygorii_stras...@epam.com> >>>>> --- >>>>> xen/arch/arm/irq.c | 29 ----------------------------- >>>>> 1 file changed, 29 deletions(-) >>>> >>>> Can this really be a separate change? That is, aren't we going to have >>>> transient >>>> Misra violations (for Arm only) between the two changes? >>> >>> The violation exist even before this series, and applies to arm/ppc/riscv >>> actually >>> >>> alloc_pirq_struct - unreachable >>> pirq_guest_bind - unreachable >>> pirq_guest_unbind - unreachable >>> pirq_set_affinity - "reachable" at least from compiler point of view. >>> >>> Would you like to have cumulative, cross-arch change to drop above arch >>> callbacks and >>> squash it in previous patch? >> >> If the issue is pre-existing, then it doesn't need squashing and the order >> isn't important. But it would indeed be desirable to have the cleanup done >> across the board. > > I can create clean-up patches for all affected arches. > > What's you opinion on how to proceed: > - re-send this series with additional patches > - wait for patch 1 and then send arch specific clean-up series > ?
Largely up to you, I would say. I was actually about to commit patch 1, when I noticed that it's still lacking a scheduler maintainer ack. Jan
