Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp457732pxb; Wed, 3 Feb 2021 09:18:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJy/2e57G8FGuORqunDCqNPiAwiBoGets0njnQ6hmpS96C0jQTcfwSyVSE4GXYxuHDxdBV6b X-Received: by 2002:a19:f115:: with SMTP id p21mr2224689lfh.99.1612372716415; Wed, 03 Feb 2021 09:18:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612372715; cv=none; d=google.com; s=arc-20160816; b=q+YylG+YBfw+WnxRkpW3m9qWvrb53nHAH/xClzdwEPUQKNKIsLBYumNd0s09YaqpB3 ZYtXXfNE8PpIOLDsr9Wb2pNG9kkgyW9MPIF9leUxTElL5X68wkm1az7lsMUEnbpxSY2P B1URlLe59sqsKSoOTEAIox4u0t1QZGk1rCG4S4LxARij+RBhXbiQ3Owuu73oVq/Rv0qv 8wCi8i7kr5W2g7AjWAtW1N1kZiegZ7EIdz3FPgG8snjSNzq+Vi5TsxmMnpPzANYetHf3 wDaMZbrUF5gFDVLDjCBWxoVpFbgaKvf9bvzUvzyJXCvwQEiUFRrYFGqn8HwPnd5R2C7F 2L/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=YmKmmagLDCrQhzRpPfDJ+a00KLQE0WO4rpCVn+BQlfs=; b=W8Eg3RRxxGz1/uSC58Dby/tt3tPOz9IW6PM/A42qi4s61ZtT2OehjYX8zHhSK/rAe8 L/Wx1WI89ym3yNAZaVqZEj14+Y3tBrfle8iOLvc4FFIRekfBiMiBGo7VZS7wEnCbbSWi NCIAC6pxc4+pZcS4Dm+rdaPGabGQfLlREH98UM+Pf5s9e9dDHzCMBHDRnRdmViVm7v54 7ul0gcashl4dYRgisbYahgQk+SvLcBPNhIb6IDyJJMT+Lm4fN9gn/s0/RvL+4Hdu7Wny I6uFmeX9hGR9x3yjpfyzfLKn0cGtv7z6IEUNALLiN9lLsJJq9cN+lmTcAcHH15GDknUp 1Bbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=e7Dnxtue; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q13si2115936ljg.592.2021.02.03.09.18.04; Wed, 03 Feb 2021 09:18:35 -0800 (PST) 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=@infradead.org header.s=casper.20170209 header.b=e7Dnxtue; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232070AbhBCRQV (ORCPT + 99 others); Wed, 3 Feb 2021 12:16:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34872 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231436AbhBCRQT (ORCPT ); Wed, 3 Feb 2021 12:16:19 -0500 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC8B4C061573; Wed, 3 Feb 2021 09:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=YmKmmagLDCrQhzRpPfDJ+a00KLQE0WO4rpCVn+BQlfs=; b=e7DnxtuelhIqa4xqq/20eW5NIV f6NQ/p3AbDn7kMc1Eh5KhHWRPFOR3pB6zqYoAYD01L0UpUijgN/V1I/HVrmG1epr54eKrvFTrFvaH 65Q6rWhaCSUMyXUU8/OJ+Xzy1MrM/m2n8WCwIrqqMtvwypMFmT4iX0Ed779qjPdOrBOSy850iA/YH I1CeYIgZonhF5NTYnX9OjXQwoXTFjawggcLcVigEjXEZVFf6hAaHXMrRXM22eOa9yDAKs9GjT1zKi JooUNm+8NvBvP1LfobZMZyTjuxdilI0DqLEbR5IdOARjbf89TUwLjJyxusqeB3ZLsnfeQnOABBYEq q8lU1bTA==; Received: from hch by casper.infradead.org with local (Exim 4.94 #2 (Red Hat Linux)) id 1l7Lkc-00HEut-2e; Wed, 03 Feb 2021 17:15:34 +0000 Date: Wed, 3 Feb 2021 17:15:34 +0000 From: Christoph Hellwig To: Ben Widawsky Cc: Christoph Hellwig , linux-cxl@vger.kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-nvdimm@lists.01.org, linux-pci@vger.kernel.org, Bjorn Helgaas , Chris Browy , Dan Williams , Ira Weiny , Jon Masters , Jonathan Cameron , Rafael Wysocki , Randy Dunlap , Vishal Verma , daniel.lll@alibaba-inc.com, "John Groves (jgroves)" , "Kelley, Sean V" Subject: Re: [PATCH 03/14] cxl/mem: Find device capabilities Message-ID: <20210203171534.GB4104698@infradead.org> References: <20210130002438.1872527-1-ben.widawsky@intel.com> <20210130002438.1872527-4-ben.widawsky@intel.com> <20210202181016.GD3708021@infradead.org> <20210202182418.3wyxnm6rqeoeclu2@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210202182418.3wyxnm6rqeoeclu2@intel.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org. See http://www.infradead.org/rpr.html Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 02, 2021 at 10:24:18AM -0800, Ben Widawsky wrote: > > > + /* Cap 4000h - CXL_CAP_CAP_ID_MEMDEV */ > > > + struct { > > > + void __iomem *regs; > > > + } mem; > > > > This style looks massively obsfucated. For one the comments look like > > absolute gibberish, but also what is the point of all these anonymous > > structures? > > They're not anonymous, and their names are for the below register functions. The > comments are connected spec reference 'Cap XXXXh' to definitions in cxl.h. I can > articulate that if it helps. But why no simply a void __iomem *mem_regs; field vs the extra struct? > The register space for CXL devices is a bit weird since it's all subdivided > under 1 BAR for now. To clearly distinguish over the different subregions, these > helpers exist. It's really easy to mess this up as the developer and I actually > would disagree that it makes debugging quite a bit easier. It also gets more > convoluted when you add the other 2 BARs which also each have their own > subregions. > > For example. if my mailbox function does: > cxl_read_status_reg32(cxlm, CXLDEV_MB_CAPS_OFFSET); > > instead of: > cxl_read_mbox_reg32(cxlm, CXLDEV_MB_CAPS_OFFSET); > > It's easier to spot than: > readl(cxlm->regs + cxlm->status_offset + CXLDEV_MB_CAPS_OFFSET) Well, what I think would be the most obvious is: readl(cxlm->status_regs + CXLDEV_MB_CAPS_OFFSET); > > > + /* 8.2.8.4.3 */ > > > > ???? > > > > I had been trying to be consistent with 'CXL2.0 - ' in front of all spec > reference. I obviously missed this one. FYI, I generally find section names much easier to find than section numbers. Especially as the numbers change very frequently, some times even for very minor updates to the spec. E.g. in NVMe the numbers might even change from NVMe 1.X to NVMe 1.Xa because an errata had to add a clarification as its own section.