From: Wei Liu <wei.liu@xxxxxxxxxx> Sent: Tuesday, July 26, 2022 6:09 AM > > On Tue, Jul 26, 2022 at 09:15:58AM +0200, Joerg Roedel wrote: > > Hi Michael, > > > > On Mon, Jul 25, 2022 at 05:53:40PM -0700, Michael Kelley wrote: > > > Recent changes to solve inconsistencies in handling IRQ masks #ifdef > > > out the affinity field in irq_common_data for non-SMP configurations. > > > The current code in hyperv_irq_remapping_alloc() gets a compiler error > > > in that case. > > > > > > Fix this by using the new irq_data_update_affinity() helper, which > > > handles the non-SMP case correctly. > > > > > > Signed-off-by: Michael Kelley <mikelley@xxxxxxxxxxxxx> > > > > Please add a fixes tag. > > > > Where is the change which breaks this currently, in some subsystem tree > > or already upstream? > > > > The offending patch aa081358 is in linux-next. > > > In case it is still in a maintainers tree, this patch should be applied > > there. Here is my > > > > Acked-by: Joerg Roedel <jroedel@xxxxxxx> > > I can take this patch via hyperv-next. This is a good improvement > anyway. I don't think this patch should go via hyperv-next. The helper function is introduced in the linux-next patch in the irq/irqchip-next tree, so this patch should go through irq/irqchip-next to avoid creating an interdependency. Since the original breaking change is not upstream, do I need a Fixes: tag? Won't using a linux-next commitID in a Fixes: tag be confusing? There's nothing to backport to stable. Michael
