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 X-Spam-Level: X-Spam-Status: No, score=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4167AC433DB for ; Tue, 12 Jan 2021 22:00:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E977E221F5 for ; Tue, 12 Jan 2021 22:00:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437266AbhALVeR (ORCPT ); Tue, 12 Jan 2021 16:34:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2436656AbhALUHV (ORCPT ); Tue, 12 Jan 2021 15:07:21 -0500 Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81D56C061575 for ; Tue, 12 Jan 2021 12:06:40 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id w1so5234981ejf.11 for ; Tue, 12 Jan 2021 12:06:40 -0800 (PST) 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=8/Bid2Bzf98jE1/ALAKGTMu2+XIpeX//lGOiyhOAPLE=; b=vhrrzDmitO32JAO3cpPHjbqdMSMUZDuwupYPaErRNdmyLCV9CGhPdYK6oTrgJG74+m I9dA7oEIptk1EhB30sBwuzhsn5ped+8hrj1SEpOIehrqgvt9hLGZusi5QYNsLyb0Ojr7 B5CZvlBXkQak1yX5cCoTDYZjpURO/BDj90CBV2xV11nCqustJMw6QGBur7B+HWFMThJz 1UOpx1uPYSC7PIQzDXmNwWVBl2xqVAawLUUMn5pIwD3C/PuDUKVuv9cePx/NSJz7tGiC JaIZx/W2kwjLwrF97+S1fQrkm406AotYB5qwe5dQ+9CSge06C4wEogikQR+XPc1DtPae 9wSw== 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=8/Bid2Bzf98jE1/ALAKGTMu2+XIpeX//lGOiyhOAPLE=; b=k1wxRCM0cslW9W3INaPenb3+S21kyt7XYGBzg5jbcALgTPJatf7IMPlDgXi6uEhfnr Vo1/2Q4Fi6iPCZTBoTFeGkRnVMZAem2hPvi4ZCjO6Hlos1dgIIX6kNNwSIxGjvZLl9+N gq8K/Bh0YdWvnIC/hbWT1gMnnqlMxFsHDL1auHazhjvkQkbZ+JrDHN2jELrbg4pjjNMW 8PWv/W+BeQmg8suTEc0gp3xHaLUh4pe6BfDvugW30pVXMMeZo64ot9NyQzTNvWbronzl nixpXV00TF5Uobj9ZEuGqZdqCFP8jsce+JBtMx/DDGod7TdBFOlvJJdk39N4+bTNX0kv PS4A== X-Gm-Message-State: AOAM532gn9QDj+KaI02qfiaXA5G7wRYE/RV6ciHHohu47Aw223iVnvyY N5Hulwi8hVn4lCTHz/rZKX4WUC46da/YI9tzY4FEpw== X-Google-Smtp-Source: ABdhPJyfN4mVkZqUgmpVifgODbiKiUV7zPHfN/mvTykoOz6wGwySd2pfuLRTAFzoWqiTJ14Yjd/67QsQSjvEqEh7UX8= X-Received: by 2002:a17:906:2707:: with SMTP id z7mr357027ejc.418.1610481999273; Tue, 12 Jan 2021 12:06:39 -0800 (PST) MIME-Version: 1.0 References: <20210111225121.820014-1-ben.widawsky@intel.com> <20210111225121.820014-5-ben.widawsky@intel.com> <20210112190103.00004644@Huawei.com> In-Reply-To: <20210112190103.00004644@Huawei.com> From: Dan Williams Date: Tue, 12 Jan 2021 12:06:30 -0800 Message-ID: Subject: Re: [RFC PATCH v3 04/16] cxl/mem: Introduce a driver for CXL-2.0-Type-3 endpoints To: Jonathan Cameron Cc: Ben Widawsky , linux-cxl@vger.kernel.org, Linux Kernel Mailing List , Linux PCI , "linux-acpi@vger.kernel.org, Ira Weiny" , Vishal Verma , "Kelley, Sean V" , Rafael Wysocki , Bjorn Helgaas , Jon Masters , Chris Browy , Randy Dunlap , Christoph Hellwig , daniel.lll@alibaba-inc.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 12, 2021 at 11:03 AM Jonathan Cameron wrote: > > On Mon, 11 Jan 2021 14:51:08 -0800 > Ben Widawsky wrote: > > > From: Dan Williams > > > > The CXL.mem protocol allows a device to act as a provider of "System > > RAM" and/or "Persistent Memory" that is fully coherent as if the memory > > was attached to the typical CPU memory controller. > > > > With the CXL-2.0 specification a PCI endpoint can implement a "Type-3" > > device interface and give the operating system control over "Host > > Managed Device Memory". See section 2.3 Type 3 CXL Device. > > > > The memory range exported by the device may optionally be described by > > the platform firmware memory map, or by infrastructure like LIBNVDIMM to > > provision persistent memory capacity from one, or more, CXL.mem devices. > > > > A pre-requisite for Linux-managed memory-capacity provisioning is this > > cxl_mem driver that can speak the mailbox protocol defined in section > > 8.2.8.4 Mailbox Registers. > > > > For now just land the driver boiler-plate and fill it in with > > functionality in subsequent commits. > > > > Link: https://www.computeexpresslink.org/download-the-specification > > Signed-off-by: Dan Williams > > Signed-off-by: Ben Widawsky > > Just one passing comment inline. > > > diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c > > new file mode 100644 > > index 000000000000..005404888942 > > --- /dev/null > > +++ b/drivers/cxl/mem.c > > @@ -0,0 +1,69 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* Copyright(c) 2020 Intel Corporation. All rights reserved. */ > > +#include > > +#include > > +#include > > +#include "acpi.h" > > +#include "pci.h" > > + > > +static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec) > > Is it worth pulling this out to a utility library now as we are going > to keep needing this for CXL devices? > Arguably, with a vendor_id parameter it might make sense to have > it as a utility function for pci rather than CXL alone. Sure, cxl_mem_dvsec() can move to a central location, but I'd wait for the first incremental user to split it out.