Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4800276ioa; Wed, 27 Apr 2022 11:22:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEjsyYorKVJjswEjOI+9Molip+X2dG7bv50wcNItR6KZoBb/lUBrVDUYruQnW07wYOVjse X-Received: by 2002:aa7:9041:0:b0:4fe:3d6c:1739 with SMTP id n1-20020aa79041000000b004fe3d6c1739mr31292734pfo.13.1651083767520; Wed, 27 Apr 2022 11:22:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651083767; cv=none; d=google.com; s=arc-20160816; b=gk/Azq4uJY4jyz7lVZrhu/IdqN8jRsFTjjUP5HHPpLPnTtFjhoeS1T9bpZ8QMzvhcW TqEIr3vv7cy8XQnEaUIIVoCt7QN2dmIH7V46vCIGr3vXkSD2aWlTPuIcKhh6ni2LEVj0 wtPUcrOYaooDrfNzC2fmkoD8Lqn5Pucn+BI25wg8udWfJqJbCHAecuxg63Fwbz124zCE zlXLZ+OuwvDnLjNx77fUdxjk/4y+D9dUzDLjfbPwef3cXx4Hmy5YNMDh/1sRaCdjzNhc mka68sUtmvTdG6gqqUce0MQNVFLo3dVnmmCmqDjLeJ8QcffsWJrV8nNhv8uaVt7eZnX6 fcEw== 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 :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=kG8tmJad7OQqo2vYj+EL/zXw7u3T7LMCj7DC4LYY+Ro=; b=NVQKCDfYuRGi/KVxs+GbmS9Ce21C9cVSEtoppllJHKGfnh3ITuphGHscjRpU2e+MOW Qt3E1fXVJegBN4D0DEnAVIApBg+40YrbvLW+Rryy8aOWt0MkeTVvJvBompjYRYTJzxY4 2A8W3Kzx9Gf3RXkcqSZTpVpeUoWBseP3VVbjdIvidb6/gTHPEVI6kvl/2U9bhqVbLvNj bBTNA+asHv62SofkIUvfi2y9sC/IAAuc6DVEI97kZ37GNhwJy8uNnASCHF8FIraJ2AP7 4OuceIyKDQMI7Cen+1aA8f0Xy20ERC0+TxghLAWmWqUyiF89hlqSs9zgDPGgD+kXrft3 4lzw== 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:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id f19-20020a635113000000b003aad34c72ebsi2223740pgb.618.2022.04.27.11.22.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 11:22:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7EFB21759CF; Wed, 27 Apr 2022 10:55:19 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244493AbiD0R6V (ORCPT + 99 others); Wed, 27 Apr 2022 13:58:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229451AbiD0R6T (ORCPT ); Wed, 27 Apr 2022 13:58:19 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6115912ACC9; Wed, 27 Apr 2022 10:55:07 -0700 (PDT) Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KpRCk0YZmz67KmH; Thu, 28 Apr 2022 01:52:18 +0800 (CST) Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 27 Apr 2022 19:55:05 +0200 Received: from localhost (10.81.200.74) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2375.24; Wed, 27 Apr 2022 18:55:04 +0100 Date: Wed, 27 Apr 2022 18:55:02 +0100 From: Jonathan Cameron To: CC: Dan Williams , Bjorn Helgaas , Alison Schofield , "Vishal Verma" , Ben Widawsky , , , Subject: Re: [PATCH V8 07/10] cxl/mem: Read CDAT table Message-ID: <20220427185502.00001fbf@Huawei.com> In-Reply-To: <20220414203237.2198665-8-ira.weiny@intel.com> References: <20220414203237.2198665-1-ira.weiny@intel.com> <20220414203237.2198665-8-ira.weiny@intel.com> Organization: Huawei Technologies Research and Development (UK) Ltd. 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.81.200.74] X-ClientProxiedBy: lhreml709-chm.china.huawei.com (10.201.108.58) To lhreml710-chm.china.huawei.com (10.201.108.61) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE autolearn=no 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, 14 Apr 2022 13:32:34 -0700 ira.weiny@intel.com wrote: > From: Jonathan Cameron > > The OS will need CDAT data from CXL devices to properly set up > interleave sets. Currently this is supported by a through a DOE mailbox > which supports CDAT. But any cxl_mem object can provide this data later > if need be, for example for testing. > > Cache the CDAT data for later parsing. Provide a sysfs binary attribute > to allow dumping of the CDAT. > > Binary dumping is modeled on /sys/firmware/ACPI/tables/ > > The ability to dump this table will be very useful for emulation of real > devices once they become available as QEMU CXL type 3 device emulation will > be able to load this file in. > > This does not support table updates at runtime. It will always provide > whatever was there when first cached. Handling of table updates can be > implemented later. > > Finally create a complete list of DOE defines within cdat.h for code > wishing to decode the CDAT table. > > Signed-off-by: Jonathan Cameron > Co-developed-by: Ira Weiny > Signed-off-by: Ira Weiny > I'd have left the introduction of callbacks until they were actually needed, but meh. That's minor. On trivial below. Reviewed-by: Jonathan Cameron ... > + > +static int read_cdat_data(struct cxl_dev_state *cxlds) > +{ > + struct device *dev = cxlds->dev; > + size_t cdat_length; > + int ret; > + > + if (cxl_mem_cdat_get_length(cxlds, &cdat_length)) > + return 0; > + > + cxlds->cdat.table = devm_kzalloc(dev, cdat_length, GFP_KERNEL); > + if (!cxlds->cdat.table) > + return -ENOMEM; Trivial but blank line here. > + cxlds->cdat.length = cdat_length; > + ret = cxl_mem_cdat_read_table(cxlds, &cxlds->cdat); > + if (ret) { > + devm_kfree(dev, cxlds->cdat.table); > + cxlds->cdat.table = NULL; > + cxlds->cdat.length = 0; > + } > + return ret; > +}