Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Adam Manzanares <a.manzanares@samsung.com>
To:     Dan Williams <dan.j.williams@intel.com>
CC:     Davidlohr Bueso <dave@stgolabs.net>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        "alison.schofield@intel.com" <alison.schofield@intel.com>,
        "vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
        "ira.weiny@intel.com" <ira.weiny@intel.com>,
        "widawsk@kernel.org" <widawsk@kernel.org>,
        "linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cxl: Replace HDM decoder granularity magic numbers
Thread-Topic: [PATCH] cxl: Replace HDM decoder granularity magic numbers
Thread-Index: AQHYtklu6j3UH4AVtU69YQX5WSmWH627nsOAgAKmF4CAAGEMAIAADPQAgADemwA=
Date:   Thu, 25 Aug 2022 05:34:33 +0000
Message-ID: <20220825053425.GA141173@bgt-140510-bm01>
In-Reply-To: <63064f28720cf_1b3229490@dwillia2-xfh.jf.intel.com.notmuch>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5B0FDDFCF444524CBB59BE01FD1BB71E@ssi.samsung.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
CMS-TYPE: 301P
References: <CGME20220822170552uscas1p1b1ee530bf38a14806010d65d1b593ab0@uscas1p1.samsung.com>
        <20220822170510.125082-1-a.manzanares@samsung.com>
        <20220822171703.sfizbmn6retpxggi@offworld>
        <20220824104401.00005cd4@huawei.com>
        <20220824153122.2bgths6lnsxlolos@offworld>
        <63064f28720cf_1b3229490@dwillia2-xfh.jf.intel.com.notmuch>
Precedence: bulk

On Wed, Aug 24, 2022 at 09:17:44AM -0700, Dan Williams wrote:
> Davidlohr Bueso wrote:
> > On Wed, 24 Aug 2022, Jonathan Cameron wrote:
> >=20
> > >On Mon, 22 Aug 2022 10:17:03 -0700
> > >Davidlohr Bueso <dave@stgolabs.net> wrote:
> >=20
> > >> Actually the whole drivers/cxl/* could use updating the comments for=
 3.0.
> > >
> > >Interesting point.  What do we want to do on this?  Most similar
> > >cases I've been involved on rely on referring to 'oldest' compatible s=
pec.
> > >(this is true for ACPI stuff for example).
> >=20
> > I find it incredibly annoying to reference table or section numbers fro=
m old
> > specs mention in the code. Unless dealing with specific version things,=
 why
> > use old specs at all?
> >=20
> > The main drawback to this is obviously the constant need to update ever=
ything,
> > so...
>=20
> I think a happy medium is all new references being 3.0 and touching any
> old references and refresh them up to 3.0.

I'll shoot for the happy medium in a v2.

>=20
> That said if someone wants to do the work to refresh all of them, and
> someone else wants to review those updates I would take the patch.=