Documentation/driver-api/mtdnand.rst
Source file repositories/reference/linux-study-clean/Documentation/driver-api/mtdnand.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/driver-api/mtdnand.rst- Extension
.rst- Size
- 35995 bytes
- Lines
- 1007
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: exported/initcall integration point
- Status
- integration implementation candidate
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
- 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
- No C-style include directives detected by the generator.
Detected Declarations
struct nand_oobinfofunction chipfunction board_hwcontrolfunction readyfunction board_cleanupfunction nand_scanfunction board_select_chipmodule init board_init
Annotated Snippet
module_init(board_init);
Exit function
-------------
The exit function is only necessary if the driver is compiled as a
module. It releases all resources which are held by the chip driver and
unregisters the partitions in the MTD layer.
::
#ifdef MODULE
static void __exit board_cleanup (void)
{
/* Unregister device */
WARN_ON(mtd_device_unregister(board_mtd));
/* Release resources */
nand_cleanup(mtd_to_nand(board_mtd));
/* unmap physical address */
iounmap(baseaddr);
/* Free the MTD device structure */
kfree (mtd_to_nand(board_mtd));
}
module_exit(board_cleanup);
#endif
Advanced board driver functions
===============================
This chapter describes the advanced functionality of the NAND driver.
For a list of functions which can be overridden by the board driver see
the documentation of the nand_chip structure.
Multiple chip control
---------------------
The nand driver can control chip arrays. Therefore the board driver must
provide an own select_chip function. This function must (de)select the
requested chip. The function pointer in the nand_chip structure must be
set before calling nand_scan(). The maxchip parameter of nand_scan()
defines the maximum number of chips to scan for. Make sure that the
select_chip function can handle the requested number of chips.
The nand driver concatenates the chips to one virtual chip and provides
this virtual chip to the MTD layer.
*Note: The driver can only handle linear chip arrays of equally sized
chips. There is no support for parallel arrays which extend the
buswidth.*
*GPIO based example*
::
static void board_select_chip (struct mtd_info *mtd, int chip)
{
/* Deselect all chips, set all nCE pins high */
GPIO(BOARD_NAND_NCE) |= 0xff;
if (chip >= 0)
GPIO(BOARD_NAND_NCE) &= ~ (1 << chip);
}
*Address lines based example.* Its assumed that the nCE pins are
connected to an address decoder.
Annotation
- Detected declarations: `struct nand_oobinfo`, `function chip`, `function board_hwcontrol`, `function ready`, `function board_cleanup`, `function nand_scan`, `function board_select_chip`, `module init board_init`.
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: integration 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.