On Tue, 21 Jul 2015, Florian Fainelli wrote: > On 21/07/15 14:23, Thomas Gleixner wrote: > > I just read back on the problem report which was mentioned in the > > changelog: > > > > "It's not a problem with patch 7, exactly, it's a problem with the > > irqchip driver which handles the UART interrupt mask (irq-bcm7120-l2.c). > > The problem is that with a trimmed down device tree (such as the one > > found at arch/arm/boot/dts/bcm7445-bcm97445svmb.dtb), none of the child > > interrupts of the 'irq0_intc' node are described -- we don't have device > > tree nodes for them yet -- but we still require saving and restoring the > > forwarding mask (see 'brcm,int-fwd-mask') in order for the UART > > interrupts to continue operating." > > > > So you are trying to work around a flaw in the device tree by adding > > random callbacks to the core kernel? > > Not quite, you could have your interrupt controller node declared in > Device Tree, but have no "interrupts" property referencing it because: > > - the hardware is just not there, but you inherit a common Device Tree > skleten (*.dtsi) > - you could have Device Tree overlays which may or may not be loaded as > a result of finding expansion boards etc... So if no hardware is there which uses any of those interrupts, then WHY is it a problem at all? If it's a requirement that these registers must be restored (once, not per irq), then I can see that it'd be nice to do that from the core. Though that core suspend/resume function is generic chip specific. So it does not make any sense to force it into struct irq_chip because we have no core infrastructure to deal with it. Thanks, tglx
