i2c_of_probe_component(9)

💅 i2c_of_probe_component 💅

okay bestie, buckle up — this is a page from the Kernel API Manual and it's all about i2c_of_probe_component, a function that goes hunting for devices of a certain "type" chilling on the same i2c bus. no cap, it's actually kinda iconic once you get the vibe. ✨

---

🦋 SYNOPSIS 🦋

int i2c_of_probe_component (struct device *dev , const struct
       i2c_of_probe_cfg *cfg , void *ctx );

---

🎀 ARGUMENTS 🎀

• dev — a pointer to the struct device of whoever's calling. bestie, it's literally only used for dev_printk messages — that's it, that's the whole job. it's giving "i'm just here for the log lines."
• cfg — a pointer to the struct i2c_of_probe_cfg, which is the lil bundle holding the callbacks and other options for the prober. the main character of the operation, honestly.
• ctx — context data for the callbacks. just passing the vibes along. 🫶

---

💖 DESCRIPTION 💖

so what does this thing do? it probes for possible I2C components of the same "type" (i2c_of_probe_cfg->type) sitting on the same I2C bus, specifically the ones that have their status marked as "fail-needs-probe". like, it's rounding up the stragglers. 🧚

it assumes that across the entire device tree, the only instances of nodes with "type"-prefixed node names (not counting the address portion) are the ones that need handling for second source components. in other words — if "type" is "touchscreen", then all device nodes named "touchscreen*" are the ones that need probing. and there cannot be another "touchscreen*" node that's already enabled. no sneaky duplicates allowed, periodt.

it also assumes that for each "type" of component, only one actually exists. in other words, only one matching and existing device will be enabled. one type, one device. very monogamous of it. 💀

---

✨ CONTEXT ✨

process context only, bestie. it does non-atomic I2C transfers.

⚠️ this should only be used from a driver probe function, because the function can return -EPROBE_DEFER if the I2C adapter or other resources are unavailable. so like, don't just call it from anywhere, okay? know your lane. 🙈

---

🌈 RETURN 🌈

you get 0 on success or on a no-op, and an error code otherwise. 🔥

and a no-op? it can happen when it seems like the device tree already has components of the type to be probed already enabled. this can happen in two (2) situations:

• the device tree hadn't been updated to mark the status of the to-be-probed components as "fail-needs-probe" — like, the DT forgot to do its homework. 😭
• or this function was already run with the same parameters and succeeded in enabling a component. the latter could happen if the user had multiple types of components to probe, and one of them down the list caused a deferred probe.

and guess what — this is expected behavior. so don't come for it. it's literally fine. 👑

---

🍓 SEE ALSO 🍓

• Kernel file ./drivers/i2c/i2c-core-of-prober.c
• i2c_of_probe_simple_enable(9)
• i2c_of_probe_simple_cleanup_early(9)
• i2c_of_probe_simple_cleanup(9)

go read those next, iykyk. 💜

---

and that's the whole page, bestie! 🌸 this lil slice of kernel wisdom lives under ./drivers/i2c and it's dated October 2026 — so go forth, probe responsibly, and slay those "fail-needs-probe" nodes. mwah! 💅💖🎀