STRUCT QCOM_SMP2P(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ struct qcom_smp2p(9) ✨

okay bestie, welcome to the Kernel API Manual β€” we're looking at struct qcom_smp2p, which is literally the device driver context. that's the whole vibe. it's giving "i hold all the state so you don't have to" πŸ’…


πŸŽ€ NAME πŸŽ€

struct qcom_smp2p β€” device driver context. that's it, that's the name, she's concise and she knows it ✨


🌸 SYNOPSIS 🌸

here's the whole glow-up, bestie β€” every single field, exactly as written, no edits no cap:

struct qcom_smp2p {
    struct device *dev;
    struct smp2p_smem_item *in;
    struct smp2p_smem_item *out;
    unsigned smem_items[SMP2P_OUTBOUND + 1];
    unsigned valid_entries;
    bool ssr_ack_enabled;
    bool ssr_ack;
    bool negotiation_done;
    unsigned local_pid;
    unsigned remote_pid;
    struct regmap *ipc_regmap;
    int ipc_offset;
    int ipc_bit;
    struct mbox_client mbox_client;
    struct mbox_chan *mbox_chan;
    struct list_head inbound;
    struct list_head outbound;
 };

πŸ‘‘ Members πŸ‘‘

okay so now we go field by field, main character by main character 🫢

  • dev β€” the device driver handle. she's the anchor, the home base, the it girl of the struct 🏠✨
  • in β€” pointer to the inbound smem item. incoming messages, we love to see it πŸ’Œ
  • out β€” pointer to the outbound smem item. outgoing, obviously, she's booked and busy πŸ“€πŸ”₯
  • smem_items β€” the ids of the two smem items. just the ids, two of them, iconic 🌈
  • valid_entries β€” already scanned inbound entries. like, we've done the reading bestie, we're caught up πŸ“šπŸ’…
  • ssr_ack_enabled β€” SMP2P_FEATURE_SSR_ACK feature is supported and was enabled. yes both things, supported and enabled, she's thorough βœ…
  • ssr_ack β€” current cached state of the local ack bit. cached! so we don't have to go ask again πŸ™ˆ
  • negotiation_done β€” whether negotiating finished. the will-they-won't-they is over, it's settled 🎬
  • local_pid β€” processor id of the inbound edge. local, as in me, as in this side πŸ’β€β™€οΈ
  • remote_pid β€” processor id of the outbound edge. the other side, the pen pal, the faraway friend πŸ¦‹
  • ipc_regmap β€” regmap for the outbound ipc. the map of the outbound vibes πŸ—ΊοΈ
  • ipc_offset β€” offset within the regmap. how far in, like, positionally πŸ“
  • ipc_bit β€” bit in regmapoffset to kick to signal remote processor. you kick the bit, the remote processor gets the message, everybody slays 🦡⚑
  • mbox_client β€” mailbox client handle. her mailbox, her rules πŸ“¬
  • mbox_chan β€” apcs ipc mailbox channel handle. yes it's a whole specific channel, say it with your chest πŸ“’
  • inbound β€” list of inbound entries. the whole inbound squad, in list form 🧚
  • outbound β€” list of outbound entries. and the outbound squad too, matching set fr fr πŸ‘―β€β™€οΈ

πŸ’œ SEE ALSO πŸ’œ

go read these next, bestie, i'm obsessed with this little cluster of cross-references:

  • Kernel file ./drivers/soc/qcom/smp2p.c
  • struct smp2p_smem_item(9)
  • struct smp2p_entry(9)
  • qcom_smp2p_intr(9)

ok tiny PSA from me to you: this page is literally just a struct definition + member explanations. no dangerous flags, no deprecated anything, no undefined behaviour lurking in the shadows. you're safe to read this one in bed πŸŒ™

anyway that's the whole thing!! sourced from ./drivers/soc/qcom, dated October 2026, and once again we're signing off from struct qcom_smp2p(9). mwah πŸ’‹βœ¨πŸŽ€

πŸ“¦ where this page comes from