drivers/mtd/chips/fwh_lock.h
Source file repositories/reference/linux-study-clean/drivers/mtd/chips/fwh_lock.h
File Facts
- System
- Linux kernel
- Corpus path
drivers/mtd/chips/fwh_lock.h- Extension
.h- Size
- 2849 bytes
- Lines
- 109
- 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.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
struct fwh_xxlock_thunkenum fwh_lock_statefunction fwh_xxlock_oneblockfunction fwh_lock_varsizefunction fwh_unlock_varsizefunction fixup_use_fwh_lock
Annotated Snippet
struct fwh_xxlock_thunk {
enum fwh_lock_state val;
flstate_t state;
};
#define FWH_XXLOCK_ONEBLOCK_LOCK ((struct fwh_xxlock_thunk){ FWH_DENY_WRITE, FL_LOCKING})
#define FWH_XXLOCK_ONEBLOCK_UNLOCK ((struct fwh_xxlock_thunk){ FWH_UNLOCKED, FL_UNLOCKING})
/*
* This locking/unlock is specific to firmware hub parts. Only one
* is known that supports the Intel command set. Firmware
* hub parts cannot be interleaved as they are on the LPC bus
* so this code has not been tested with interleaved chips,
* and will likely fail in that context.
*/
static int fwh_xxlock_oneblock(struct map_info *map, struct flchip *chip,
unsigned long adr, int len, void *thunk)
{
struct cfi_private *cfi = map->fldrv_priv;
struct fwh_xxlock_thunk *xxlt = (struct fwh_xxlock_thunk *)thunk;
int ret;
/* Refuse the operation if the we cannot look behind the chip */
if (chip->start < 0x400000) {
pr_debug( "MTD %s(): chip->start: %lx wanted >= 0x400000\n",
__func__, chip->start );
return -EIO;
}
/*
* lock block registers:
* - on 64k boundariesand
* - bit 1 set high
* - block lock registers are 4MiB lower - overflow subtract (danger)
*
* The address manipulation is first done on the logical address
* which is 0 at the start of the chip, and then the offset of
* the individual chip is addted to it. Any other order a weird
* map offset could cause problems.
*/
adr = (adr & ~0xffffUL) | 0x2;
adr += chip->start - 0x400000;
/*
* This is easy because these are writes to registers and not writes
* to flash memory - that means that we don't have to check status
* and timeout.
*/
mutex_lock(&chip->mutex);
ret = get_chip(map, chip, adr, FL_LOCKING);
if (ret) {
mutex_unlock(&chip->mutex);
return ret;
}
chip->oldstate = chip->state;
chip->state = xxlt->state;
map_write(map, CMD(xxlt->val), adr);
/* Done and happy. */
chip->state = chip->oldstate;
put_chip(map, chip, adr);
mutex_unlock(&chip->mutex);
return 0;
}
static int fwh_lock_varsize(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
int ret;
ret = cfi_varsize_frob(mtd, fwh_xxlock_oneblock, ofs, len,
(void *)&FWH_XXLOCK_ONEBLOCK_LOCK);
return ret;
}
static int fwh_unlock_varsize(struct mtd_info *mtd, loff_t ofs, uint64_t len)
{
int ret;
ret = cfi_varsize_frob(mtd, fwh_xxlock_oneblock, ofs, len,
(void *)&FWH_XXLOCK_ONEBLOCK_UNLOCK);
return ret;
}
static void fixup_use_fwh_lock(struct mtd_info *mtd)
{
Annotation
- Detected declarations: `struct fwh_xxlock_thunk`, `enum fwh_lock_state`, `function fwh_xxlock_oneblock`, `function fwh_lock_varsize`, `function fwh_unlock_varsize`, `function fixup_use_fwh_lock`.
- Atlas domain: Driver Families / drivers/mtd.
- Implementation status: source implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
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.