On Sun, Feb 05, 2023 at 05:02:51PM -0800, Dan Williams wrote:
> In preparation for a new region mode, do not, for example, allow
> 'ram' decoders to be assigned to 'pmem' regions and vice versa.
>
> Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx>
> ---
> drivers/cxl/core/region.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index c9e7f05caa0f..53d6dbe4de6d 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
> @@ -1217,6 +1217,12 @@ static int cxl_region_attach(struct cxl_region *cxlr,
> struct cxl_dport *dport;
> int i, rc = -ENXIO;
>
> + if (cxled->mode != cxlr->mode) {
> + dev_dbg(&cxlr->dev, "%s region mode: %d mismatch: %d\n",
> + dev_name(&cxled->cxld.dev), cxlr->mode, cxled->mode);
> + return -EINVAL;
> + }
> +
> if (cxled->mode == CXL_DECODER_DEAD) {
> dev_dbg(&cxlr->dev, "%s dead\n", dev_name(&cxled->cxld.dev));
> return -ENODEV;
>
Maybe a stupid question. It will be entirely possible to "convert" pmem
to "ram" (i.e. just online it as system memory).
Are type-3 devices with pmem expected to carry 2 decoders (one ram, 1
pmem), such that you can create a ram region from pmem, or is it expected
that the pmem decoder will be used for pmem, even if it gets onlined
as volatile?
Just asking because depending on how that flushes out, you might
expected a "ram region" to get assigned to a "pmem decoder", unless
you're expecting all pmem-carrying-devices to create 2 decoders per pmem
region depending on how the end user intends to use it.
~Gregory
