From: Alejandro Lucero Palau <alucerop@amd.com>
To: Alison Schofield <alison.schofield@intel.com>,
alejandro.lucero-palau@amd.com
Cc: linux-cxl@vger.kernel.org, dan.j.williams@intel.com,
dave.jiang@intel.com, Gregory Price <gourry@gourry.net>
Subject: Re: [PATCH v2 2/3] cxl/region: Factor out interleave ways setup
Date: Fri, 27 Feb 2026 20:13:38 +0000 [thread overview]
Message-ID: <014b48d1-8b93-478f-b9d4-f8a5ca8ec8df@amd.com> (raw)
In-Reply-To: <aZ-KeLC8tKemoNJH@aschofie-mobl2.lan>
On 2/25/26 23:49, Alison Schofield wrote:
> On Wed, Feb 25, 2026 at 12:22:22PM +0000, alejandro.lucero-palau@amd.com wrote:
>> From: Alejandro Lucero <alucerop@amd.com>
>>
>> Region creation based on Type3 devices can be triggered from user space
>> allowing memory combination through interleaving.
>>
>> In preparation for kernel driven region creation, that is Type2 drivers
>> triggering region creation backed with its advertised CXL memory, factor
>> out a common helper from the user-sysfs region setup for interleave ways.
>>
>> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
>> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
>> Reviewed-by: Gregory Price <gourry@gourry.net>
>> Tested-by: Gregory Price <gourry@gourry.net>
>> ---
>> drivers/cxl/core/region.c | 41 +++++++++++++++++++++++++--------------
>> 1 file changed, 26 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
>> index cac33c99fe6a..3ef4ccf1c92b 100644
>> --- a/drivers/cxl/core/region.c
>> +++ b/drivers/cxl/core/region.c
>> @@ -485,22 +485,14 @@ static ssize_t interleave_ways_show(struct device *dev,
>>
>> static const struct attribute_group *get_cxl_region_target_group(void);
>>
>> -static ssize_t interleave_ways_store(struct device *dev,
>> - struct device_attribute *attr,
>> - const char *buf, size_t len)
>> +static int set_interleave_ways(struct cxl_region *cxlr, int val)
>> {
>> - struct cxl_region *cxlr = to_cxl_region(dev);
>> struct cxl_root_decoder *cxlrd = cxlr->cxlrd;
>> struct cxl_decoder *cxld = &cxlrd->cxlsd.cxld;
>> struct cxl_region_params *p = &cxlr->params;
>> - unsigned int val, save;
>> - int rc;
>> + int save, rc;
>> u8 iw;
> Why the type differences? set_interleave_ways() takes an int while
> the sysfs store path parses val as unsigned int via kstrtouint()?
> How about keeping the helper argument type aligned with the sysfs
> parse type (and/or p->interleave_ways type)?
Yes, that was pointed out for interleave_granularity_store by Ben
Cheatham, and I did change there from kstrtouint to kstrtoint as
cxl_regions_params expect int type.
I forgot to do the same here.
>
> Even if todays sysfs path won't pass negative, the helper is
> being positioned for non sysfs callers IIUC.
Not sure what you mean here. Should I do the change above as with
granularity?
>
> Similar question with 'save'? Should it match type of
> p->interleave_ways?
save is an int and interleave_ways as defined in cxl_region_params is an
int.
Thank you
>
>
>>
>> - rc = kstrtouint(buf, 0, &val);
>> - if (rc)
>> - return rc;
>> -
>> rc = ways_to_eiw(val, &iw);
>> if (rc)
>> return rc;
>> @@ -515,9 +507,7 @@ static ssize_t interleave_ways_store(struct device *dev,
>> return -EINVAL;
>> }
>>
>> - ACQUIRE(rwsem_write_kill, rwsem)(&cxl_rwsem.region);
>> - if ((rc = ACQUIRE_ERR(rwsem_write_kill, &rwsem)))
>> - return rc;
>> + lockdep_assert_held_write(&cxl_rwsem.region);
>>
>> if (p->state >= CXL_CONFIG_INTERLEAVE_ACTIVE)
>> return -EBUSY;
>> @@ -525,10 +515,31 @@ static ssize_t interleave_ways_store(struct device *dev,
>> save = p->interleave_ways;
>> p->interleave_ways = val;
>> rc = sysfs_update_group(&cxlr->dev.kobj, get_cxl_region_target_group());
>> - if (rc) {
>> + if (rc)
>> p->interleave_ways = save;
>> +
>> + return rc;
>> +}
>> +
>> +static ssize_t interleave_ways_store(struct device *dev,
>> + struct device_attribute *attr,
>> + const char *buf, size_t len)
>> +{
>> + struct cxl_region *cxlr = to_cxl_region(dev);
>> + unsigned int val;
>> + int rc;
>> +
>> + rc = kstrtouint(buf, 0, &val);
>> + if (rc)
>> + return rc;
>> +
>> + ACQUIRE(rwsem_write_kill, rwsem)(&cxl_rwsem.region);
>> + if ((rc = ACQUIRE_ERR(rwsem_write_kill, &rwsem)))
>> + return rc;
>> +
>> + rc = set_interleave_ways(cxlr, val);
>> + if (rc)
>> return rc;
>> - }
>>
>> return len;
>> }
>> --
>> 2.34.1
>>
>>
next prev parent reply other threads:[~2026-02-27 20:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-25 12:22 [PATCH v2 0/3] cxl region changes for Type2 support alejandro.lucero-palau
2026-02-25 12:22 ` [PATCH v2 1/3] cxl: Make region type based on endpoint type alejandro.lucero-palau
2026-02-25 12:22 ` [PATCH v2 2/3] cxl/region: Factor out interleave ways setup alejandro.lucero-palau
2026-02-25 23:49 ` Alison Schofield
2026-02-27 20:13 ` Alejandro Lucero Palau [this message]
2026-02-25 12:22 ` [PATCH v2 3/3] cxl/region: Factor out interleave granularity setup alejandro.lucero-palau
2026-02-25 23:52 ` Alison Schofield
2026-02-27 13:21 ` Jonathan Cameron
2026-02-27 20:17 ` Alejandro Lucero Palau
2026-02-25 23:42 ` [PATCH v2 0/3] cxl region changes for Type2 support Alison Schofield
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=014b48d1-8b93-478f-b9d4-f8a5ca8ec8df@amd.com \
--to=alucerop@amd.com \
--cc=alejandro.lucero-palau@amd.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=gourry@gourry.net \
--cc=linux-cxl@vger.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