STRUCT SHT15_DATA(9)

📦 version 7.3.1, in nixpkgs unstable

💖 NAME 💖

okay so bestie, struct sht15_data is literally the device instance specific data for the sht15 driver — it's the lil' bag of state that the driver carries around for each device. main character struct energy, no cap ✨

this is from the Kernel API Manual, section 9 (that's the kernel API section, iykyk 🧚)

🦋 SYNOPSIS 🦋

like, here's the whole shape of it, exactly as it is:

struct sht15_data {
    struct gpio_desc                *sck;
    struct gpio_desc                *data;
    struct work_struct              read_work;
    wait_queue_head_t wait_queue;
    uint16_t val_temp;
    uint16_t val_humid;
    u8 val_status;
    bool checksum_ok;
    bool checksumming;
    enum sht15_state                state;
    bool measurements_valid;
    bool status_valid;
    unsigned long                   last_measurement;
    unsigned long                   last_status;
    struct mutex                    read_lock;
    struct device                   *dev;
    struct device                   *hwmon_dev;
    struct regulator                *reg;
    struct notifier_block           nb;
    int supply_uv;
    bool supply_uv_valid;
    struct work_struct              update_supply_work;
    atomic_t interrupt_handled;
 };

👑 Members 👑

okay this is the part you actually came for, let's go member by member 💅

  • sck — the clock GPIO line 🎀
  • data — the data GPIO line 🌸
  • read_work — the bh of the interrupt handler. (bh = bottom half, in case you were wondering 🙈)
  • wait_queue — the wait queue used for getting values from the device 🦋
  • val_temp — the last temperature value read from the device 🔥
  • val_humid — the last humidity value read from the device 💧
  • val_status — the last status register value read from the device 📋
  • checksum_ok — whether the last value read from the device passed CRC validation ✅ — literally the vibe check for your data
  • checksumming — a flag used to enable the data validation with CRC 🧚
  • state — the state identifying the action the driver is doing ⭐
  • measurements_valid — are the current stored measures valid (start condition)? 🫶
  • status_valid — is the current stored status valid (start condition)? 🫶
  • last_measurement — the time of the last measure ⏰
  • last_status — the time of the last status reading ⏰
  • read_lock — a mutex to ensure only one read is in progress at a time 🔒 (no double-dipping bestie, one read at a time periodt)
  • dev — the associate device structure 🖇️
  • hwmon_dev — the device associated with the hwmon subsystem 🌡️
  • reg — the associated regulator (if specified) ⚡
  • nb — the notifier block used to handle notifications of voltage changes 📣
  • supply_uv — a local copy of supply voltage, used to allow use of the regulator consumer if available 🔌
  • supply_uv_valid — indicates that an updated value has not yet been obtained from the regulator, and so any calculations based upon it will be invalid 😭 (yes, it's a "not yet updated" flag — read it carefully, it's giving sneaky)
  • update_supply_work — the work struct that is used to update supply_uv 🛠️
  • interrupt_handled — a flag used to indicate a handler has been scheduled 🚦

✨ SEE ALSO ✨

that's the whole friend group right there, go read all of them, i'll wait 💜

fr fr that's the entire struct, nothing skipped, nothing invented — every field, every flag, every "if specified" and every "start condition" note stayed exactly where it was 🫶

and that's a wrap bestie!! 🎀 this one's from ./drivers/hwmon, dated October 2026, and it's the struct sht15_data(9) page — slay, you made it to the end 💅👑

📦 where this page comes from