linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Trent Piepho <tpiepho@impinj.com>,
	"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>
Cc: "jpinto@synopsys.com" <jpinto@synopsys.com>,
	"jingoohan1@gmail.com" <jingoohan1@gmail.com>,
	"gustavo.pimentel@synopsys.com" <gustavo.pimentel@synopsys.com>,
	"faiz_abbas@ti.com" <faiz_abbas@ti.com>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"bhelgaas@google.com" <bhelgaas@google.com>,
	"vigneshr@ti.com" <vigneshr@ti.com>
Subject: Re: [PATCH] PCI: dwc: Fix interrupt race in when handling MSI
Date: Wed, 7 Nov 2018 18:41:11 +0000	[thread overview]
Message-ID: <597d9ebd-f95f-0a4d-e1a3-fe79d4333879@arm.com> (raw)
In-Reply-To: <1541533217.30311.263.camel@impinj.com>

On 06/11/18 19:40, Trent Piepho wrote:
> On Tue, 2018-11-06 at 16:00 +0000, Marc Zyngier wrote:
>>
>> It is hard to decide what the right solution is without understanding
>> exactly what this particular write actually does. It seems to be some
>> form of acknowledgement, but I'm only making an educated guess, and some
>> of the defines suggest that there might be another register for that.
> 
> Unfortunately, there are no docs for this controller.  I've determined
> that it sets a bit in this register when an MSI is received.  Once set,
> it acts as a mask and the controller will generate no interrupts when
> the same MSI is subsequently received.  Writing a 1 to a bit clears
> that mask bit, obviously so that each bit can be cleared atomically vs
> a non-atomic RMW.  The controller does not queue any MSIs received
> while the interrupt was masked.

I'm not sure this is really a mask, as the controller seems to have
other ways of really masking the interrupt. It looks a lot more like
either an ACK, but I need to understand how this interacts with the
masking register.

And I do not want to guess it. I want actual information from people who
build this IP.

>> What I'm interested in is the relationship this has with the mask/unmask
>> callbacks, and whether masking the interrupt before acking it would help.
> 
> 
>>
>> Gustavo, can you help here?
>>
>> In any way, moving the action of acknowledging the interrupt to its
>> right spot in the kernel (dw_pci_bottom_ack) would be a good start.
> 
> 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.

Thanks,

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

  parent reply	other threads:[~2018-11-07 18:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-27  0:00 [PATCH] PCI: dwc: Fix interrupt race in when handling MSI Trent Piepho
2018-11-05 10:28 ` Vignesh R
2018-11-05 12:08 ` Gustavo Pimentel
2018-11-06 14:53 ` Lorenzo Pieralisi
2018-11-06 16:00   ` Marc Zyngier
2018-11-06 19:40     ` Trent Piepho
2018-11-07 11:07       ` Lorenzo Pieralisi
2018-11-07 12:58         ` Gustavo Pimentel
2018-11-07 18:41       ` Marc Zyngier [this message]
2018-11-07 20:17         ` Trent Piepho
2018-11-08  9:49           ` Marc Zyngier
2018-11-08 19:49             ` Trent Piepho
2018-11-09 10:13               ` Lorenzo Pieralisi
2018-11-09 17:17                 ` Vignesh R
2018-11-09 11:34               ` Marc Zyngier
2018-11-09 18:53                 ` Trent Piepho
2018-11-13  0:41                 ` Gustavo Pimentel
2018-11-13  1:18                   ` Trent Piepho
2018-11-13 10:36                     ` Lorenzo Pieralisi
2018-11-13 18:55                       ` Trent Piepho
2018-11-13 14:40                   ` Marc Zyngier
2018-11-07 12:57     ` Gustavo Pimentel
2018-11-07 18:32       ` Trent Piepho
2018-11-08 11:46         ` Gustavo Pimentel
2018-11-08 20:51           ` Trent Piepho
2018-11-12 16:01             ` Lorenzo Pieralisi
2018-11-13  1:03               ` Gustavo Pimentel
2018-11-14 21:29               ` Trent Piepho
2018-11-12 23:45             ` Gustavo Pimentel
2018-11-07 18:46       ` Marc Zyngier
2018-11-08 11:24         ` Gustavo Pimentel
2018-11-06 18:59   ` Trent Piepho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=597d9ebd-f95f-0a4d-e1a3-fe79d4333879@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=bhelgaas@google.com \
    --cc=faiz_abbas@ti.com \
    --cc=gustavo.pimentel@synopsys.com \
    --cc=jingoohan1@gmail.com \
    --cc=jpinto@synopsys.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=stable@vger.kernel.org \
    --cc=tpiepho@impinj.com \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).