Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1598271pxb; Tue, 8 Feb 2022 23:37:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJwqWTyQRQOK3Nzvo46hu2iSG1eqM3y6pUljD0Nr694SZ0fP9QIe3369UZVPEM0L5545Q1Wb X-Received: by 2002:a17:902:b683:: with SMTP id c3mr916141pls.144.1644392246448; Tue, 08 Feb 2022 23:37:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644392246; cv=none; d=google.com; s=arc-20160816; b=sR1/X4IFBJV7i2+u0/MHj/k6KN9pNZGpDVVPu1kuFsYva2O03lPlWOQgApk9aX46lV BAENDL4+iy4vkj0ZkleyHhMHJ5kmpnfqm2xtm8oDdxQShexDzXR9W/nchJGgf1zFY5RF Ixxnjo9FrDspcfO4kH3b2Js8xT60sr7nMEz+OQ8CdxAR6pMOUZBBHgkXy35t4W4HvfJg TXu5uYo/kzM3BWuOLOC1+VgVYgxzOLWVGGJPJSfd9pKMCipvh8gvLzZ+N3QhsPWAhIbY CfbjMykYO2aY5qg/4pntBaI6FqO6keh/TzBQZVd9sX9cTQQB+agg/VH4Kym9H0nDkm4j qzWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :message-id:subject:cc:to:from:date:dkim-signature; bh=L2xzHDt9qHTN6Zzr2dwCIH6ckuRMFFDMFu9pPgEHaz4=; b=jeIO14dLVAtI+Ttxdj7w2Nec6Juemqd1cKyHcmaR7BL5wXfQ/6iiPYMTsm12P5QDpQ ntW1TDGn86beYCmikwL4NeNeVRzwJkMYh4+SwRknxHCJbtz9Cb4GB9tpB3W3jaSQpijH KMeS7yOMqnvSSrO/T0UYrS882pTKySmepIQk8XTWzD1842xAc4dyqpmwnjRA9iNM6uWK 4g+hNc5Op96osfM04mzad7/RIc/jUCTz/CGTRfLniIRvirZ2K4Vsuze/jzAj0+qR3OFp ZRqjYV1HanxFqXNNTtXBd94iHZFHk0BY2jxkxrLjcndFPJiX1NBjdAd7KZ/n+xquKap2 45zw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sIIeoPL8; 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 l13si3976586pls.127.2022.02.08.23.37.13; Tue, 08 Feb 2022 23:37:26 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=sIIeoPL8; 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 S242151AbiBGRqG (ORCPT + 99 others); Mon, 7 Feb 2022 12:46:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1384311AbiBGRgy (ORCPT ); Mon, 7 Feb 2022 12:36:54 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33FB7C0401D5; Mon, 7 Feb 2022 09:36:53 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id E5717B815C6; Mon, 7 Feb 2022 17:36:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51C3CC004E1; Mon, 7 Feb 2022 17:36:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1644255410; bh=/7YN1m76qf4snYDMVXR15LGTPvRjVN/AzA2qo6qhVtI=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=sIIeoPL8OANAhj44U1X2u3zQNXXTY1oNGPK1fQdVT33tNkvktg0GpxHLyNj3K0x0Y wtLfKFRIAPZAXgk6+w5ADLpkcGocrbN7xLd3pMhnGVkDs7MLXNgdzQHEBb+dHjMOCA lPu5UbwA4JkRzAAZglw0pPUuwOTIVReV56CBlvm1GdMxqXbvCjeYYGxm1aKC3/xnlE LVAsPetTzl99KaBACPC+Q4vhd2QS7IScea5Vt041eaunVaLh9tAUgXN4J26/cEi2V1 gqn18+3Cut7ljOd6vFbBscsv+wvwpDnmq2ODyZpbafGo39RxgCSfqrEsbZ3+4IsH09 yhC3Bq8NCI8wg== Date: Mon, 7 Feb 2022 11:36:48 -0600 From: Bjorn Helgaas To: Vidya Sagar Cc: bhelgaas@google.com, lorenzo.pieralisi@arm.com, robh+dt@kernel.org, thierry.reding@gmail.com, jonathanh@nvidia.com, kishon@ti.com, vkoul@kernel.org, kw@linux.com, krzysztof.kozlowski@canonical.com, p.zabel@pengutronix.de, mperttunen@nvidia.com, linux-pci@vger.kernel.org, devicetree@vger.kernel.org, linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, kthota@nvidia.com, mmaddireddy@nvidia.com, sagar.tv@gmail.com Subject: Re: [PATCH V1 09/10] PCI: Disable MSI for Tegra234 root ports Message-ID: <20220207173648.GA402391@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220205162144.30240-10-vidyas@nvidia.com> X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 05, 2022 at 09:51:43PM +0530, Vidya Sagar wrote: > Tegra234 PCIe rootports don't generate MSI interrupts for PME and AER > events. Since PCIe spec (Ref: r4.0 sec 7.7.1.2 and 7.7.2.2) doesn't support > using a mix of INTx and MSI/MSI-X, MSI needs to be disabled to avoid root > ports service drivers registering their respective ISRs with MSI interrupt > and to let only INTx be used for all events. s/rootports/root ports/ to match other usage here. This argument matches that in 8c7e96d3fe75 ("PCI: Disable MSI for Tegra root ports") [1], but that's not quite what sec 7.7.1.2 and 7.7.2.2 say. Those sections talk about what happens when both MSI and MSI-X are disabled: If MSI and MSI-X are both disabled, the Function requests servicing using INTx interrupts (if supported). but they don't say anything about what happens when MSI or MSI-X is *enabled*. I think a better citation is PCIe r6.0, sec 6.1.4.3, which says: While enabled for MSI or MSI-X operation, a Function is prohibited from using INTx interrupts (if implemented) to request service (MSI, MSI-X, and INTx are mutually exclusive). Can you please update the comment in the code and this commit log to cite PCIe r6.0, sec 6.1.4.3 instead, and to clarify that these Tegra devices always use INTx for PME and AER, even when MSI/MSI-X is enabled? Why do these Tegra quirks use DECLARE_PCI_FIXUP_CLASS_EARLY() instead of just DECLARE_PCI_FIXUP_EARLY()? quirk_al_msi_disable() uses the _CLASS version because the same Device ID is used for non-Root Port devices. Is the same true here, or could these use DECLARE_PCI_FIXUP_EARLY()? There are many quirks that disable MSI, and they're a mixture of EARLY and FINAL. They should probably all be the same. [1] https://git.kernel.org/linus/8c7e96d3fe75 > Signed-off-by: Vidya Sagar > --- > drivers/pci/quirks.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > index d2dd6a6cda60..3ac5c45e61a1 100644 > --- a/drivers/pci/quirks.c > +++ b/drivers/pci/quirks.c > @@ -2747,6 +2747,15 @@ DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_NVIDIA, 0x10e5, > DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_NVIDIA, 0x10e6, > PCI_CLASS_BRIDGE_PCI, 8, > pci_quirk_nvidia_tegra_disable_rp_msi); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_NVIDIA, 0x229a, > + PCI_CLASS_BRIDGE_PCI, 8, > + pci_quirk_nvidia_tegra_disable_rp_msi); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_NVIDIA, 0x229c, > + PCI_CLASS_BRIDGE_PCI, 8, > + pci_quirk_nvidia_tegra_disable_rp_msi); > +DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_NVIDIA, 0x229e, > + PCI_CLASS_BRIDGE_PCI, 8, > + pci_quirk_nvidia_tegra_disable_rp_msi); > > /* > * Some versions of the MCP55 bridge from Nvidia have a legacy IRQ routing > -- > 2.17.1 >