2021-08-02 10:30:05 -07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
/* Copyright(c) 2020 Intel Corporation. */
|
|
|
|
|
2023-06-12 11:10:35 -07:00
|
|
|
#include <linux/io-64-nonatomic-lo-hi.h>
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
#include <linux/firmware.h>
|
2021-08-02 10:30:05 -07:00
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/idr.h>
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <cxlmem.h>
|
2023-04-18 20:26:28 -07:00
|
|
|
#include "trace.h"
|
2021-08-02 10:30:05 -07:00
|
|
|
#include "core.h"
|
|
|
|
|
2021-09-08 22:12:32 -07:00
|
|
|
static DECLARE_RWSEM(cxl_memdev_rwsem);
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
/*
|
|
|
|
* An entire PCI topology full of devices should be enough for any
|
|
|
|
* config
|
|
|
|
*/
|
|
|
|
#define CXL_MEM_MAX_DEVS 65536
|
|
|
|
|
|
|
|
static int cxl_mem_major;
|
|
|
|
static DEFINE_IDA(cxl_memdev_ida);
|
|
|
|
|
|
|
|
static void cxl_memdev_release(struct device *dev)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
|
|
|
|
ida_free(&cxl_memdev_ida, cxlmd->id);
|
2025-05-21 13:47:44 +01:00
|
|
|
devm_cxl_memdev_edac_release(cxlmd);
|
2021-08-02 10:30:05 -07:00
|
|
|
kfree(cxlmd);
|
|
|
|
}
|
|
|
|
|
2023-01-11 12:30:08 +01:00
|
|
|
static char *cxl_memdev_devnode(const struct device *dev, umode_t *mode, kuid_t *uid,
|
2021-08-02 10:30:05 -07:00
|
|
|
kgid_t *gid)
|
|
|
|
{
|
|
|
|
return kasprintf(GFP_KERNEL, "cxl/%s", dev_name(dev));
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t firmware_version_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
2021-11-02 13:29:01 -07:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2023-06-14 18:30:02 -07:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
2021-08-02 10:30:05 -07:00
|
|
|
|
2023-06-14 18:30:07 -07:00
|
|
|
if (!mds)
|
|
|
|
return sysfs_emit(buf, "\n");
|
2023-06-14 18:30:02 -07:00
|
|
|
return sysfs_emit(buf, "%.16s\n", mds->firmware_version);
|
2021-08-02 10:30:05 -07:00
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(firmware_version);
|
|
|
|
|
|
|
|
static ssize_t payload_max_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
2021-11-02 13:29:01 -07:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2023-06-14 18:30:02 -07:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
2021-08-02 10:30:05 -07:00
|
|
|
|
2023-06-14 18:30:07 -07:00
|
|
|
if (!mds)
|
|
|
|
return sysfs_emit(buf, "\n");
|
2024-09-05 15:35:46 -07:00
|
|
|
return sysfs_emit(buf, "%zu\n", cxlds->cxl_mbox.payload_size);
|
2021-08-02 10:30:05 -07:00
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(payload_max);
|
|
|
|
|
|
|
|
static ssize_t label_storage_size_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
2021-11-02 13:29:01 -07:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2023-06-14 18:30:02 -07:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
2021-08-02 10:30:05 -07:00
|
|
|
|
2023-06-14 18:30:07 -07:00
|
|
|
if (!mds)
|
|
|
|
return sysfs_emit(buf, "\n");
|
2023-06-14 18:30:02 -07:00
|
|
|
return sysfs_emit(buf, "%zu\n", mds->lsa_size);
|
2021-08-02 10:30:05 -07:00
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(label_storage_size);
|
|
|
|
|
2025-02-03 20:24:35 -08:00
|
|
|
static resource_size_t cxl_ram_size(struct cxl_dev_state *cxlds)
|
|
|
|
{
|
|
|
|
/* Static RAM is only expected at partition 0. */
|
|
|
|
if (cxlds->part[0].mode != CXL_PARTMODE_RAM)
|
|
|
|
return 0;
|
|
|
|
return resource_size(&cxlds->part[0].res);
|
|
|
|
}
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static ssize_t ram_size_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
2021-11-02 13:29:01 -07:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
cxl: Introduce 'struct cxl_dpa_partition' and 'struct cxl_range_info'
The pending efforts to add CXL Accelerator (type-2) device [1], and
Dynamic Capacity (DCD) support [2], tripped on the
no-longer-fit-for-purpose design in the CXL subsystem for tracking
device-physical-address (DPA) metadata. Trip hazards include:
- CXL Memory Devices need to consider a PMEM partition, but Accelerator
devices with CXL.mem likely do not in the common case.
- CXL Memory Devices enumerate DPA through Memory Device mailbox
commands like Partition Info, Accelerators devices do not.
- CXL Memory Devices that support DCD support more than 2 partitions.
Some of the driver algorithms are awkward to expand to > 2 partition
cases.
- DPA performance data is a general capability that can be shared with
accelerators, so tracking it in 'struct cxl_memdev_state' is no longer
suitable.
- Hardcoded assumptions around the PMEM partition always being index-1
if RAM is zero-sized or PMEM is zero sized.
- 'enum cxl_decoder_mode' is sometimes a partition id and sometimes a
memory property, it should be phased in favor of a partition id and
the memory property comes from the partition info.
Towards cleaning up those issues and allowing a smoother landing for the
aforementioned pending efforts, introduce a 'struct cxl_dpa_partition'
array to 'struct cxl_dev_state', and 'struct cxl_range_info' as a shared
way for Memory Devices and Accelerators to initialize the DPA information
in 'struct cxl_dev_state'.
For now, split a new cxl_dpa_setup() from cxl_mem_create_range_info() to
get the new data structure initialized, and cleanup some qos_class init.
Follow on patches will go further to use the new data structure to
cleanup algorithms that are better suited to loop over all possible
partitions.
cxl_dpa_setup() follows the locking expectations of mutating the device
DPA map, and is suitable for Accelerator drivers to use. Accelerators
likely only have one hardcoded 'ram' partition to convey to the
cxl_core.
Link: http://lore.kernel.org/20241230214445.27602-1-alejandro.lucero-palau@amd.com [1]
Link: http://lore.kernel.org/20241210-dcd-type2-upstream-v8-0-812852504400@intel.com [2]
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alejandro Lucero <alucerop@amd.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305827.668823.13978794102080021276.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:18 -08:00
|
|
|
unsigned long long len = cxl_ram_size(cxlds);
|
2021-08-02 10:30:05 -07:00
|
|
|
|
|
|
|
return sysfs_emit(buf, "%#llx\n", len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct device_attribute dev_attr_ram_size =
|
|
|
|
__ATTR(size, 0444, ram_size_show, NULL);
|
|
|
|
|
|
|
|
static ssize_t pmem_size_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
2021-11-02 13:29:01 -07:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
cxl: Introduce to_{ram,pmem}_{res,perf}() helpers
In preparation for consolidating all DPA partition information into an
array of DPA metadata, introduce helpers that hide the layout of the
current data. I.e. make the eventual replacement of ->ram_res,
->pmem_res, ->ram_perf, and ->pmem_perf with a new DPA metadata array a
no-op for code paths that consume that information, and reduce the noise
of follow-on patches.
The end goal is to consolidate all DPA information in 'struct
cxl_dev_state', but for now the helpers just make it appear that all DPA
metadata is relative to @cxlds.
As the conversion to generic partition metadata walking is completed,
these helpers will naturally be eliminated, or reduced in scope.
Cc: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305238.668823.16553986866633608541.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:12 -08:00
|
|
|
unsigned long long len = cxl_pmem_size(cxlds);
|
2021-08-02 10:30:05 -07:00
|
|
|
|
|
|
|
return sysfs_emit(buf, "%#llx\n", len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct device_attribute dev_attr_pmem_size =
|
|
|
|
__ATTR(size, 0444, pmem_size_show, NULL);
|
|
|
|
|
2022-01-31 13:56:11 -08:00
|
|
|
static ssize_t serial_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
|
|
|
|
|
|
|
return sysfs_emit(buf, "%#llx\n", cxlds->serial);
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(serial);
|
|
|
|
|
2022-01-23 16:31:24 -08:00
|
|
|
static ssize_t numa_node_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
2024-01-12 14:27:09 +08:00
|
|
|
return sysfs_emit(buf, "%d\n", dev_to_node(dev));
|
2022-01-23 16:31:24 -08:00
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(numa_node);
|
|
|
|
|
2023-06-12 11:10:33 -07:00
|
|
|
static ssize_t security_state_show(struct device *dev,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2024-09-05 15:35:46 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &cxlds->cxl_mbox;
|
2023-06-25 17:16:51 -07:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
|
|
|
unsigned long state = mds->security.state;
|
2023-10-04 18:35:01 -07:00
|
|
|
int rc = 0;
|
2023-06-12 11:10:35 -07:00
|
|
|
|
2023-10-04 18:35:01 -07:00
|
|
|
/* sync with latest submission state */
|
2024-09-05 15:35:46 -07:00
|
|
|
mutex_lock(&cxl_mbox->mbox_mutex);
|
2023-10-04 18:35:01 -07:00
|
|
|
if (mds->security.sanitize_active)
|
|
|
|
rc = sysfs_emit(buf, "sanitize\n");
|
2024-09-05 15:35:46 -07:00
|
|
|
mutex_unlock(&cxl_mbox->mbox_mutex);
|
2023-10-04 18:35:01 -07:00
|
|
|
if (rc)
|
|
|
|
return rc;
|
2023-06-12 11:10:33 -07:00
|
|
|
|
|
|
|
if (!(state & CXL_PMEM_SEC_STATE_USER_PASS_SET))
|
|
|
|
return sysfs_emit(buf, "disabled\n");
|
|
|
|
if (state & CXL_PMEM_SEC_STATE_FROZEN ||
|
|
|
|
state & CXL_PMEM_SEC_STATE_MASTER_PLIMIT ||
|
|
|
|
state & CXL_PMEM_SEC_STATE_USER_PLIMIT)
|
|
|
|
return sysfs_emit(buf, "frozen\n");
|
|
|
|
if (state & CXL_PMEM_SEC_STATE_LOCKED)
|
|
|
|
return sysfs_emit(buf, "locked\n");
|
2025-05-09 17:06:46 +02:00
|
|
|
|
|
|
|
return sysfs_emit(buf, "unlocked\n");
|
2023-06-12 11:10:33 -07:00
|
|
|
}
|
|
|
|
static struct device_attribute dev_attr_security_state =
|
|
|
|
__ATTR(state, 0444, security_state_show, NULL);
|
|
|
|
|
2023-06-12 11:10:35 -07:00
|
|
|
static ssize_t security_sanitize_store(struct device *dev,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
const char *buf, size_t len)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
bool sanitize;
|
2023-06-25 17:16:51 -07:00
|
|
|
ssize_t rc;
|
2023-06-12 11:10:35 -07:00
|
|
|
|
|
|
|
if (kstrtobool(buf, &sanitize) || !sanitize)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-10-04 18:35:01 -07:00
|
|
|
rc = cxl_mem_sanitize(cxlmd, CXL_MBOX_OP_SANITIZE);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
2023-06-12 11:10:35 -07:00
|
|
|
|
2023-10-04 18:35:01 -07:00
|
|
|
return len;
|
2023-06-12 11:10:35 -07:00
|
|
|
}
|
|
|
|
static struct device_attribute dev_attr_security_sanitize =
|
|
|
|
__ATTR(sanitize, 0200, NULL, security_sanitize_store);
|
|
|
|
|
2023-06-12 11:10:37 -07:00
|
|
|
static ssize_t security_erase_store(struct device *dev,
|
|
|
|
struct device_attribute *attr,
|
|
|
|
const char *buf, size_t len)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
ssize_t rc;
|
|
|
|
bool erase;
|
|
|
|
|
|
|
|
if (kstrtobool(buf, &erase) || !erase)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-10-04 18:35:01 -07:00
|
|
|
rc = cxl_mem_sanitize(cxlmd, CXL_MBOX_OP_SECURE_ERASE);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
2023-06-12 11:10:37 -07:00
|
|
|
|
2023-10-04 18:35:01 -07:00
|
|
|
return len;
|
2023-06-12 11:10:37 -07:00
|
|
|
}
|
|
|
|
static struct device_attribute dev_attr_security_erase =
|
|
|
|
__ATTR(erase, 0200, NULL, security_erase_store);
|
|
|
|
|
2023-04-18 10:39:06 -07:00
|
|
|
static int cxl_get_poison_by_memdev(struct cxl_memdev *cxlmd)
|
|
|
|
{
|
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
|
|
|
u64 offset, length;
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
/* CXL 3.0 Spec 8.2.9.8.4.1 Separate pmem and ram poison requests */
|
2025-02-03 20:24:29 -08:00
|
|
|
for (int i = 0; i < cxlds->nr_partitions; i++) {
|
|
|
|
const struct resource *res = &cxlds->part[i].res;
|
cxl: Introduce to_{ram,pmem}_{res,perf}() helpers
In preparation for consolidating all DPA partition information into an
array of DPA metadata, introduce helpers that hide the layout of the
current data. I.e. make the eventual replacement of ->ram_res,
->pmem_res, ->ram_perf, and ->pmem_perf with a new DPA metadata array a
no-op for code paths that consume that information, and reduce the noise
of follow-on patches.
The end goal is to consolidate all DPA information in 'struct
cxl_dev_state', but for now the helpers just make it appear that all DPA
metadata is relative to @cxlds.
As the conversion to generic partition metadata walking is completed,
these helpers will naturally be eliminated, or reduced in scope.
Cc: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305238.668823.16553986866633608541.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:12 -08:00
|
|
|
|
|
|
|
offset = res->start;
|
|
|
|
length = resource_size(res);
|
2023-04-18 10:39:06 -07:00
|
|
|
rc = cxl_mem_get_poison(cxlmd, offset, length, NULL);
|
|
|
|
/*
|
|
|
|
* Invalid Physical Address is not an error for
|
|
|
|
* volatile addresses. Device support is optional.
|
|
|
|
*/
|
2025-02-03 20:24:29 -08:00
|
|
|
if (rc == -EFAULT && cxlds->part[i].mode == CXL_PARTMODE_RAM)
|
2023-04-18 10:39:06 -07:00
|
|
|
rc = 0;
|
|
|
|
}
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
int cxl_trigger_poison_list(struct cxl_memdev *cxlmd)
|
|
|
|
{
|
2023-04-18 10:39:07 -07:00
|
|
|
struct cxl_port *port;
|
2023-04-18 10:39:06 -07:00
|
|
|
int rc;
|
|
|
|
|
2023-06-14 18:30:43 -07:00
|
|
|
port = cxlmd->endpoint;
|
2023-04-18 10:39:07 -07:00
|
|
|
if (!port || !is_cxl_endpoint(port))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2025-07-11 16:49:32 -07:00
|
|
|
ACQUIRE(rwsem_read_intr, region_rwsem)(&cxl_rwsem.region);
|
|
|
|
if ((rc = ACQUIRE_ERR(rwsem_read_intr, ®ion_rwsem)))
|
2023-04-18 10:39:06 -07:00
|
|
|
return rc;
|
|
|
|
|
2025-07-11 16:49:32 -07:00
|
|
|
ACQUIRE(rwsem_read_intr, dpa_rwsem)(&cxl_rwsem.dpa);
|
|
|
|
if ((rc = ACQUIRE_ERR(rwsem_read_intr, &dpa_rwsem)))
|
2023-11-26 16:09:29 -08:00
|
|
|
return rc;
|
|
|
|
|
2023-10-16 10:57:48 -07:00
|
|
|
if (cxl_num_decoders_committed(port) == 0) {
|
2023-04-18 10:39:07 -07:00
|
|
|
/* No regions mapped to this memdev */
|
|
|
|
rc = cxl_get_poison_by_memdev(cxlmd);
|
|
|
|
} else {
|
|
|
|
/* Regions mapped, collect poison by endpoint */
|
|
|
|
rc = cxl_get_poison_by_endpoint(port);
|
|
|
|
}
|
2023-04-18 10:39:06 -07:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(cxl_trigger_poison_list, "CXL");
|
2023-04-18 10:39:06 -07:00
|
|
|
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
static int cxl_validate_poison_dpa(struct cxl_memdev *cxlmd, u64 dpa)
|
|
|
|
{
|
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_DEBUG_FS))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (!resource_size(&cxlds->dpa_res)) {
|
|
|
|
dev_dbg(cxlds->dev, "device has no dpa resource\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2025-07-11 11:23:57 +08:00
|
|
|
if (!cxl_resource_contains_addr(&cxlds->dpa_res, dpa)) {
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
dev_dbg(cxlds->dev, "dpa:0x%llx not in resource:%pR\n",
|
|
|
|
dpa, &cxlds->dpa_res);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (!IS_ALIGNED(dpa, 64)) {
|
|
|
|
dev_dbg(cxlds->dev, "dpa:0x%llx is not 64-byte aligned\n", dpa);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int cxl_inject_poison(struct cxl_memdev *cxlmd, u64 dpa)
|
|
|
|
{
|
2024-09-05 15:35:47 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &cxlmd->cxlds->cxl_mbox;
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
struct cxl_mbox_inject_poison inject;
|
2023-04-18 20:26:28 -07:00
|
|
|
struct cxl_poison_record record;
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
2023-04-18 20:26:27 -07:00
|
|
|
struct cxl_region *cxlr;
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_DEBUG_FS))
|
|
|
|
return 0;
|
|
|
|
|
2025-07-11 16:49:32 -07:00
|
|
|
ACQUIRE(rwsem_read_intr, region_rwsem)(&cxl_rwsem.region);
|
|
|
|
if ((rc = ACQUIRE_ERR(rwsem_read_intr, ®ion_rwsem)))
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
return rc;
|
|
|
|
|
2025-07-11 16:49:32 -07:00
|
|
|
ACQUIRE(rwsem_read_intr, dpa_rwsem)(&cxl_rwsem.dpa);
|
|
|
|
if ((rc = ACQUIRE_ERR(rwsem_read_intr, &dpa_rwsem)))
|
2023-11-26 16:09:30 -08:00
|
|
|
return rc;
|
|
|
|
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
rc = cxl_validate_poison_dpa(cxlmd, dpa);
|
|
|
|
if (rc)
|
2025-07-11 16:49:32 -07:00
|
|
|
return rc;
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
|
|
|
|
inject.address = cpu_to_le64(dpa);
|
|
|
|
mbox_cmd = (struct cxl_mbox_cmd) {
|
|
|
|
.opcode = CXL_MBOX_OP_INJECT_POISON,
|
|
|
|
.size_in = sizeof(inject),
|
|
|
|
.payload_in = &inject,
|
|
|
|
};
|
2024-09-05 15:35:47 -07:00
|
|
|
rc = cxl_internal_send_cmd(cxl_mbox, &mbox_cmd);
|
2023-04-18 20:26:27 -07:00
|
|
|
if (rc)
|
2025-07-11 16:49:32 -07:00
|
|
|
return rc;
|
2023-04-18 20:26:27 -07:00
|
|
|
|
|
|
|
cxlr = cxl_dpa_to_region(cxlmd, dpa);
|
|
|
|
if (cxlr)
|
2024-09-05 15:35:47 -07:00
|
|
|
dev_warn_once(cxl_mbox->host,
|
2023-04-18 20:26:27 -07:00
|
|
|
"poison inject dpa:%#llx region: %s\n", dpa,
|
|
|
|
dev_name(&cxlr->dev));
|
2023-04-18 20:26:28 -07:00
|
|
|
|
|
|
|
record = (struct cxl_poison_record) {
|
|
|
|
.address = cpu_to_le64(dpa),
|
|
|
|
.length = cpu_to_le32(1),
|
|
|
|
};
|
|
|
|
trace_cxl_poison(cxlmd, cxlr, &record, 0, 0, CXL_POISON_TRACE_INJECT);
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
|
2025-07-11 16:49:32 -07:00
|
|
|
return 0;
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(cxl_inject_poison, "CXL");
|
cxl/memdev: Add support for the Inject Poison mailbox command
CXL devices optionally support the INJECT POISON mailbox command. Add
memdev driver support for the mailbox command.
Per the CXL Specification (3.0 8.2.9.8.4.2), after receiving a valid
inject poison request, the device will return poison when the address
is accessed through the CXL.mem driver. Injecting poison adds the address
to the device's Poison List and the error source is set to Injected.
In addition, the device adds a poison creation event to its internal
Informational Event log, updates the Event Status register, and if
configured, interrupts the host.
Also, per the CXL Specification, it is not an error to inject poison
into an address that already has poison present and no error is
returned from the device.
If the address is not contained in the device's dpa resource, or is
not 64 byte aligned, return -EINVAL without issuing the mbox command.
Poison injection is intended for debug only and will be exposed to
userspace through debugfs. Restrict compilation to CONFIG_DEBUG_FS.
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/241c64115e6bd2effed9c7a20b08b3908dd7be8f.1681874357.git.alison.schofield@intel.com
Tested-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-04-18 20:26:25 -07:00
|
|
|
|
2023-04-18 20:26:26 -07:00
|
|
|
int cxl_clear_poison(struct cxl_memdev *cxlmd, u64 dpa)
|
|
|
|
{
|
2024-09-05 15:35:47 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &cxlmd->cxlds->cxl_mbox;
|
2023-04-18 20:26:26 -07:00
|
|
|
struct cxl_mbox_clear_poison clear;
|
2023-04-18 20:26:28 -07:00
|
|
|
struct cxl_poison_record record;
|
2023-04-18 20:26:26 -07:00
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
2023-04-18 20:26:27 -07:00
|
|
|
struct cxl_region *cxlr;
|
2023-04-18 20:26:26 -07:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_DEBUG_FS))
|
|
|
|
return 0;
|
|
|
|
|
2025-07-11 16:49:32 -07:00
|
|
|
ACQUIRE(rwsem_read_intr, region_rwsem)(&cxl_rwsem.region);
|
|
|
|
if ((rc = ACQUIRE_ERR(rwsem_read_intr, ®ion_rwsem)))
|
2023-04-18 20:26:26 -07:00
|
|
|
return rc;
|
|
|
|
|
2025-07-11 16:49:32 -07:00
|
|
|
ACQUIRE(rwsem_read_intr, dpa_rwsem)(&cxl_rwsem.dpa);
|
|
|
|
if ((rc = ACQUIRE_ERR(rwsem_read_intr, &dpa_rwsem)))
|
2023-11-26 16:09:30 -08:00
|
|
|
return rc;
|
|
|
|
|
2023-04-18 20:26:26 -07:00
|
|
|
rc = cxl_validate_poison_dpa(cxlmd, dpa);
|
|
|
|
if (rc)
|
2025-07-11 16:49:32 -07:00
|
|
|
return rc;
|
2023-04-18 20:26:26 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* In CXL 3.0 Spec 8.2.9.8.4.3, the Clear Poison mailbox command
|
|
|
|
* is defined to accept 64 bytes of write-data, along with the
|
|
|
|
* address to clear. This driver uses zeroes as write-data.
|
|
|
|
*/
|
|
|
|
clear = (struct cxl_mbox_clear_poison) {
|
|
|
|
.address = cpu_to_le64(dpa)
|
|
|
|
};
|
|
|
|
|
|
|
|
mbox_cmd = (struct cxl_mbox_cmd) {
|
|
|
|
.opcode = CXL_MBOX_OP_CLEAR_POISON,
|
|
|
|
.size_in = sizeof(clear),
|
|
|
|
.payload_in = &clear,
|
|
|
|
};
|
|
|
|
|
2024-09-05 15:35:47 -07:00
|
|
|
rc = cxl_internal_send_cmd(cxl_mbox, &mbox_cmd);
|
2023-04-18 20:26:26 -07:00
|
|
|
if (rc)
|
2025-07-11 16:49:32 -07:00
|
|
|
return rc;
|
2023-04-18 20:26:27 -07:00
|
|
|
|
|
|
|
cxlr = cxl_dpa_to_region(cxlmd, dpa);
|
|
|
|
if (cxlr)
|
2024-09-05 15:35:47 -07:00
|
|
|
dev_warn_once(cxl_mbox->host,
|
2023-06-14 18:30:02 -07:00
|
|
|
"poison clear dpa:%#llx region: %s\n", dpa,
|
|
|
|
dev_name(&cxlr->dev));
|
2023-04-18 20:26:28 -07:00
|
|
|
|
|
|
|
record = (struct cxl_poison_record) {
|
|
|
|
.address = cpu_to_le64(dpa),
|
|
|
|
.length = cpu_to_le32(1),
|
|
|
|
};
|
|
|
|
trace_cxl_poison(cxlmd, cxlr, &record, 0, 0, CXL_POISON_TRACE_CLEAR);
|
2023-04-18 20:26:26 -07:00
|
|
|
|
2025-07-11 16:49:32 -07:00
|
|
|
return 0;
|
2023-04-18 20:26:26 -07:00
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(cxl_clear_poison, "CXL");
|
2023-04-18 20:26:26 -07:00
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static struct attribute *cxl_memdev_attributes[] = {
|
2022-01-31 13:56:11 -08:00
|
|
|
&dev_attr_serial.attr,
|
2021-08-02 10:30:05 -07:00
|
|
|
&dev_attr_firmware_version.attr,
|
|
|
|
&dev_attr_payload_max.attr,
|
|
|
|
&dev_attr_label_storage_size.attr,
|
2022-01-23 16:31:24 -08:00
|
|
|
&dev_attr_numa_node.attr,
|
2021-08-02 10:30:05 -07:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2025-02-03 20:24:35 -08:00
|
|
|
static struct cxl_dpa_perf *to_pmem_perf(struct cxl_dev_state *cxlds)
|
|
|
|
{
|
|
|
|
for (int i = 0; i < cxlds->nr_partitions; i++)
|
|
|
|
if (cxlds->part[i].mode == CXL_PARTMODE_PMEM)
|
|
|
|
return &cxlds->part[i].perf;
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2024-02-06 12:03:39 -07:00
|
|
|
static ssize_t pmem_qos_class_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
|
|
|
|
cxl: Introduce to_{ram,pmem}_{res,perf}() helpers
In preparation for consolidating all DPA partition information into an
array of DPA metadata, introduce helpers that hide the layout of the
current data. I.e. make the eventual replacement of ->ram_res,
->pmem_res, ->ram_perf, and ->pmem_perf with a new DPA metadata array a
no-op for code paths that consume that information, and reduce the noise
of follow-on patches.
The end goal is to consolidate all DPA information in 'struct
cxl_dev_state', but for now the helpers just make it appear that all DPA
metadata is relative to @cxlds.
As the conversion to generic partition metadata walking is completed,
these helpers will naturally be eliminated, or reduced in scope.
Cc: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305238.668823.16553986866633608541.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:12 -08:00
|
|
|
return sysfs_emit(buf, "%d\n", to_pmem_perf(cxlds)->qos_class);
|
2024-02-06 12:03:39 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct device_attribute dev_attr_pmem_qos_class =
|
|
|
|
__ATTR(qos_class, 0444, pmem_qos_class_show, NULL);
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static struct attribute *cxl_memdev_pmem_attributes[] = {
|
|
|
|
&dev_attr_pmem_size.attr,
|
2024-02-06 12:03:39 -07:00
|
|
|
&dev_attr_pmem_qos_class.attr,
|
2021-08-02 10:30:05 -07:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2025-02-03 20:24:35 -08:00
|
|
|
static struct cxl_dpa_perf *to_ram_perf(struct cxl_dev_state *cxlds)
|
|
|
|
{
|
|
|
|
if (cxlds->part[0].mode != CXL_PARTMODE_RAM)
|
|
|
|
return NULL;
|
|
|
|
return &cxlds->part[0].perf;
|
|
|
|
}
|
|
|
|
|
2024-02-06 12:03:39 -07:00
|
|
|
static ssize_t ram_qos_class_show(struct device *dev,
|
|
|
|
struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
|
|
|
|
cxl: Introduce to_{ram,pmem}_{res,perf}() helpers
In preparation for consolidating all DPA partition information into an
array of DPA metadata, introduce helpers that hide the layout of the
current data. I.e. make the eventual replacement of ->ram_res,
->pmem_res, ->ram_perf, and ->pmem_perf with a new DPA metadata array a
no-op for code paths that consume that information, and reduce the noise
of follow-on patches.
The end goal is to consolidate all DPA information in 'struct
cxl_dev_state', but for now the helpers just make it appear that all DPA
metadata is relative to @cxlds.
As the conversion to generic partition metadata walking is completed,
these helpers will naturally be eliminated, or reduced in scope.
Cc: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305238.668823.16553986866633608541.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:12 -08:00
|
|
|
return sysfs_emit(buf, "%d\n", to_ram_perf(cxlds)->qos_class);
|
2024-02-06 12:03:39 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct device_attribute dev_attr_ram_qos_class =
|
|
|
|
__ATTR(qos_class, 0444, ram_qos_class_show, NULL);
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static struct attribute *cxl_memdev_ram_attributes[] = {
|
|
|
|
&dev_attr_ram_size.attr,
|
2024-02-06 12:03:39 -07:00
|
|
|
&dev_attr_ram_qos_class.attr,
|
2021-08-02 10:30:05 -07:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2023-06-12 11:10:33 -07:00
|
|
|
static struct attribute *cxl_memdev_security_attributes[] = {
|
|
|
|
&dev_attr_security_state.attr,
|
2023-06-12 11:10:35 -07:00
|
|
|
&dev_attr_security_sanitize.attr,
|
2023-06-12 11:10:37 -07:00
|
|
|
&dev_attr_security_erase.attr,
|
2023-06-12 11:10:33 -07:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2022-01-23 16:31:24 -08:00
|
|
|
static umode_t cxl_memdev_visible(struct kobject *kobj, struct attribute *a,
|
|
|
|
int n)
|
|
|
|
{
|
|
|
|
if (!IS_ENABLED(CONFIG_NUMA) && a == &dev_attr_numa_node.attr)
|
|
|
|
return 0;
|
|
|
|
return a->mode;
|
|
|
|
}
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static struct attribute_group cxl_memdev_attribute_group = {
|
|
|
|
.attrs = cxl_memdev_attributes,
|
2022-01-23 16:31:24 -08:00
|
|
|
.is_visible = cxl_memdev_visible,
|
2021-08-02 10:30:05 -07:00
|
|
|
};
|
|
|
|
|
2024-02-06 12:03:39 -07:00
|
|
|
static umode_t cxl_ram_visible(struct kobject *kobj, struct attribute *a, int n)
|
|
|
|
{
|
|
|
|
struct device *dev = kobj_to_dev(kobj);
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
cxl: Introduce to_{ram,pmem}_{res,perf}() helpers
In preparation for consolidating all DPA partition information into an
array of DPA metadata, introduce helpers that hide the layout of the
current data. I.e. make the eventual replacement of ->ram_res,
->pmem_res, ->ram_perf, and ->pmem_perf with a new DPA metadata array a
no-op for code paths that consume that information, and reduce the noise
of follow-on patches.
The end goal is to consolidate all DPA information in 'struct
cxl_dev_state', but for now the helpers just make it appear that all DPA
metadata is relative to @cxlds.
As the conversion to generic partition metadata walking is completed,
these helpers will naturally be eliminated, or reduced in scope.
Cc: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305238.668823.16553986866633608541.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:12 -08:00
|
|
|
struct cxl_dpa_perf *perf = to_ram_perf(cxlmd->cxlds);
|
2024-02-06 12:03:39 -07:00
|
|
|
|
cxl: Introduce to_{ram,pmem}_{res,perf}() helpers
In preparation for consolidating all DPA partition information into an
array of DPA metadata, introduce helpers that hide the layout of the
current data. I.e. make the eventual replacement of ->ram_res,
->pmem_res, ->ram_perf, and ->pmem_perf with a new DPA metadata array a
no-op for code paths that consume that information, and reduce the noise
of follow-on patches.
The end goal is to consolidate all DPA information in 'struct
cxl_dev_state', but for now the helpers just make it appear that all DPA
metadata is relative to @cxlds.
As the conversion to generic partition metadata walking is completed,
these helpers will naturally be eliminated, or reduced in scope.
Cc: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305238.668823.16553986866633608541.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:12 -08:00
|
|
|
if (a == &dev_attr_ram_qos_class.attr &&
|
|
|
|
(!perf || perf->qos_class == CXL_QOS_CLASS_INVALID))
|
|
|
|
return 0;
|
2024-02-06 12:03:39 -07:00
|
|
|
|
|
|
|
return a->mode;
|
|
|
|
}
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static struct attribute_group cxl_memdev_ram_attribute_group = {
|
|
|
|
.name = "ram",
|
|
|
|
.attrs = cxl_memdev_ram_attributes,
|
2024-02-06 12:03:39 -07:00
|
|
|
.is_visible = cxl_ram_visible,
|
2021-08-02 10:30:05 -07:00
|
|
|
};
|
|
|
|
|
2024-02-06 12:03:39 -07:00
|
|
|
static umode_t cxl_pmem_visible(struct kobject *kobj, struct attribute *a, int n)
|
|
|
|
{
|
|
|
|
struct device *dev = kobj_to_dev(kobj);
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
cxl: Introduce to_{ram,pmem}_{res,perf}() helpers
In preparation for consolidating all DPA partition information into an
array of DPA metadata, introduce helpers that hide the layout of the
current data. I.e. make the eventual replacement of ->ram_res,
->pmem_res, ->ram_perf, and ->pmem_perf with a new DPA metadata array a
no-op for code paths that consume that information, and reduce the noise
of follow-on patches.
The end goal is to consolidate all DPA information in 'struct
cxl_dev_state', but for now the helpers just make it appear that all DPA
metadata is relative to @cxlds.
As the conversion to generic partition metadata walking is completed,
these helpers will naturally be eliminated, or reduced in scope.
Cc: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305238.668823.16553986866633608541.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:12 -08:00
|
|
|
struct cxl_dpa_perf *perf = to_pmem_perf(cxlmd->cxlds);
|
2024-02-06 12:03:39 -07:00
|
|
|
|
cxl: Introduce to_{ram,pmem}_{res,perf}() helpers
In preparation for consolidating all DPA partition information into an
array of DPA metadata, introduce helpers that hide the layout of the
current data. I.e. make the eventual replacement of ->ram_res,
->pmem_res, ->ram_perf, and ->pmem_perf with a new DPA metadata array a
no-op for code paths that consume that information, and reduce the noise
of follow-on patches.
The end goal is to consolidate all DPA information in 'struct
cxl_dev_state', but for now the helpers just make it appear that all DPA
metadata is relative to @cxlds.
As the conversion to generic partition metadata walking is completed,
these helpers will naturally be eliminated, or reduced in scope.
Cc: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Tested-by: Alejandro Lucero <alucerop@amd.com>
Link: https://patch.msgid.link/173864305238.668823.16553986866633608541.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
2025-02-03 20:24:12 -08:00
|
|
|
if (a == &dev_attr_pmem_qos_class.attr &&
|
|
|
|
(!perf || perf->qos_class == CXL_QOS_CLASS_INVALID))
|
|
|
|
return 0;
|
2024-02-06 12:03:39 -07:00
|
|
|
|
|
|
|
return a->mode;
|
|
|
|
}
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static struct attribute_group cxl_memdev_pmem_attribute_group = {
|
|
|
|
.name = "pmem",
|
|
|
|
.attrs = cxl_memdev_pmem_attributes,
|
2024-02-06 12:03:39 -07:00
|
|
|
.is_visible = cxl_pmem_visible,
|
2021-08-02 10:30:05 -07:00
|
|
|
};
|
|
|
|
|
2023-07-25 22:19:40 -07:00
|
|
|
static umode_t cxl_memdev_security_visible(struct kobject *kobj,
|
|
|
|
struct attribute *a, int n)
|
|
|
|
{
|
|
|
|
struct device *dev = kobj_to_dev(kobj);
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlmd->cxlds);
|
|
|
|
|
|
|
|
if (a == &dev_attr_security_sanitize.attr &&
|
|
|
|
!test_bit(CXL_SEC_ENABLED_SANITIZE, mds->security.enabled_cmds))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (a == &dev_attr_security_erase.attr &&
|
|
|
|
!test_bit(CXL_SEC_ENABLED_SECURE_ERASE, mds->security.enabled_cmds))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return a->mode;
|
|
|
|
}
|
|
|
|
|
2023-06-12 11:10:33 -07:00
|
|
|
static struct attribute_group cxl_memdev_security_attribute_group = {
|
|
|
|
.name = "security",
|
|
|
|
.attrs = cxl_memdev_security_attributes,
|
2023-07-25 22:19:40 -07:00
|
|
|
.is_visible = cxl_memdev_security_visible,
|
2023-06-12 11:10:33 -07:00
|
|
|
};
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static const struct attribute_group *cxl_memdev_attribute_groups[] = {
|
|
|
|
&cxl_memdev_attribute_group,
|
|
|
|
&cxl_memdev_ram_attribute_group,
|
|
|
|
&cxl_memdev_pmem_attribute_group,
|
2023-06-12 11:10:33 -07:00
|
|
|
&cxl_memdev_security_attribute_group,
|
2021-08-02 10:30:05 -07:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2024-02-06 12:03:39 -07:00
|
|
|
void cxl_memdev_update_perf(struct cxl_memdev *cxlmd)
|
|
|
|
{
|
|
|
|
sysfs_update_group(&cxlmd->dev.kobj, &cxl_memdev_ram_attribute_group);
|
|
|
|
sysfs_update_group(&cxlmd->dev.kobj, &cxl_memdev_pmem_attribute_group);
|
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(cxl_memdev_update_perf, "CXL");
|
2024-02-06 12:03:39 -07:00
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static const struct device_type cxl_memdev_type = {
|
|
|
|
.name = "cxl_memdev",
|
|
|
|
.release = cxl_memdev_release,
|
|
|
|
.devnode = cxl_memdev_devnode,
|
|
|
|
.groups = cxl_memdev_attribute_groups,
|
|
|
|
};
|
|
|
|
|
2023-01-11 12:30:17 +01:00
|
|
|
bool is_cxl_memdev(const struct device *dev)
|
2022-02-04 07:18:31 -08:00
|
|
|
{
|
|
|
|
return dev->type == &cxl_memdev_type;
|
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(is_cxl_memdev, "CXL");
|
2022-02-04 07:18:31 -08:00
|
|
|
|
2021-09-14 12:03:04 -07:00
|
|
|
/**
|
|
|
|
* set_exclusive_cxl_commands() - atomically disable user cxl commands
|
2023-06-14 18:30:02 -07:00
|
|
|
* @mds: The device state to operate on
|
2021-09-14 12:03:04 -07:00
|
|
|
* @cmds: bitmap of commands to mark exclusive
|
|
|
|
*
|
|
|
|
* Grab the cxl_memdev_rwsem in write mode to flush in-flight
|
|
|
|
* invocations of the ioctl path and then disable future execution of
|
|
|
|
* commands with the command ids set in @cmds.
|
|
|
|
*/
|
2023-06-14 18:30:02 -07:00
|
|
|
void set_exclusive_cxl_commands(struct cxl_memdev_state *mds,
|
|
|
|
unsigned long *cmds)
|
2021-09-14 12:03:04 -07:00
|
|
|
{
|
2025-02-04 15:03:02 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &mds->cxlds.cxl_mbox;
|
|
|
|
|
2025-02-21 09:24:47 +08:00
|
|
|
guard(rwsem_write)(&cxl_memdev_rwsem);
|
2025-02-04 15:03:02 -07:00
|
|
|
bitmap_or(cxl_mbox->exclusive_cmds, cxl_mbox->exclusive_cmds,
|
|
|
|
cmds, CXL_MEM_COMMAND_ID_MAX);
|
2021-09-14 12:03:04 -07:00
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(set_exclusive_cxl_commands, "CXL");
|
2021-09-14 12:03:04 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* clear_exclusive_cxl_commands() - atomically enable user cxl commands
|
2023-06-14 18:30:02 -07:00
|
|
|
* @mds: The device state to modify
|
2021-09-14 12:03:04 -07:00
|
|
|
* @cmds: bitmap of commands to mark available for userspace
|
|
|
|
*/
|
2023-06-14 18:30:02 -07:00
|
|
|
void clear_exclusive_cxl_commands(struct cxl_memdev_state *mds,
|
|
|
|
unsigned long *cmds)
|
2021-09-14 12:03:04 -07:00
|
|
|
{
|
2025-02-04 15:03:02 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &mds->cxlds.cxl_mbox;
|
|
|
|
|
2025-02-21 09:24:47 +08:00
|
|
|
guard(rwsem_write)(&cxl_memdev_rwsem);
|
2025-02-04 15:03:02 -07:00
|
|
|
bitmap_andnot(cxl_mbox->exclusive_cmds, cxl_mbox->exclusive_cmds,
|
|
|
|
cmds, CXL_MEM_COMMAND_ID_MAX);
|
2021-09-14 12:03:04 -07:00
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(clear_exclusive_cxl_commands, "CXL");
|
2021-09-14 12:03:04 -07:00
|
|
|
|
2021-09-08 22:12:32 -07:00
|
|
|
static void cxl_memdev_shutdown(struct device *dev)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
|
2025-02-21 09:24:47 +08:00
|
|
|
guard(rwsem_write)(&cxl_memdev_rwsem);
|
2021-11-02 13:29:01 -07:00
|
|
|
cxlmd->cxlds = NULL;
|
2021-09-08 22:12:32 -07:00
|
|
|
}
|
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
static void cxl_memdev_unregister(void *_cxlmd)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = _cxlmd;
|
|
|
|
struct device *dev = &cxlmd->dev;
|
|
|
|
|
|
|
|
cdev_device_del(&cxlmd->cdev, dev);
|
2023-09-28 18:02:07 -07:00
|
|
|
cxl_memdev_shutdown(dev);
|
2021-08-02 10:30:05 -07:00
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
2022-02-04 07:18:31 -08:00
|
|
|
static void detach_memdev(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd;
|
|
|
|
|
|
|
|
cxlmd = container_of(work, typeof(*cxlmd), detach_work);
|
|
|
|
device_release_driver(&cxlmd->dev);
|
|
|
|
put_device(&cxlmd->dev);
|
|
|
|
}
|
|
|
|
|
2022-04-21 08:33:13 -07:00
|
|
|
static struct lock_class_key cxl_memdev_key;
|
|
|
|
|
2021-11-02 13:29:01 -07:00
|
|
|
static struct cxl_memdev *cxl_memdev_alloc(struct cxl_dev_state *cxlds,
|
2021-08-02 10:30:05 -07:00
|
|
|
const struct file_operations *fops)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd;
|
|
|
|
struct device *dev;
|
|
|
|
struct cdev *cdev;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
cxlmd = kzalloc(sizeof(*cxlmd), GFP_KERNEL);
|
|
|
|
if (!cxlmd)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
2023-02-08 10:19:44 -08:00
|
|
|
rc = ida_alloc_max(&cxl_memdev_ida, CXL_MEM_MAX_DEVS - 1, GFP_KERNEL);
|
2021-08-02 10:30:05 -07:00
|
|
|
if (rc < 0)
|
|
|
|
goto err;
|
|
|
|
cxlmd->id = rc;
|
2023-02-10 17:29:09 -08:00
|
|
|
cxlmd->depth = -1;
|
2021-08-02 10:30:05 -07:00
|
|
|
|
|
|
|
dev = &cxlmd->dev;
|
|
|
|
device_initialize(dev);
|
2022-04-21 08:33:13 -07:00
|
|
|
lockdep_set_class(&dev->mutex, &cxl_memdev_key);
|
2021-11-02 13:29:01 -07:00
|
|
|
dev->parent = cxlds->dev;
|
2021-08-02 10:30:05 -07:00
|
|
|
dev->bus = &cxl_bus_type;
|
|
|
|
dev->devt = MKDEV(cxl_mem_major, cxlmd->id);
|
|
|
|
dev->type = &cxl_memdev_type;
|
|
|
|
device_set_pm_not_required(dev);
|
2022-02-04 07:18:31 -08:00
|
|
|
INIT_WORK(&cxlmd->detach_work, detach_memdev);
|
2021-08-02 10:30:05 -07:00
|
|
|
|
|
|
|
cdev = &cxlmd->cdev;
|
|
|
|
cdev_init(cdev, fops);
|
|
|
|
return cxlmd;
|
|
|
|
|
|
|
|
err:
|
|
|
|
kfree(cxlmd);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
|
|
|
|
2021-09-08 22:12:32 -07:00
|
|
|
static long __cxl_memdev_ioctl(struct cxl_memdev *cxlmd, unsigned int cmd,
|
|
|
|
unsigned long arg)
|
|
|
|
{
|
2025-02-04 15:03:02 -07:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlmd->cxlds);
|
|
|
|
struct cxl_mailbox *cxl_mbox = &mds->cxlds.cxl_mbox;
|
|
|
|
|
2021-09-08 22:12:32 -07:00
|
|
|
switch (cmd) {
|
|
|
|
case CXL_MEM_QUERY_COMMANDS:
|
2025-02-04 15:03:02 -07:00
|
|
|
return cxl_query_cmd(cxl_mbox, (void __user *)arg);
|
2021-09-08 22:12:32 -07:00
|
|
|
case CXL_MEM_SEND_COMMAND:
|
2025-02-04 15:03:02 -07:00
|
|
|
return cxl_send_cmd(cxl_mbox, (void __user *)arg);
|
2021-09-08 22:12:32 -07:00
|
|
|
default:
|
|
|
|
return -ENOTTY;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static long cxl_memdev_ioctl(struct file *file, unsigned int cmd,
|
|
|
|
unsigned long arg)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = file->private_data;
|
2023-06-14 18:30:07 -07:00
|
|
|
struct cxl_dev_state *cxlds;
|
2021-09-08 22:12:32 -07:00
|
|
|
|
2025-02-21 09:24:49 +08:00
|
|
|
guard(rwsem_read)(&cxl_memdev_rwsem);
|
2023-06-14 18:30:07 -07:00
|
|
|
cxlds = cxlmd->cxlds;
|
|
|
|
if (cxlds && cxlds->type == CXL_DEVTYPE_CLASSMEM)
|
2025-02-21 09:24:49 +08:00
|
|
|
return __cxl_memdev_ioctl(cxlmd, cmd, arg);
|
2021-09-08 22:12:32 -07:00
|
|
|
|
2025-02-21 09:24:49 +08:00
|
|
|
return -ENXIO;
|
2021-09-08 22:12:32 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int cxl_memdev_open(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd =
|
|
|
|
container_of(inode->i_cdev, typeof(*cxlmd), cdev);
|
|
|
|
|
|
|
|
get_device(&cxlmd->dev);
|
|
|
|
file->private_data = cxlmd;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int cxl_memdev_release_file(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd =
|
|
|
|
container_of(inode->i_cdev, typeof(*cxlmd), cdev);
|
|
|
|
|
|
|
|
put_device(&cxlmd->dev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
/**
|
|
|
|
* cxl_mem_get_fw_info - Get Firmware info
|
2023-06-29 10:11:18 +08:00
|
|
|
* @mds: The device data for the operation
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
*
|
|
|
|
* Retrieve firmware info for the device specified.
|
|
|
|
*
|
|
|
|
* Return: 0 if no error: or the result of the mailbox command.
|
|
|
|
*
|
|
|
|
* See CXL-3.0 8.2.9.3.1 Get FW Info
|
|
|
|
*/
|
2023-06-25 17:16:51 -07:00
|
|
|
static int cxl_mem_get_fw_info(struct cxl_memdev_state *mds)
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
{
|
2024-09-05 15:35:47 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &mds->cxlds.cxl_mbox;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
struct cxl_mbox_get_fw_info info;
|
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
mbox_cmd = (struct cxl_mbox_cmd) {
|
|
|
|
.opcode = CXL_MBOX_OP_GET_FW_INFO,
|
|
|
|
.size_out = sizeof(info),
|
|
|
|
.payload_out = &info,
|
|
|
|
};
|
|
|
|
|
2024-09-05 15:35:47 -07:00
|
|
|
rc = cxl_internal_send_cmd(cxl_mbox, &mbox_cmd);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
if (rc < 0)
|
|
|
|
return rc;
|
|
|
|
|
2023-06-25 17:16:51 -07:00
|
|
|
mds->fw.num_slots = info.num_slots;
|
|
|
|
mds->fw.cur_slot = FIELD_GET(CXL_FW_INFO_SLOT_INFO_CUR_MASK,
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
info.slot_info);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* cxl_mem_activate_fw - Activate Firmware
|
2023-06-25 17:16:51 -07:00
|
|
|
* @mds: The device data for the operation
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
* @slot: slot number to activate
|
|
|
|
*
|
|
|
|
* Activate firmware in a given slot for the device specified.
|
|
|
|
*
|
|
|
|
* Return: 0 if no error: or the result of the mailbox command.
|
|
|
|
*
|
|
|
|
* See CXL-3.0 8.2.9.3.3 Activate FW
|
|
|
|
*/
|
2023-06-25 17:16:51 -07:00
|
|
|
static int cxl_mem_activate_fw(struct cxl_memdev_state *mds, int slot)
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
{
|
2024-09-05 15:35:47 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &mds->cxlds.cxl_mbox;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
struct cxl_mbox_activate_fw activate;
|
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
|
|
|
|
2023-06-25 17:16:51 -07:00
|
|
|
if (slot == 0 || slot > mds->fw.num_slots)
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
mbox_cmd = (struct cxl_mbox_cmd) {
|
|
|
|
.opcode = CXL_MBOX_OP_ACTIVATE_FW,
|
|
|
|
.size_in = sizeof(activate),
|
|
|
|
.payload_in = &activate,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Only offline activation supported for now */
|
|
|
|
activate.action = CXL_FW_ACTIVATE_OFFLINE;
|
|
|
|
activate.slot = slot;
|
|
|
|
|
2024-09-05 15:35:47 -07:00
|
|
|
return cxl_internal_send_cmd(cxl_mbox, &mbox_cmd);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* cxl_mem_abort_fw_xfer - Abort an in-progress FW transfer
|
2023-06-25 17:16:51 -07:00
|
|
|
* @mds: The device data for the operation
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
*
|
|
|
|
* Abort an in-progress firmware transfer for the device specified.
|
|
|
|
*
|
|
|
|
* Return: 0 if no error: or the result of the mailbox command.
|
|
|
|
*
|
|
|
|
* See CXL-3.0 8.2.9.3.2 Transfer FW
|
|
|
|
*/
|
2023-06-25 17:16:51 -07:00
|
|
|
static int cxl_mem_abort_fw_xfer(struct cxl_memdev_state *mds)
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
{
|
2024-09-05 15:35:47 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &mds->cxlds.cxl_mbox;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
struct cxl_mbox_transfer_fw *transfer;
|
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
transfer = kzalloc(struct_size(transfer, data, 0), GFP_KERNEL);
|
|
|
|
if (!transfer)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* Set a 1s poll interval and a total wait time of 30s */
|
|
|
|
mbox_cmd = (struct cxl_mbox_cmd) {
|
|
|
|
.opcode = CXL_MBOX_OP_TRANSFER_FW,
|
|
|
|
.size_in = sizeof(*transfer),
|
|
|
|
.payload_in = transfer,
|
|
|
|
.poll_interval_ms = 1000,
|
|
|
|
.poll_count = 30,
|
|
|
|
};
|
|
|
|
|
|
|
|
transfer->action = CXL_FW_TRANSFER_ACTION_ABORT;
|
|
|
|
|
2024-09-05 15:35:47 -07:00
|
|
|
rc = cxl_internal_send_cmd(cxl_mbox, &mbox_cmd);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
kfree(transfer);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cxl_fw_cleanup(struct fw_upload *fwl)
|
|
|
|
{
|
2023-06-25 17:16:51 -07:00
|
|
|
struct cxl_memdev_state *mds = fwl->dd_handle;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
|
2023-06-25 17:16:51 -07:00
|
|
|
mds->fw.next_slot = 0;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static int cxl_fw_do_cancel(struct fw_upload *fwl)
|
|
|
|
{
|
2023-06-25 17:16:51 -07:00
|
|
|
struct cxl_memdev_state *mds = fwl->dd_handle;
|
|
|
|
struct cxl_dev_state *cxlds = &mds->cxlds;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
struct cxl_memdev *cxlmd = cxlds->cxlmd;
|
|
|
|
int rc;
|
|
|
|
|
2023-06-25 17:16:51 -07:00
|
|
|
rc = cxl_mem_abort_fw_xfer(mds);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
if (rc < 0)
|
|
|
|
dev_err(&cxlmd->dev, "Error aborting FW transfer: %d\n", rc);
|
|
|
|
|
|
|
|
return FW_UPLOAD_ERR_CANCELED;
|
|
|
|
}
|
|
|
|
|
|
|
|
static enum fw_upload_err cxl_fw_prepare(struct fw_upload *fwl, const u8 *data,
|
|
|
|
u32 size)
|
|
|
|
{
|
2023-06-25 17:16:51 -07:00
|
|
|
struct cxl_memdev_state *mds = fwl->dd_handle;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
struct cxl_mbox_transfer_fw *transfer;
|
2024-09-05 15:35:46 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &mds->cxlds.cxl_mbox;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
|
|
|
|
if (!size)
|
|
|
|
return FW_UPLOAD_ERR_INVALID_SIZE;
|
|
|
|
|
2023-06-25 17:16:51 -07:00
|
|
|
mds->fw.oneshot = struct_size(transfer, data, size) <
|
2024-09-05 15:35:46 -07:00
|
|
|
cxl_mbox->payload_size;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
|
2023-06-25 17:16:51 -07:00
|
|
|
if (cxl_mem_get_fw_info(mds))
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
return FW_UPLOAD_ERR_HW_ERROR;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* So far no state has been changed, hence no other cleanup is
|
|
|
|
* necessary. Simply return the cancelled status.
|
|
|
|
*/
|
2023-06-25 17:16:51 -07:00
|
|
|
if (test_and_clear_bit(CXL_FW_CANCEL, mds->fw.state))
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
return FW_UPLOAD_ERR_CANCELED;
|
|
|
|
|
|
|
|
return FW_UPLOAD_ERR_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static enum fw_upload_err cxl_fw_write(struct fw_upload *fwl, const u8 *data,
|
|
|
|
u32 offset, u32 size, u32 *written)
|
|
|
|
{
|
2023-06-25 17:16:51 -07:00
|
|
|
struct cxl_memdev_state *mds = fwl->dd_handle;
|
|
|
|
struct cxl_dev_state *cxlds = &mds->cxlds;
|
2024-09-05 15:35:46 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &cxlds->cxl_mbox;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
struct cxl_memdev *cxlmd = cxlds->cxlmd;
|
|
|
|
struct cxl_mbox_transfer_fw *transfer;
|
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
|
|
|
u32 cur_size, remaining;
|
|
|
|
size_t size_in;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
*written = 0;
|
|
|
|
|
|
|
|
/* Offset has to be aligned to 128B (CXL-3.0 8.2.9.3.2 Table 8-57) */
|
|
|
|
if (!IS_ALIGNED(offset, CXL_FW_TRANSFER_ALIGNMENT)) {
|
|
|
|
dev_err(&cxlmd->dev,
|
|
|
|
"misaligned offset for FW transfer slice (%u)\n",
|
|
|
|
offset);
|
|
|
|
return FW_UPLOAD_ERR_RW_ERROR;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2023-06-25 17:16:51 -07:00
|
|
|
* Pick transfer size based on mds->payload_size @size must bw 128-byte
|
|
|
|
* aligned, ->payload_size is a power of 2 starting at 256 bytes, and
|
|
|
|
* sizeof(*transfer) is 128. These constraints imply that @cur_size
|
|
|
|
* will always be 128b aligned.
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
*/
|
2024-09-05 15:35:46 -07:00
|
|
|
cur_size = min_t(size_t, size, cxl_mbox->payload_size - sizeof(*transfer));
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
|
|
|
|
remaining = size - cur_size;
|
|
|
|
size_in = struct_size(transfer, data, cur_size);
|
|
|
|
|
2023-06-25 17:16:51 -07:00
|
|
|
if (test_and_clear_bit(CXL_FW_CANCEL, mds->fw.state))
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
return cxl_fw_do_cancel(fwl);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Slot numbers are 1-indexed
|
|
|
|
* cur_slot is the 0-indexed next_slot (i.e. 'cur_slot - 1 + 1')
|
|
|
|
* Check for rollover using modulo, and 1-index it by adding 1
|
|
|
|
*/
|
2023-06-25 17:16:51 -07:00
|
|
|
mds->fw.next_slot = (mds->fw.cur_slot % mds->fw.num_slots) + 1;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
|
|
|
|
/* Do the transfer via mailbox cmd */
|
|
|
|
transfer = kzalloc(size_in, GFP_KERNEL);
|
|
|
|
if (!transfer)
|
|
|
|
return FW_UPLOAD_ERR_RW_ERROR;
|
|
|
|
|
|
|
|
transfer->offset = cpu_to_le32(offset / CXL_FW_TRANSFER_ALIGNMENT);
|
|
|
|
memcpy(transfer->data, data + offset, cur_size);
|
2023-06-25 17:16:51 -07:00
|
|
|
if (mds->fw.oneshot) {
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
transfer->action = CXL_FW_TRANSFER_ACTION_FULL;
|
2023-06-25 17:16:51 -07:00
|
|
|
transfer->slot = mds->fw.next_slot;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
} else {
|
|
|
|
if (offset == 0) {
|
|
|
|
transfer->action = CXL_FW_TRANSFER_ACTION_INITIATE;
|
|
|
|
} else if (remaining == 0) {
|
|
|
|
transfer->action = CXL_FW_TRANSFER_ACTION_END;
|
2023-06-25 17:16:51 -07:00
|
|
|
transfer->slot = mds->fw.next_slot;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
} else {
|
|
|
|
transfer->action = CXL_FW_TRANSFER_ACTION_CONTINUE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
mbox_cmd = (struct cxl_mbox_cmd) {
|
|
|
|
.opcode = CXL_MBOX_OP_TRANSFER_FW,
|
|
|
|
.size_in = size_in,
|
|
|
|
.payload_in = transfer,
|
|
|
|
.poll_interval_ms = 1000,
|
|
|
|
.poll_count = 30,
|
|
|
|
};
|
|
|
|
|
2024-09-05 15:35:47 -07:00
|
|
|
rc = cxl_internal_send_cmd(cxl_mbox, &mbox_cmd);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
if (rc < 0) {
|
|
|
|
rc = FW_UPLOAD_ERR_RW_ERROR;
|
|
|
|
goto out_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
*written = cur_size;
|
|
|
|
|
|
|
|
/* Activate FW if oneshot or if the last slice was written */
|
2023-06-25 17:16:51 -07:00
|
|
|
if (mds->fw.oneshot || remaining == 0) {
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
dev_dbg(&cxlmd->dev, "Activating firmware slot: %d\n",
|
2023-06-25 17:16:51 -07:00
|
|
|
mds->fw.next_slot);
|
|
|
|
rc = cxl_mem_activate_fw(mds, mds->fw.next_slot);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
if (rc < 0) {
|
|
|
|
dev_err(&cxlmd->dev, "Error activating firmware: %d\n",
|
|
|
|
rc);
|
|
|
|
rc = FW_UPLOAD_ERR_HW_ERROR;
|
|
|
|
goto out_free;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
rc = FW_UPLOAD_ERR_NONE;
|
|
|
|
|
|
|
|
out_free:
|
|
|
|
kfree(transfer);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static enum fw_upload_err cxl_fw_poll_complete(struct fw_upload *fwl)
|
|
|
|
{
|
2023-06-25 17:16:51 -07:00
|
|
|
struct cxl_memdev_state *mds = fwl->dd_handle;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* cxl_internal_send_cmd() handles background operations synchronously.
|
|
|
|
* No need to wait for completions here - any errors would've been
|
|
|
|
* reported and handled during the ->write() call(s).
|
|
|
|
* Just check if a cancel request was received, and return success.
|
|
|
|
*/
|
2023-06-25 17:16:51 -07:00
|
|
|
if (test_and_clear_bit(CXL_FW_CANCEL, mds->fw.state))
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
return cxl_fw_do_cancel(fwl);
|
|
|
|
|
|
|
|
return FW_UPLOAD_ERR_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cxl_fw_cancel(struct fw_upload *fwl)
|
|
|
|
{
|
2023-06-25 17:16:51 -07:00
|
|
|
struct cxl_memdev_state *mds = fwl->dd_handle;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
|
2023-06-25 17:16:51 -07:00
|
|
|
set_bit(CXL_FW_CANCEL, mds->fw.state);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct fw_upload_ops cxl_memdev_fw_ops = {
|
|
|
|
.prepare = cxl_fw_prepare,
|
|
|
|
.write = cxl_fw_write,
|
|
|
|
.poll_complete = cxl_fw_poll_complete,
|
|
|
|
.cancel = cxl_fw_cancel,
|
|
|
|
.cleanup = cxl_fw_cleanup,
|
|
|
|
};
|
|
|
|
|
2023-10-04 16:04:49 -07:00
|
|
|
static void cxl_remove_fw_upload(void *fwl)
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
{
|
|
|
|
firmware_upload_unregister(fwl);
|
|
|
|
}
|
|
|
|
|
2023-10-04 16:04:49 -07:00
|
|
|
int devm_cxl_setup_fw_upload(struct device *host, struct cxl_memdev_state *mds)
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
{
|
2023-06-25 17:16:51 -07:00
|
|
|
struct cxl_dev_state *cxlds = &mds->cxlds;
|
2025-02-04 15:03:02 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &cxlds->cxl_mbox;
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
struct device *dev = &cxlds->cxlmd->dev;
|
|
|
|
struct fw_upload *fwl;
|
|
|
|
|
2025-02-04 15:03:02 -07:00
|
|
|
if (!test_bit(CXL_MEM_COMMAND_ID_GET_FW_INFO, cxl_mbox->enabled_cmds))
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
fwl = firmware_upload_register(THIS_MODULE, dev, dev_name(dev),
|
2023-06-25 17:16:51 -07:00
|
|
|
&cxl_memdev_fw_ops, mds);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
if (IS_ERR(fwl))
|
2023-10-04 16:24:39 -07:00
|
|
|
return PTR_ERR(fwl);
|
2023-10-04 16:04:49 -07:00
|
|
|
return devm_add_action_or_reset(host, cxl_remove_fw_upload, fwl);
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(devm_cxl_setup_fw_upload, "CXL");
|
cxl: add a firmware update mechanism using the sysfs firmware loader
The sysfs based firmware loader mechanism was created to easily allow
userspace to upload firmware images to FPGA cards. This also happens to
be pretty suitable to create a user-initiated but kernel-controlled
firmware update mechanism for CXL devices, using the CXL specified
mailbox commands.
Since firmware update commands can be long-running, and can be processed
in the background by the endpoint device, it is desirable to have the
ability to chunk the firmware transfer down to smaller pieces, so that
one operation does not monopolize the mailbox, locking out any other
long running background commands entirely - e.g. security commands like
'sanitize' or poison scanning operations.
The firmware loader mechanism allows a natural way to perform this
chunking, as after each mailbox command, that is restricted to the
maximum mailbox payload size, the cxl memdev driver relinquishes control
back to the fw_loader system and awaits the next chunk of data to
transfer. This opens opportunities for other background commands to
access the mailbox and send their own slices of background commands.
Add the necessary helpers and state tracking to be able to perform the
'Get FW Info', 'Transfer FW', and 'Activate FW' mailbox commands as
described in the CXL spec. Wire these up to the firmware loader
callbacks, and register with that system to create the memX/firmware/
sysfs ABI.
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Russ Weight <russell.h.weight@intel.com>
Cc: Alison Schofield <alison.schofield@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ben Widawsky <bwidawsk@kernel.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Signed-off-by: Vishal Verma <vishal.l.verma@intel.com>
Link: https://lore.kernel.org/r/20230602-vv-fw_update-v4-1-c6265bd7343b@intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-06-14 11:17:40 -06:00
|
|
|
|
2021-09-08 22:12:32 -07:00
|
|
|
static const struct file_operations cxl_memdev_fops = {
|
|
|
|
.owner = THIS_MODULE,
|
|
|
|
.unlocked_ioctl = cxl_memdev_ioctl,
|
|
|
|
.open = cxl_memdev_open,
|
|
|
|
.release = cxl_memdev_release_file,
|
|
|
|
.compat_ioctl = compat_ptr_ioctl,
|
|
|
|
.llseek = noop_llseek,
|
|
|
|
};
|
|
|
|
|
2023-10-04 16:04:49 -07:00
|
|
|
struct cxl_memdev *devm_cxl_add_memdev(struct device *host,
|
|
|
|
struct cxl_dev_state *cxlds)
|
2021-08-02 10:30:05 -07:00
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd;
|
|
|
|
struct device *dev;
|
|
|
|
struct cdev *cdev;
|
|
|
|
int rc;
|
|
|
|
|
2021-11-02 13:29:01 -07:00
|
|
|
cxlmd = cxl_memdev_alloc(cxlds, &cxl_memdev_fops);
|
2021-08-02 10:30:05 -07:00
|
|
|
if (IS_ERR(cxlmd))
|
|
|
|
return cxlmd;
|
|
|
|
|
|
|
|
dev = &cxlmd->dev;
|
|
|
|
rc = dev_set_name(dev, "mem%d", cxlmd->id);
|
|
|
|
if (rc)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Activate ioctl operations, no cxl_memdev_rwsem manipulation
|
|
|
|
* needed as this is ordered with cdev_add() publishing the device.
|
|
|
|
*/
|
2021-11-02 13:29:01 -07:00
|
|
|
cxlmd->cxlds = cxlds;
|
2022-11-29 10:48:59 -07:00
|
|
|
cxlds->cxlmd = cxlmd;
|
2021-08-02 10:30:05 -07:00
|
|
|
|
|
|
|
cdev = &cxlmd->cdev;
|
|
|
|
rc = cdev_device_add(cdev, dev);
|
|
|
|
if (rc)
|
|
|
|
goto err;
|
|
|
|
|
2023-10-04 16:04:49 -07:00
|
|
|
rc = devm_add_action_or_reset(host, cxl_memdev_unregister, cxlmd);
|
2021-08-02 10:30:05 -07:00
|
|
|
if (rc)
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
return cxlmd;
|
|
|
|
|
|
|
|
err:
|
|
|
|
/*
|
|
|
|
* The cdev was briefly live, shutdown any ioctl operations that
|
|
|
|
* saw that state.
|
|
|
|
*/
|
2021-09-08 22:12:32 -07:00
|
|
|
cxl_memdev_shutdown(dev);
|
2021-08-02 10:30:05 -07:00
|
|
|
put_device(dev);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(devm_cxl_add_memdev, "CXL");
|
2021-08-02 10:30:05 -07:00
|
|
|
|
2023-10-04 16:49:36 -07:00
|
|
|
static void sanitize_teardown_notifier(void *data)
|
|
|
|
{
|
|
|
|
struct cxl_memdev_state *mds = data;
|
2024-09-05 15:35:46 -07:00
|
|
|
struct cxl_mailbox *cxl_mbox = &mds->cxlds.cxl_mbox;
|
2023-10-04 16:49:36 -07:00
|
|
|
struct kernfs_node *state;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prevent new irq triggered invocations of the workqueue and
|
|
|
|
* flush inflight invocations.
|
|
|
|
*/
|
2024-09-05 15:35:46 -07:00
|
|
|
mutex_lock(&cxl_mbox->mbox_mutex);
|
2023-10-04 16:49:36 -07:00
|
|
|
state = mds->security.sanitize_node;
|
|
|
|
mds->security.sanitize_node = NULL;
|
2024-09-05 15:35:46 -07:00
|
|
|
mutex_unlock(&cxl_mbox->mbox_mutex);
|
2023-10-04 16:49:36 -07:00
|
|
|
|
|
|
|
cancel_delayed_work_sync(&mds->security.poll_dwork);
|
|
|
|
sysfs_put(state);
|
|
|
|
}
|
|
|
|
|
|
|
|
int devm_cxl_sanitize_setup_notifier(struct device *host,
|
|
|
|
struct cxl_memdev *cxlmd)
|
|
|
|
{
|
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
|
|
|
struct kernfs_node *sec;
|
|
|
|
|
|
|
|
if (!test_bit(CXL_SEC_ENABLED_SANITIZE, mds->security.enabled_cmds))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note, the expectation is that @cxlmd would have failed to be
|
|
|
|
* created if these sysfs_get_dirent calls fail.
|
|
|
|
*/
|
|
|
|
sec = sysfs_get_dirent(cxlmd->dev.kobj.sd, "security");
|
|
|
|
if (!sec)
|
|
|
|
return -ENOENT;
|
|
|
|
mds->security.sanitize_node = sysfs_get_dirent(sec, "state");
|
|
|
|
sysfs_put(sec);
|
|
|
|
if (!mds->security.sanitize_node)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
return devm_add_action_or_reset(host, sanitize_teardown_notifier, mds);
|
|
|
|
}
|
module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.
Scripted using
git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
do
awk -i inplace '
/^#define EXPORT_SYMBOL_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/^#define MODULE_IMPORT_NS/ {
gsub(/__stringify\(ns\)/, "ns");
print;
next;
}
/MODULE_IMPORT_NS/ {
$0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
}
/EXPORT_SYMBOL_NS/ {
if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
$0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
$0 !~ /^my/) {
getline line;
gsub(/[[:space:]]*\\$/, "");
gsub(/[[:space:]]/, "", line);
$0 = $0 " " line;
}
$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
"\\1(\\2, \"\\3\")", "g");
}
}
{ print }' $file;
done
Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 15:59:47 +01:00
|
|
|
EXPORT_SYMBOL_NS_GPL(devm_cxl_sanitize_setup_notifier, "CXL");
|
2023-10-04 16:49:36 -07:00
|
|
|
|
2021-08-02 10:30:05 -07:00
|
|
|
__init int cxl_memdev_init(void)
|
|
|
|
{
|
|
|
|
dev_t devt;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = alloc_chrdev_region(&devt, 0, CXL_MEM_MAX_DEVS, "cxl");
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
cxl_mem_major = MAJOR(devt);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void cxl_memdev_exit(void)
|
|
|
|
{
|
|
|
|
unregister_chrdev_region(MKDEV(cxl_mem_major, 0), CXL_MEM_MAX_DEVS);
|
|
|
|
}
|