drivers/ata/sata_nv.c
Source file repositories/reference/linux-study-clean/drivers/ata/sata_nv.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/ata/sata_nv.c- Extension
.c- Size
- 68766 bytes
- Lines
- 2507
- Domain
- Driver Families
- Bucket
- drivers/ata
- Inferred role
- Driver Families: operation-table or driver-model contract
- Status
- pattern 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 an operation table; this is where Linux turns generic core objects into subsystem-specific behavior.
- Uses kernel synchronization; read lock ordering, sleepability, and interrupt context assumptions before translating.
- Touches IRQ or DMA behavior; this matters for the representative real-device path.
- 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/gfp.hlinux/pci.hlinux/blkdev.hlinux/delay.hlinux/interrupt.hlinux/device.hscsi/scsi_host.hscsi/scsi_device.hlinux/libata.htrace/events/libata.h
Detected Declarations
struct nv_adma_prdstruct nv_adma_cpbstruct nv_adma_port_privstruct nv_host_privstruct defer_queuestruct nv_swncq_port_privstruct nv_pi_privenum nv_adma_regbitsenum ncq_saw_flag_listenum nv_host_typefunction nv_adma_register_modefunction nv_adma_modefunction nv_adma_sdev_configurefunction nv_adma_check_atapi_dmafunction nv_adma_tf_readfunction nv_adma_tf_to_cpbfunction nv_adma_check_cpbfunction nv_host_intrfunction nv_adma_interruptfunction nv_adma_freezefunction nv_adma_thawfunction nv_adma_irq_clearfunction nv_adma_post_internal_cmdfunction nv_adma_port_startfunction nv_adma_port_stopfunction nv_adma_port_suspendfunction nv_adma_port_resumefunction nv_adma_setup_portfunction nv_adma_host_initfunction nv_adma_fill_aprdfunction nv_adma_fill_sgfunction for_each_sgfunction nv_adma_use_reg_modefunction nv_adma_qc_prepfunction nv_adma_qc_issuefunction nv_generic_interruptfunction nv_do_interruptfunction nv_nf2_interruptfunction nv_ck804_interruptfunction nv_scr_readfunction nv_scr_writefunction nv_hardresetfunction nv_nf2_freezefunction nv_nf2_thawfunction nv_ck804_freezefunction nv_ck804_thawfunction nv_mcp55_freezefunction nv_mcp55_thaw
Annotated Snippet
static struct pci_driver nv_pci_driver = {
.name = DRV_NAME,
.id_table = nv_pci_tbl,
.probe = nv_init_one,
#ifdef CONFIG_PM_SLEEP
.suspend = ata_pci_device_suspend,
.resume = nv_pci_device_resume,
#endif
.remove = ata_pci_remove_one,
};
static const struct scsi_host_template nv_sht = {
ATA_BMDMA_SHT(DRV_NAME),
};
static const struct scsi_host_template nv_adma_sht = {
__ATA_BASE_SHT(DRV_NAME),
.can_queue = NV_ADMA_MAX_CPBS,
.sg_tablesize = NV_ADMA_SGTBL_TOTAL_LEN,
.dma_boundary = NV_ADMA_DMA_BOUNDARY,
.sdev_configure = nv_adma_sdev_configure,
.sdev_groups = ata_ncq_sdev_groups,
.change_queue_depth = ata_scsi_change_queue_depth,
.tag_alloc_policy_rr = true,
};
static const struct scsi_host_template nv_swncq_sht = {
__ATA_BASE_SHT(DRV_NAME),
.can_queue = ATA_MAX_QUEUE - 1,
.sg_tablesize = LIBATA_MAX_PRD,
.dma_boundary = ATA_DMA_BOUNDARY,
.sdev_configure = nv_swncq_sdev_configure,
.sdev_groups = ata_ncq_sdev_groups,
.change_queue_depth = ata_scsi_change_queue_depth,
.tag_alloc_policy_rr = true,
};
/*
* NV SATA controllers have various different problems with hardreset
* protocol depending on the specific controller and device.
*
* GENERIC:
*
* bko11195 reports that link doesn't come online after hardreset on
* generic nv's and there have been several other similar reports on
* linux-ide.
*
* bko12351#c23 reports that warmplug on MCP61 doesn't work with
* softreset.
*
* NF2/3:
*
* bko3352 reports nf2/3 controllers can't determine device signature
* reliably after hardreset. The following thread reports detection
* failure on cold boot with the standard debouncing timing.
*
* http://thread.gmane.org/gmane.linux.ide/34098
*
* bko12176 reports that hardreset fails to bring up the link during
* boot on nf2.
*
* CK804:
*
* For initial probing after boot and hot plugging, hardreset mostly
* works fine on CK804 but curiously, reprobing on the initial port
* by rescanning or rmmod/insmod fails to acquire the initial D2H Reg
* FIS in somewhat undeterministic way.
*
* SWNCQ:
*
* bko12351 reports that when SWNCQ is enabled, for hotplug to work,
* hardreset should be used and hardreset can't report proper
* signature, which suggests that mcp5x is closer to nf2 as long as
* reset quirkiness is concerned.
*
* bko12703 reports that boot probing fails for intel SSD with
* hardreset. Link fails to come online. Softreset works fine.
*
* The failures are varied but the following patterns seem true for
* all flavors.
*
* - Softreset during boot always works.
*
* - Hardreset during boot sometimes fails to bring up the link on
* certain comibnations and device signature acquisition is
* unreliable.
*
* - Hardreset is often necessary after hotplug.
*
* So, preferring softreset for boot probing and error handling (as
Annotation
- Immediate include surface: `linux/kernel.h`, `linux/module.h`, `linux/gfp.h`, `linux/pci.h`, `linux/blkdev.h`, `linux/delay.h`, `linux/interrupt.h`, `linux/device.h`.
- Detected declarations: `struct nv_adma_prd`, `struct nv_adma_cpb`, `struct nv_adma_port_priv`, `struct nv_host_priv`, `struct defer_queue`, `struct nv_swncq_port_priv`, `struct nv_pi_priv`, `enum nv_adma_regbits`, `enum ncq_saw_flag_list`, `enum nv_host_type`.
- Atlas domain: Driver Families / drivers/ata.
- Implementation status: pattern implementation candidate.
- Synchronization appears in or near this file; preserve lock ordering, sleepability, and interrupt-context constraints.
- IRQ or DMA behavior appears here, which is relevant to the selected PCIe/NVMe device path.
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.