Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp7040314ybi; Thu, 13 Jun 2019 08:34:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqwpcmWicZivPyMLcqnTOOGjO3PTYrJqUXMOY+vtQ6QbmC1B62xoPXnViIfj/d04757eew88 X-Received: by 2002:a17:902:2a69:: with SMTP id i96mr79584202plb.108.1560440057310; Thu, 13 Jun 2019 08:34:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560440057; cv=none; d=google.com; s=arc-20160816; b=I9PojzTnepfB36uqJNBfPPJDcU6JHFnIakDWh7VhX9+pFh6xzj2JKk+m1V24uzeQlj QDPvTJUJ6iI1GoLtOkLFCcB/uizuZAhQTQ7Q8EH5jCKkhcpvBdMjh9AeW/x9j8gdWm10 B6rVNn8UT7CH8/krKXFY1WunyOnqyTZEHqQ/R/reGrfsX+oVkP+Z5K53rnAcc8RoHpIe ejvGILQbmAiljpXGGWEJHQ+bQgvoeOSr64V+LBfcQTsa7K6e8BKpvpnZYKnCcVYbV15o +DW1HqzQZOSZt2fBEtryeyaXzdHWp5qWn/hn9xemZDdlfdocxfrV7LpBma8qGueiqmRz 3COg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=70Igxccp1LSYpYS9Y6RrflVjOpEYkRCuUAz24Yt6d98=; b=PGhxMDJqkoHkklIAaZyfBaojalO8MOyF9K0ocoThAPQpvo4Bfk1dinEahbda2Ye+MN isq9sZ00HXKYC2J45/HDyJwWjRabfKQ0UgywHi+5uPOV4Jw/cuFBXzTljoHiTcy90Tjt 90UmffpIJaz/rIEgnbx6ApD+QbSDAv+ojUT2oFuys8Vuli9b03jWVYuzfxpRuMcDsV1N Olxby2kmEgYw5eSHrVzG+x29H3ARnqCuamuznZl8wEX0f515V6d8Q3jJPJLNdUA4EIwJ B0QyWPdzf7F0RDK8qVk/F9y3P326u1gblVmM16TRR59HU91rrrxeTqetqKsb0/848HLD fEjg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g125si1195589pfb.232.2019.06.13.08.34.01; Thu, 13 Jun 2019 08:34:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728306AbfFMPbx (ORCPT + 99 others); Thu, 13 Jun 2019 11:31:53 -0400 Received: from gate.crashing.org ([63.228.1.57]:47095 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728593AbfFMK46 (ORCPT ); Thu, 13 Jun 2019 06:56:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x5DAuVOr010532; Thu, 13 Jun 2019 05:56:32 -0500 Message-ID: <5e3e3f21b53f45cb115b4c04e04dc7557c63982d.camel@kernel.crashing.org> Subject: Re: [PATCH+DISCUSSION] irqchip: armada-370-xp: Remove redundant ops assignment From: Benjamin Herrenschmidt To: Marc Zyngier Cc: Thomas Petazzoni , Gregory CLEMENT , "linux-kernel@vger.kernel.org" , linux-arm-kernel@lists.infradead.org Date: Thu, 13 Jun 2019 20:56:31 +1000 In-Reply-To: <86muilc012.wl-marc.zyngier@arm.com> References: <86muilc012.wl-marc.zyngier@arm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2019-06-13 at 10:22 +0100, Marc Zyngier wrote: > > It looks to me that masking at the PCI level is rather superfluous as > long as the MSI controller HW has the capability to mask the interrupt > on a per MSI basis. After all, most non MSI-X endpoint lack support > for masking of individual vectors, so I think that we should just mask > things at the irqchip level. This is also consistent with what you'd > have to do for non-PCI MSI, where nothing standardises the MSI > masking. > > I think this is in effect a split in responsibilities: > > - the end-point driver should (directly or indirectly) control the > interrupt generation at the end-point level, > > - the MSI controller driver should control the signalling of the MSI > to the CPU. > > The only case where we should rely on masking interrupts at the > end-point level is when the MSI controller doesn't provide a method to > do so (hopefully a rare exception). While I would tend to agree, I'm also wary of standardizing on something which isn't what x86 does today :-) You know what happens when we break them... interestingly enough they (like quite a few other drivers) don't even bother trying to mask at the APIC level unless I misread the code. That means that for endpoints that don't support masking, they just get those MSIs and "ignore" them... But I'll look into it, see what the patch looks like. I've also looked at trying to make the "inner domain" more generic but that's looking a tad trickier... not giving up yet though :-) Cheers, Ben.