Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1938594pxb; Thu, 4 Nov 2021 11:05:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxJKtt00L91/72arv4iCKzieu4pc3PnEuLZcO6F5qMbroHmKpEHOFUDwhuF8GrpF7Vbo37k X-Received: by 2002:a17:906:8145:: with SMTP id z5mr14363150ejw.519.1636049148365; Thu, 04 Nov 2021 11:05:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636049148; cv=none; d=google.com; s=arc-20160816; b=UeNYJ4K9mTaCKU9xz/FkOsmSs3RJhPeu9Vamw4XwMwH7e1gZgYqo3FW78e8IHvDXz9 u4w2xL6eQy1h+9zxu7fMay+fZiTXRWors5GT8hzWEBI0gTUlSpuP8R2S6m9X+Euqvzko 8mjxQrwEH5dIsoZk4wZHAlfNjlMyEUF5aykaJKnNkUXXIV+ThSKL4LK5nOUofYRHsEuH I9jLb4SlS2tAy01dBfuWfUq0vGr1n6obvsaKLddNg61vMyD2XJT2c0MF1pXZg8Nci5Em xCspBCDMMS7QzT3nhPhy6afWxTcBsoolmS98shSNuZaLVe6jNu+GGOZSjbeHUsNHl+pl WP8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=RKOwkD/v71OyVWOSPHLOXp+HTpdNdUt8FzmDRYBrSso=; b=VkLeRRjOFM9n87G+MzZy/3RL2GocmWBQ52+HnjK8lFtCjloLgM+8vvF3R+ArhZ0bY6 eNDLxPYRT9j3nqdL6aGZjl9EHW/oO9PFM6NumW//09W0ln8DTXBbwzLNerMjh+vZzQn0 eLiO7Rv/Fe2VwcJKomDVlE1E9VmRbHnhEQvrgfj1n8cW8HZW6T85cRx/FJmTw3eN1m8r 4HoblIAZFZRDsTKJt+MeXnkvhNPmO8ArF2zjcVheyymRrzPzOyJaKkuNdwY/LOzyokXS AFsenZ/Hp1wiyIuF/96nz1nwF2mU41JPI7cEwdj9gF8CeBy/DKx0uYvN2IpPvHNAKSDj 9vWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ds3si12795749ejc.113.2021.11.04.11.04.51; Thu, 04 Nov 2021 11:05:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234058AbhKDSEQ (ORCPT + 99 others); Thu, 4 Nov 2021 14:04:16 -0400 Received: from mail.kernel.org ([198.145.29.99]:54210 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234010AbhKDSEO (ORCPT ); Thu, 4 Nov 2021 14:04:14 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id AF0FF611EF; Thu, 4 Nov 2021 18:01:36 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.lan) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mih3O-003WTf-Vg; Thu, 04 Nov 2021 18:01:35 +0000 From: Marc Zyngier To: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Bjorn Helgaas , Thomas Gleixner , Rui Salvaterra , kernel-team@android.com Subject: [PATCH 1/2] PCI: MSI: Deal with devices lying about their MSI mask capability Date: Thu, 4 Nov 2021 18:01:29 +0000 Message-Id: <20211104180130.3825416-2-maz@kernel.org> X-Mailer: git-send-email 2.30.2 In-Reply-To: <20211104180130.3825416-1-maz@kernel.org> References: <20211104180130.3825416-1-maz@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, bhelgaas@google.com, tglx@linutronix.de, rsalvaterra@gmail.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org It appears that some devices are lying about their mask capability, pretending that they don't have it, while they actually do. The net result is that now that we don't enable MSIs on such endpoint. Add a new per-device flag to deal with this. Further patches will make use of it, sadly. Signed-off-by: Marc Zyngier --- drivers/pci/msi.c | 3 +++ include/linux/pci.h | 2 ++ 2 files changed, 5 insertions(+) diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c index 0099a00af361..2f9ec7210991 100644 --- a/drivers/pci/msi.c +++ b/drivers/pci/msi.c @@ -479,6 +479,9 @@ msi_setup_entry(struct pci_dev *dev, int nvec, struct irq_affinity *affd) goto out; pci_read_config_word(dev, dev->msi_cap + PCI_MSI_FLAGS, &control); + /* Lies, damned lies, and MSIs */ + if (dev->dev_flags & PCI_DEV_FLAGS_HAS_MSI_MASKING) + control |= PCI_MSI_FLAGS_MASKBIT; entry->msi_attrib.is_msix = 0; entry->msi_attrib.is_64 = !!(control & PCI_MSI_FLAGS_64BIT); diff --git a/include/linux/pci.h b/include/linux/pci.h index cd8aa6fce204..152a4d74f87f 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -233,6 +233,8 @@ enum pci_dev_flags { PCI_DEV_FLAGS_NO_FLR_RESET = (__force pci_dev_flags_t) (1 << 10), /* Don't use Relaxed Ordering for TLPs directed at this device */ PCI_DEV_FLAGS_NO_RELAXED_ORDERING = (__force pci_dev_flags_t) (1 << 11), + /* Device does honor MSI masking despite saying otherwise */ + PCI_DEV_FLAGS_HAS_MSI_MASKING = (__force pci_dev_flags_t) (1 << 12), }; enum pci_irq_reroute_variant { -- 2.30.2