fc_remote_port_add(9)

💫 fc_remote_port_add — a Kernel API Manual moment (section 9, bestie)

okay so this is fc_remote_port_add(9), and it's literally the glow-up announcement system for remote FC ports ✨

---

🎀 NAME 🎀

fc_remote_port_add — notify fc transport of the existence of a remote FC port. that's it, that's the whole vibe 💅

---

🌸 SYNOPSIS 🌸

struct fc_rport * fc_remote_port_add (struct Scsi_Host *shost , int channel , struct fc_rport_identifiers *ids );

like, you hand it a shost, a channel, and some ids, and it hands you back a struct fc_rport *. iconic behavior fr fr 👑

---

🦋 ARGUMENTS 🦋

• shost — the scsi host that the remote port is connected to. this is the main character's home base 🏠
• channel — the channel on the shost port that's connected to. yes, channel number, not a TV channel, sorry 😭
• ids — the world wide names, the fc address, and the FC4 port roles for the remote port. the whole ID card, basically 🪪✨

---

💖 DESCRIPTION 💖

so the LLDD calls this routine to notify the transport that a remote port exists. the LLDD is the one supplying the deets: the unique identifiers (wwpn, wwn) of the port, its FC address (port_id), and the FC4 roles that are active for that port. no gatekeeping, we love a provider 🫶

for ports that are FCP targets (aka scsi targets), the FC transport is out here maintaining consistent target id bindings on behalf of the LLDD. and what even is a consistent target id binding? glad you asked bestie — it's an assignment of a target id to a remote port identifier, and it persists while the scsi host is attached. the remote port can dip out, then later reappear, and its target id assignment stays exactly the same. so you can have shifts in FC addressing (if binding by wwpn or wwnn) with no apparent changes to the scsi subsystem — which is based on scsi host number and target id values. the way it just keeps everything stable 😌✨

⚠️ important though: bindings are only valid during the attachment of the scsi host. if the host detaches, then later re-attaches, target id bindings may change. so don't be surprised, okay? 🙈

this routine is responsible for returning a remote port structure. it'll search the list of remote ports it maintains internally on behalf of consistent target id mappings. if found? the remote port structure gets reused, slay. otherwise? a brand-new remote port structure gets allocated. fresh out the box 🎁

and whenever a remote port is allocated, a new fc_remote_port class device is created. every single time. no skips 💅

🚨 also: should not be called from interrupt context. like, do not do that. nope. 🙅‍♀️

---

⭐ NOTES ⭐

this routine assumes no locks are held on entry. zero locks. empty hands. walk in free 🚶‍♀️✨

---

🌈 SEE ALSO 🌈

kernel file ./drivers/scsi/scsi_transport_fc.c, plus the whole friend group:

fc_get_event_number(9), fc_host_post_fc_event(9), fc_host_post_event(9), fc_host_post_vendor_event(9), fc_find_rport_by_wwpn(9), fc_host_fpin_rcv(9), fc_eh_timed_out(9), fc_queue_work(9), fc_flush_work(9), fc_queue_devloss_work(9), fc_flush_devloss(9), fc_remove_host(9), fc_starget_delete(9), fc_rport_final_delete(9), fc_remote_port_create(9), fc_remote_port_delete(9), fc_remote_port_rolechg(9), fc_timeout_deleted_rport(9), fc_timeout_fail_rport_io(9), fc_scsi_scan_rport(9), fc_block_rport(9), fc_block_scsi_eh(9), fc_vport_setup(9), fc_vport_create(9), fc_vport_terminate(9), fc_vport_sched_delete(9), fc_bsg_job_timeout(9), fc_bsg_host_dispatch(9), fc_bsg_rport_dispatch(9), fc_bsg_hostadd(9), fc_bsg_rportadd(9), fc_bsg_remove(9)

---

and that's the page!! brought to you by ./drivers/scsi, dated October 2026 — mwah, go forth and register your remote ports responsibly 💜🎀