Hi Vivek, On Wed, 18 May 2022 08:48:41 +0100, Vivek Kumar <quic_vivekuma@xxxxxxxxxxx> wrote: > > Code added in this patch takes backup of different set of > registers during hibernation suspend. On receiving hibernation > restore callback, it restores register values from backup. This > ensures state of hardware to be same just before hibernation and > after restore. > > Signed-off-by: Vivek Kumar <quic_vivekuma@xxxxxxxxxxx> > Signed-off-by: Prasanna Kumar <quic_kprasan@xxxxxxxxxxx> > --- > drivers/irqchip/irq-gic-v3.c | 138 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 136 insertions(+), 2 deletions(-) > > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c > index 2be8dea..442d32f 100644 > --- a/drivers/irqchip/irq-gic-v3.c > +++ b/drivers/irqchip/irq-gic-v3.c > @@ -29,6 +29,10 @@ > #include <asm/smp_plat.h> > #include <asm/virt.h> > > +#include <linux/syscore_ops.h> > +#include <linux/suspend.h> > +#include <linux/notifier.h> > + > #include "irq-gic-common.h" > > #define GICD_INT_NMI_PRI (GICD_INT_DEF_PRI & ~0x80) > @@ -56,6 +60,14 @@ struct gic_chip_data { > bool has_rss; > unsigned int ppi_nr; > struct partition_desc **ppi_descs; > +#ifdef CONFIG_HIBERNATION > + unsigned int enabled_irqs[32]; > + unsigned int active_irqs[32]; > + unsigned int irq_edg_lvl[64]; > + unsigned int ppi_edg_lvl; > + unsigned int enabled_sgis; > + unsigned int pending_sgis; > +#endif This is either way too much, or way too little. Just restoring these registers is nowhere near enough, as you are completely ignoring the ITS, so this will leave the machine broken for anything that requires LPIs. But If the bootloader is supposed to replace the kernel to put the HW in a state where the GIC is usable again, why do we need any of this? Hibernation relies on a basic promise: the secondary kernel is entered with the HW in a reasonable state, and the basic infrastructure (specially for stuff that can be only programmed once per boot such as the RD tables) is already available. If the bootloader is going to do the work of the initial kernel, then it must do it fully, and not require this sort of random sprinkling all over the shop. Effectively, there is an ABI between the primary kernel and the secondary, and I don't see why this interface should change to paper over what I see as the deficiencies of the bootloader. Am I missing anything? Thanks, M. -- Without deviation from the norm, progress is not possible.