SMP_READ_GPIO(8)

πŸ’– SMP_READ_GPIO β€” bestie, we're reading GPIO registers πŸ’–

okay so this is smp_read_gpio(8), one of the lil gems in the smp_utils collection. it pokes at your SAS expander's sideband vibes. let's go πŸ¦‹


✨ NAME ✨

smp_read_gpio β€” invoke the READ GPIO REGISTER (ENHANCED) SMP function. that's it, that's the whole job. πŸ’…


✨ SYNOPSIS ✨

smp_read_gpio [--count=CO] [--enhanced] [--help] [--hex] [--index=IN]
[--interface=PARAMS] [--raw] [--sa=SAS_ADDR] [--type=TY] [--verbose]
[--version] SMP_DEVICE[,N]

✨ DESCRIPTION ✨

so what it does is: it sends a SAS Serial Management Protocol (SMP) READ GPIO REGISTER request β€” or the READ GPIO REGISTER ENHANCED one, your call β€” to an SMP target. πŸŽ€

who's the target? that's the SMP_DEVICE plus the SAS_ADDR. and depending on the interface, the SAS_ADDR may just be deduced from the SMP_DEVICE all by itself, no extra work. the mpt interface uses SMP_DEVICE to identify a HBA (an SMP initiator), and it needs the extra ,N to tell HBAs apart if you've got multiple hanging around. it's giving "who dis" energy πŸ™ˆ

this function is defined in SFF-8485 (see www.sffcommittee.com), alongside its partner-in-crime, the WRITE GPIO REGISTER SMP function. the rest of the SMP functions live in SAS documents over at www.t10.org. 🧚

and here's the lore: SFF-8485 defines a curious device called a "virtual SMP port" that lives inside a host bus adapter (HBA) and lets SMP manipulate the sideband signals on wide internal cables. so it can touch the wires. iconic behavior. ⚑ but to stop other initiators in a multi-initiator domain from getting at those sideband signals, the virtual SMP (target) port is not indicated in a DISCOVER response. sneaky. lowkey invisible. πŸ«₯

for notes on the READ GPIO REGISTER ENHANCED function, peep the ENHANCED FUNCTION section down below. ⬇️


✨ OPTIONS ✨

fr fr: mandatory arguments to long options are mandatory for short options too. no shortcuts, bestie. πŸ’…

  • -c, --count=CO β€” where CO is the register count. that's how many (4 byte) registers you're asking for. default is 1. πŸ“
  • -E, --enhanced β€” sends a READ GPIO REGISTER ENHANCED function request. and if you don't use it? default is to send a plain READ GPIO REGISTER function request. ✨
  • -h, --help β€” outputs the usage message then dips. bye πŸ‘‹
  • -H, --hex β€” outputs the response (less the CRC field) in hexadecimal. 🌈
  • -i, --index=IN β€” where IN is the register index. this value is origin zero and its default value is 0. if the request succeeds, then --count=CO registers starting from --index=IN of the given --type=TY should be in the response. πŸŽ€
  • -I, --interface=PARAMS β€” interface specific parameters. and yes, "interface" here means the path through the operating system to the SMP initiator. see the smp_utils man page for more info. πŸ¦‹
  • -r, --raw β€” sends the response (less the CRC field) to stdout in binary. all error messages go to stderr instead, so they don't get mixed into your raw bytes. πŸ™ˆ
  • -s, --sa=SAS_ADDR β€” specifies the SAS address of the SMP target device. typically this is an expander. this option may not be needed if the SMP_DEVICE already has the target's SAS address inside it. heads up: the SAS_ADDR is in decimal, but most SAS addresses are shown in hexadecimal. so to give a number in hexadecimal, either prefix it with '0x' or put a trailing 'h' on it. πŸ’€ (this trips everyone up, you're not alone)
  • -t, --type=TY β€” where TY is the register type. default value is 0 (GPIO_CFG). if the request succeeds, then --count=CO registers starting from --index=IN of the given --type=TY should be in the response. πŸ‘‘
  • -v, --verbose β€” increases the verbosity of the output. can be used multiple times. stack it up πŸ—£οΈ
  • -V, --version β€” prints the version string then exits. ⭐

✨ ENHANCED FUNCTION ✨

okay this section is the drama. 🍿

in the technical review of SAS-2 prior to standardization, in this t10 document: 08-212r8.pdf (page 871 or 552), there's a comment saying that the READ GPIO REGISTER and WRITE GPIO REGISTER function headers (i.e. the first 4 bytes) do not comply with all the other SMP functions in SAS-2. caught lacking. 😭

there's a suggestion that enhanced variants be introduced in the next version of the SFF-8485 document. and if that ever happened, it has not been made public. mystery. πŸ•΅οΈ in SAS-2.1, both the READ and WRITE GPIO REGISTER functions have been made obsolete, and the corresponding ENHANCED function numbers are "restricted" for SFF-8485.

🚨 so if you're reaching for --enhanced: if the --enhanced option is given then the ENHANCED function number is sent. the register type, index and count fields (1 byte each) are increased by two byte positions, leaving enough space for a compliant SAS-2 SMP header to be built. that's the whole trick. 🎩

✨ EXAMPLES ✨

see the "Examples" section in http://sg.danny.cz/sg/smp_utils.html β€” the docs live there, go look bestie 🫢


✨ CONFORMING TO ✨

the SMP READ GPIO REGISTER (ENHANCED) function is defined in SFF-8485 (see www.sffcommittee.com) together with its corresponding WRITE GPIO REGISTER (ENHANCED) SMP function. they're a package deal. πŸ’ž


✨ AUTHORS ✨

written by Douglas Gilbert. πŸ‘‘


✨ REPORTING BUGS ✨

report bugs to <dgilbert at interlog dot com>. πŸ“¬


copyright Β© 2006-2011 Douglas Gilbert

this software is distributed under a FreeBSD license. there is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. so like, it's free, but it's also free, yk? πŸ’€


✨ SEE ALSO ✨

  • smp_utils
  • smp_write_gpio(smp_utils)

and that's the whole page, bestie!! πŸ’– this was smp_utils-0.97, dated August 2011, and you just read SMP_READ_GPIO(8). go read some GPIO registers, slay, periodt βœ¨πŸŽ€πŸ¦‹