From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Sakari Ailus <sakari.ailus@iki.fi>, linux-media@vger.kernel.org
Cc: g.liakhovetski@gmx.de, laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH v4 3/4] v4l: of: Parse variable length properties --- link-frequencies
Date: Fri, 10 Apr 2015 11:50:47 +0200 [thread overview]
Message-ID: <55279CF7.4040800@samsung.com> (raw)
In-Reply-To: <1428614706-8367-4-git-send-email-sakari.ailus@iki.fi>
On 09/04/15 23:25, Sakari Ailus wrote:
> The link-frequencies property is a variable length array of link frequencies
> in an endpoint. The array is needed by an increasing number of drivers, so
> it makes sense to add it to struct v4l2_of_endpoint.
>
> However, the length of the array is variable and the size of struct
> v4l2_of_endpoint is fixed since it is allocated by the caller. The options
> here are
>
> 1. to define a fixed maximum limit of link frequencies that has to be the
> global maximum of all boards. This is seen as problematic since the maximum
> could be largish, and everyone hitting the problem would need to submit a
> patch to fix it, or
>
> 2. parse the property in every driver. This doesn't sound appealing as two
> of the three implementations submitted to linux-media were wrong, and one of
> them was even merged before this was noticed, or
>
> 3. change the interface so that allocating and releasing memory according to
> the size of the array is possible. This is what the patch does.
>
> v4l2_of_alloc_parse_endpoint() is just like v4l2_of_parse_endpoint(), but it
> will allocate the memory resources needed to store struct v4l2_of_endpoint
> and the additional arrays pointed to by this struct. A corresponding release
> function v4l2_of_free_endpoint() is provided to release the memory allocated
> by v4l2_of_alloc_parse_endpoint().
>
> In addition to this, the link-frequencies property is parsed as well, and
> the result is stored to struct v4l2_of_endpoint field link_frequencies.
>
> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
It's a bit sad we need to introduce the ERR_PTR() patter, nevertheless
I can't see a better alternative now. I think in long term we need to
get rid of v4l2_of_parse_endpoint() function.
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
--
Regards,
Sylwester
next prev parent reply other threads:[~2015-04-10 9:50 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-09 21:25 [PATCH v4 0/4] Add link-frequencies to struct v4l2_of_endpoint Sakari Ailus
2015-04-09 21:25 ` [PATCH v4 1/4] v4l: of: Remove the head field in " Sakari Ailus
2015-04-10 9:47 ` Sylwester Nawrocki
2015-04-10 22:40 ` Sakari Ailus
2015-04-09 21:25 ` [PATCH v4 2/4] v4l: of: Instead of zeroing bus_type and bus field separately, unify this Sakari Ailus
2015-04-10 9:50 ` Sylwester Nawrocki
2015-04-10 22:16 ` Lad, Prabhakar
2015-04-09 21:25 ` [PATCH v4 3/4] v4l: of: Parse variable length properties --- link-frequencies Sakari Ailus
2015-04-10 9:50 ` Sylwester Nawrocki [this message]
2015-04-10 22:15 ` Lad, Prabhakar
2015-04-09 21:25 ` [PATCH v4 4/4] smiapp: Use v4l2_of_alloc_parse_endpoint() Sakari Ailus
2015-04-10 9:52 ` Sylwester Nawrocki
2015-04-10 21:54 ` Lad, Prabhakar
2015-04-10 22:10 ` Sakari Ailus
2015-04-10 22:16 ` [PATCH v4.1 " Sakari Ailus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55279CF7.4040800@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=g.liakhovetski@gmx.de \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=sakari.ailus@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox