drivers/mtd/devices/powernv_flash.c
Source file repositories/reference/linux-study-clean/drivers/mtd/devices/powernv_flash.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/mtd/devices/powernv_flash.c- Extension
.c- Size
- 7377 bytes
- Lines
- 299
- Domain
- Driver Families
- Bucket
- drivers/mtd
- Inferred role
- Driver Families: implementation source
- Status
- source implementation candidate
Why This File Exists
Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Repeatable hardware-adapter layer. Deep compatibility for every driver is out of scope; this atlas records patterns, probe lifecycles, bus glue, IRQ/DMA usage, and links back to core abstractions.
- Allocates kernel memory; connect allocation flags and lifetime to context constraints.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/kernel.hlinux/module.hlinux/errno.hlinux/of.hlinux/of_address.hlinux/platform_device.hlinux/string.hlinux/slab.hlinux/mtd/mtd.hlinux/mtd/partitions.hlinux/debugfs.hlinux/seq_file.hasm/opal.h
Detected Declarations
struct powernv_flashenum flash_opfunction powernv_flash_async_opfunction powernv_flash_readfunction powernv_flash_writefunction powernv_flash_erasefunction powernv_flash_set_driver_infofunction powernv_flash_probefunction powernv_flash_release
Annotated Snippet
struct powernv_flash {
struct mtd_info mtd;
u32 id;
};
enum flash_op {
FLASH_OP_READ,
FLASH_OP_WRITE,
FLASH_OP_ERASE,
};
/*
* Don't return -ERESTARTSYS if we can't get a token, the MTD core
* might have split up the call from userspace and called into the
* driver more than once, we'll already have done some amount of work.
*/
static int powernv_flash_async_op(struct mtd_info *mtd, enum flash_op op,
loff_t offset, size_t len, size_t *retlen, u_char *buf)
{
struct powernv_flash *info = (struct powernv_flash *)mtd->priv;
struct device *dev = &mtd->dev;
int token;
struct opal_msg msg;
int rc;
dev_dbg(dev, "%s(op=%d, offset=0x%llx, len=%zu)\n",
__func__, op, offset, len);
token = opal_async_get_token_interruptible();
if (token < 0) {
if (token != -ERESTARTSYS)
dev_err(dev, "Failed to get an async token\n");
else
token = -EINTR;
return token;
}
switch (op) {
case FLASH_OP_READ:
rc = opal_flash_read(info->id, offset, __pa(buf), len, token);
break;
case FLASH_OP_WRITE:
rc = opal_flash_write(info->id, offset, __pa(buf), len, token);
break;
case FLASH_OP_ERASE:
rc = opal_flash_erase(info->id, offset, len, token);
break;
default:
WARN_ON_ONCE(1);
opal_async_release_token(token);
return -EIO;
}
if (rc == OPAL_ASYNC_COMPLETION) {
rc = opal_async_wait_response_interruptible(token, &msg);
if (rc) {
/*
* If we return the mtd core will free the
* buffer we've just passed to OPAL but OPAL
* will continue to read or write from that
* memory.
* It may be tempting to ultimately return 0
* if we're doing a read or a write since we
* are going to end up waiting until OPAL is
* done. However, because the MTD core sends
* us the userspace request in chunks, we need
* it to know we've been interrupted.
*/
rc = -EINTR;
if (opal_async_wait_response(token, &msg))
dev_err(dev, "opal_async_wait_response() failed\n");
goto out;
}
rc = opal_get_async_rc(msg);
}
/*
* OPAL does mutual exclusion on the flash, it will return
* OPAL_BUSY.
* During firmware updates by the service processor OPAL may
* be (temporarily) prevented from accessing the flash, in
* this case OPAL will also return OPAL_BUSY.
* Both cases aren't errors exactly but the flash could have
* changed, userspace should be informed.
*/
if (rc != OPAL_SUCCESS && rc != OPAL_BUSY)
dev_err(dev, "opal_flash_async_op(op=%d) failed (rc %d)\n",
op, rc);
if (rc == OPAL_SUCCESS && retlen)
Annotation
- Immediate include surface: `linux/kernel.h`, `linux/module.h`, `linux/errno.h`, `linux/of.h`, `linux/of_address.h`, `linux/platform_device.h`, `linux/string.h`, `linux/slab.h`.
- Detected declarations: `struct powernv_flash`, `enum flash_op`, `function powernv_flash_async_op`, `function powernv_flash_read`, `function powernv_flash_write`, `function powernv_flash_erase`, `function powernv_flash_set_driver_info`, `function powernv_flash_probe`, `function powernv_flash_release`.
- Atlas domain: Driver Families / drivers/mtd.
- Implementation status: source implementation candidate.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.