drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
Source file repositories/reference/linux-study-clean/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
File Facts
- System
- Linux kernel
- Corpus path
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c- Extension
.c- Size
- 314379 bytes
- Lines
- 10775
- Domain
- Driver Families
- Bucket
- drivers/net
- 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.
- 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/delay.hcxgb4.ht4_regs.ht4_values.ht4fw_api.ht4fw_version.h
Detected Declarations
struct exprom_headerstruct intr_infostruct flash_descfunction Copyrightfunction t4_wait_op_donefunction t4_set_reg_fieldfunction t4_read_indirectfunction t4_write_indirectfunction t4_hw_pci_read_cfg4function t4_report_fw_errorfunction get_mbox_rplfunction fw_asrtfunction t4_record_mboxfunction FWfunction t4_wr_mbox_meatfunction t4_edc_err_readfunction t4_memory_rw_initfunction t4_memory_update_winfunction t4_memory_rw_residualfunction t4_memory_rwfunction t4_read_pcie_cfg4function t4_get_windowfunction t4_get_util_windowfunction t4_setup_memwinfunction t4_get_regs_lenfunction t4_get_regsfunction t4_eeprom_ptovfunction t4_seeprom_wpfunction t4_get_raw_vpd_paramsfunction t4_get_vpd_paramsfunction t4_get_pfresfunction sf1_readfunction sf1_writefunction flash_wait_opfunction t4_read_flashfunction datafunction t4_get_fw_versionfunction t4_get_bs_versionfunction t4_get_tp_versionfunction numberfunction interfacefunction t4_get_scfg_versionfunction t4_get_version_infofunction t4_get_version_infofunction t4_check_fw_versionfunction fw_compatiblefunction should_install_fs_fwfunction t4_prep_fw
Annotated Snippet
struct exprom_header {
unsigned char hdr_arr[16]; /* must start with 0x55aa */
unsigned char hdr_ver[4]; /* Expansion ROM version */
} *hdr;
u32 exprom_header_buf[DIV_ROUND_UP(sizeof(struct exprom_header),
sizeof(u32))];
int ret;
ret = t4_read_flash(adap, FLASH_EXP_ROM_START,
ARRAY_SIZE(exprom_header_buf), exprom_header_buf,
0);
if (ret)
return ret;
hdr = (struct exprom_header *)exprom_header_buf;
if (hdr->hdr_arr[0] != 0x55 || hdr->hdr_arr[1] != 0xaa)
return -ENOENT;
*vers = (FW_HDR_FW_VER_MAJOR_V(hdr->hdr_ver[0]) |
FW_HDR_FW_VER_MINOR_V(hdr->hdr_ver[1]) |
FW_HDR_FW_VER_MICRO_V(hdr->hdr_ver[2]) |
FW_HDR_FW_VER_BUILD_V(hdr->hdr_ver[3]));
return 0;
}
/**
* t4_get_vpd_version - return the VPD version
* @adapter: the adapter
* @vers: where to place the version
*
* Reads the VPD via the Firmware interface (thus this can only be called
* once we're ready to issue Firmware commands). The format of the
* VPD version is adapter specific. Returns 0 on success, an error on
* failure.
*
* Note that early versions of the Firmware didn't include the ability
* to retrieve the VPD version, so we zero-out the return-value parameter
* in that case to avoid leaving it with garbage in it.
*
* Also note that the Firmware will return its cached copy of the VPD
* Revision ID, not the actual Revision ID as written in the Serial
* EEPROM. This is only an issue if a new VPD has been written and the
* Firmware/Chip haven't yet gone through a RESET sequence. So it's best
* to defer calling this routine till after a FW_RESET_CMD has been issued
* if the Host Driver will be performing a full adapter initialization.
*/
int t4_get_vpd_version(struct adapter *adapter, u32 *vers)
{
u32 vpdrev_param;
int ret;
vpdrev_param = (FW_PARAMS_MNEM_V(FW_PARAMS_MNEM_DEV) |
FW_PARAMS_PARAM_X_V(FW_PARAMS_PARAM_DEV_VPDREV));
ret = t4_query_params(adapter, adapter->mbox, adapter->pf, 0,
1, &vpdrev_param, vers);
if (ret)
*vers = 0;
return ret;
}
/**
* t4_get_scfg_version - return the Serial Configuration version
* @adapter: the adapter
* @vers: where to place the version
*
* Reads the Serial Configuration Version via the Firmware interface
* (thus this can only be called once we're ready to issue Firmware
* commands). The format of the Serial Configuration version is
* adapter specific. Returns 0 on success, an error on failure.
*
* Note that early versions of the Firmware didn't include the ability
* to retrieve the Serial Configuration version, so we zero-out the
* return-value parameter in that case to avoid leaving it with
* garbage in it.
*
* Also note that the Firmware will return its cached copy of the Serial
* Initialization Revision ID, not the actual Revision ID as written in
* the Serial EEPROM. This is only an issue if a new VPD has been written
* and the Firmware/Chip haven't yet gone through a RESET sequence. So
* it's best to defer calling this routine till after a FW_RESET_CMD has
* been issued if the Host Driver will be performing a full adapter
* initialization.
*/
int t4_get_scfg_version(struct adapter *adapter, u32 *vers)
{
u32 scfgrev_param;
int ret;
scfgrev_param = (FW_PARAMS_MNEM_V(FW_PARAMS_MNEM_DEV) |
FW_PARAMS_PARAM_X_V(FW_PARAMS_PARAM_DEV_SCFGREV));
Annotation
- Immediate include surface: `linux/delay.h`, `cxgb4.h`, `t4_regs.h`, `t4_values.h`, `t4fw_api.h`, `t4fw_version.h`.
- Detected declarations: `struct exprom_header`, `struct intr_info`, `struct flash_desc`, `function Copyright`, `function t4_wait_op_done`, `function t4_set_reg_field`, `function t4_read_indirect`, `function t4_write_indirect`, `function t4_hw_pci_read_cfg4`, `function t4_report_fw_error`.
- Atlas domain: Driver Families / drivers/net.
- Implementation status: source 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.