of_find_node_by_type(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– of_find_node_by_type β€” the Kernel API Manual, bestie edition πŸ’–

Okay so picture this: you're deep in the device tree (yes, that device tree, the of_ one, we're in the kernel API manual of_find_node_by_type(9) territory) and you need to find a node by its "device_type" property. That's literally the whole gig. Let's get into it 🫢


✨ SYNOPSIS ✨

struct device_node * of_find_node_by_type (struct device_node *from ,
const char *type );

Slay. Two args, one pointer back. Moving on πŸ’…


πŸŽ€ ARGUMENTS πŸŽ€

  • from β€” the node where your search begins 🐾. Pass NULL and it searches the entire device tree, main character energy. Heads up tho: the node you pass in does not get searched β€” only the next one does, no cap. So typically you just feed back whatever the last call returned, like a lil relay race πŸƒβ€β™€οΈ. And of_node_put will be called on from for you β€” the function handles that cleanup itself, so don't stress ✨
  • type β€” the type string you're matching against. That's it, that's the vibe check 🌸

πŸ‘‘ RETURN πŸ‘‘

You get back a node pointer with its refcount incremented πŸ”₯ β€” which means it is so your responsibility now. Call of_node_put on it when you're done, periodt. Don't leave that refcount hanging, bestie, that's giving leak 😭


πŸ¦‹ SEE ALSO πŸ¦‹

The kernel file behind all this magic lives at ./drivers/of/base.c, and here's the whole friend group πŸ’œ:

All forty-four of them, accounted for, nobody left on read πŸ’€βœ¨


Genuinely obsessed with how clean this one is. Find the node, bump the refcount, put it back. That's the whole arc 🌈

And that's a wrap, bestie πŸŽ€ this came out of ./drivers/of and it's dated October 2026, still wearing the of_find_node_by_type(9) name tag like the icon it is. Mwah πŸ’‹πŸ‘‘

πŸ“¦ where this page comes from