Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp526534rwe; Thu, 1 Sep 2022 03:50:32 -0700 (PDT) X-Google-Smtp-Source: AA6agR688hzTy09ih+FR9C3QLfkHDx8aZAV1GJA7Zq74Hss6G20X0IRM5GMEsKzDbWnpM4g//74k X-Received: by 2002:aa7:ca46:0:b0:447:af0a:be68 with SMTP id j6-20020aa7ca46000000b00447af0abe68mr27992178edt.327.1662029432134; Thu, 01 Sep 2022 03:50:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662029432; cv=none; d=google.com; s=arc-20160816; b=QKUkg3PnajETW+/9ELuc7cqJGZtj+F6fJJQlXlncUBzZBAKLUaa5E+pOuoKIrcmDNQ vZCSdzDPpmwKcLmkpm6prN5davdNQ0XEcoq/b2igQF6H4tqhwvKyuLl03qsKWbusj3JI S1qDENoO+W7YPyY/O3qyvKFf7KaxorzxQcAjsyK1ItEPk8dJFyq2iZRFmYmvpGTdpyY1 Ze6cMKkCdIcV46JV9EW0WghUbAZ/z8U0oXoeuJKAhKuNBHZIvlhk1HFY4ngvU2KXgCaC LNNRCCmjTmmCYCDPvte9VgEd+IRl7zpQzPuWdTeMntTE9g7JB+YZJgBeplqA7zC4pD6Z SI2w== 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:subject:cc:to:from:date; bh=ISUExkKUd1QiEisP1ds66BtYi/mAQOwb+qThrnZDn2Q=; b=DCgyrhLa52kw5ve6ShZc/LD+DO5lZ2mOfzekfmTxWoo3XPl/qmp41TL7yStT8K57gr tH0M281Wp7Jzn4t2jWsNrl+SoMIsad+X8tywLSTyFln5zIUDzzz8hrYpc7Mx+yOcuK7O hAPEu9qW1gFblRKL4ZPl81cMyUHJPYBRxrkefMo+6PPTyl4MtXc0ryAeamZ7fzsC27iY xu22XHkra3PjdWrtPfb0yhuiNGwxeSvCzAoY6iE8oCFEm64v2mkSz54vsIMr0STdMFVZ xCqzySI/gVIy2ca1S+pDSaIkSkYl/R7YRJHd3FoSIObspVERXguOimDnjdLSk2LK5bTx ZLZw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pk4-20020a170906d7a400b0072b0303a11asi11255019ejb.955.2022.09.01.03.50.05; Thu, 01 Sep 2022 03:50:32 -0700 (PDT) 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; 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=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233663AbiIAKiF (ORCPT + 99 others); Thu, 1 Sep 2022 06:38:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232418AbiIAKiD (ORCPT ); Thu, 1 Sep 2022 06:38:03 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4EF541299CB; Thu, 1 Sep 2022 03:38:02 -0700 (PDT) Received: from fraeml705-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MJHTc4lJyz688nt; Thu, 1 Sep 2022 18:34:12 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (7.191.163.240) by fraeml705-chm.china.huawei.com (10.206.15.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.31; Thu, 1 Sep 2022 12:37:59 +0200 Received: from localhost (10.202.226.42) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 1 Sep 2022 11:37:59 +0100 Date: Thu, 1 Sep 2022 11:37:57 +0100 From: Jonathan Cameron To: Robert Richter CC: Alison Schofield , Vishal Verma , Ira Weiny , Ben Widawsky , Dan Williams , , , Bjorn Helgaas , "Rafael J. Wysocki" , Len Brown Subject: Re: [PATCH 08/15] cxl/acpi: Check RCH's CXL DVSEC capabilities Message-ID: <20220901113757.00004193@huawei.com> In-Reply-To: References: <20220831081603.3415-1-rrichter@amd.com> <20220831081603.3415-9-rrichter@amd.com> <20220831115224.00003afd@huawei.com> <20220831121222.00000977@huawei.com> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.29; i686-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.202.226.42] X-ClientProxiedBy: lhrpeml100002.china.huawei.com (7.191.160.241) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,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 Thu, 1 Sep 2022 08:38:52 +0200 Robert Richter wrote: > On 31.08.22 12:12:22, Jonathan Cameron wrote: > > > On Wed, 31 Aug 2022 10:15:56 +0200 > > > Robert Richter wrote: > > > > > @@ -322,6 +322,8 @@ struct pci_host_bridge *cxl_find_next_rch(struct pci_host_bridge *host) > > > > { > > > > struct pci_bus *bus = host ? host->bus : NULL; > > > > struct acpi_device *adev; > > > > + struct pci_dev *pdev; > > > > + bool is_restricted_host; > > > > > > > > while ((bus = pci_find_next_bus(bus)) != NULL) { > > > > host = bus ? to_pci_host_bridge(bus->bridge) : NULL; > > > > @@ -343,6 +345,20 @@ struct pci_host_bridge *cxl_find_next_rch(struct pci_host_bridge *host) > > > > dev_dbg(&host->dev, "PCI ACPI host found: %s\n", > > > > acpi_dev_name(adev)); > > > > > > > > + /* Check CXL DVSEC of dev 0 func 0 */ > > > > > > So assumption here is that the hostbridge has a one or more RCiEPs. > > > The spec (r3.0 9.11.4) allows for the EP to appear behind a root port > > > - that case always felt odd to me, so I'm fine with not supporting it until > > > we see a user. > > > > > > > + pdev = pci_get_slot(bus, PCI_DEVFN(0, 0)); > > > > + is_restricted_host = pdev > > > > + && (pci_pcie_type(pdev) == PCI_EXP_TYPE_RC_END) > > > > + && pci_find_dvsec_capability(pdev, > > > > + PCI_DVSEC_VENDOR_ID_CXL, > > > > + CXL_DVSEC_PCIE_DEVICE); > > > > Thinking a bit more on this. I'm not sure this is sufficient. > > Nothing in CXL 2.0 or later prevents true RCiEP devices (there are a > > few references in CXL 3.0 e.g. 9.12.1 has RCDs or CXL RCiEPs - so just > > detecting that there is one on the host bridge might not be sufficient > > to distinguish this from a non RCH / RCB. > > An RCD has its own host bridge created (software view, not the phys > topology). Host and device are paired in this case. Non-RCDs are > standard endpoints and not RCiEPs, they have their own host. I disagree. CXL spec does not exclude the possibility of real CXL RCiEPs. So a CXL 2.0+ device that talks CXL configuration for some reason but is part of the root complex itself (maybe a chiplet or something where there isn't necessarily a real CXL bus involved). Same reason we have RCiEPs in normal PCIe. Chasing references - there is only one I can find (CXL r3.0 9.12.1) "If a Host bridge is not associated with RCDs or CXL RCiEPs." Both listed because they are different things. (I think it's fine to say here that this has been queried in appropriate place in the past and is something that is allowed). So I still don't think the above check is sufficient'. If you happen to have just one CXL 2.0+ RCiEP on a host bridge with not root ports, then the check will identify it as a restriced host. Maybe I'm missing another check that wouldn't though.... > There > cannot be both types connected to the same host. > > Again, see figure 9-12 and 9-13. Examples - don't show all the crazy things people are allowed to build - you would need an awful lot of diagrams to do that. > > -Robert > > > > > > > + pci_dev_put(pdev); > > > > + > > > > + if (!is_restricted_host) > > > > + continue; > > > > + > > > > + dev_dbg(&host->dev, "CXL restricted host found\n"); > > > > + > > > > return host; > > > > } > > > > > > > > @@ -354,6 +370,7 @@ static int __init cxl_restricted_host_probe(struct platform_device *pdev) > > > > struct pci_host_bridge *host = NULL; > > > > > > > > while ((host = cxl_find_next_rch(host)) != NULL) { > > > > + dev_info(&host->dev, "host supports CXL\n"); > > > > } > > > > > > > > return 0; > > > > >