pm8001_get_a...hed_sas_addr(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… pm8001_get_attached_sas_addr(9) β€” the kernel API manual, bestie edition πŸŽ€

okay so before we even start: this page lives in the Kernel API Manual, section 9, and the function's full government name is pm8001_get_attached_sas_addr. it's a whole mouthful, i know. buckle up πŸ¦‹


✨ NAME ✨

pm8001_get_attached_sas_addr β€” literally just extract/generate attached SAS address. that's the whole vibe. πŸ’…


🌸 SYNOPSIS 🌸

void pm8001_get_attached_sas_addr (struct pm8001_phy *phy , u8 *sas_addr );

no cap, that's it. returns void, so like… it doesn't hand you anything back, it just does the thing. girlboss behavior 🫢


πŸŽ€ ARGUMENTS πŸŽ€

  • phy β€” pointer to asd_phy. yes bestie, that's what it says. we don't question it, we just pass the pointer. 🧚
  • sas_addr β€” pointer to the buffer where the SAS address is gonna be written. this is the destination, the main character slot ✨

πŸ”₯ DESCRIPTION πŸ”₯

so what this function actually does: it extracts the SAS address from an IDENTIFY frame that's been received. iconic. 🌈

but here's the plot twist β€” if OOB is SATA, then a SAS address gets generated from the HA tables instead of being pulled out of a frame. so it's giving "extract or generate," depending on the situation. iykyk πŸ’€

LOCKING (read this, fr fr): the frame_rcvd_lock needs to be held while you're in here, because this parses the frame buffer. not optional, not a suggestion, not a "we'll fix it later." hold the lock or things get messy 😭 πŸ‘‘

πŸ‘‘ SEE ALSO πŸ‘‘

the kernel file where all this lives, in all its glory:

  • ./drivers/scsi/pm8001/pm8001_hwi.c

and the whole friend group of related functions β€” every single one, because we don't leave anyone out πŸ’–:


that's the whole page, bestie, you ate it up πŸ“

and yes β€” the source path is ./drivers/scsi/pm8001, the date on this lil masterpiece is October 2026, and it's filed under pm8001_get_a...hed_sas_addr(9). periodt πŸ’œπŸŒΈ

πŸ“¦ where this page comes from