v4l2_fwnode_endpoint_parse(9)

📦 version 7.3.1, in nixpkgs unstable

💅 v4l2_fwnode_endpoint_parse 💅

okay so bestie, this is a page from the Kernel API Manual — yes, the actual kernel docs, and yes, we're gonna make it cute. sit down, grab a strawberry 🍓, and let's get into it.

✨ NAME ✨

v4l2_fwnode_endpoint_parse — the girl whose whole job is parsing all the fwnode node properties. that's it, that's the vibe. 💖

🌸 SYNOPSIS 🌸

int v4l2_fwnode_endpoint_parse (struct fwnode_handle *fwnode , struct
v4l2_fwnode_endpoint *vep );

like literally that's the whole signature, no notes. 🎀

🦋 ARGUMENTS 🦋

  • fwnode — pointer to the endpoint's fwnode handle. and listen, it may be NULL 👀 (we'll get to what happens then, don't worry).
  • vep — pointer to the V4L2 fwnode data structure. the main character of this whole operation fr fr.

👑 DESCRIPTION 👑

so what does she actually do? she parses the V4L2 fwnode endpoint specific parameters straight out of the firmware. iconic behaviour honestly. ✨

there are two ways to use this function, and you gotta pick your lane:

  1. let it figure out the type of the bus itself — you do this by setting the vep.bus_type field to V4L2_MBUS_UNKNOWN
  2. or specify the bus type explicitly, using one of the enum v4l2_mbus_type types

option 1 — the "you decide" route: when vep.bus_type is V4L2_MBUS_UNKNOWN, the function will use the "bus-type" property to determine the type when it is available. and then — this is important, bestie — the caller is responsible for validating the contents of the vep.bus_type field after the call returns. it does not do that part for you. you are the validator. you are the moment. 💅

and now the messy part 🫣: there's this deprecated functionality that exists to support older DT bindings that don't have a "bus-type" property, for devices that support multiple types. if the "bus-type" property does not exist, the function will attempt to guess the type based on the endpoint properties available.

🚨 NEVER RELY ON GUESSING THE BUS TYPE IN NEW DRIVERS OR BINDINGS. 🚨 like, ever. it's giving deprecated. it's giving legacy. do not do it. periodt.

option 2 — the "i already know" route: it's also possible to set vep.bus_type corresponding to an actual bus. in this case the function will only attempt to parse properties related to this bus, and it will return an error if the value of the "bus-type" property corresponds to a different bus. mismatched. rejected. blocked. 💀

housekeeping rule 🧹: the caller is required to initialise all fields of vep — either with explicit values, or by zeroing them. all of them. no leaving fields in mystery states, that's not the vibe.

and the safety net 🫶: the function does not change the V4L2 fwnode endpoint state if it fails. so if it flops, nothing got messed up. we love a clean failure.

⭐ NOTE ⭐

heads up bestie: this function does not parse the "link-frequencies" property, because its size is not known in advance 😭 like it literally can't know how big it's gonna be. so if you need properties of variable size, please use v4l2_fwnode_endpoint_alloc_parse instead. she's the one for that job. 🌈

🔥 RETURN 🔥

  • 0 on success 🎉 (we love a zero)
  • a negative error code on failure, specifically:
    • -ENOMEM on memory allocation failure
    • -EINVAL on parsing failure
    • -ENXIO on mismatching bus types
    • -EPROBE_DEFER on NULL fwnode

so yeah, that NULL fwnode from earlier? that's your -EPROBE_DEFER. told you we'd get there 🙈

🧚 SEE ALSO 🧚

like, read the whole friend group, they all matter. 🫶✨

aaaand that's the page!! 💖 this one lives at ./include/media, dated October 2026, and it's filed under v4l2_fwnode_endpoint_parse(9). go parse something, bestie — safely, and never by guessing the bus type. 👑💅

📦 where this page comes from