drivers/mtd/maps/physmap-ixp4xx.c
Source file repositories/reference/linux-study-clean/drivers/mtd/maps/physmap-ixp4xx.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/mtd/maps/physmap-ixp4xx.c- Extension
.c- Size
- 3247 bytes
- Lines
- 133
- 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.
- Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.
Dependency Surface
linux/export.hlinux/of.hlinux/platform_device.hlinux/mtd/map.hlinux/mtd/xip.hphysmap-ixp4xx.h
Detected Declarations
function Copyrightfunction flash_write16function flash_read16function flash_write16function ixp4xx_read16function ixp4xx_copy_fromfunction ixp4xx_write16function of_flash_probe_ixp4xx
Annotated Snippet
// SPDX-License-Identifier: GPL-2.0
/*
* Intel IXP4xx OF physmap add-on
* Copyright (C) 2019 Linus Walleij <linus.walleij@linaro.org>
*
* Based on the ixp4xx.c map driver, originally written by:
* Intel Corporation
* Deepak Saxena <dsaxena@mvista.com>
* Copyright (C) 2002 Intel Corporation
* Copyright (C) 2003-2004 MontaVista Software, Inc.
*/
#include <linux/export.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/mtd/map.h>
#include <linux/mtd/xip.h>
#include "physmap-ixp4xx.h"
/*
* Read/write a 16 bit word from flash address 'addr'.
*
* When the cpu is in little-endian mode it swizzles the address lines
* ('address coherency') so we need to undo the swizzling to ensure commands
* and the like end up on the correct flash address.
*
* To further complicate matters, due to the way the expansion bus controller
* handles 32 bit reads, the byte stream ABCD is stored on the flash as:
* D15 D0
* +---+---+
* | A | B | 0
* +---+---+
* | C | D | 2
* +---+---+
* This means that on LE systems each 16 bit word must be swapped. Note that
* this requires CONFIG_MTD_CFI_BE_BYTE_SWAP to be enabled to 'unswap' the CFI
* data and other flash commands which are always in D7-D0.
*/
#ifndef CONFIG_CPU_BIG_ENDIAN
static inline u16 flash_read16(void __iomem *addr)
{
return be16_to_cpu(__raw_readw((void __iomem *)((unsigned long)addr ^ 0x2)));
}
static inline void flash_write16(u16 d, void __iomem *addr)
{
__raw_writew(cpu_to_be16(d), (void __iomem *)((unsigned long)addr ^ 0x2));
}
#define BYTE0(h) ((h) & 0xFF)
#define BYTE1(h) (((h) >> 8) & 0xFF)
#else
static inline u16 flash_read16(const void __iomem *addr)
{
return __raw_readw(addr);
}
static inline void flash_write16(u16 d, void __iomem *addr)
{
__raw_writew(d, addr);
}
#define BYTE0(h) (((h) >> 8) & 0xFF)
#define BYTE1(h) ((h) & 0xFF)
#endif
static map_word ixp4xx_read16(struct map_info *map, unsigned long ofs)
{
map_word val;
val.x[0] = flash_read16(map->virt + ofs);
return val;
}
/*
* The IXP4xx expansion bus only allows 16-bit wide acceses
* when attached to a 16-bit wide device (such as the 28F128J3A),
* so we can't just memcpy_fromio().
*/
static void ixp4xx_copy_from(struct map_info *map, void *to,
unsigned long from, ssize_t len)
{
u8 *dest = (u8 *) to;
void __iomem *src = map->virt + from;
if (len <= 0)
return;
Annotation
- Immediate include surface: `linux/export.h`, `linux/of.h`, `linux/platform_device.h`, `linux/mtd/map.h`, `linux/mtd/xip.h`, `physmap-ixp4xx.h`.
- Detected declarations: `function Copyright`, `function flash_write16`, `function flash_read16`, `function flash_write16`, `function ixp4xx_read16`, `function ixp4xx_copy_from`, `function ixp4xx_write16`, `function of_flash_probe_ixp4xx`.
- 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.