From: Dan Williams <dan.j.williams@intel.com>
To: Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Adam Manzanares <a.manzanares@samsung.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>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
"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
Date: Wed, 24 Aug 2022 09:17:44 -0700 [thread overview]
Message-ID: <63064f28720cf_1b3229490@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20220824153122.2bgths6lnsxlolos@offworld>
Davidlohr Bueso wrote:
> On Wed, 24 Aug 2022, Jonathan Cameron wrote:
>
> >On Mon, 22 Aug 2022 10:17:03 -0700
> >Davidlohr Bueso <dave@stgolabs.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.
next prev parent reply other threads:[~2022-08-24 16:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20220822170552uscas1p1b1ee530bf38a14806010d65d1b593ab0@uscas1p1.samsung.com>
2022-08-22 17:05 ` Adam Manzanares
2022-08-22 17:17 ` Davidlohr Bueso
2022-08-24 9:44 ` Jonathan Cameron
2022-08-24 15:31 ` Davidlohr Bueso
2022-08-24 16:17 ` Dan Williams [this message]
2022-08-25 5:34 ` Adam Manzanares
2022-08-25 5:48 ` Adam Manzanares
2022-08-22 17:34 ` Dan Williams
2022-08-25 5:36 ` Adam Manzanares
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=63064f28720cf_1b3229490@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=a.manzanares@samsung.com \
--cc=alison.schofield@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vishal.l.verma@intel.com \
--cc=widawsk@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®