From: Hans Verkuil <hverkuil@xs4all.nl>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
Pawel Osciak <pawel@osciak.com>
Subject: Re: [REVIEWv2 PATCH for v3.15 2/4] videobuf2-core: fix sparse errors.
Date: Mon, 17 Mar 2014 13:32:44 +0100 [thread overview]
Message-ID: <5326EB6C.9090508@xs4all.nl> (raw)
In-Reply-To: <4203879.N4NqSdO3mH@avalon>
On 03/17/2014 01:26 PM, Laurent Pinchart wrote:
> Hi Hans,
>
> Thank you for the patch.
>
> On Monday 17 March 2014 11:58:08 Hans Verkuil wrote:
>> (Fixed typo pointed out by Pawel, but more importantly made an additional
>> change to __qbuf_dmabuf. See last paragraph in the commit log)
>
> [snip]
>
>> I made one other change: in __qbuf_dmabuf the result of the memop call
>> attach_dmabuf() is checked by IS_ERR() instead of IS_ERR_OR_NULL(). Since
>> the call_ptr_memop macro checks for IS_ERR_OR_NULL and since a NULL pointer
>> makes no sense anyway, I've changed the IS_ERR to IS_ERR_OR_NULL to remain
>> consistent, both with the call_ptr_memop macro, but also with all other
>> cases where a pointer is checked.
>
> Could you please split this to a separate patch ?
>
>> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
>> ---
>> drivers/media/v4l2-core/videobuf2-core.c | 215 +++++++++++++++++-----------
>> 1 file changed, 132 insertions(+), 83 deletions(-)
>>
>> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
>> b/drivers/media/v4l2-core/videobuf2-core.c index f9059bb..fb1ee86 100644
>> --- a/drivers/media/v4l2-core/videobuf2-core.c
>> +++ b/drivers/media/v4l2-core/videobuf2-core.c
>
> [snip]
>
>> @@ -1401,12 +1458,11 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb,
>> const struct v4l2_buffer *b) memset(&vb->v4l2_planes[plane], 0,
>> sizeof(struct v4l2_plane));
>>
>> /* Acquire each plane's memory */
>> - mem_priv = call_memop(vb, attach_dmabuf, q->alloc_ctx[plane],
>> + mem_priv = call_ptr_memop(vb, attach_dmabuf, q->alloc_ctx[plane],
>> dbuf, planes[plane].length, write);
>> - if (IS_ERR(mem_priv)) {
>> + if (IS_ERR_OR_NULL(mem_priv)) {
>> dprintk(1, "qbuf: failed to attach dmabuf\n");
>> - fail_memop(vb, attach_dmabuf);
>> - ret = PTR_ERR(mem_priv);
>> + ret = mem_priv ? PTR_ERR(mem_priv) : -EINVAL;
>
> That gets confusing. Wouldn't it be better to switch the other memop calls
> that return pointers to return an ERR_PTR() in error cases instead of NULL ?
I don't see why it is confusing as long as everyone sticks to the same scheme.
I actually prefer this way, since it is more robust as it will catch cases
where the memop unintentionally returned NULL. If I would just check for IS_ERR,
then that would be missed. Especially in a core piece of code like this I'd
like to err on the robust side.
Regards,
Hans
>
>> dma_buf_put(dbuf);
>> goto err;
>> }
>
next prev parent reply other threads:[~2014-03-17 12:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-17 10:58 [REVIEWv2 PATCH for v3.15 2/4] videobuf2-core: fix sparse errors Hans Verkuil
2014-03-17 12:26 ` Laurent Pinchart
2014-03-17 12:32 ` Hans Verkuil [this message]
2014-03-17 12:41 ` Laurent Pinchart
2014-03-17 12:47 ` Hans Verkuil
2014-03-17 13:27 ` Laurent Pinchart
2014-03-17 13:30 ` Hans Verkuil
2014-03-17 13:35 ` Laurent Pinchart
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=5326EB6C.9090508@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=pawel@osciak.com \
/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