of_qcom_ice_get(9)

✨ of_qcom_ice_get(9) ✨

okay so bestie, we're in the Kernel API Manual today and the main character is of_qcom_ice_get — she's the one who goes and fetches you an ICE instance straight out of a DT node. 💅

---

🌸 NAME 🌸

of_qcom_ice_get — get an ICE instance from a DT node 🧚

---

🎀 SYNOPSIS 🎀

struct qcom_ice * of_qcom_ice_get (struct device *dev );

---

💖 ARGUMENTS 💖

• dev — device pointer for the consumer device. that's the device that wants the ICE, she's the consumer, she's the one asking nicely 🫶

---

🦋 DESCRIPTION 🦋

So here's the vibe: this function hands you an ICE instance, and there are literally two ways that can go down. 👑

Route one — it just creates one for the consumer device, but only if that device's DT node provides the 'ice' reg range and the 'ice' clock. That's the legacy DT style, iykyk. ✨

Route two — if the consumer instead provides a phandle via the 'qcom,ice' property pointing at an ICE DT, then the ICE instance is already created, so this function doesn't build anything, it just returns that one. no cap. 💅

---

🔥 RETURN 🔥

• ICE pointer on success 🎉
• NULL if there is no ICE data provided by the consumer 🙈
• ERR_PTR on error 💀

fr fr check what you got back before you start dereferencing it, okay? NULL and ERR_PTR are not the same thing and they are not a valid ICE pointer. 👀

---

🌈 SEE ALSO 🌈

Kernel file ./drivers/soc/qcom/ice.c, plus the whole squad:

• qcom_ice_get_supported_key_type(9)
• qcom_ice_derive_sw_secret(9)
• qcom_ice_generate_key(9)
• qcom_ice_prepare_key(9)
• qcom_ice_import_key(9)
• devm_of_qcom_ice_get(9)

---

and that's the whole page bestie, mwah 💋 this little gem lives down in ./drivers/soc/qcom, stamped October 2026, so go be iconic with it ⭐🍓