public inbox for linux-cxl@vger.kernel.org
 help / color / mirror / Atom feed
From: "Koralahalli Channabasappa, Smita" <skoralah@amd.com>
To: Alejandro Lucero Palau <alucerop@amd.com>,
	Jonathan Cameron <jonathan.cameron@huawei.com>,
	alejandro.lucero-palau@amd.com
Cc: linux-cxl@vger.kernel.org, netdev@vger.kernel.org,
	dan.j.williams@intel.com, edward.cree@amd.com,
	davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com,
	edumazet@google.com, dave.jiang@intel.com,
	Alison Schofield <alison.schofield@intel.com>
Subject: Re: [PATCH v19 01/22] cxl/mem: Arrange for always-synchronous memdev attach
Date: Thu, 30 Oct 2025 12:57:21 -0700	[thread overview]
Message-ID: <030a36b6-0ade-4ee1-a535-9f01b15581a6@amd.com> (raw)
In-Reply-To: <801f4bcb-e12e-4fe2-a6d4-a46ca96a15f6@amd.com>

Hi Alejandro,

I need patches 1–3 from this series as prerequisites for the 
Soft-Reserved coordination work, so I wanted to check in on your plans 
for the next revision.

Link to the discussion: 
https://lore.kernel.org/all/aPbOfFPIhtu5npaG@aschofie-mobl2.lan/

Are patches 1–3 already being updated as part of your v20 work?
If so, I can wait and pick them up from v20 directly.

If v20 is still in progress and may take some time, I can probably carry 
patches 1–3 at the start of my series, and if that helps, I can fold in 
the review comments by Jonathan while keeping authorship as is. I would 
only adjust wording in the commit descriptions to reflect the 
Soft-Reserved coordination context.

Alternatively, if you prefer to continue carrying them in the Type-2 
series, I can simply reference them as prerequisites instead.

I’m fine with either approach just trying to avoid duplicated effort and 
keep review in one place.

Thanks
Smita

