From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6127C43441 for ; Thu, 15 Nov 2018 19:29:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 744EA21582 for ; Thu, 15 Nov 2018 19:29:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 744EA21582 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-pci-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727041AbeKPFii (ORCPT ); Fri, 16 Nov 2018 00:38:38 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:40276 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725923AbeKPFii (ORCPT ); Fri, 16 Nov 2018 00:38:38 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2330980D; Thu, 15 Nov 2018 11:29:32 -0800 (PST) Received: from big-swifty.misterjones.org (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C63D83F5BD; Thu, 15 Nov 2018 11:29:31 -0800 (PST) Date: Thu, 15 Nov 2018 19:29:30 +0000 Message-ID: <865zwyw351.wl-marc.zyngier@arm.com> From: Marc Zyngier To: Trent Piepho Cc: "linux-pci@vger.kernel.org" , "lorenzo.pieralisi@arm.com" , "gustavo.pimentel@synopsys.com" , "helgaas@google.com" , "jingoohan1@gmail.com" , "faiz_abbas@ti.com" , "vigneshr@ti.com" , "Joao.Pinto@synopsys.com" Subject: Re: [PATCH 0/3] PCI: designware: Fixing MSI handling flow In-Reply-To: <1542307052.30311.531.camel@impinj.com> References: <20181113225734.8026-1-marc.zyngier@arm.com> <1542220084.30311.453.camel@impinj.com> <1542307052.30311.531.camel@impinj.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Organization: ARM Ltd MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Thu, 15 Nov 2018 18:37:33 +0000, Trent Piepho wrote: > > On Thu, 2018-11-15 at 15:22 +0000, Gustavo Pimentel wrote: > > On 14/11/2018 18:28, Trent Piepho wrote: > > > On Tue, 2018-11-13 at 22:57 +0000, Marc Zyngier wrote: > > > > > > > Now it works again. Race still present. I don't see the > > > dw_pci_msi_bottom_(un)mask methods ever get called. I seem to recall > > > that they are called as a substitute if enable/disable are not present, > > > but haven't confirmed that, which would explain why they are not called > > > after I added enable. > > > > Hum, this probably is correlated with [1] where on the describition the this > > enumerator says that "One shot does not require mask/unmask" see [2] > > That seems reasonable then. I've said before that while I think > masking could be added in the interrupt flow without breaking anything, > I think it's redundant to do it at this layer. > > I suspect it might be possible mask/unmask the interrupt "manually", > e.g. UIO does this to allow handling a level interrupt from userspace, > and that would be a path to reach the mask methods. The real use case is that a driver can perfectly disable (mask) an interrupt while being in the interrupt handler, and enable it again at a later time. M. -- Jazz is not dead, it just smell funny.