of_property...le_u64_array(9)

💅 of_property_read_variable_u64_array — Kernel API Manual ✨

okay bestie, so this one is of_property_read_variable_u64_array(9) from the Kernel API Manual, and it's literally the glow-up version of reading 64-bit ints out of a property — because it also lets you put bounds on how many array elements you're willing to accept. main character energy fr fr 🎀

---

✨ NAME ✨

of_property_read_variable_u64_array — find and read an array of 64 bit integers from a property, with bounds on the minimum and maximum array size. yes, both bounds. she's flexible but she has standards 💅

---

🌸 SYNOPSIS 🌸

int of_property_read_variable_u64_array (const struct device_node *np ,
       const char *propname , u64 *out_values , size_t sz_min , size_t sz_max
       );

---

🦋 ARGUMENTS 🦋

• np — the device node you're pulling the property value out of. like, where the tea lives, iykyk 💖
• propname — the name of the property you're searching for. your little search bar 🍓
• out_values — pointer to found values. this is where the good stuff goes 🫶
• sz_min — minimum number of array elements to read. non-negotiable, she needs at least this much ⭐
• sz_max — maximum number of array elements to read. and okay, plot twist: if it's zero there is no upper limit on the number of elements in the dts entry, but only sz_min will be read. so zero = vibes off, read the minimum and go 💀

---

🔥 DESCRIPTION 🔥

Search for a property in a device node and read 64-bit value(s) from it. that's the whole mission bestie, and she executes ✨

The out_values is modified only if a valid u64 value can be decoded. so if the data's giving nothing, your buffer stays untouched. no cap, that's genuinely such a considerate design choice 🙈

---

👑 RETURN 👑

• the number of elements read on success — slay 🌈
• -EINVAL if the property does not exist 😭
• -ENODATA if property does not have a value 💀
• -EOVERFLOW if the property data is smaller than sz_min or longer than sz_max 🚨

like, -EOVERFLOW is doing double duty here — too smol or too big, both get sent to the same exit. respect the efficiency honestly 💅

---

🧚 SEE ALSO 🧚

Kernel file ./drivers/of/property.c — and literally the whole friend group: of_property_read_bool(9), of_graph_is_present(9), of_property_count_elems_of_size(9), of_find_property_value_of_size(9), of_property_read_u8_index(9), of_property_read_u16_index(9), of_property_read_u32_index(9), of_property_read_u64_index(9), of_property_read_variable_u8_array(9), of_property_read_variable_u16_array(9), of_property_read_variable_u32_array(9), of_property_read_u64(9), of_property_read_string(9), of_property_match_string(9), of_property_read_string_helper(9), of_graph_parse_endpoint(9), of_graph_get_port_by_id(9), of_graph_get_next_port(9), of_graph_get_next_port_endpoint(9), of_graph_get_next_endpoint(9), of_graph_get_endpoint_by_regs(9), of_graph_get_remote_endpoint(9), of_graph_get_port_parent(9), of_graph_get_remote_port_parent(9), of_graph_get_remote_port(9), of_graph_get_endpoint_count(9), of_graph_get_port_count(9), of_graph_get_remote_node(9), parse_prop_cells(9), parse_suffix_prop_cells(9), struct supplier_bindings(9), of_link_property(9). that's the whole roster. go say hi 🫶💜

---

and that's the page, bestie! 💖 this icon lived in ./drivers/of, dated October 2026, and the header is of_property...le_u64_array(9) — now go read some u64 arrays responsibly ✨🎀