Re: [PATCH] PCI: dwc: Fix interrupt race in when handling MSI

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/11/18 19:49, Trent Piepho wrote:
> On Thu, 2018-11-08 at 09:49 +0000, Marc Zyngier wrote:
>> 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".
> 
> Little more history to this bug.  The code was originally the way it is
> now, but this same bug was fixed in 2013 in https://patchwork.kernel.or
> g/patch/3333681/
> 
> Then that lasted four years until it was changed Aug 2017 in https://pa
> tchwork.kernel.org/patch/9893303/
> 
> That lasted just six months until someone tried to revert it, https://p
> atchwork.kernel.org/patch/9893303/
> 
> Seems pretty clear the way it is now is much worse than the way it was
> before, even if the previous design may have had another flaw.  Though
> I've yet to see anyone point out something makes the previous design
> broken.  Sub-optimal yes, but not broken.

This is not what was reported by the previous submitter. I guess they
changed this for a reason, no? I'm prepared to admit this is a end-point
driver bug, but we need to understand what is happening and stop
changing this driver randomly.

>> 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".
> 
> It feels like you're using this bug to hold designware hostage in a
> broken kernel, and me along with them.  I don't have the documentation,
> no one does, there's no way for me to give you want you want.  But I've
> got hardware that doesn't work in the mainline kernel.

I take it as a personal offence that I'd be holding anything or anyone
hostage. I think I have a long enough track record working with the
Linux kernel not to take any of this nonsense. What's my interest in
keeping anything in this sorry state? Think about it for a minute.

When I'm asking for documentation, I'm not asking you. I perfectly
understood that you don't have any. We need Synopsys to step up and give
us a simple description of what the MSI workflow is. Because no matter
how you randomly mutate this code, it will still be broken until we get
a clear answer from *Synopsys*.

Gustavo, here's one simple ask. Please reply to this email with a step
by step, register by register description of how an MSI must be handled
on this HW. We do need it, and we need it now.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux