Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3938749pxj; Tue, 15 Jun 2021 11:50:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxLGO6oNfwgFpIV4Tj5fnCnFmtG8uo0dPZmcBGKU2+tVYBmSmHJqEWB3BM6+fbNw+zK3Ubn X-Received: by 2002:a05:6e02:11b1:: with SMTP id 17mr598782ilj.225.1623783049091; Tue, 15 Jun 2021 11:50:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623783049; cv=none; d=google.com; s=arc-20160816; b=AAGzu2Fw3cQH7NMiu0hCIyDu9TiLlGyMrFwDJ4kcg3kURMspOeNTR4wXMuyku7D/VF Mcjney8sZf2UMEGPf/PYARh5Gy4Y+70fi3cu+q4OZn5isWUPH/NZCeepMB0rDHSIysLX DJ4/suagmTIoj9Ur+2JVYojSbRDoSHjqA4J+RFpYvwjxLmvRj0vflouz7fewNiuvTZ7i 9zrM12XB3YA9O5RNM4qx6EByP2zpP+HButvN3F4PPm87H7w8ZMTQxbHF3e+hfze+Vt9m cjclkKF56mileVEdxkXnFcHVNS0CqWd0fyIw5F+MJyH+yWp1GRXzTc4aATR4/Scc5vYp bIwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=0JM4+VLgeYRBpYPu+DbbsTsMP4gd2M6j0wYVzMmmmqc=; b=zHXtvwblX73sPSaD+auz+PcGp6DDjUJReLrRE/Xpt6qgJitYSr4V13/pBGsTowp5Ui 9N4X2lxnSLjz2F2UPvvgFEjL3sLnH5GPvJT9VOKT94RiUImxLRGGNJzIgFUWuhJzk6RI wMYeJzsgOWNAHv1glSj3BJzHFgK/Z32AIQSRpg59+Ee6V23b10k1rpzSSMirZg/p4F+T nVpS7bp0e6IiJ0bdzldTrSIzQT9qF4hp9w2SQGe3J8hZRtiwFmX3D98kNFynOzJIxQMV cc7woI/KX9ZncllPb52oCcrKc656wfvqKyPon/SzvJ6TEs3McyvzMHagoWlihPAfgpBq v3tQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=CSPS9dQl; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f15si5013681ila.89.2021.06.15.11.50.36; Tue, 15 Jun 2021 11:50:49 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=CSPS9dQl; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231218AbhFOSvA (ORCPT + 99 others); Tue, 15 Jun 2021 14:51:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42686 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230387AbhFOSu7 (ORCPT ); Tue, 15 Jun 2021 14:50:59 -0400 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C85C3C06175F for ; Tue, 15 Jun 2021 11:48:54 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id q25so135301pfh.7 for ; Tue, 15 Jun 2021 11:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0JM4+VLgeYRBpYPu+DbbsTsMP4gd2M6j0wYVzMmmmqc=; b=CSPS9dQljg7NwD37B6BvNQO/fek6+ZCZqpqvB/2NgoHreGc9IxF807VzPPjNsTTMZ1 MkcCeOQCkoZpZAEW4Kt2CyXmURSyk7htgofRr/2TMGzCxO2Z5x4qevLGIoLsKA4eXGWM jyC5Vx7fOAMRhxYTlRySNa4VVkktWQZteqN6YzO1cn83NMDPWGLvND92FWPvLk8W7dz2 7YDHQPch9tLmUjyeLxEDs6blnVi7WlDqH0ryS6XVdi/+MGdFfNOa6N+xD0xSOllPtzeM D7N+lUOwTUNhcq6CPMD52wILETPrB/h15+ULmur/W5UYROHJtvBz/qoU7kkuzTb9xIYN 9ODg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0JM4+VLgeYRBpYPu+DbbsTsMP4gd2M6j0wYVzMmmmqc=; b=EukgUBT0bzS83dCdDvjBCxaw43Osvx7/8T1vQq4NdKsM3Be/XFl0NY0vanvTkfAv/N qAa+TR4yl7JsbOHLBi3qrcdiKJxh7aS4c1iaAjby5z3n6KllsobZB9KBRZ8XHiTyoMv7 ZJUX5DwnFHTehdrTgFZEvLZNEZQ/roGZV8lYMTf3hdxf1r0SBv/eOdQyog9ydcXVNfOL 1TJ1aNIuRCGv16i+mD2fl/YZx8Bwx8iTS0dSflTLmDcUkS2Jh3Jaf/j2dSMhpQtn6dox tOe+T+qwYr0fuB03/HqEEPWf9Z+2ArAGVZYLT7MVpUqmVcKL1VTV03rE1rHc/vSIZ5BR ZxtA== X-Gm-Message-State: AOAM530b1DbktMiPIkECdsJnUExHlW50WeGaYfHld1ugbDfoEknehqov q2ApRvMder2xnwYvH5qW0lLfVCu8QukX4aRot7JSGg== X-Received: by 2002:a62:8647:0:b029:2c4:b8d6:843 with SMTP id x68-20020a6286470000b02902c4b8d60843mr5627105pfd.71.1623782934196; Tue, 15 Jun 2021 11:48:54 -0700 (PDT) MIME-Version: 1.0 References: <0246fe923945ba2b8d885f45279d7d3956c46950.1623705308.git.alison.schofield@intel.com> In-Reply-To: <0246fe923945ba2b8d885f45279d7d3956c46950.1623705308.git.alison.schofield@intel.com> From: Dan Williams Date: Tue, 15 Jun 2021 11:48:43 -0700 Message-ID: Subject: Re: [PATCH 2/2] cxl/acpi: Use the ACPI CFMWS to create static decoder objects To: Alison Schofield Cc: Ben Widawsky , Ira Weiny , Vishal Verma , linux-cxl@vger.kernel.org, Linux Kernel Mailing List , Linux ACPI Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [ add linu-acpi for variable length array question below ] On Mon, Jun 14, 2021 at 3:57 PM Alison Schofield wrote: > > The ACPI CXL Early Discovery Table (CEDT) includes a list of CXL memory > resources in CXL Fixed Memory Window Structures (CFMWS). Retrieve each > CFMWS in the CEDT and add a cxl_decoder object to the root port (root0) > for each memory resource. > > Signed-off-by: Alison Schofield > --- > drivers/cxl/acpi.c | 106 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 106 insertions(+) > > diff --git a/drivers/cxl/acpi.c b/drivers/cxl/acpi.c > index 16f60bc6801f..ac4b3e37e294 100644 > --- a/drivers/cxl/acpi.c > +++ b/drivers/cxl/acpi.c > @@ -8,8 +8,112 @@ > #include > #include "cxl.h" > > +/* Encode defined in CXL 2.0 8.2.5.12.7 HDM Decoder Control Register */ > +#define CFMWS_INTERLEAVE_WAYS(x) (1 << (x)->interleave_ways) > +#define CFMWS_INTERLEAVE_GRANULARITY(x) ((x)->granularity + 8) > + > +/* > + * CFMWS Restrictions mapped to CXL Decoder Flags > + * Restrictions defined in CXL 2.0 ECN CEDT CFMWS > + * Decoder Flags defined in CXL 2.0 8.2.5.12.7 HDM Decoder Control Register > + */ > +#define CFMWS_TO_DECODE_TYPE2(x) ((x & ACPI_CEDT_CFMWS_RESTRICT_TYPE2) << 2) > +#define CFMWS_TO_DECODE_TYPE3(x) ((x & ACPI_CEDT_CFMWS_RESTRICT_TYPE3) << 2) > +#define CFMWS_TO_DECODE_RAM(x) ((x & ACPI_CEDT_CFMWS_RESTRICT_VOLATILE) >> 2) > +#define CFMWS_TO_DECODE_PMEM(x) ((x & ACPI_CEDT_CFMWS_RESTRICT_PMEM) >> 2) > +#define CFMWS_TO_DECODE_FIXED(x) (x & ACPI_CEDT_CFMWS_RESTRICT_FIXED) > + > +#define CFMWS_TO_DECODER_FLAGS(x) (CFMWS_TO_DECODE_TYPE2(x) | \ > + CFMWS_TO_DECODE_TYPE3(x) | \ > + CFMWS_TO_DECODE_RAM(x) | \ > + CFMWS_TO_DECODE_PMEM(x) | \ > + CFMWS_TO_DECODE_FIXED(x)) I don't understand the approach taken above. It seems to assume that the CXL_DECODER_F_* values are fixed. Those flag values are arbitrary and mutable. There is no guarantee that today's CXL_DECODER_F_* values match tomorrow's so I'd rather not have 2 places to check when / if that happens. > + > static struct acpi_table_header *cedt_table; > > +static int cxl_acpi_cfmws_verify(struct device *dev, > + struct acpi_cedt_cfmws *cfmws) > +{ > + int expected_len; > + > + if (cfmws->interleave_arithmetic != ACPI_CEDT_CFMWS_ARITHMETIC_MODULO) { > + dev_err(dev, "CFMWS Unsupported Interleave Arithmetic\n"); I expect the user will want to know more about which decode range is not being registered. So, for all of these error messages please print out the entry, at least the base and end address. > + return -EINVAL; > + } > + > + if (!IS_ALIGNED(cfmws->base_hpa, SZ_256M)) { > + dev_err(dev, "CFMWS Base HPA not 256MB aligned\n"); > + return -EINVAL; > + } > + > + if (!IS_ALIGNED(cfmws->window_size, SZ_256M)) { > + dev_err(dev, "CFMWS Window Size not 256MB aligned\n"); > + return -EINVAL; > + } > + > + expected_len = struct_size((cfmws), interleave_targets, > + CFMWS_INTERLEAVE_WAYS(cfmws)); Oh interesting, I was about to say "unfortunately struct_size() can't be used", becuase I thought ACPICA could not support variable length array. It turns out 'struct acpi_cedt_cfmws' got away with this. Not sure if that is going to change in the future, but it's a positive sign otherwise. > + > + if (expected_len != cfmws->header.length) { > + dev_err(dev, "CFMWS interleave ways and targets mismatch\n"); > + return -EINVAL; > + } > + > + return 0; > +} > + > +static void cxl_add_cfmws_decoders(struct device *dev, > + struct cxl_port *root_port) > +{ > + struct acpi_cedt_cfmws *cfmws; > + struct cxl_decoder *cxld; > + acpi_size len, cur = 0; > + void *cedt_base; > + int rc; > + > + len = cedt_table->length - sizeof(*cedt_table); > + cedt_base = cedt_table + 1; > + > + while (cur < len) { > + struct acpi_cedt_header *c = cedt_base + cur; > + > + if (c->type != ACPI_CEDT_TYPE_CFMWS) { > + cur += c->length; > + continue; > + } > + > + cfmws = cedt_base + cur; > + > + if (cfmws->header.length < sizeof(*cfmws)) { > + dev_err(dev, "Invalid CFMWS header length %u\n", > + cfmws->header.length); > + dev_err(dev, "Failed to add decoders\n"); > + return; > + } > + > + rc = cxl_acpi_cfmws_verify(dev, cfmws); > + if (rc) { > + cur += c->length; > + continue; > + } > + > + cxld = devm_cxl_add_decoder(dev, root_port, > + CFMWS_INTERLEAVE_WAYS(cfmws), > + cfmws->base_hpa, cfmws->window_size, > + CFMWS_INTERLEAVE_WAYS(cfmws), > + CFMWS_INTERLEAVE_GRANULARITY(cfmws), > + CXL_DECODER_EXPANDER, > + CFMWS_TO_DECODER_FLAGS(cfmws->restrictions)); > + > + if (IS_ERR(cxld)) > + dev_err(dev, "Failed to add decoder\n"); This would be another place to print out the CFMWS entry so that the user has some record of which address range is offline. > + else > + dev_dbg(dev, "add: %s\n", dev_name(&cxld->dev)); > + > + cur += c->length; > + } > +} > + > static struct acpi_cedt_chbs *cxl_acpi_match_chbs(struct device *dev, u32 uid) > { > struct acpi_cedt_chbs *chbs, *chbs_match = NULL; > @@ -251,6 +355,8 @@ static int cxl_acpi_probe(struct platform_device *pdev) > if (rc) > goto out; > > + cxl_add_cfmws_decoders(host, root_port); > + > /* > * Root level scanned with host-bridge as dports, now scan host-bridges > * for their role as CXL uports to their CXL-capable PCIe Root Ports. > -- > 2.26.2 >