Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp7240566rwb; Wed, 23 Nov 2022 04:13:07 -0800 (PST) X-Google-Smtp-Source: AA0mqf6kKwAXrBg9XF9qQ0pWz/+c4EabLEfLJSC3J6Ix6eI2Q/FRisHHN21ws2svcm4gUXr+h4uJ X-Received: by 2002:a17:90a:be11:b0:218:c83e:4735 with SMTP id a17-20020a17090abe1100b00218c83e4735mr10112693pjs.9.1669205587746; Wed, 23 Nov 2022 04:13:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669205587; cv=none; d=google.com; s=arc-20160816; b=x+m6vzmHx9He4b5GSM4lznAaReAMVgihee5WeebNctf3d8qDkK6D0Cixc1vjBL0PXj 9ykTFXS4IvydWDijAI1LpnV7OVF9dalBGwePa4Zabmdfz4QwMvEGjhDAS3bex0956SBm Jw7Gx/xCSdeVBvPZnqj2Y5FqJL1T9bC0/mgiT+aF6KXPRK9goFyZxSdy/BAfOmFjvRNg lfABIOsR35s311SJRSt3hLWoKlrpoFHbh1eCPKMpqH27S8eOHgLrnv8hJHde6d9Dsnxa TMaruMwE/bJ+gKaJ3xj3a6PQy24KGcWd3tn7pwOX3bAjmD+WyqTyWIeUFYuUH/gMNCR+ d7Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=373bQ1nq+nl0rYtdJTO5Jt2zlt/TLiciMjBg/gptv3M=; b=e6dG+NYgUO9YMgCkoCiYeI2eq/kiNM9mY707WpyF36xXknSnwjfi72zlzCaqPGnPSL ZoUp5unPQtPfGEVoj8jasaptGNgjyT6aJYkUaUOGtyVUdVtusnPwxBU75I2nDvXzgKVr d+nu+vV4qLr6qrNm082IJiiNDt+YoDiFg9gE30noTr6Lkm8rvzgazlWn2poOWutDeXWm eE0146ZReFMhRGpQQjeKsgqcQVB4xCPCWLYuratUYkEkrVpWU0CCDOtioeH1ZHuc9ule UfgA2Icl/JR38+OaC4krmLqcjPtaftZbkX3LIXJ1SAFuUD4HX8m1U6c55XEV0Vjqh+xk 2GXw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=KpEqNtPq; dkim=neutral (no key) header.i=@linutronix.de header.b=cQlKvLqR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cn15-20020a056a00340f00b00572f208f7basi15142160pfb.149.2022.11.23.04.12.48; Wed, 23 Nov 2022 04:13:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=KpEqNtPq; dkim=neutral (no key) header.i=@linutronix.de header.b=cQlKvLqR; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237440AbiKWLlP (ORCPT + 89 others); Wed, 23 Nov 2022 06:41:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49968 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237411AbiKWLlL (ORCPT ); Wed, 23 Nov 2022 06:41:11 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 70A30109583; Wed, 23 Nov 2022 03:41:07 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669203666; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=373bQ1nq+nl0rYtdJTO5Jt2zlt/TLiciMjBg/gptv3M=; b=KpEqNtPqfiJppK8AvzqtheMaPcoZmN8t/rFv6jjr6hTYoy40ftLFhpimHJ5jw8l6Va6aMw Hj8rFIEBDV55rsgKjpjmn7AIQVUNwC2gbZf1xfpahuw3LOSLh/LJheui3OO1y+1cm92f6x HQIXyX+ew/MZPbmSyWMukFU5yTJnHGzvmeRo4Z3KIKZfQvoGpIuFiGmWGU1jHalUcMt94Q UjDY8OCA77xKJVyyWjMTJG76mp6GpoVYrvAE002YCUD9t6HNkhsIHaymA3SxGTYalj768Y JPVHnOXR9BT/siy0wfNlaD21yUTYXDrgoxQ6VRkYoAyn0ji4clI4WvLn5hj9Hg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669203666; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=373bQ1nq+nl0rYtdJTO5Jt2zlt/TLiciMjBg/gptv3M=; b=cQlKvLqRtjVxKMFF8O3YttItxpSP0whK6NO6CdL/nA66+knkQDkTy9kfdNkswueZtwmlSX vU8ev3zdRcFC1GBQ== To: "Tian, Kevin" , LKML Cc: "x86@kernel.org" , Joerg Roedel , Will Deacon , "linux-pci@vger.kernel.org" , Bjorn Helgaas , Lorenzo Pieralisi , Marc Zyngier , Greg Kroah-Hartman , Jason Gunthorpe , "Jiang, Dave" , Alex Williamson , "Williams, Dan J" , Logan Gunthorpe , "Raj, Ashok" , Jon Mason , Allen Hubbe , "Ahmed S. Darwish" Subject: RE: [patch V2 12/33] PCI/MSI: Add support for per device MSI[X] domains In-Reply-To: References: <20221121083657.157152924@linutronix.de> <20221121091327.163146917@linutronix.de> Date: Wed, 23 Nov 2022 12:41:05 +0100 Message-ID: <87zgchew4u.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS 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 Wed, Nov 23 2022 at 08:08, Kevin Tian wrote: >> From: Thomas Gleixner > > pci_mask_msi() and pci_msi_mask() are confusing. > > Probably pci_irq_mask_msi() given the parameter is irq_data. maybe. >> +bool pci_setup_msi_device_domain(struct pci_dev *pdev) >> +{ >> + if (WARN_ON_ONCE(pdev->msix_enabled)) >> + return false; > > the check already exists in __pci_enable_msi_range() > >> +bool pci_setup_msix_device_domain(struct pci_dev *pdev, unsigned int >> hwsize) >> +{ >> + if (WARN_ON_ONCE(pdev->msix_enabled)) >> + return false; > > ditto. > > btw according to the comment this should check pdev->msi_enabled. Yeah, those are probably redundant. > >> @@ -152,13 +316,33 @@ bool pci_msi_domain_supports(struct pci_ >> { >> struct msi_domain_info *info; >> struct irq_domain *domain; >> + unsigned int supported; >> >> domain = dev_get_msi_domain(&pdev->dev); >> >> if (!domain || !irq_domain_is_hierarchy(domain)) >> return mode == ALLOW_LEGACY; >> - info = domain->host_data; >> - return (info->flags & feature_mask) == feature_mask; >> + >> + if (!irq_domain_is_msi_parent(domain)) { >> + /* >> + * For "global" PCI/MSI interrupt domains the associated >> + * msi_domain_info::flags is the authoritive source of >> + * information. >> + */ >> + info = domain->host_data; >> + supported = info->flags; >> + } else { >> + /* >> + * For MSI parent domains the supported feature set >> + * is avaliable in the parent ops. This makes checks >> + * possible before actually instantiating the >> + * per device domain because the parent is never >> + * expanding the PCI/MSI functionality. >> + */ >> + supported = domain->msi_parent_ops->supported_flags; > > This is general PCI MSI logic. So an open related to my rely to patch02, > is it correct for PCI core to assume that the real parent imposes all the > restrictions and there is no need to further go down the hierarchy? That was my working assumption and it turned out to be correct with both x86 and ARM. Thanks, tglx