On 10/29/2025 4:20 AM, Alejandro Lucero Palau wrote:
> 
> On 10/7/25 13:40, Jonathan Cameron wrote:
>> On Mon, 6 Oct 2025 11:01:09 +0100
>> <alejandro.lucero-palau@amd.com> wrote:
>>
>>> From: Alejandro Lucero <alucerop@amd.com>
>>>
>>> In preparation for CXL accelerator drivers that have a hard 
>>> dependency on
>>> CXL capability initialization, arrange for the endpoint probe result 
>>> to be
>>> conveyed to the caller of devm_cxl_add_memdev().
>>>
>>> As it stands cxl_pci does not care about the attach state of the 
>>> cxl_memdev
>>> because all generic memory expansion functionality can be handled by the
>>> cxl_core. For accelerators, that driver needs to know perform driver
>>> specific initialization if CXL is available, or exectute a fallback 
>>> to PCIe
>>> only operation.
>>>
>>> By moving devm_cxl_add_memdev() to cxl_mem.ko it removes async module
>>> loading as one reason that a memdev may not be attached upon return from
>>> devm_cxl_add_memdev().
>>>
>>> The diff is busy as this moves cxl_memdev_alloc() down below the 
>>> definition
>>> of cxl_memdev_fops and introduces devm_cxl_memdev_add_or_reset() to
>>> preclude needing to export more symbols from the cxl_core.
>>>
>>> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
>> Alejandro, SoB chain broken here which makes this currently unmergeable.
>>
>> Should definitely have your SoB as you sent the patch to the list and 
>> need
>> to make a statement that you believe it to be fine to do so (see the 
>> Certificate
>> of origin stuff in the docs).  Also, From should always be one of the 
>> authors.
>> If Dan wrote this as the SoB suggests then From should be set to him..
>>
>> git commit --amend --author="Dan Williams <dan.j.williams@intel.com>"
>>
>> Will fix that up.  Then either you add your SoB on basis you just 
>> 'handled'
>> the patch but didn't make substantial changes, or your SoB and a 
>> Codeveloped-by
>> if you did make major changes.  If it is minor stuff you can an
>> a sign off with # what changed
>> comment next to it.
> 
> 
> Understood. I'll ask Dan what he prefers.
> 
> 
>>
>> A few minor comments inline.
>>
>> Thanks,
>>
>> Jonathan
>>
>>
>>> ---
>>>   drivers/cxl/Kconfig       |  2 +-
>>>   drivers/cxl/core/memdev.c | 97 ++++++++++++++++-----------------------
>>>   drivers/cxl/mem.c         | 30 ++++++++++++
>>>   drivers/cxl/private.h     | 11 +++++
>>>   4 files changed, 82 insertions(+), 58 deletions(-)
>>>   create mode 100644 drivers/cxl/private.h
>>>
>>> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
>>> index 028201e24523..111e05615f09 100644
>>> --- a/drivers/cxl/Kconfig
>>> +++ b/drivers/cxl/Kconfig
>>> @@ -22,6 +22,7 @@ if CXL_BUS
>>>   config CXL_PCI
>>>       tristate "PCI manageability"
>>>       default CXL_BUS
>>> +    select CXL_MEM
>>>       help
>>>         The CXL specification defines a "CXL memory device" sub-class 
>>> in the
>>>         PCI "memory controller" base class of devices. Device's 
>>> identified by
>>> @@ -89,7 +90,6 @@ config CXL_PMEM
>>>   config CXL_MEM
>>>       tristate "CXL: Memory Expansion"
>>> -    depends on CXL_PCI
>>>       default CXL_BUS
>>>       help
>>>         The CXL.mem protocol allows a device to act as a provider of 
>>> "System
>>> diff --git a/drivers/cxl/core/memdev.c b/drivers/cxl/core/memdev.c
>>> index c569e00a511f..2bef231008df 100644
>>> --- a/drivers/cxl/core/memdev.c
>>> +++ b/drivers/cxl/core/memdev.c
>>> -
>>> -err:
>>> -    kfree(cxlmd);
>>> -    return ERR_PTR(rc);
>>>   }
>>> +EXPORT_SYMBOL_NS_GPL(devm_cxl_memdev_add_or_reset, "CXL");
>>>   static long __cxl_memdev_ioctl(struct cxl_memdev *cxlmd, unsigned 
>>> int cmd,
>>>                      unsigned long arg)
>>> @@ -1023,50 +1012,44 @@ static const struct file_operations 
>>> cxl_memdev_fops = {
>>>       .llseek = noop_llseek,
>>>   };
>>> -struct cxl_memdev *devm_cxl_add_memdev(struct device *host,
>>> -                       struct cxl_dev_state *cxlds)
>>> +struct cxl_memdev *cxl_memdev_alloc(struct cxl_dev_state *cxlds)
>>>   {
>>>       struct cxl_memdev *cxlmd;
>>>       struct device *dev;
>>>       struct cdev *cdev;
>>>       int rc;
>>> -    cxlmd = cxl_memdev_alloc(cxlds, &cxl_memdev_fops);
>>> -    if (IS_ERR(cxlmd))
>>> -        return cxlmd;
>>> +    cxlmd = kzalloc(sizeof(*cxlmd), GFP_KERNEL);
>> It's a little bit non obvious due to the device initialize mid way
>> through this, but given there are no error paths after that you can
>> currently just do.
>>     struct cxl_memdev *cxlmd __free(kfree) =
>>         cxl_memdev_alloc(cxlds, &cxl_memdev_fops);
>> and
>>     return_ptr(cxlmd);
>>
>> in the good path.  That lets you then just return rather than having
>> the goto err: handling for the error case that currently frees this
>> manually.
>>
>> Unlike the change below, this one I think is definitely worth making.
> 
> 
> I agree so I'll do it. The below suggestion is also needed ...
> 
> 
>>
>>> +    if (!cxlmd)
>>> +        return ERR_PTR(-ENOMEM);
>>> -    dev = &cxlmd->dev;
>>> -    rc = dev_set_name(dev, "mem%d", cxlmd->id);
>>> -    if (rc)
>>> +    rc = ida_alloc_max(&cxl_memdev_ida, CXL_MEM_MAX_DEVS - 1, 
>>> GFP_KERNEL);
>>> +    if (rc < 0)
>>>           goto err;
>>> -
>>> -    /*
>>> -     * Activate ioctl operations, no cxl_memdev_rwsem manipulation
>>> -     * needed as this is ordered with cdev_add() publishing the device.
>>> -     */
>>> +    cxlmd->id = rc;
>>> +    cxlmd->depth = -1;
>>>       cxlmd->cxlds = cxlds;
>>>       cxlds->cxlmd = cxlmd;
>>> -    cdev = &cxlmd->cdev;
>>> -    rc = cdev_device_add(cdev, dev);
>>> -    if (rc)
>>> -        goto err;
>>> +    dev = &cxlmd->dev;
>>> +    device_initialize(dev);
>>> +    lockdep_set_class(&dev->mutex, &cxl_memdev_key);
>>> +    dev->parent = cxlds->dev;
>>> +    dev->bus = &cxl_bus_type;
>>> +    dev->devt = MKDEV(cxl_mem_major, cxlmd->id);
>>> +    dev->type = &cxl_memdev_type;
>>> +    device_set_pm_not_required(dev);
>>> +    INIT_WORK(&cxlmd->detach_work, detach_memdev);
>>> -    rc = devm_add_action_or_reset(host, cxl_memdev_unregister, cxlmd);
>>> -    if (rc)
>>> -        return ERR_PTR(rc);
>>> +    cdev = &cxlmd->cdev;
>>> +    cdev_init(cdev, &cxl_memdev_fops);
>>>       return cxlmd;
>>>   err:
>>> -    /*
>>> -     * The cdev was briefly live, shutdown any ioctl operations that
>>> -     * saw that state.
>>> -     */
>>> -    cxl_memdev_shutdown(dev);
>>> -    put_device(dev);
>>> +    kfree(cxlmd);
>>>       return ERR_PTR(rc);
>>>   }
>>> -EXPORT_SYMBOL_NS_GPL(devm_cxl_add_memdev, "CXL");
>>> +EXPORT_SYMBOL_NS_GPL(cxl_memdev_alloc, "CXL");
>>>   static void sanitize_teardown_notifier(void *data)
>>>   {
>>> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
>>> index f7dc0ba8905d..144749b9c818 100644
>>> --- a/drivers/cxl/mem.c
>>> +++ b/drivers/cxl/mem.c
>>> @@ -7,6 +7,7 @@
>>>   #include "cxlmem.h"
>>>   #include "cxlpci.h"
>>> +#include "private.h"
>>>   #include "core/core.h"
>>>   /**
>>> @@ -203,6 +204,34 @@ static int cxl_mem_probe(struct device *dev)
>>>       return devm_add_action_or_reset(dev, enable_suspend, NULL);
>>>   }
>>> +/**
>>> + * devm_cxl_add_memdev - Add a CXL memory device
>>> + * @host: devres alloc/release context and parent for the memdev
>>> + * @cxlds: CXL device state to associate with the memdev
>>> + *
>>> + * Upon return the device will have had a chance to attach to the
>>> + * cxl_mem driver, but may fail if the CXL topology is not ready
>>> + * (hardware CXL link down, or software platform CXL root not attached)
>>> + */
>>> +struct cxl_memdev *devm_cxl_add_memdev(struct device *host,
>>> +                       struct cxl_dev_state *cxlds)
>>> +{
>>> +    struct cxl_memdev *cxlmd = cxl_memdev_alloc(cxlds);
>> Bit marginal but you could do a DEFINE_FREE() for cxlmd
>> similar to the one that exists for put_cxl_port
>>
>> You would then need to steal the pointer for the devm_ call at the
>> end of this function.
> 
> 
> We are not freeing cxlmd in case of errors after we got the allocation, 
> so I think it makes sense.
> 
> 
> Thank you.
> 
> 
>>
>>> +    int rc;
>>> +
>>> +    if (IS_ERR(cxlmd))
>>> +        return cxlmd;
>>> +
>>> +    rc = dev_set_name(&cxlmd->dev, "mem%d", cxlmd->id);
>>> +    if (rc) {
>>> +        put_device(&cxlmd->dev);
>>> +        return ERR_PTR(rc);
>>> +    }
>>> +
>>> +    return devm_cxl_memdev_add_or_reset(host, cxlmd);
>>> +}
>>> +EXPORT_SYMBOL_NS_GPL(devm_cxl_add_memdev, "CXL");
> 


  reply	other threads:[~2025-10-30 19:57 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-06 10:01 [PATCH v19 00/22] Type2 device basic support alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 01/22] cxl/mem: Arrange for always-synchronous memdev attach alejandro.lucero-palau
2025-10-07 12:40   ` Jonathan Cameron
2025-10-07 12:42     ` Jonathan Cameron
2025-10-10 23:11       ` Dave Jiang
2025-10-29 11:20     ` Alejandro Lucero Palau
2025-10-30 19:57       ` Koralahalli Channabasappa, Smita [this message]
2025-11-10 10:43         ` Alejandro Lucero Palau
2025-10-06 10:01 ` [PATCH v19 02/22] cxl/port: Arrange for always synchronous endpoint attach alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 03/22] cxl/mem: Introduce a memdev creation ->probe() operation alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 04/22] cxl: Add type2 device basic support alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 05/22] sfc: add cxl support alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 06/22] cxl: Move pci generic code alejandro.lucero-palau
2025-10-07 13:01   ` Jonathan Cameron
2025-11-10 11:23     ` Alejandro Lucero Palau
2025-11-11 13:41       ` Jonathan Cameron
2025-10-06 10:01 ` [PATCH v19 07/22] cxl: allow Type2 drivers to map cxl component regs alejandro.lucero-palau
2025-10-07 13:18   ` Jonathan Cameron
2025-11-10 11:28     ` Alejandro Lucero Palau
2025-10-06 10:01 ` [PATCH v19 08/22] cxl: Support dpa initialization without a mailbox alejandro.lucero-palau
2025-10-07 13:22   ` Jonathan Cameron
2025-11-10 11:28     ` Alejandro Lucero Palau
2025-10-06 10:01 ` [PATCH v19 09/22] cxl: Prepare memdev creation for type2 alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 10/22] sfc: create type2 cxl memdev alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 11/22] cxl: Define a driver interface for HPA free space enumeration alejandro.lucero-palau
2025-10-07 13:43   ` Jonathan Cameron
2025-11-10 11:46     ` Alejandro Lucero Palau
2025-10-09 20:55   ` Cheatham, Benjamin
2025-10-10 11:16     ` Alejandro Lucero Palau
2025-10-15 17:52       ` Dave Jiang
2025-10-15 18:17   ` Dave Jiang
2025-11-10 11:57     ` Alejandro Lucero Palau
2025-10-06 10:01 ` [PATCH v19 12/22] sfc: get root decoder alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 13/22] cxl: Define a driver interface for DPA allocation alejandro.lucero-palau
2025-10-07 13:52   ` Jonathan Cameron
2025-10-15 20:07     ` Dave Jiang
2025-11-10 12:02     ` Alejandro Lucero Palau
2025-10-15 20:08   ` Dave Jiang
2025-11-10 12:04     ` Alejandro Lucero Palau
2025-10-06 10:01 ` [PATCH v19 14/22] sfc: get endpoint decoder alejandro.lucero-palau
2025-10-15 20:15   ` Dave Jiang
2025-11-10 12:08     ` Alejandro Lucero Palau
2025-10-06 10:01 ` [PATCH v19 15/22] cxl: Make region type based on endpoint type alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 16/22] cxl/region: Factor out interleave ways setup alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 17/22] cxl/region: Factor out interleave granularity setup alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 18/22] cxl: Allow region creation by type2 drivers alejandro.lucero-palau
2025-10-07 14:11   ` Jonathan Cameron
2025-11-10 13:47     ` Alejandro Lucero Palau
2025-11-11 14:04       ` Jonathan Cameron
2025-10-09 20:56   ` Cheatham, Benjamin
2025-10-15 21:42     ` Dave Jiang
2025-10-16 13:23       ` Cheatham, Benjamin
2025-10-20 13:24         ` Alejandro Lucero Palau
2025-10-20 13:59           ` Dave Jiang
2025-10-20 14:59             ` Alejandro Lucero Palau
2025-10-15 21:36   ` Dave Jiang
2025-10-20 13:04     ` Alejandro Lucero Palau
2025-10-06 10:01 ` [PATCH v19 19/22] cxl: Avoid dax creation for accelerators alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 20/22] sfc: create cxl region alejandro.lucero-palau
2025-10-07 14:13   ` Jonathan Cameron
2025-10-06 10:01 ` [PATCH v19 21/22] cxl: Add function for obtaining region range alejandro.lucero-palau
2025-10-06 10:01 ` [PATCH v19 22/22] sfc: support pio mapping based on cxl alejandro.lucero-palau
2025-10-07 14:48   ` Jonathan Cameron
2025-11-10 14:54     ` Alejandro Lucero Palau
2025-10-07 23:41 ` [PATCH v19 00/22] Type2 device basic support Dave Jiang
2025-10-10 10:39   ` Alejandro Lucero Palau
2025-10-10 15:57     ` Dave Jiang
2025-10-10 16:54       ` Dave Jiang

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=030a36b6-0ade-4ee1-a535-9f01b15581a6@amd.com \
    --to=skoralah@amd.com \
    --cc=alejandro.lucero-palau@amd.com \
    --cc=alison.schofield@intel.com \
    --cc=alucerop@amd.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=edward.cree@amd.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=kuba@kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    /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