__lpfc_update_fcf_record(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… __lpfc_update_fcf_record β€” like, the whole page, bestie

okay so real quick, this is a page from the Kernel API Manual (yes, the kernel has a manual, she's ✨thriving✨) and honestly? it's a glow-up for one little function. let's get into it 🫢


✨ NAME ✨

__lpfc_update_fcf_record β€” Update driver fcf record

that's it, that's the whole pitch. she updates the driver's fcf record. iconic behavior, no notes. πŸ’…


🌸 SYNOPSIS 🌸

void __lpfc_update_fcf_record (struct lpfc_hba *phba , struct
lpfc_fcf_rec *fcf_rec , struct fcf_record *new_fcf_record , uint32_t
addr_mode , uint16_t vlan_id , uint32_t flag );

six arguments, returns literally nothing (void), and she's still the main character. we love a low-key queen πŸ‘‘


πŸŽ€ ARGUMENTS πŸŽ€

  • phba β€” pointer to lpfc hba data structure. your hba bestie, basically.
  • fcf_rec β€” pointer to driver fcf record. this is the one getting the makeover.
  • new_fcf_record β€” pointer to hba fcf record. the inspo pic, if you will.
  • addr_mode β€” address mode to be set to the driver fcf record.
  • vlan_id β€” vlan tag to be set to the driver fcf record.
  • flag β€” flag bits to be set to the driver fcf record.

three pointers and three settings, all going into the same driver fcf record. it's giving "group project but everyone actually showed up" 🌈


πŸ¦‹ DESCRIPTION πŸ¦‹

so what does she do? this routine updates the driver FCF record from the new HBA FCF record, together with the addr_mode, vlan_id, and other information. like, she takes the new HBA info and folds it into the driver's version. chef's kiss, honestly.

⚠️ important caveat bestie: this routine is called with the hbalock held. no cap, don't be out here calling it without the lock, that's not the vibe. πŸ”’

πŸ’œ SEE ALSO πŸ’œ

first up, the actual source file this lives in:

Kernel file ./drivers/scsi/lpfc/lpfc_hbadisc.c

and now the extended friend group β€” yes, it's a long list, she's popular, we're not skipping anyone 😭:

lpfc_check_inactive_vmid_one(9), lpfc_check_inactive_vmid(9), lpfc_check_nlp_post_devloss(9), lpfc_dev_loss_tmo_handler(9), lpfc_sli4_post_dev_loss_tmo_handler(9), lpfc_alloc_fast_evt(9), lpfc_free_fast_evt(9), lpfc_send_fastpath_evt(9), lpfc_sli4_clear_fcf_rr_bmask(9), lpfc_fab_name_match(9), lpfc_sw_name_match(9), lpfc_mac_addr_match(9), __lpfc_update_fcf_record_pri(9), lpfc_copy_fcf_record(9), lpfc_register_fcf(9), lpfc_match_fcf_conn_list(9), lpfc_check_pending_fcoe_event(9), lpfc_sli4_new_fcf_random_select(9), lpfc_sli4_fcf_rec_mbox_parse(9), lpfc_sli4_log_fcf_record_info(9), lpfc_sli4_fcf_record_match(9), lpfc_sli4_fcf_rr_next_proc(9), lpfc_sli4_fcf_pri_list_del(9), lpfc_sli4_set_fcf_flogi_fail(9), lpfc_sli4_fcf_pri_list_add(9), lpfc_mbx_cmpl_fcf_scan_read_fcf_rec(9), lpfc_mbx_cmpl_fcf_rr_read_fcf_rec(9), lpfc_mbx_cmpl_read_fcf_rec(9), lpfc_init_vfi_cmpl(9), lpfc_issue_init_vfi(9), lpfc_init_vpi_cmpl(9), lpfc_issue_init_vpi(9), lpfc_start_fdiscs(9), lpfc_create_static_vport(9), lpfc_issue_gidpt(9), lpfc_initialize_node(9), lpfc_nlp_logo_unreg(9), lpfc_unreg_hba_rpis(9), lpfc_find_vport_by_vpid(9), lpfc_fcf_inuse(9), lpfc_unregister_vfi_cmpl(9), lpfc_unregister_fcfi_cmpl(9), lpfc_unregister_fcf_prep(9), lpfc_sli4_unregister_fcf(9), lpfc_unregister_fcf_rescan(9), lpfc_unregister_fcf(9), lpfc_unregister_unused_fcf(9), lpfc_read_fcf_conn_tbl(9), lpfc_read_fcoe_param(9), lpfc_get_rec_conf23(9), lpfc_parse_fcoe_conf(9)


and that's the whole page, bestie β€” every flag, every pointer, every one of those fifty-ish cross-refs, all present and accounted for. periodt. ✨

🧚 sign-off so you know where this came from: it lives under ./drivers/scsi/lpfc and the page is dated October 2026. screenshot it, cite it, love it. πŸ’–πŸŽ€πŸŒ·
πŸ“¦ where this page comes from