On Fri, 2019-01-04 at 16:23 -0700, Stephen Warren wrote:
> On 1/4/19 4:00 PM, Stephen Warren wrote:
> >
> >
> > Hmm. Well I guess I'll go for the patch I posted in our downstream
> > kernels, since back-porting a bunch of not-yet-available restructuring
> > to our ancient kernels doesn't sound pleasant:-) But I'll go and take a
> > quick look at the other patches you mentioned just in case. Thanks!
>
> So I went and read the thread for "PCI: dwc: Fix interrupt race in when
> handling MSI" and see:
>
> Vignesh R wrote:
> > Lorenzo Pieralisi wrote:
> > > AFAICS:
> > >
> > > 8c934095fa2f ("PCI: dwc: Clear MSI interrupt status after it is handled,
> > > not before")
> > >
> > > was fixing a bug, causing "timeouts on some wireless lan cards", we want
> > > to understand what the problem is, fix it once for all on all DWC
> > > based systems.
> > >
> So it seems quite clear that the correct course of action is to
> immediately revert commit 8c934095fa2f ("PCI: dwc: Clear MSI interrupt
> status after it is handled, not before") (or apply my or Trent's patches
> which are effectively reverts) since it (a) attempts to fix a bug (in
> the core DWC driver) that doesn't actually exist (the bug is in the DRA
> HW and is being fixed in the DRA wrapper driver), and (b) has many
> reports that the change causes regressions; I'm at least the 3rd or 4th
> person to confirm this now (Faiz originally, then later Trent, Vignesh,
> myself).
It also seemed clear to me! But if you check the thread fully, this
was very forcefully rejected.
> Now, whether there's some cleanup or additional fixes needed beyond the
> simple revert is another question I currently have no insight into, but
> let's at least get back to a driver without that worked well for people
> for years, even if there's a theoretical issue to be fixed that nobody
> hit in practice.
I do not think a real or theoretical mechanism for incorrect behavior
was identified beyond the revert we know of. More of a case of pieces
not being where the framework intended them to be.
