Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp4078202pxj; Tue, 15 Jun 2021 15:05:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyzKZpOHI+NpqpXaVetK3hQWvqWsx0sb8mYegSgzKrFgnaTtKU3QgXW9uHGVbeG555S7eua X-Received: by 2002:a17:907:a8f:: with SMTP id by15mr1730250ejc.91.1623794711867; Tue, 15 Jun 2021 15:05:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1623794711; cv=none; d=google.com; s=arc-20160816; b=YW+CgmjgalKV4AX+hS6WkzHZ/ltHxKf6Pcu7RoCMDHAUCOzLNVnLoSgbkbTvopcmzH wOs56ddTf1ID1pntCSPOnDR4KP4370/2TDE2QR3e1BckgjyW4J25B/U8DP9dMea38aVB 3o13Vw1V++faWAnjVaKqGKx5xdjFQMW9xdHT1jcA6tNP5SO/YoHqTfWGxqJZAYUhDjT3 2e7ook8yzIDfW86/qEQQ9KysPPLazwqmIp5sXEmDNtH/I5V+Ntdywzuy4qVhQraweTv+ 2b93B3FQ+9kWpuG9kdzDAovoDPuc1xeiB/UvQ6/g+8Tpq7oTCsusyZIwBmkrsUk1v50f LHrg== 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=JAW0zh0lnrneDmrUJXzBCI0coVLuVRYrnPiW+I/zDg8=; b=GyhfDAiENvvrNtkqbpvIq5rVdEbm0Sha+t/NcrQeRqtN15rRVYyJLYIlSUiec0weba XOuCaBL4zIf7xHZNCA18r//1f+09uLe/3DFiHvRFa2eFtGVxQfqr8277I3tEP5Q+JgYe s06ZktlMvuzhWz8aUkHwHNbTypsLfNKNim2eJi/CqSFYENTiAhWW3ptRpPyyfm1qnudy tN1f6VhM7YDGn9BMJSsakUOIo7c2Ch6NZ5DksTdb0udYK2GhS/Br+hoynKdzlcWqsSJt NwfVR4CXsDg2hPFNVITQ0uHFx71Q/p8gxxvaVPPIjwfwRp7uL5Teh0YlTAOz7XH9LrIG pQZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=dUCqcuVG; 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 hy11si218180ejc.162.2021.06.15.15.04.38; Tue, 15 Jun 2021 15:05:11 -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=dUCqcuVG; 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 S230321AbhFOWDW (ORCPT + 99 others); Tue, 15 Jun 2021 18:03:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57358 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230039AbhFOWDW (ORCPT ); Tue, 15 Jun 2021 18:03:22 -0400 Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 285D2C06175F for ; Tue, 15 Jun 2021 15:01:17 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id v13so55120ple.9 for ; Tue, 15 Jun 2021 15:01:17 -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=JAW0zh0lnrneDmrUJXzBCI0coVLuVRYrnPiW+I/zDg8=; b=dUCqcuVG9dMBPasm8laBVdwM1G4BkryuVauvy6BFE6SqaWlfBSH0CxTSBQGVGaZcX+ /rEday4Tyl8dGM2Dd/hedSpI/A+jd/Lv8lj4BLZjwXj1VgxBYhgkbvJRwhwZguZ/g1tQ IRmCRxBsqoprSSOjzBLpx++MdTDnvqpivoMb6LGOSS6aFndQGU18O9IyRstFPRTfr86D b4DMTMdUUyssRjdK+qQpNiE1xBVWa0Y+DEE1fhCLf7/6G3pLMh8URjWSIVCIHBEEnTrx bsaCJck5RYJ74jw8qK3Qb1LW8bZtQnvG6iH7IRM18qq6n4htUgORN/X4BFFO063YApke 7BVw== 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=JAW0zh0lnrneDmrUJXzBCI0coVLuVRYrnPiW+I/zDg8=; b=GP0kcxb2mdys4lDU57IcmBkySkK+1pjtGAd3ERFhIate0B4ee4E3yQoTlIUHSfK7Vi dRftc7OMNZclT1lh72XP1aD5bg+7+Lq0no550tNB1Nfv1twbV+Y8jkLn7W/cJLj6y8+i 3fMMlfgfVmwYNdne7Mcjeusu7S63c5N8c7+YlBY14+3PkAzTWbxNLRzj16FoI55KzW99 1IfypdJhQQJUTNFwiMb8x+2WOApv5JWqM8VEaWRqBBbHJ+N6Qg0lNuCN37YnHEN4Kubt 0e+uYYjLPTSQHYA5ghb/ugrJmGsM+qJfi5WwRZrDDQhRE4mQvrTQok8uDTgr6DwwlUpS 7KUg== X-Gm-Message-State: AOAM531hjBvBcTiboNHHSMmb4qhEZZoe4bvQ/DKRPakGllgRW+gZqAa8 UKCF5WS6aYzh954I583+dhnDhD8VUVyKzRXS8fRU9w== X-Received: by 2002:a17:90a:fc88:: with SMTP id ci8mr7230964pjb.13.1623794476682; Tue, 15 Jun 2021 15:01:16 -0700 (PDT) MIME-Version: 1.0 References: <0246fe923945ba2b8d885f45279d7d3956c46950.1623705308.git.alison.schofield@intel.com> <20210615210518.GA22172@alison-desk.jf.intel.com> In-Reply-To: <20210615210518.GA22172@alison-desk.jf.intel.com> From: Dan Williams Date: Tue, 15 Jun 2021 15:01:06 -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 On Tue, Jun 15, 2021 at 2:09 PM Alison Schofield wrote: > > Thanks for the review Dan... > > On Tue, Jun 15, 2021 at 11:48:43AM -0700, Dan Williams wrote: > > [ 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. > > > > Here's my next take - making the handling resilient. > Not so sure on gracefulness. Open for suggestions. > > -#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)) > +#define FLAG_TYPE2(x) \ > + ((x & ACPI_CEDT_CFMWS_RESTRICT_TYPE2) ? CXL_DECODER_F_TYPE2 : 0) > +#define FLAG_TYPE3(x) \ > + ((x & ACPI_CEDT_CFMWS_RESTRICT_TYPE3) ? CXL_DECODER_F_TYPE3 : 0) > +#define FLAG_RAM(x) \ > + ((x & ACPI_CEDT_CFMWS_RESTRICT_VOLATILE) ? CXL_DECODER_F_RAM : 0) > +#define FLAG_PMEM(x) \ > + ((x & ACPI_CEDT_CFMWS_RESTRICT_PMEM) ? CXL_DECODER_F_PMEM : 0) > +#define FLAG_FIXED(x) \ > + ((x & ACPI_CEDT_CFMWS_RESTRICT_FIXED) ? CXL_DECODER_F_LOCK : 0) > + > +#define CFMWS_TO_DECODER_FLAGS(x) (FLAG_TYPE2(x) | FLAG_TYPE3(x) | \ > + FLAG_RAM(x) | FLAG_PMEM(x)| FLAG_FIXED(x)) Hmm, why the macros? Just make CFMWS_TO_DECODER_FLAGS a proper function. if (cfmws->restrictions & ACPI_CEDT_CFMWS_RESTRICT_TYPE2) flags |= CXL_DECODER_F_TYPE2; ...etc Unless you foresee where macros were going to be reused somewhere else I would just as soon open code them like above.