From: Alejandro Lucero Palau <alucerop@amd.com>
To: 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, martin.habets@xilinx.com,
edward.cree@amd.com, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, edumazet@google.com
Subject: Re: [PATCH v3 02/20] cxl: add capabilities field to cxl_dev_state and cxl_port
Date: Mon, 16 Sep 2024 13:13:57 +0100 [thread overview]
Message-ID: <d299d623-429e-ec64-2d36-c6456793978b@amd.com> (raw)
In-Reply-To: <20240913182552.000003ed@Huawei.com>
On 9/13/24 18:25, Jonathan Cameron wrote:
> On Sat, 7 Sep 2024 09:18:18 +0100
> alejandro.lucero-palau@amd.com wrote:
>
>> From: Alejandro Lucero <alucerop@amd.com>
>>
>> Type2 devices have some Type3 functionalities as optional like an mbox
>> or an hdm decoder, and CXL core needs a way to know what an CXL accelerator
>> implements.
>>
>> Add a new field for keeping device capabilities as discovered during
>> initialization.
>>
>> Add same field to cxl_port which for an endpoint will use those
>> capabilities discovered previously, and which will be initialized when
>> calling cxl_port_setup_regs for no endpoints.
>>
>> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
> Hi,
>
> My only real suggestion on this one is to use a bitmap to make
> it easy to extend the capabilities as needed in future.
> That means passing an unsigned long pointer around.
>
It makes sense.
I'll do.
>> @@ -600,6 +600,7 @@ struct cxl_dax_region {
>> * @cdat: Cached CDAT data
>> * @cdat_available: Should a CDAT attribute be available in sysfs
>> * @pci_latency: Upstream latency in picoseconds
>> + * @capabilities: those capabilities as defined in device mapped registers
>> */
>> struct cxl_port {
>> struct device dev;
>> @@ -623,6 +624,7 @@ struct cxl_port {
>> } cdat;
>> bool cdat_available;
>> long pci_latency;
>> + u32 capabilities;
> Use DECLARE_BITMAP() for this to make life easy should we ever
> have more than 32.
>
>> };
>>
>> /**
>> diff --git a/drivers/cxl/cxlmem.h b/drivers/cxl/cxlmem.h
>> index afb53d058d62..37c043100300 100644
>> --- a/drivers/cxl/cxlmem.h
>> +++ b/drivers/cxl/cxlmem.h
>> @@ -424,6 +424,7 @@ struct cxl_dpa_perf {
>> * @ram_res: Active Volatile memory capacity configuration
>> * @serial: PCIe Device Serial Number
>> * @type: Generic Memory Class device or Vendor Specific Memory device
>> + * @capabilities: those capabilities as defined in device mapped registers
>> */
>> struct cxl_dev_state {
>> struct device *dev;
>> @@ -438,6 +439,7 @@ struct cxl_dev_state {
>> struct resource ram_res;
>> u64 serial;
>> enum cxl_devtype type;
>> + u32 capabilities;
> As above, use a bitmap and access it with the various bitmap operators
> so that we aren't constrained to 32 bits given half are
> used already.
I though maybe I should use u64 ...
>
>> };
>>
>> /**
>> diff --git a/include/linux/cxl/cxl.h b/include/linux/cxl/cxl.h
>> index e78eefa82123..930b1b9c1d6a 100644
>> --- a/include/linux/cxl/cxl.h
>> +++ b/include/linux/cxl/cxl.h
>> @@ -12,6 +12,36 @@ enum cxl_resource {
>> CXL_ACCEL_RES_PMEM,
>> };
>>
>> +/* Capabilities as defined for:
> Trivial but cxl tends to do
> /*
> * Capabilities ..
>
> style multiline comments.
Right. I'll fit it.
>> + *
>> + * Component Registers (Table 8-22 CXL 3.0 specification)
>> + * Device Registers (8.2.8.2.1 CXL 3.0 specification)
>> + */
>> +
>> +enum cxl_dev_cap {
>> + /* capabilities from Component Registers */
>> + CXL_DEV_CAP_RAS,
>> + CXL_DEV_CAP_SEC,
>> + CXL_DEV_CAP_LINK,
>> + CXL_DEV_CAP_HDM,
>> + CXL_DEV_CAP_SEC_EXT,
>> + CXL_DEV_CAP_IDE,
>> + CXL_DEV_CAP_SNOOP_FILTER,
>> + CXL_DEV_CAP_TIMEOUT_AND_ISOLATION,
>> + CXL_DEV_CAP_CACHEMEM_EXT,
>> + CXL_DEV_CAP_BI_ROUTE_TABLE,
>> + CXL_DEV_CAP_BI_DECODER,
>> + CXL_DEV_CAP_CACHEID_ROUTE_TABLE,
>> + CXL_DEV_CAP_CACHEID_DECODER,
>> + CXL_DEV_CAP_HDM_EXT,
>> + CXL_DEV_CAP_METADATA_EXT,
>> + /* capabilities from Device Registers */
>> + CXL_DEV_CAP_DEV_STATUS,
>> + CXL_DEV_CAP_MAILBOX_PRIMARY,
>> + CXL_DEV_CAP_MAILBOX_SECONDARY,
> Dan raised this one already - definitely not something any
> driver in Linux should be aware of. Hence just drop this entry.
You mean never ever or just by now?
Maybe I'm missing something specific to the secondary mailbox, but if
the rule is if none used yet, do not add it, then there are other caps I
should remove as well.
>> + CXL_DEV_CAP_MEMDEV,
>> +};
>> +
>> struct cxl_dev_state *cxl_accel_state_create(struct device *dev);
>>
>> void cxl_set_dvsec(struct cxl_dev_state *cxlds, u16 dvsec);
next prev parent reply other threads:[~2024-09-16 12:15 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-07 8:18 [PATCH v3 00/20] cxl: add Type2 device support alejandro.lucero-palau
2024-09-07 8:18 ` [PATCH v3 01/20] cxl: add type2 device basic support alejandro.lucero-palau
2024-09-07 20:26 ` kernel test robot
2024-09-10 6:12 ` Li, Ming4
2024-09-10 7:25 ` Alejandro Lucero Palau
2024-09-12 8:57 ` Zhi Wang
2024-09-16 9:52 ` Alejandro Lucero Palau
2024-09-12 9:35 ` Zhi Wang
2024-09-16 10:03 ` Alejandro Lucero Palau
2024-09-13 16:41 ` Jonathan Cameron
2024-09-16 12:03 ` Alejandro Lucero Palau
2024-09-16 12:24 ` Jonathan Cameron
2024-09-07 8:18 ` [PATCH v3 02/20] cxl: add capabilities field to cxl_dev_state and cxl_port alejandro.lucero-palau
2024-09-07 18:08 ` kernel test robot
2024-09-11 22:17 ` Dave Jiang
2024-09-16 8:36 ` Alejandro Lucero Palau
2024-09-16 16:07 ` Dave Jiang
2024-09-13 17:25 ` Jonathan Cameron
2024-09-16 12:13 ` Alejandro Lucero Palau [this message]
2024-09-07 8:18 ` [PATCH v3 03/20] cxl/pci: add check for validating capabilities alejandro.lucero-palau
2024-09-10 3:26 ` Li, Ming4
2024-09-10 6:24 ` Li, Ming4
2024-09-10 7:31 ` Alejandro Lucero Palau
2024-09-11 23:06 ` Dave Jiang
2024-09-16 8:56 ` Alejandro Lucero Palau
2024-09-16 16:11 ` Dave Jiang
2024-09-13 17:28 ` Jonathan Cameron
2024-09-16 12:17 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 04/20] cxl: move pci generic code alejandro.lucero-palau
2024-09-11 23:55 ` Dave Jiang
2024-09-16 9:46 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 05/20] cxl: add function for type2 cxl regs setup alejandro.lucero-palau
2024-09-10 6:00 ` Li, Ming4
2024-09-10 7:24 ` Alejandro Lucero Palau
2024-09-12 9:08 ` Zhi Wang
2024-09-13 17:32 ` Jonathan Cameron
2024-09-16 12:23 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 06/20] cxl: add functions for resource request/release by a driver alejandro.lucero-palau
2024-09-10 6:15 ` Li, Ming4
2024-09-16 8:15 ` Alejandro Lucero Palau
2024-09-13 17:35 ` Jonathan Cameron
2024-09-16 12:33 ` Alejandro Lucero Palau
2024-09-16 13:21 ` Jonathan Cameron
2024-09-07 8:18 ` [PATCH v3 07/20] cxl: harden resource_contains checks to handle zero size resources alejandro.lucero-palau
2024-09-13 17:36 ` Jonathan Cameron
2024-09-16 12:36 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 08/20] cxl: add function for setting media ready by a driver alejandro.lucero-palau
2024-09-07 8:18 ` [PATCH v3 09/20] cxl: support type2 memdev creation alejandro.lucero-palau
2024-09-12 18:19 ` Dave Jiang
2024-09-16 12:38 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 10/20] cxl: indicate probe deferral alejandro.lucero-palau
2024-09-10 6:37 ` Li, Ming4
2024-09-16 8:24 ` Alejandro Lucero Palau
2024-09-17 3:31 ` Li, Ming4
2024-09-17 9:16 ` Alejandro Lucero Palau
2024-09-12 9:19 ` Zhi Wang
2024-09-16 10:08 ` Alejandro Lucero Palau
2024-09-13 17:43 ` Jonathan Cameron
2024-09-16 13:24 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 11/20] cxl: define a driver interface for HPA free space enumaration alejandro.lucero-palau
2024-09-13 17:52 ` Jonathan Cameron
2024-09-16 14:09 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 12/20] efx: use acquire_endpoint when looking for free HPA alejandro.lucero-palau
2024-09-07 19:33 ` kernel test robot
2024-09-12 23:09 ` Dave Jiang
2024-09-16 10:29 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 13/20] cxl: define a driver interface for DPA allocation alejandro.lucero-palau
2024-09-13 17:59 ` Jonathan Cameron
2024-09-16 14:26 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 14/20] cxl: make region type based on endpoint type alejandro.lucero-palau
2024-09-07 8:18 ` [PATCH v3 15/20] cxl/region: factor out interleave ways setup alejandro.lucero-palau
2024-09-07 8:18 ` [PATCH v3 16/20] cxl/region: factor out interleave granularity setup alejandro.lucero-palau
2024-09-07 8:18 ` [PATCH v3 17/20] cxl: allow region creation by type2 drivers alejandro.lucero-palau
2024-09-13 18:08 ` Jonathan Cameron
2024-09-16 16:31 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 18/20] cxl: preclude device memory to be used for dax alejandro.lucero-palau
2024-09-13 17:26 ` Dave Jiang
2024-09-16 14:32 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 19/20] cxl: add function for obtaining params from a region alejandro.lucero-palau
2024-09-13 17:48 ` Dave Jiang
2024-09-16 16:22 ` Alejandro Lucero Palau
2024-09-07 8:18 ` [PATCH v3 20/20] efx: support pio mapping based on cxl alejandro.lucero-palau
2024-09-13 17:45 ` Edward Cree
2024-09-16 16:12 ` Alejandro Lucero Palau
2024-09-13 17:52 ` Dave Jiang
2024-09-16 16:23 ` Alejandro Lucero Palau
2024-09-13 18:10 ` Jonathan Cameron
2024-09-16 16:23 ` 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=d299d623-429e-ec64-2d36-c6456793978b@amd.com \
--to=alucerop@amd.com \
--cc=Jonathan.Cameron@Huawei.com \
--cc=alejandro.lucero-palau@amd.com \
--cc=dan.j.williams@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=martin.habets@xilinx.com \
--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