STRUCT TEST_CONFIG(9)

💅 struct test_config(9) — the Kernel API Manual glow-up ✨

okay so before we even start: this is a page from the Kernel API Manual, section 9, and it's all about struct test_config — no cap, it's the whole personality of this page 🎀

---

✨ NAME ✨

struct test_config — literally the configuration struct for the test, one for each of the different triggers 🦋

---

🌸 SYNOPSIS 🌸

here's the whole shape of it, bestie — every field, exactly as it lives:

struct test_config {
    char *name;
    bool into_buf;
    size_t buf_size;
    size_t file_offset;
    bool partial;
    bool sync_direct;
    bool send_uevent;
    u8 num_requests;
    u8 read_fw_idx;
    char *upload_name;
    struct test_batched_req *reqs;
    int test_result;
    int (*req_firmware)(const struct firmware **fw, const char *name,
struct device *device);
 };

---

👑 Members 👑

okay this is the main character section, let's go member by member 💖

• name — the name of the firmware file we're looking for 🔍
• into_buf — when into_buf is used, if this is true then request_firmware_into_buf will be used instead. iykyk 🫶
• buf_size — size of buf to allocate when into_buf is true
• file_offset — file offset to request when calling request_firmware_into_buf
• partial — the partial read opt, used when calling request_firmware_into_buf
• sync_direct — when the sync trigger is used, if this is true then request_firmware_direct will be used instead ✨
• send_uevent — whether or not to send a uevent for async requests 📨
• num_requests — number of requests to try per test case. this one is trigger specific, so it's giving "depends on the vibe" 💅
• read_fw_idx — index of the thread from which we want to read firmware results from, through the read_fw trigger 🧵
• upload_name — firmware name to be used with the upload_read sysfs node
• reqs — stores all requests information 📚
• test_result — a test may use this to collect the result from the call of the request_firmware*() calls used in their tests.

in order of priority we always keep first any setup error. if no setup errors were found, then we move on to the first error encountered while running the API.

note that for async calls this typically will be a successful result (0) unless of course you've used bogus parameters, or the system is out of memory 😭 in the async case the callback is expected to do a bit more homework to figure out what happened — unfortunately the only information passed today on error is the fact that no firmware was found, so we can only assume -ENOENT on async calls if the firmware is NULL. not me crying over missing context 🙈

• req_firmware — if sync_direct is true this is set to request_firmware_direct, otherwise request_firmware 🔥

---

🦋 Description 🦋

the errors you can expect, laid out for you bestie 🌈

API specific 💜

• 0: success for sync — for async it means request was sent ✨
• -EINVAL: invalid parameters or request
• -ENOENT: files not found 💀

System environment 🌸

• -ENOMEM: memory pressure on system
• -ENODEV: out of number of devices to test
• -EINVAL: an unexpected error has occurred 🙈

---

🌟 SEE ALSO 🌟

• Kernel file ./lib/test_firmware.c — go read it, it ate 👑

---

aaaand that's the whole page, you're officially educated 🎓✨ this was brought to you by the ./lib crew, October 2026 era, filed under struct test_config(9) — periodt 💅💖