device_property_read_string(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ NAME πŸŽ€

device_property_read_string β€” return a string property of a device. periodt, that's the whole name vibe. πŸ’–

Welcome to the Kernel API Manual page for device_property_read_string(9) β€” manual name folded in right here, bestie, no header-line copy-paste required. 🫢

✨ SYNOPSIS ✨

the signature, exactly as it appears:

int device_property_read_string (const struct device *dev , const char
*propname , const char **val );

πŸ’… ARGUMENTS πŸ’…

  • dev β€” the Device you're getting the property of. main character device energy πŸŽ€
  • propname β€” the name of the property. iykyk ✨
  • val β€” the value is stored here. that's where the string lands πŸ’–

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so here's the tea: the way that this function reads the property propname from the device firmware description and stores the value into val if it's found is iconic. and yes, the value is checked to be a string β€” fr fr. string vibe check passed or it's not passing at all. πŸ’…

lowkey important: the value is checked to be a string, so don't come at it with a non-string property and expect good vibes.

🌈 RETURN 🌈

What you get back, bestie:

  • 0 β€” the property was found (success) πŸŽ‰
  • -EINVAL β€” given arguments are not valid πŸ™ˆ
  • -ENODATA β€” the property does not have a value πŸ’€
  • -EPROTO or -EILSEQ β€” the property type is not a string 😭
  • -ENXIO β€” no suitable firmware interface is present 🫠

πŸ”₯ SEE ALSO πŸ”₯

Kernel file ./drivers/base/property.c β€” the file in question. Also go say hi to the whole friend group, ngl it's huge:


πŸ’– xoxo, your kernel bestie β€” source/version: ./drivers/base, date: October 2026, page: device_property_read_string(9). periodt πŸŽ€

πŸ“¦ where this page comes from