All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: [patch 2/6] usb: gadget: uvc: cleanup __uvcg_fill_strm()
Date: Fri, 16 Jan 2015 11:38:33 +0000	[thread overview]
Message-ID: <54B8F839.4070502@samsung.com> (raw)
In-Reply-To: <20150114210107.GB23203@mwanda>

W dniu 14.01.2015 o 22:01, Dan Carpenter pisze:
> Static checkers complain about this API:
>
> 	drivers/usb/gadget/function/uvc_configfs.c:2139
> 		uvcg_streaming_class_allow_link()
> 	warn: did you really mean to pass the address of 'data'?
>
> Indeed, the code is cleaner when we just pass the pointer instead of the
> pointer to the pointer.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>

I'm sorry but this patch breaks the code.

You should look at the broader context in which the __uvcg_fill_strm()
is called: it is used as a callback from __uvcg_iter_strm_cls().
The purpose of the latter is to iterate over a hierarchy of streaming
descriptors' config items built by the user with configfs.
This function is generic, because it needs to be called twice:
the first time to calculate the actual amount of memory needed for
an array of descriptors which is to be created, and the second time
to actually fill the said array - this is the purpose of __uvcg_fill_strm().

__uvcg_iter_strm_cls() flow of control is more or less like this:
"process" the header, then for each format that follows the header
"process" the format itself and then for each frame inside
a format "process" the frame.

__uvcg_fill_stream(), which is used to "process", during its execution
uses priv2 as a pointer to a pointer, because it advances the current
position by the amount of data taken by each processed descriptor
and the advanced position should be visible outside this function,
so that the next time it is called, the current position corresponds
to the place where it was the last time rather than again at
the beginning of some block of data. In other words priv2
is an "out" parameter.

> ---
> Looks obvious enough to me, but I've only compiled this code and haven't
> tested it.
>

What I suggest is to revert this patch and then I will post another
patch which adds comments to __uvcg_iterm_strm_cls(), __uvcg_cnt_strm()
and __uvcg_fill_strm() so that their purpose and meaning of parameters
is clear.

AP

  reply	other threads:[~2015-01-16 11:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14 21:01 [patch 2/6] usb: gadget: uvc: cleanup __uvcg_fill_strm() Dan Carpenter
2015-01-16 11:38 ` Andrzej Pietrasiewicz [this message]
2015-01-16 12:12 ` Dan Carpenter
2015-01-16 12:44 ` Andrzej Pietrasiewicz
2015-01-19 16:09 ` Felipe Balbi
2015-01-19 17:46 ` Dan Carpenter

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=54B8F839.4070502@samsung.com \
    --to=andrzej.p@samsung.com \
    --cc=kernel-janitors@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.