STRUCT ST_DATA_S(9)

👑 struct st_data_s(9) — the ST core internal structure, bestie 💅

Okay so this is from the Kernel API Manual (yes, the (9) section, the cool one) and it's basically the master blueprint of the ST core internals. Think of it as the group chat roster for everything the ST driver keeps track of: states, skbs, queues, locks, and the tty it's parasocially attached to. Let's get into it 🫶

---

✨ NAME ✨

struct st_data_s — the ST core internal structure. That's it, that's the vibe. It's the struct holding all the inside info, no cap.

---

🌸 SYNOPSIS 🌸

struct st_data_s {
    unsigned long st_state;
    struct sk_buff *tx_skb;
  #define ST_TX_SENDING   1;
  #define ST_TX_WAKEUP    2;
    unsigned long tx_state;
    struct st_proto_s *list[ST_MAX_CHANNELS];
    bool is_registered[ST_MAX_CHANNELS];
    unsigned long rx_state;
    unsigned long rx_count;
    struct sk_buff *rx_skb;
    unsigned char rx_chnl;
    struct sk_buff_head txq, tx_waitq;
    spinlock_t lock;
    unsigned char   protos_registered;
    unsigned long ll_state;
    void *kim_data;
    struct tty_struct *tty;
    struct work_struct work_write_wakeup;
 };

Copy it exactly, bestie — every field, every #define, semicolons and all. Not me being dramatic, but those #defines live literally inside the struct braces and that's iconic of them. 😭

---

🎀 Members 🎀

Buckle in, we're going field by field. Every single one gets its moment. ⭐

• st_state — the different states of ST, like initializing, or registration being in progress. It's mainly used so we can return relevant err codes when protocol drivers are registering. It also tracks the recv function: during fw download only HCI events can occur, where as during other times other events CH8, CH9 can occur. So yeah, it's the main character of state tracking. 👑
• tx_skb — if for some reason the tty's write returns lesser bytes written, then this keeps the rest of the data around to be written on the next instance. It needs to be protected, hence the lock inside wakeup func. Protect the skb at all costs 🛡️
• tx_state — if the data is being written onto the TTY and the protocol driver wants to send more, we queue up data and mark that there is more data to send. Queue it, flag it, slay it. 💅
• list — the list of protocols registered. Only MAX can exist, and one protocol can register only once. Exclusive club, no double-dipping, iykyk. 🚪✨
• rx_state — states to be maintained inside st's tty receive. That's the whole description, and honestly? Respect the brevity. 🦋
• rx_count — count to be maintained inside st's tty receieve. (Their spelling, not mine — I'm keeping it exactly as written, fr fr. 💀)
• rx_skb — the skb where all data for a protocol gets accumulated. Since the tty might not call receive when a complete event packet is received, the states, count and the skb all need to be maintained. It's giving "we hold onto things here." 😤
• rx_chnl — the channel ID for which the data is getting accumalated for. (Again — their spelling, keeping it 💖)
• txq — the list of skbs which needs to be sent onto the TTY. Outbox energy. 📤
• tx_waitq — if the chip is not in AWAKE state, the skbs needs to be queued up in here. PM(WAKEUP_IND) data needs to be sent, and then the skbs from the waitq can be moved onto the txq. Needs locking too. It's like the waiting room before the main stage — literally so much drama happens here. 😴➡️🔥
• lock — the lock to protect skbs, queues, and ST states. Small field, huge responsibility. 🔒
• protos_registered — count of the protocols registered. Also, when it's 0 the chip enable gpio can be toggled, and when it changes to 1 the fw needs to be downloaded to initialize chip side ST. Zero to one, glow-up arc. 🌈
• ll_state — the various PM states the chip can be in. The states are notified to us when the chip sends relevant PM packets (SLEEP_IND, WAKE_IND). The chip is basically texting us its mood. 🧚
• kim_data — reference to the parent encapsulating structure. The parent! We stan a supportive ancestor. 🫶
• tty — tty provided by the TTY core for line disciplines. That's the whole entry, and it's doing the most with the least. 🎀

Quick aside bestie: a couple fields in the synopsis (is_registered, work_write_wakeup) don't get their own Members entry up there. That's just the page being the page — I'm not gonna invent lore, that's not my job. 🙈

---

🔥 SEE ALSO 🔥

Go read these next, in this exact order, no skipping:

• Kernel file ./include/linux/ti_wilink_st.h
• struct st_proto_s(9)
• st_int_write(9)
• st_write(9)
• struct chip_version(9)
• struct kim_data_s(9)
• struct bts_header(9)
• struct bts_action(9)
• struct hci_command(9)
• struct ti_st_plat_data(9)

That's the whole reading list. Cue the study montage 🧚✨📚

---

Alright, that's the page! Shoutout to the source path ./include/linux and the <rainbow>October 2026</rainbow> date stamp at the bottom — that's the version/source energy, we love a documented timeline. Byeee, go read your headers 💜🦋🎀