From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58F22C77B7A for ; Tue, 16 May 2023 20:58:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229799AbjEPU6u (ORCPT ); Tue, 16 May 2023 16:58:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229486AbjEPU6t (ORCPT ); Tue, 16 May 2023 16:58:49 -0400 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7F82F59E0 for ; Tue, 16 May 2023 13:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684270728; x=1715806728; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=qcCj7ZrpIS1Jwyt4yRAR5ZxlQrDY5ZwBVFpdnJb8v8o=; b=YL629auUb86PjeFNsS1g/lZZH+6Kmfr1McuOTbbxWmUNxX2fh4pC6QOw iXLwGWd04yOiBr6fCpY4Cujf6V0qGViIT5nkBzldPn6RvO7OG6R+KLwAk 3gKbLvrUKtUNbOeNxQ4rvlhCTdax5NrHIDAwtiu/xFCyc+E4tiPUHMUFi id2p9NvFJ82O+HnrhltxnJVd1J2DUMKuLI07xCMo3/A7Nq0naNeTeIXgX t+M5ZwrdtMNXXNUtUgLQhKYcEArjnwj9odNAMe4kvuqX6Y4Dd7SfvLF0W kKTbAmzvvD6ZqsF7gHt41ctXeNH+gJfSWWwY7xtCm6RnmNwiP9mPzPIC+ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="349092204" X-IronPort-AV: E=Sophos;i="5.99,278,1677571200"; d="scan'208";a="349092204" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 13:58:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10712"; a="766505108" X-IronPort-AV: E=Sophos;i="5.99,278,1677571200"; d="scan'208";a="766505108" Received: from djiang5-mobl3.amr.corp.intel.com (HELO [10.212.5.122]) ([10.212.5.122]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 May 2023 13:58:47 -0700 Message-ID: <4f398988-e5fa-cbc8-f73a-bfefaf89e252@intel.com> Date: Tue, 16 May 2023 13:58:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.10.0 Subject: Re: [PATCH v5 06/14] cxl: Store the access coordinates for the generic ports Content-Language: en-US To: Jonathan Cameron Cc: linux-cxl@vger.kernel.org, dan.j.williams@intel.com, ira.weiny@intel.com, vishal.l.verma@intel.com, alison.schofield@intel.com References: <168357873843.2756219.5839806150467356492.stgit@djiang5-mobl3> <168357884996.2756219.11067819935569345137.stgit@djiang5-mobl3> <20230512155957.00000c2f@Huawei.com> From: Dave Jiang In-Reply-To: <20230512155957.00000c2f@Huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-cxl@vger.kernel.org On 5/12/23 7:59 AM, Jonathan Cameron wrote: > On Mon, 08 May 2023 13:47:29 -0700 > Dave Jiang wrote: > >> Each CXL host bridge is represented by an ACPI0016 device. A generic port >> device handle that is an ACPI device is represented by a string of >> ACPI0016 device HID and UID. Create a device handle from the ACPI device >> and retrieve the access coordinates from the stored memory targets. The >> access coordinates are stored under the cxl_dport that is associated with >> the CXL host bridge. >> >> Signed-off-by: Dave Jiang >> --- >> drivers/cxl/acpi.c | 28 ++++++++++++++++++++++++++++ >> drivers/cxl/cxl.h | 2 ++ >> 2 files changed, 30 insertions(+) >> >> diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c >> index f9b35e8fe810..675a4f423f4b 100644 >> --- a/drivers/cxl/acpi.c >> +++ b/drivers/cxl/acpi.c >> @@ -537,8 +537,26 @@ static int cxl_get_chbcr(union acpi_subtable_headers *header, void *arg, >> return 0; >> } >> >> +static int get_genport_coordinates(struct device *dev, struct cxl_dport *dport) >> +{ >> + struct acpi_device *hb = to_cxl_host_bridge(NULL, dev); >> + u8 handle[ACPI_SRAT_DEVICE_HANDLE_SIZE] = { 0 }; >> + int rc; >> + >> + /* ACPI spec 6.5 tABLE 5.65 */ > > tABLE? ooops caps lock > >> + memcpy(handle, acpi_device_hid(hb), 8); >> + memcpy(&handle[8], acpi_device_uid(hb), 4); >> + >> + rc = acpi_get_genport_coordinates(handle, dport->genport_coord); >> + if (rc) >> + return rc; >> + >> + return 0; >> +} >> + >> static int add_host_bridge_dport(struct device *match, void *arg) >> { >> + int ret; >> acpi_status rc; >> struct device *bridge; >> unsigned long long uid; >> @@ -594,6 +612,16 @@ static int add_host_bridge_dport(struct device *match, void *arg) >> if (IS_ERR(dport)) >> return PTR_ERR(dport); >> >> + dport->genport_coord = devm_kzalloc(dport->dport, >> + sizeof(*dport->genport_coord), >> + GFP_KERNEL); > > It's pretty small - worth allocating separately? > > Maybe add something on why to the patch description if there is another reason > for this dance. My intention was to allow detection of whether the data exists or not based on if the ptr is NULL. I'll add explanation in patch description. > >> + if (!dport->genport_coord) >> + return -ENOMEM; >> + >> + ret = get_genport_coordinates(match, dport); >> + if (ret) >> + dev_dbg(match, "Failed to get generic port perf coordinates.\n"); >> + >> return 0; >> } >> >> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h >> index c1e2c3703a63..033b822a20f2 100644 >> --- a/drivers/cxl/cxl.h >> +++ b/drivers/cxl/cxl.h >> @@ -626,6 +626,7 @@ cxl_find_dport_by_dev(struct cxl_port *port, const struct device *dport_dev) >> * @rcrb: base address for the Root Complex Register Block >> * @rch: Indicate whether this dport was enumerated in RCH or VH mode >> * @port: reference to cxl_port that contains this downstream port >> + * @genport_coord: access coordinates (performance) from ACPI generic port >> * @coord: access coordinates (performance) for switch from CDAT >> * @link_latency: calculated PCIe downstream latency >> */ >> @@ -636,6 +637,7 @@ struct cxl_dport { >> resource_size_t rcrb; >> bool rch; >> struct cxl_port *port; >> + struct access_coordinate *genport_coord; >> struct access_coordinate coord; >> long link_latency; >> }; >> >> >