[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220824153122.2bgths6lnsxlolos@offworld>
Date: Wed, 24 Aug 2022 08:31:22 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: 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
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...
Thanks,
Davidlohr
Powered by blists - more mailing lists