drivers/net/fddi/defxx.c
Source file repositories/reference/linux-study-clean/drivers/net/fddi/defxx.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/fddi/defxx.c- Extension
.c- Size
- 118816 bytes
- Lines
- 3868
- Domain
- Driver Families
- Bucket
- drivers/net
- 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/bitops.hlinux/compiler.hlinux/delay.hlinux/dma-mapping.hlinux/eisa.hlinux/errno.hlinux/fddidevice.hlinux/interrupt.hlinux/ioport.hlinux/kernel.hlinux/module.hlinux/netdevice.hlinux/pci.hlinux/skbuff.hlinux/slab.hlinux/string.hlinux/tc.hasm/byteorder.hasm/io.hdefxx.h
Detected Declarations
function dfx_rcv_flushfunction dfx_writelfunction dfx_outlfunction dfx_port_write_longfunction dfx_readlfunction dfx_inlfunction dfx_port_read_longfunction dfx_get_barsfunction dfx_register_res_errfunction adaptersfunction dfx_bus_initfunction dfx_bus_uninitfunction configurationfunction dfx_openfunction dfx_adap_initfunction dfx_openfunction dfx_openfunction dfx_int_pr_halt_idfunction dfx_int_type_0_processfunction routinefunction levelfunction canonicalfunction filterfunction overridefunction groupfunction CAMfunction addressfunction dfx_hw_dma_cmd_reqfunction dfx_hw_port_ctrl_reqfunction dfx_hw_adap_resetfunction dfx_hw_adap_state_rdfunction dfx_hw_dma_uninitfunction my_skb_alignfunction dfx_adap_initfunction dfx_rcv_queue_processfunction dma_map_singlefunction dfx_xmt_donefunction dfx_rcv_flushfunction dfx_xmt_flushfunction adaptersfunction dfx_pci_registerfunction dfx_pci_unregisterfunction dfx_dev_registerfunction dfx_dev_unregisterfunction dfx_initfunction dfx_cleanupmodule init dfx_init
Annotated Snippet
static struct pci_driver dfx_pci_driver;
static struct eisa_driver dfx_eisa_driver;
static struct tc_driver dfx_tc_driver;
/*
* =======================
* = dfx_port_write_long =
* = dfx_port_read_long =
* =======================
*
* Overview:
* Routines for reading and writing values from/to adapter
*
* Returns:
* None
*
* Arguments:
* bp - pointer to board information
* offset - register offset from base I/O address
* data - for dfx_port_write_long, this is a value to write;
* for dfx_port_read_long, this is a pointer to store
* the read value
*
* Functional Description:
* These routines perform the correct operation to read or write
* the adapter register.
*
* EISA port block base addresses are based on the slot number in which the
* controller is installed. For example, if the EISA controller is installed
* in slot 4, the port block base address is 0x4000. If the controller is
* installed in slot 2, the port block base address is 0x2000, and so on.
* This port block can be used to access PDQ, ESIC, and DEFEA on-board
* registers using the register offsets defined in DEFXX.H.
*
* PCI port block base addresses are assigned by the PCI BIOS or system
* firmware. There is one 128 byte port block which can be accessed. It
* allows for I/O mapping of both PDQ and PFI registers using the register
* offsets defined in DEFXX.H.
*
* Return Codes:
* None
*
* Assumptions:
* bp->base is a valid base I/O address for this adapter.
* offset is a valid register offset for this adapter.
*
* Side Effects:
* Rather than produce macros for these functions, these routines
* are defined using "inline" to ensure that the compiler will
* generate inline code and not waste a procedure call and return.
* This provides all the benefits of macros, but with the
* advantage of strict data type checking.
*/
static inline void dfx_writel(DFX_board_t *bp, int offset, u32 data)
{
writel(data, bp->base.mem + offset);
mb();
}
static inline void dfx_outl(DFX_board_t *bp, int offset, u32 data)
{
outl(data, bp->base.port + offset);
}
static void dfx_port_write_long(DFX_board_t *bp, int offset, u32 data)
{
struct device __maybe_unused *bdev = bp->bus_dev;
if (dfx_use_mmio)
dfx_writel(bp, offset, data);
else
dfx_outl(bp, offset, data);
}
static inline void dfx_readl(DFX_board_t *bp, int offset, u32 *data)
{
mb();
*data = readl(bp->base.mem + offset);
}
static inline void dfx_inl(DFX_board_t *bp, int offset, u32 *data)
{
*data = inl(bp->base.port + offset);
}
static void dfx_port_read_long(DFX_board_t *bp, int offset, u32 *data)
{
Annotation
- Immediate include surface: `linux/bitops.h`, `linux/compiler.h`, `linux/delay.h`, `linux/dma-mapping.h`, `linux/eisa.h`, `linux/errno.h`, `linux/fddidevice.h`, `linux/interrupt.h`.
- Detected declarations: `function dfx_rcv_flush`, `function dfx_writel`, `function dfx_outl`, `function dfx_port_write_long`, `function dfx_readl`, `function dfx_inl`, `function dfx_port_read_long`, `function dfx_get_bars`, `function dfx_register_res_err`, `function adapters`.
- Atlas domain: Driver Families / drivers/net.
- 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.