[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aBz19JAPxKm_XYRc@aschofie-mobl2.lan>
Date: Thu, 8 May 2025 11:20:36 -0700
From: Alison Schofield <alison.schofield@...el.com>
To: <alejandro.lucero-palau@....com>
CC: <linux-cxl@...r.kernel.org>, <netdev@...r.kernel.org>,
<dan.j.williams@...el.com>, <edward.cree@....com>, <davem@...emloft.net>,
<kuba@...nel.org>, <pabeni@...hat.com>, <edumazet@...gle.com>,
<dave.jiang@...el.com>, Alejandro Lucero <alucerop@....com>, Zhi Wang
<zhiw@...dia.com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>, "Ben
Cheatham" <benjamin.cheatham@....com>
Subject: Re: [PATCH v14 19/22] cxl: add region flag for precluding a device
memory to be used for dax
On Thu, Apr 17, 2025 at 10:29:22PM +0100, alejandro.lucero-palau@....com wrote:
> From: Alejandro Lucero <alucerop@....com>
>
> By definition a type2 cxl device will use the host managed memory for
> specific functionality, therefore it should not be available to other
> uses. However, a dax interface could be just good enough in some cases.
>
> Add a flag to a cxl region for specifically state to not create a dax
> device. Allow a Type2 driver to set that flag at region creation time.
>
> Signed-off-by: Alejandro Lucero <alucerop@....com>
> Reviewed-by: Zhi Wang <zhiw@...dia.com>
> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
> Reviewed-by: Ben Cheatham <benjamin.cheatham@....com>
> Reviewed-by: Dave Jiang <dave.jiang@...el.com>
> ---
> drivers/cxl/core/region.c | 10 +++++++++-
> drivers/cxl/cxl.h | 3 +++
> include/cxl/cxl.h | 3 ++-
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index f55fb253ecde..cec168a26efb 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
> @@ -3649,12 +3649,14 @@ __construct_new_region(struct cxl_root_decoder *cxlrd,
> * @cxlrd: root decoder to allocate HPA
> * @cxled: endpoint decoder with reserved DPA capacity
> * @ways: interleave ways required
> + * @no_dax: if true no DAX device should be created
I'll suggest avoiding the double negative on no_dax and name this
variable based on what can happen, not what must be prevented.
Something like: dax_allowed or allow_dax or dax_ok
snip
>
Powered by blists - more mailing lists