Hi, While I was adding a link_frequencies array field to struct v4l2_of_endpoint, I also realised that the smiapp driver was not reading the link-frequencies property from the endpoint, but the i2c device node instead. This is what the second patch addresses. The third patch does add support for reading the link-frequencies property to struct v4l2_of_endpoint. There were a few options to consider. I'm not entirely happy with the solution, but it still appears the best option to me, all being: 1. Let drivers parse the link-frequencies property. There are three samples from three different developers (myself, Laurent and Prabhakar) and two of them seemed to have issues. 2. Reading the contents of the link-frequencies property in v4l2_of_parse_endpoint() addresses the above issue. It currently has no cleanup function to release memory reserved for the variable-size link_frequencies array. 2a. Use a constant size array for link-frequencies. This limits the number of link-frequencies and wastes memory elsewhere. 2b. Use devm_*() functions to allocate the memory. v4l2_of_parse_endpoint() would require a device pointer argument in order to read variable size content from the endpoint. One major issue in this approach is that the configuration struct is typically short-lived as drivers allocate it in stack in their DT node parsing function. 2c. Add a function to release resources reserved by v4l2_of_parse_endpoint(). This is what the third patch does. Comments are welcome. -- Kind regards, Sakari -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
