On 07/11/18 20:17, Trent Piepho wrote:
On Wed, 2018-11-07 at 18:41 +0000, Marc Zyngier wrote:
On 06/11/18 19:40, Trent Piepho wrote:
What about stable kernels that don't have the hierarchical API?
My goal is to fix mainline first. Once we have something that works on mainline, we can look at propagating the fix to other versions. But mainline always comes first.
This is a regression that went into 4.14. Wouldn't the appropriate action for the stable series be to undo the regression?
This is not how stable works. Stable kernels *only* contain patches that are backported from mainline, and do not take standalone patch.
Furthermore, your fix is to actually undo someone else's fix. Who is right? In the absence of any documentation, the answer is "nobody".
The hierarchical design might allow unmasking the irq to be placed in a better location. And maybe knowing how the hardware worked would allow for a design that maintained a separate pending and active state in hardware, with distinct ack and eoi controls, i.e. allowed an MSI to be queued while still masked. But that doesn't seem like the kind of enhancement that would be backported to stable.
Anything can be backported to stable once we understand the issue. At the moment, we're just playing games moving stuff around and hope nothing else will break. That's not a sustainable way of maintaining this driver. At the moment, the only patch I'm inclined to propose until we get an actual interrupt handling flow from Synopsys is to mark this driver as "BROKEN".
Thanks,
M.