drivers/crypto/cavium/cpt/cptvf_main.c

File Facts

System

Linux kernel

Corpus path

drivers/crypto/cavium/cpt/cptvf_main.c

Extension

.c

Size

21431 bytes

Lines

857

Domain

Driver Families

Bucket

drivers/crypto

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/interrupt.h
• linux/module.h
• cptvf.h

Detected Declarations

• struct cptvf_wqe
• struct cptvf_wqe_info
• function vq_work_handler
• function init_worker_threads
• function cleanup_worker_threads
• function free_pending_queues
• function for_each_pending_queue
• function alloc_pending_queues
• function for_each_pending_queue
• function init_pending_queues
• function cleanup_pending_queues
• function free_command_queues
• function hlist_for_each_entry_safe
• function alloc_command_queues
• function init_command_queues
• function cleanup_command_queues
• function cptvf_sw_cleanup
• function cptvf_sw_init
• function cptvf_free_irq_affinity
• function cptvf_write_vq_ctl
• function cptvf_write_vq_doorbell
• function cptvf_write_vq_inprog
• function cptvf_write_vq_done_numwait
• function cptvf_write_vq_done_timewait
• function cptvf_enable_swerr_interrupts
• function cptvf_enable_mbox_interrupts
• function cptvf_enable_done_interrupts
• function cptvf_clear_dovf_intr
• function cptvf_clear_irde_intr
• function cptvf_clear_nwrp_intr
• function cptvf_clear_mbox_intr
• function cptvf_clear_swerr_intr
• function cptvf_read_vf_misc_intr_status
• function cptvf_misc_intr_handler
• function cptvf_read_vq_done_count
• function cptvf_write_vq_done_ack
• function cptvf_done_intr_handler
• function cptvf_set_irq_affinity
• function cptvf_write_vq_saddr
• function cptvf_device_init
• function cptvf_probe
• function cptvf_remove
• function cptvf_shutdown

Annotated Snippet

static struct pci_driver cptvf_pci_driver = {
	.name = DRV_NAME,
	.id_table = cptvf_id_table,
	.probe = cptvf_probe,
	.remove = cptvf_remove,
	.shutdown = cptvf_shutdown,
};

module_pci_driver(cptvf_pci_driver);

MODULE_AUTHOR("George Cherian <george.cherian@cavium.com>");
MODULE_DESCRIPTION("Cavium Thunder CPT Virtual Function Driver");
MODULE_LICENSE("GPL v2");
MODULE_VERSION(DRV_VERSION);

Annotation

• Immediate include surface: `linux/interrupt.h`, `linux/module.h`, `cptvf.h`.
• Detected declarations: `struct cptvf_wqe`, `struct cptvf_wqe_info`, `function vq_work_handler`, `function init_worker_threads`, `function cleanup_worker_threads`, `function free_pending_queues`, `function for_each_pending_queue`, `function alloc_pending_queues`, `function for_each_pending_queue`, `function init_pending_queues`.
• Atlas domain: Driver Families / drivers/crypto.
• 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.