[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <63064f28720cf_1b3229490@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 24 Aug 2022 09:17:44 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Davidlohr Bueso <dave@...olabs.net>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>
CC: Adam Manzanares <a.manzanares@...sung.com>,
"alison.schofield@...el.com" <alison.schofield@...el.com>,
"vishal.l.verma@...el.com" <vishal.l.verma@...el.com>,
"ira.weiny@...el.com" <ira.weiny@...el.com>,
"widawsk@...nel.org" <widawsk@...nel.org>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] cxl: Replace HDM decoder granularity magic numbers
Davidlohr Bueso wrote:
> On Wed, 24 Aug 2022, Jonathan Cameron wrote:
>
> >On Mon, 22 Aug 2022 10:17:03 -0700
> >Davidlohr Bueso <dave@...olabs.net> wrote:
>
> >> 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 spec.
> >(this is true for ACPI stuff for example).
>
> I find it incredibly annoying to reference table or section numbers from old
> specs mention in the code. Unless dealing with specific version things, why
> use old specs at all?
>
> The main drawback to this is obviously the constant need to update everything,
> so...
I think a happy medium is all new references being 3.0 and touching any
old references and refresh them up to 3.0.
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.
Powered by blists - more mailing lists