2021-08-03 01:30:05 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
|
|
|
/* Copyright(c) 2020 Intel Corporation. */
|
|
|
|
|
2023-06-13 02:10:35 +08: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-15 01:17:40 +08:00
|
|
|
#include <linux/firmware.h>
|
2021-08-03 01:30:05 +08:00
|
|
|
#include <linux/device.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/idr.h>
|
|
|
|
#include <linux/pci.h>
|
|
|
|
#include <cxlmem.h>
|
2023-04-19 11:26:28 +08:00
|
|
|
#include "trace.h"
|
2021-08-03 01:30:05 +08:00
|
|
|
#include "core.h"
|
|
|
|
|
2021-09-09 13:12:32 +08:00
|
|
|
static DECLARE_RWSEM(cxl_memdev_rwsem);
|
|
|
|
|
2021-08-03 01:30:05 +08: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);
|
|
|
|
kfree(cxlmd);
|
|
|
|
}
|
|
|
|
|
2023-01-11 19:30:08 +08:00
|
|
|
static char *cxl_memdev_devnode(const struct device *dev, umode_t *mode, kuid_t *uid,
|
2021-08-03 01:30:05 +08: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-03 04:29:01 +08:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2023-06-15 09:30:02 +08:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
2021-08-03 01:30:05 +08:00
|
|
|
|
2023-06-15 09:30:07 +08:00
|
|
|
if (!mds)
|
|
|
|
return sysfs_emit(buf, "\n");
|
2023-06-15 09:30:02 +08:00
|
|
|
return sysfs_emit(buf, "%.16s\n", mds->firmware_version);
|
2021-08-03 01:30:05 +08: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-03 04:29:01 +08:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2023-06-15 09:30:02 +08:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
2021-08-03 01:30:05 +08:00
|
|
|
|
2023-06-15 09:30:07 +08:00
|
|
|
if (!mds)
|
|
|
|
return sysfs_emit(buf, "\n");
|
2023-06-15 09:30:02 +08:00
|
|
|
return sysfs_emit(buf, "%zu\n", mds->payload_size);
|
2021-08-03 01:30:05 +08: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-03 04:29:01 +08:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2023-06-15 09:30:02 +08:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
2021-08-03 01:30:05 +08:00
|
|
|
|
2023-06-15 09:30:07 +08:00
|
|
|
if (!mds)
|
|
|
|
return sysfs_emit(buf, "\n");
|
2023-06-15 09:30:02 +08:00
|
|
|
return sysfs_emit(buf, "%zu\n", mds->lsa_size);
|
2021-08-03 01:30:05 +08:00
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(label_storage_size);
|
|
|
|
|
|
|
|
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-03 04:29:01 +08:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2022-05-22 06:35:29 +08:00
|
|
|
unsigned long long len = resource_size(&cxlds->ram_res);
|
2021-08-03 01:30:05 +08: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-03 04:29:01 +08:00
|
|
|
struct cxl_dev_state *cxlds = cxlmd->cxlds;
|
2022-05-22 06:35:29 +08:00
|
|
|
unsigned long long len = resource_size(&cxlds->pmem_res);
|
2021-08-03 01:30:05 +08:00
|
|
|
|
|
|
|
return sysfs_emit(buf, "%#llx\n", len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct device_attribute dev_attr_pmem_size =
|
|
|
|
__ATTR(size, 0444, pmem_size_show, NULL);
|
|
|
|
|
2022-02-01 05: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-24 08:31:24 +08:00
|
|
|
static ssize_t numa_node_show(struct device *dev, struct device_attribute *attr,
|
|
|
|
char *buf)
|
|
|
|
{
|
|
|
|
return sprintf(buf, "%d\n", dev_to_node(dev));
|
|
|
|
}
|
|
|
|
static DEVICE_ATTR_RO(numa_node);
|
|
|
|
|
2023-06-13 02:10:33 +08: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;
|
2023-06-26 08:16:51 +08:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlds);
|
|
|
|
unsigned long state = mds->security.state;
|
2023-10-05 09:35:01 +08:00
|
|
|
int rc = 0;
|
2023-06-13 02:10:35 +08:00
|
|
|
|
2023-10-05 09:35:01 +08:00
|
|
|
/* sync with latest submission state */
|
|
|
|
mutex_lock(&mds->mbox_mutex);
|
|
|
|
if (mds->security.sanitize_active)
|
|
|
|
rc = sysfs_emit(buf, "sanitize\n");
|
|
|
|
mutex_unlock(&mds->mbox_mutex);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
2023-06-13 02:10:33 +08: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");
|
|
|
|
else
|
|
|
|
return sysfs_emit(buf, "unlocked\n");
|
|
|
|
}
|
|
|
|
static struct device_attribute dev_attr_security_state =
|
|
|
|
__ATTR(state, 0444, security_state_show, NULL);
|
|
|
|
|
2023-06-13 02:10:35 +08: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-26 08:16:51 +08:00
|
|
|
ssize_t rc;
|
2023-06-13 02:10:35 +08:00
|
|
|
|
|
|
|
if (kstrtobool(buf, &sanitize) || !sanitize)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-10-05 09:35:01 +08:00
|
|
|
rc = cxl_mem_sanitize(cxlmd, CXL_MBOX_OP_SANITIZE);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
2023-06-13 02:10:35 +08:00
|
|
|
|
2023-10-05 09:35:01 +08:00
|
|
|
return len;
|
2023-06-13 02:10:35 +08:00
|
|
|
}
|
|
|
|
static struct device_attribute dev_attr_security_sanitize =
|
|
|
|
__ATTR(sanitize, 0200, NULL, security_sanitize_store);
|
|
|
|
|
2023-06-13 02:10:37 +08: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-05 09:35:01 +08:00
|
|
|
rc = cxl_mem_sanitize(cxlmd, CXL_MBOX_OP_SECURE_ERASE);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
2023-06-13 02:10:37 +08:00
|
|
|
|
2023-10-05 09:35:01 +08:00
|
|
|
return len;
|
2023-06-13 02:10:37 +08:00
|
|
|
}
|
|
|
|
static struct device_attribute dev_attr_security_erase =
|
|
|
|
__ATTR(erase, 0200, NULL, security_erase_store);
|
|
|
|
|
2023-04-19 01:39:06 +08: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 */
|
|
|
|
if (resource_size(&cxlds->pmem_res)) {
|
|
|
|
offset = cxlds->pmem_res.start;
|
|
|
|
length = resource_size(&cxlds->pmem_res);
|
|
|
|
rc = cxl_mem_get_poison(cxlmd, offset, length, NULL);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
if (resource_size(&cxlds->ram_res)) {
|
|
|
|
offset = cxlds->ram_res.start;
|
|
|
|
length = resource_size(&cxlds->ram_res);
|
|
|
|
rc = cxl_mem_get_poison(cxlmd, offset, length, NULL);
|
|
|
|
/*
|
|
|
|
* Invalid Physical Address is not an error for
|
|
|
|
* volatile addresses. Device support is optional.
|
|
|
|
*/
|
|
|
|
if (rc == -EFAULT)
|
|
|
|
rc = 0;
|
|
|
|
}
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
int cxl_trigger_poison_list(struct cxl_memdev *cxlmd)
|
|
|
|
{
|
2023-04-19 01:39:07 +08:00
|
|
|
struct cxl_port *port;
|
2023-04-19 01:39:06 +08:00
|
|
|
int rc;
|
|
|
|
|
2023-06-15 09:30:43 +08:00
|
|
|
port = cxlmd->endpoint;
|
2023-04-19 01:39:07 +08:00
|
|
|
if (!port || !is_cxl_endpoint(port))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2023-11-27 08:09:29 +08:00
|
|
|
rc = down_read_interruptible(&cxl_region_rwsem);
|
2023-04-19 01:39:06 +08:00
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
2023-11-27 08:09:29 +08:00
|
|
|
rc = down_read_interruptible(&cxl_dpa_rwsem);
|
|
|
|
if (rc) {
|
|
|
|
up_read(&cxl_region_rwsem);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2023-10-17 01:57:48 +08:00
|
|
|
if (cxl_num_decoders_committed(port) == 0) {
|
2023-04-19 01:39:07 +08: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-19 01:39:06 +08:00
|
|
|
up_read(&cxl_dpa_rwsem);
|
2023-11-27 08:09:29 +08:00
|
|
|
up_read(&cxl_region_rwsem);
|
2023-04-19 01:39:06 +08:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(cxl_trigger_poison_list, CXL);
|
|
|
|
|
2023-04-19 11:26:27 +08:00
|
|
|
struct cxl_dpa_to_region_context {
|
|
|
|
struct cxl_region *cxlr;
|
|
|
|
u64 dpa;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int __cxl_dpa_to_region(struct device *dev, void *arg)
|
|
|
|
{
|
|
|
|
struct cxl_dpa_to_region_context *ctx = arg;
|
|
|
|
struct cxl_endpoint_decoder *cxled;
|
|
|
|
u64 dpa = ctx->dpa;
|
|
|
|
|
|
|
|
if (!is_endpoint_decoder(dev))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
cxled = to_cxl_endpoint_decoder(dev);
|
|
|
|
if (!cxled->dpa_res || !resource_size(cxled->dpa_res))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (dpa > cxled->dpa_res->end || dpa < cxled->dpa_res->start)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
dev_dbg(dev, "dpa:0x%llx mapped in region:%s\n", dpa,
|
|
|
|
dev_name(&cxled->cxld.region->dev));
|
|
|
|
|
|
|
|
ctx->cxlr = cxled->cxld.region;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct cxl_region *cxl_dpa_to_region(struct cxl_memdev *cxlmd, u64 dpa)
|
|
|
|
{
|
|
|
|
struct cxl_dpa_to_region_context ctx;
|
|
|
|
struct cxl_port *port;
|
|
|
|
|
|
|
|
ctx = (struct cxl_dpa_to_region_context) {
|
|
|
|
.dpa = dpa,
|
|
|
|
};
|
2023-06-15 09:30:43 +08:00
|
|
|
port = cxlmd->endpoint;
|
2023-10-17 01:57:48 +08:00
|
|
|
if (port && is_cxl_endpoint(port) && cxl_num_decoders_committed(port))
|
2023-04-19 11:26:27 +08:00
|
|
|
device_for_each_child(&port->dev, &ctx, __cxl_dpa_to_region);
|
|
|
|
|
|
|
|
return ctx.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-19 11:26:25 +08: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;
|
|
|
|
}
|
|
|
|
if (dpa < cxlds->dpa_res.start || dpa > cxlds->dpa_res.end) {
|
|
|
|
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)
|
|
|
|
{
|
2023-06-15 09:30:02 +08:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlmd->cxlds);
|
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-19 11:26:25 +08:00
|
|
|
struct cxl_mbox_inject_poison inject;
|
2023-04-19 11:26:28 +08: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-19 11:26:25 +08:00
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
2023-04-19 11:26:27 +08: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-19 11:26:25 +08:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_DEBUG_FS))
|
|
|
|
return 0;
|
|
|
|
|
2023-11-27 08:09:30 +08:00
|
|
|
rc = down_read_interruptible(&cxl_region_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-19 11:26:25 +08:00
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
2023-11-27 08:09:30 +08:00
|
|
|
rc = down_read_interruptible(&cxl_dpa_rwsem);
|
|
|
|
if (rc) {
|
|
|
|
up_read(&cxl_region_rwsem);
|
|
|
|
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-19 11:26:25 +08:00
|
|
|
rc = cxl_validate_poison_dpa(cxlmd, dpa);
|
|
|
|
if (rc)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
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,
|
|
|
|
};
|
2023-06-15 09:30:02 +08:00
|
|
|
rc = cxl_internal_send_cmd(mds, &mbox_cmd);
|
2023-04-19 11:26:27 +08:00
|
|
|
if (rc)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
cxlr = cxl_dpa_to_region(cxlmd, dpa);
|
|
|
|
if (cxlr)
|
2023-06-15 09:30:02 +08:00
|
|
|
dev_warn_once(mds->cxlds.dev,
|
2023-04-19 11:26:27 +08:00
|
|
|
"poison inject dpa:%#llx region: %s\n", dpa,
|
|
|
|
dev_name(&cxlr->dev));
|
2023-04-19 11:26:28 +08: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-19 11:26:25 +08:00
|
|
|
out:
|
|
|
|
up_read(&cxl_dpa_rwsem);
|
2023-11-27 08:09:30 +08:00
|
|
|
up_read(&cxl_region_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-19 11:26:25 +08:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(cxl_inject_poison, CXL);
|
|
|
|
|
2023-04-19 11:26:26 +08:00
|
|
|
int cxl_clear_poison(struct cxl_memdev *cxlmd, u64 dpa)
|
|
|
|
{
|
2023-06-15 09:30:02 +08:00
|
|
|
struct cxl_memdev_state *mds = to_cxl_memdev_state(cxlmd->cxlds);
|
2023-04-19 11:26:26 +08:00
|
|
|
struct cxl_mbox_clear_poison clear;
|
2023-04-19 11:26:28 +08:00
|
|
|
struct cxl_poison_record record;
|
2023-04-19 11:26:26 +08:00
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
2023-04-19 11:26:27 +08:00
|
|
|
struct cxl_region *cxlr;
|
2023-04-19 11:26:26 +08:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_DEBUG_FS))
|
|
|
|
return 0;
|
|
|
|
|
2023-11-27 08:09:30 +08:00
|
|
|
rc = down_read_interruptible(&cxl_region_rwsem);
|
2023-04-19 11:26:26 +08:00
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
2023-11-27 08:09:30 +08:00
|
|
|
rc = down_read_interruptible(&cxl_dpa_rwsem);
|
|
|
|
if (rc) {
|
|
|
|
up_read(&cxl_region_rwsem);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2023-04-19 11:26:26 +08:00
|
|
|
rc = cxl_validate_poison_dpa(cxlmd, dpa);
|
|
|
|
if (rc)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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,
|
|
|
|
};
|
|
|
|
|
2023-06-15 09:30:02 +08:00
|
|
|
rc = cxl_internal_send_cmd(mds, &mbox_cmd);
|
2023-04-19 11:26:26 +08:00
|
|
|
if (rc)
|
|
|
|
goto out;
|
2023-04-19 11:26:27 +08:00
|
|
|
|
|
|
|
cxlr = cxl_dpa_to_region(cxlmd, dpa);
|
|
|
|
if (cxlr)
|
2023-06-15 09:30:02 +08:00
|
|
|
dev_warn_once(mds->cxlds.dev,
|
|
|
|
"poison clear dpa:%#llx region: %s\n", dpa,
|
|
|
|
dev_name(&cxlr->dev));
|
2023-04-19 11:26:28 +08: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-19 11:26:26 +08:00
|
|
|
out:
|
|
|
|
up_read(&cxl_dpa_rwsem);
|
2023-11-27 08:09:30 +08:00
|
|
|
up_read(&cxl_region_rwsem);
|
2023-04-19 11:26:26 +08:00
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(cxl_clear_poison, CXL);
|
|
|
|
|
2021-08-03 01:30:05 +08:00
|
|
|
static struct attribute *cxl_memdev_attributes[] = {
|
2022-02-01 05:56:11 +08:00
|
|
|
&dev_attr_serial.attr,
|
2021-08-03 01:30:05 +08:00
|
|
|
&dev_attr_firmware_version.attr,
|
|
|
|
&dev_attr_payload_max.attr,
|
|
|
|
&dev_attr_label_storage_size.attr,
|
2022-01-24 08:31:24 +08:00
|
|
|
&dev_attr_numa_node.attr,
|
2021-08-03 01:30:05 +08:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute *cxl_memdev_pmem_attributes[] = {
|
|
|
|
&dev_attr_pmem_size.attr,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute *cxl_memdev_ram_attributes[] = {
|
|
|
|
&dev_attr_ram_size.attr,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2023-06-13 02:10:33 +08:00
|
|
|
static struct attribute *cxl_memdev_security_attributes[] = {
|
|
|
|
&dev_attr_security_state.attr,
|
2023-06-13 02:10:35 +08:00
|
|
|
&dev_attr_security_sanitize.attr,
|
2023-06-13 02:10:37 +08:00
|
|
|
&dev_attr_security_erase.attr,
|
2023-06-13 02:10:33 +08:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
2022-01-24 08: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-03 01:30:05 +08:00
|
|
|
static struct attribute_group cxl_memdev_attribute_group = {
|
|
|
|
.attrs = cxl_memdev_attributes,
|
2022-01-24 08:31:24 +08:00
|
|
|
.is_visible = cxl_memdev_visible,
|
2021-08-03 01:30:05 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group cxl_memdev_ram_attribute_group = {
|
|
|
|
.name = "ram",
|
|
|
|
.attrs = cxl_memdev_ram_attributes,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group cxl_memdev_pmem_attribute_group = {
|
|
|
|
.name = "pmem",
|
|
|
|
.attrs = cxl_memdev_pmem_attributes,
|
|
|
|
};
|
|
|
|
|
2023-07-26 13:19:40 +08: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-13 02:10:33 +08:00
|
|
|
static struct attribute_group cxl_memdev_security_attribute_group = {
|
|
|
|
.name = "security",
|
|
|
|
.attrs = cxl_memdev_security_attributes,
|
2023-07-26 13:19:40 +08:00
|
|
|
.is_visible = cxl_memdev_security_visible,
|
2023-06-13 02:10:33 +08:00
|
|
|
};
|
|
|
|
|
2021-08-03 01:30:05 +08: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-13 02:10:33 +08:00
|
|
|
&cxl_memdev_security_attribute_group,
|
2021-08-03 01:30:05 +08:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
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 19:30:17 +08:00
|
|
|
bool is_cxl_memdev(const struct device *dev)
|
2022-02-04 23:18:31 +08:00
|
|
|
{
|
|
|
|
return dev->type == &cxl_memdev_type;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(is_cxl_memdev, CXL);
|
|
|
|
|
2021-09-15 03:03:04 +08:00
|
|
|
/**
|
|
|
|
* set_exclusive_cxl_commands() - atomically disable user cxl commands
|
2023-06-15 09:30:02 +08:00
|
|
|
* @mds: The device state to operate on
|
2021-09-15 03:03:04 +08: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-15 09:30:02 +08:00
|
|
|
void set_exclusive_cxl_commands(struct cxl_memdev_state *mds,
|
|
|
|
unsigned long *cmds)
|
2021-09-15 03:03:04 +08:00
|
|
|
{
|
|
|
|
down_write(&cxl_memdev_rwsem);
|
2023-06-15 09:30:02 +08:00
|
|
|
bitmap_or(mds->exclusive_cmds, mds->exclusive_cmds, cmds,
|
2021-09-15 03:03:04 +08:00
|
|
|
CXL_MEM_COMMAND_ID_MAX);
|
|
|
|
up_write(&cxl_memdev_rwsem);
|
|
|
|
}
|
2021-11-13 08:32:58 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(set_exclusive_cxl_commands, CXL);
|
2021-09-15 03:03:04 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* clear_exclusive_cxl_commands() - atomically enable user cxl commands
|
2023-06-15 09:30:02 +08:00
|
|
|
* @mds: The device state to modify
|
2021-09-15 03:03:04 +08:00
|
|
|
* @cmds: bitmap of commands to mark available for userspace
|
|
|
|
*/
|
2023-06-15 09:30:02 +08:00
|
|
|
void clear_exclusive_cxl_commands(struct cxl_memdev_state *mds,
|
|
|
|
unsigned long *cmds)
|
2021-09-15 03:03:04 +08:00
|
|
|
{
|
|
|
|
down_write(&cxl_memdev_rwsem);
|
2023-06-15 09:30:02 +08:00
|
|
|
bitmap_andnot(mds->exclusive_cmds, mds->exclusive_cmds, cmds,
|
2021-09-15 03:03:04 +08:00
|
|
|
CXL_MEM_COMMAND_ID_MAX);
|
|
|
|
up_write(&cxl_memdev_rwsem);
|
|
|
|
}
|
2021-11-13 08:32:58 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(clear_exclusive_cxl_commands, CXL);
|
2021-09-15 03:03:04 +08:00
|
|
|
|
2021-09-09 13:12:32 +08:00
|
|
|
static void cxl_memdev_shutdown(struct device *dev)
|
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd = to_cxl_memdev(dev);
|
|
|
|
|
|
|
|
down_write(&cxl_memdev_rwsem);
|
2021-11-03 04:29:01 +08:00
|
|
|
cxlmd->cxlds = NULL;
|
2021-09-09 13:12:32 +08:00
|
|
|
up_write(&cxl_memdev_rwsem);
|
|
|
|
}
|
|
|
|
|
2021-08-03 01:30:05 +08: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-29 09:02:07 +08:00
|
|
|
cxl_memdev_shutdown(dev);
|
2021-08-03 01:30:05 +08:00
|
|
|
put_device(dev);
|
|
|
|
}
|
|
|
|
|
2022-02-04 23: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 23:33:13 +08:00
|
|
|
static struct lock_class_key cxl_memdev_key;
|
|
|
|
|
2021-11-03 04:29:01 +08:00
|
|
|
static struct cxl_memdev *cxl_memdev_alloc(struct cxl_dev_state *cxlds,
|
2021-08-03 01:30:05 +08: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-09 02:19:44 +08:00
|
|
|
rc = ida_alloc_max(&cxl_memdev_ida, CXL_MEM_MAX_DEVS - 1, GFP_KERNEL);
|
2021-08-03 01:30:05 +08:00
|
|
|
if (rc < 0)
|
|
|
|
goto err;
|
|
|
|
cxlmd->id = rc;
|
2023-02-11 09:29:09 +08:00
|
|
|
cxlmd->depth = -1;
|
2021-08-03 01:30:05 +08:00
|
|
|
|
|
|
|
dev = &cxlmd->dev;
|
|
|
|
device_initialize(dev);
|
2022-04-21 23:33:13 +08:00
|
|
|
lockdep_set_class(&dev->mutex, &cxl_memdev_key);
|
2021-11-03 04:29:01 +08:00
|
|
|
dev->parent = cxlds->dev;
|
2021-08-03 01:30:05 +08: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 23:18:31 +08:00
|
|
|
INIT_WORK(&cxlmd->detach_work, detach_memdev);
|
2021-08-03 01:30:05 +08:00
|
|
|
|
|
|
|
cdev = &cxlmd->cdev;
|
|
|
|
cdev_init(cdev, fops);
|
|
|
|
return cxlmd;
|
|
|
|
|
|
|
|
err:
|
|
|
|
kfree(cxlmd);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
|
|
|
|
2021-09-09 13:12:32 +08:00
|
|
|
static long __cxl_memdev_ioctl(struct cxl_memdev *cxlmd, unsigned int cmd,
|
|
|
|
unsigned long arg)
|
|
|
|
{
|
|
|
|
switch (cmd) {
|
|
|
|
case CXL_MEM_QUERY_COMMANDS:
|
|
|
|
return cxl_query_cmd(cxlmd, (void __user *)arg);
|
|
|
|
case CXL_MEM_SEND_COMMAND:
|
|
|
|
return cxl_send_cmd(cxlmd, (void __user *)arg);
|
|
|
|
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-15 09:30:07 +08:00
|
|
|
struct cxl_dev_state *cxlds;
|
2021-09-09 13:12:32 +08:00
|
|
|
int rc = -ENXIO;
|
|
|
|
|
|
|
|
down_read(&cxl_memdev_rwsem);
|
2023-06-15 09:30:07 +08:00
|
|
|
cxlds = cxlmd->cxlds;
|
|
|
|
if (cxlds && cxlds->type == CXL_DEVTYPE_CLASSMEM)
|
2021-09-09 13:12:32 +08:00
|
|
|
rc = __cxl_memdev_ioctl(cxlmd, cmd, arg);
|
|
|
|
up_read(&cxl_memdev_rwsem);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
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-15 01:17:40 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08: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,
|
|
|
|
};
|
|
|
|
|
2023-06-26 08:16:51 +08:00
|
|
|
rc = cxl_internal_send_cmd(mds, &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-15 01:17:40 +08:00
|
|
|
if (rc < 0)
|
|
|
|
return rc;
|
|
|
|
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
info.slot_info);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* cxl_mem_activate_fw - Activate Firmware
|
2023-06-26 08:16:51 +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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
{
|
|
|
|
struct cxl_mbox_activate_fw activate;
|
|
|
|
struct cxl_mbox_cmd mbox_cmd;
|
|
|
|
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08: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;
|
|
|
|
|
2023-06-26 08:16:51 +08:00
|
|
|
return cxl_internal_send_cmd(mds, &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-15 01:17:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* cxl_mem_abort_fw_xfer - Abort an in-progress FW transfer
|
2023-06-26 08:16:51 +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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08: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;
|
|
|
|
|
2023-06-26 08:16:51 +08:00
|
|
|
rc = cxl_internal_send_cmd(mds, &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-15 01:17:40 +08:00
|
|
|
kfree(transfer);
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cxl_fw_cleanup(struct fw_upload *fwl)
|
|
|
|
{
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int cxl_fw_do_cancel(struct fw_upload *fwl)
|
|
|
|
{
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
struct cxl_memdev *cxlmd = cxlds->cxlmd;
|
|
|
|
int rc;
|
|
|
|
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
struct cxl_mbox_transfer_fw *transfer;
|
|
|
|
|
|
|
|
if (!size)
|
|
|
|
return FW_UPLOAD_ERR_INVALID_SIZE;
|
|
|
|
|
2023-06-26 08:16:51 +08:00
|
|
|
mds->fw.oneshot = struct_size(transfer, data, size) <
|
|
|
|
mds->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-15 01:17:40 +08:00
|
|
|
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
*/
|
2023-06-26 08:16:51 +08:00
|
|
|
cur_size = min_t(size_t, size, mds->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-15 01:17:40 +08:00
|
|
|
|
|
|
|
remaining = size - cur_size;
|
|
|
|
size_in = struct_size(transfer, data, cur_size);
|
|
|
|
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
transfer->action = CXL_FW_TRANSFER_ACTION_FULL;
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08: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,
|
|
|
|
};
|
|
|
|
|
2023-06-26 08:16:51 +08:00
|
|
|
rc = cxl_internal_send_cmd(mds, &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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
dev_dbg(&cxlmd->dev, "Activating firmware slot: %d\n",
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08: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-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
return cxl_fw_do_cancel(fwl);
|
|
|
|
|
|
|
|
return FW_UPLOAD_ERR_NONE;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cxl_fw_cancel(struct fw_upload *fwl)
|
|
|
|
{
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08: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-05 07:04:49 +08: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-15 01:17:40 +08:00
|
|
|
{
|
|
|
|
firmware_upload_unregister(fwl);
|
|
|
|
}
|
|
|
|
|
2023-10-05 07:04:49 +08: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-15 01:17:40 +08:00
|
|
|
{
|
2023-06-26 08:16:51 +08:00
|
|
|
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-15 01:17:40 +08:00
|
|
|
struct device *dev = &cxlds->cxlmd->dev;
|
|
|
|
struct fw_upload *fwl;
|
|
|
|
|
2023-06-26 08:16:51 +08:00
|
|
|
if (!test_bit(CXL_MEM_COMMAND_ID_GET_FW_INFO, mds->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-15 01:17:40 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
fwl = firmware_upload_register(THIS_MODULE, dev, dev_name(dev),
|
2023-06-26 08:16:51 +08: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-15 01:17:40 +08:00
|
|
|
if (IS_ERR(fwl))
|
2023-10-05 07:24:39 +08:00
|
|
|
return PTR_ERR(fwl);
|
2023-10-05 07:04:49 +08: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-15 01:17:40 +08:00
|
|
|
}
|
2023-10-05 07:04:49 +08: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-15 01:17:40 +08:00
|
|
|
|
2021-09-09 13:12:32 +08: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-05 07:04:49 +08:00
|
|
|
struct cxl_memdev *devm_cxl_add_memdev(struct device *host,
|
|
|
|
struct cxl_dev_state *cxlds)
|
2021-08-03 01:30:05 +08:00
|
|
|
{
|
|
|
|
struct cxl_memdev *cxlmd;
|
|
|
|
struct device *dev;
|
|
|
|
struct cdev *cdev;
|
|
|
|
int rc;
|
|
|
|
|
2021-11-03 04:29:01 +08:00
|
|
|
cxlmd = cxl_memdev_alloc(cxlds, &cxl_memdev_fops);
|
2021-08-03 01:30:05 +08: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-03 04:29:01 +08:00
|
|
|
cxlmd->cxlds = cxlds;
|
2022-11-30 01:48:59 +08:00
|
|
|
cxlds->cxlmd = cxlmd;
|
2021-08-03 01:30:05 +08:00
|
|
|
|
|
|
|
cdev = &cxlmd->cdev;
|
|
|
|
rc = cdev_device_add(cdev, dev);
|
|
|
|
if (rc)
|
|
|
|
goto err;
|
|
|
|
|
2023-10-05 07:04:49 +08:00
|
|
|
rc = devm_add_action_or_reset(host, cxl_memdev_unregister, cxlmd);
|
2021-08-03 01:30:05 +08: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-09 13:12:32 +08:00
|
|
|
cxl_memdev_shutdown(dev);
|
2021-08-03 01:30:05 +08:00
|
|
|
put_device(dev);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
2021-11-13 08:32:58 +08:00
|
|
|
EXPORT_SYMBOL_NS_GPL(devm_cxl_add_memdev, CXL);
|
2021-08-03 01:30:05 +08:00
|
|
|
|
2023-10-05 07:49:36 +08:00
|
|
|
static void sanitize_teardown_notifier(void *data)
|
|
|
|
{
|
|
|
|
struct cxl_memdev_state *mds = data;
|
|
|
|
struct kernfs_node *state;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Prevent new irq triggered invocations of the workqueue and
|
|
|
|
* flush inflight invocations.
|
|
|
|
*/
|
|
|
|
mutex_lock(&mds->mbox_mutex);
|
|
|
|
state = mds->security.sanitize_node;
|
|
|
|
mds->security.sanitize_node = NULL;
|
|
|
|
mutex_unlock(&mds->mbox_mutex);
|
|
|
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_NS_GPL(devm_cxl_sanitize_setup_notifier, CXL);
|
|
|
|
|
2021-08-03 01:30:05 +08: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);
|
|
|
|
}
|