netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alejandro Lucero Palau <alucerop@amd.com>
To: Ben Cheatham <benjamin.cheatham@amd.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
Subject: Re: [PATCH v11 01/23] cxl: add type2 device basic support
Date: Wed, 12 Mar 2025 08:20:51 +0000	[thread overview]
Message-ID: <17816473-c2e7-4b60-9595-3935e92e3301@amd.com> (raw)
In-Reply-To: <bf26b669-860c-493e-8126-733615f47b13@amd.com>


On 3/11/25 20:05, Ben Cheatham wrote:
> On 3/10/25 4:03 PM, alejandro.lucero-palau@amd.com wrote:
>> From: Alejandro Lucero <alucerop@amd.com>
>>
>> Differentiate CXL memory expanders (type 3) from CXL device accelerators
>> (type 2) with a new function for initializing cxl_dev_state and a macro
>> for helping accel drivers to embed cxl_dev_state inside a private
>> struct.
>>
>> Move structs to include/cxl as the size of the accel driver private
>> struct embedding cxl_dev_state needs to know the size of this struct.
>>
>> Use same new initialization with the type3 pci driver.
>>
>> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
>> ---
>>   drivers/cxl/core/mbox.c   |  12 +--
>>   drivers/cxl/core/memdev.c |  32 ++++++
>>   drivers/cxl/core/pci.c    |   1 +
>>   drivers/cxl/core/regs.c   |   1 +
>>   drivers/cxl/cxl.h         |  97 +-----------------
>>   drivers/cxl/cxlmem.h      |  88 ++--------------
>>   drivers/cxl/cxlpci.h      |  21 ----
>>   drivers/cxl/pci.c         |  17 ++--
>>   include/cxl/cxl.h         | 206 ++++++++++++++++++++++++++++++++++++++
>>   include/cxl/pci.h         |  23 +++++
>>   10 files changed, 285 insertions(+), 213 deletions(-)
>>   create mode 100644 include/cxl/cxl.h
>>   create mode 100644 include/cxl/pci.h
>>
>> diff --git a/drivers/cxl/core/mbox.c b/drivers/cxl/core/mbox.c
>> index d72764056ce6..20df6f78f148 100644
>> --- a/drivers/cxl/core/mbox.c
>> +++ b/drivers/cxl/core/mbox.c
>> @@ -1484,23 +1484,21 @@ int cxl_mailbox_init(struct cxl_mailbox *cxl_mbox, struct device *host)
>>   }
>>   EXPORT_SYMBOL_NS_GPL(cxl_mailbox_init, "CXL");
>>   
>> -struct cxl_memdev_state *cxl_memdev_state_create(struct device *dev)
>> +struct cxl_memdev_state *cxl_memdev_state_create(struct device *dev, u64 serial,
>> +						 u16 dvsec)
>>   {
>>   	struct cxl_memdev_state *mds;
>>   	int rc;
>>   
>> -	mds = devm_kzalloc(dev, sizeof(*mds), GFP_KERNEL);
>> +	mds = (struct cxl_memdev_state *)
>> +		_cxl_dev_state_create(dev, CXL_DEVTYPE_CLASSMEM, serial, dvsec,
>> +				      sizeof(struct cxl_memdev_state), true);
> I would use sizeof(*mds) instead of sizeof(struct cxl_memdev_state) above.


Yes.


>
> What's the reason to not use the cxl_dev_state_create() macro here instead? Based on the commit
> message I'm assuming it's because it's meant for accelerator drivers and this is a type 3 driver,
> but I'm going to suggest using it here anyway (and maybe amending the commit message).


The reason is the macro does checks we know for sure are not necessary 
for the cxl core pci driver for Type3.

But I have no problem using it here as well. If there are more opinions 
like yours, I'll do.


>>   	if (!mds) {
>>   		dev_err(dev, "No memory available\n");
>>   		return ERR_PTR(-ENOMEM);
>>   	}
>>   
>>   	mutex_init(&mds->event.log_lock);
>> -	mds->cxlds.dev = dev;
>> -	mds->cxlds.reg_map.host = dev;
>> -	mds->cxlds.cxl_mbox.host = dev;
>> -	mds->cxlds.reg_map.resource = CXL_RESOURCE_NONE;
>> -	mds->cxlds.type = CXL_DEVTYPE_CLASSMEM;
>>   
> [snip]
>
>> +/**
>> + * struct cxl_dev_state - The driver device state
>> + *
>> + * cxl_dev_state represents the CXL driver/device state.  It provides an
>> + * interface to mailbox commands as well as some cached data about the device.
>> + * Currently only memory devices are represented.
>> + *
>> + * @dev: The device associated with this CXL state
>> + * @cxlmd: The device representing the CXL.mem capabilities of @dev
>> + * @reg_map: component and ras register mapping parameters
>> + * @regs: Parsed register blocks
>> + * @cxl_dvsec: Offset to the PCIe device DVSEC
>> + * @rcd: operating in RCD mode (CXL 3.0 9.11.8 CXL Devices Attached to an RCH)
>> + * @media_ready: Indicate whether the device media is usable
>> + * @dpa_res: Overall DPA resource tree for the device
>> + * @part: DPA partition array
>> + * @nr_partitions: Number of DPA partitions
>> + * @serial: PCIe Device Serial Number
>> + * @type: Generic Memory Class device or Vendor Specific Memory device
>> + * @cxl_mbox: CXL mailbox context
>> + * @cxlfs: CXL features context
>> + */
>> +struct cxl_dev_state {
>> +	struct device *dev;
>> +	struct cxl_memdev *cxlmd;
>> +	struct cxl_register_map reg_map;
>> +	struct cxl_regs regs;
>> +	int cxl_dvsec;
>> +	bool rcd;
>> +	bool media_ready;
>> +	struct resource dpa_res;
>> +	struct cxl_dpa_partition part[CXL_NR_PARTITIONS_MAX];
>> +	unsigned int nr_partitions;
>> +	u64 serial;
>> +	enum cxl_devtype type;
>> +	struct cxl_mailbox cxl_mbox;
>> +#ifdef CONFIG_CXL_FEATURES
>> +	struct cxl_features_state *cxlfs;
>> +#endif
>> +};
> What happened to the comments for private/public fields for this struct that Dan suggested in
> your RFC? If you don't think they're needed that's fine, I'm just curious!


I just forgot to add them. :-(

I'll do so in v12 ...

Thanks!



  reply	other threads:[~2025-03-12  8:21 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-10 21:03 [PATCH v11 00/23] add type2 device basic support alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 01/23] cxl: " alejandro.lucero-palau
2025-03-11 20:05   ` Ben Cheatham
2025-03-12  8:20     ` Alejandro Lucero Palau [this message]
2025-03-12 20:00   ` Alison Schofield
2025-03-17  7:56     ` Alejandro Lucero Palau
2025-03-10 21:03 ` [PATCH v11 02/23] sfc: add cxl support alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 03/23] cxl: move pci generic code alejandro.lucero-palau
2025-03-11 20:05   ` Ben Cheatham
2025-03-12  8:26     ` Alejandro Lucero Palau
2025-03-10 21:03 ` [PATCH v11 04/23] cxl: move register/capability check to driver alejandro.lucero-palau
2025-03-11 20:05   ` Ben Cheatham
2025-03-25 14:21     ` Alejandro Lucero Palau
2025-03-10 21:03 ` [PATCH v11 05/23] cxl: add function for type2 cxl regs setup alejandro.lucero-palau
2025-03-11 20:05   ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 06/23] sfc: make regs setup with checking and set media ready alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 07/23] cxl: support dpa initialization without a mailbox alejandro.lucero-palau
2025-03-11 20:05   ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 08/23] sfc: initialize dpa alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 09/23] cxl: prepare memdev creation for type2 alejandro.lucero-palau
2025-03-11 20:05   ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 10/23] sfc: create type2 cxl memdev alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 11/23] cxl: define a driver interface for HPA free space enumeration alejandro.lucero-palau
2025-03-11 20:06   ` Ben Cheatham
2025-03-25 15:07     ` Alejandro Lucero Palau
2025-03-25 15:46       ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 12/23] fc: obtain root decoder with enough HPA free space alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 13/23] cxl: define a driver interface for DPA allocation alejandro.lucero-palau
2025-03-11 19:12   ` kernel test robot
2025-03-11 20:06   ` Ben Cheatham
2025-03-11 20:17   ` kernel test robot
2025-03-20 16:18   ` Simon Horman
2025-03-24 16:16     ` Alejandro Lucero Palau
2025-03-25 15:23       ` Simon Horman
2025-03-10 21:03 ` [PATCH v11 14/23] sfc: get endpoint decoder alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 15/23] cxl: make region type based on endpoint type alejandro.lucero-palau
2025-03-11 20:06   ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 16/23] cxl/region: factor out interleave ways setup alejandro.lucero-palau
2025-03-11 20:06   ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 17/23] cxl/region: factor out interleave granularity setup alejandro.lucero-palau
2025-03-11 20:06   ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 18/23] cxl: allow region creation by type2 drivers alejandro.lucero-palau
2025-03-11 20:06   ` Ben Cheatham
2025-03-12  8:28     ` Alejandro Lucero Palau
2025-03-20 16:21   ` Simon Horman
2025-03-10 21:03 ` [PATCH v11 19/23] cxl: add region flag for precluding a device memory to be used for dax alejandro.lucero-palau
2025-03-11 20:06   ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 20/23] sfc: create cxl region alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 21/23] cxl: add function for obtaining region range alejandro.lucero-palau
2025-03-11 20:06   ` Ben Cheatham
2025-03-10 21:03 ` [PATCH v11 22/23] sfc: update MCDI protocol headers alejandro.lucero-palau
2025-03-10 21:03 ` [PATCH v11 23/23] sfc: support pio mapping based on cxl alejandro.lucero-palau
2025-03-12  6:42   ` kernel test robot
2025-03-12 17:57 ` [PATCH v11 00/23] add type2 device basic support Alison Schofield
2025-03-17  7:55   ` Alejandro Lucero Palau

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=17816473-c2e7-4b60-9595-3935e92e3301@amd.com \
    --to=alucerop@amd.com \
    --cc=alejandro.lucero-palau@amd.com \
    --cc=benjamin.cheatham@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=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;
as well as URLs for NNTP newsgroup(s).