Well this is an interesting one.
It makes an incorrect assumption about the behavior of "do { ... }
while(0)", that being issuance of a "continue" within the loop would
force execution to go back to the top of the loop. But what it really
does is force a jump to the bottom, where the false co
Sorry been asleep at the wheel here. I'll take a look.
Please realize that the code path being talked about here HAS worked -
because the encoder does tend to fail and this is how the driver
recovers.
-Mike
On Fri, 16 Jan 2015, Hans Verkuil wrote:
> On 01/16/2015 12:29 PM, Haim Daniel wr
Removing 8 years old dead code seemed right to silly me.
On Fri, 2015-01-16 at 12:37 +0100, Hans Verkuil wrote:
> On 01/16/2015 12:29 PM, Haim Daniel wrote:
> > It looks that "if (try_count < 20) continue" jumps to end of the do ...
> > while(0) loop and goes out.
>
> Ah, you are right. But that
On 01/16/2015 12:29 PM, Haim Daniel wrote:
> It looks that "if (try_count < 20) continue" jumps to end of the do ...
> while(0) loop and goes out.
Ah, you are right. But that is obviously not what was intended, so just removing
it is not a proper 'fix'.
Mike, can you take a look at this?
Regard
It looks that "if (try_count < 20) continue" jumps to end of the do ...
while(0) loop and goes out.
--hd.
On Fri, 2015-01-16 at 11:57 +0100, Hans Verkuil wrote:
> On 01/05/2015 11:38 PM, Haim Daniel wrote:
> > In case a command is timed out, current flow sets the retry_flag
> > and does nothing.
On 01/05/2015 11:38 PM, Haim Daniel wrote:
> In case a command is timed out, current flow sets the retry_flag
> and does nothing.
Really? That's not how I read the code: it retries up to 20 times before
bailing out.
Perhaps you missed the "if (try_count < 20) continue;" line?
Regards,
H
In case a command is timed out, current flow sets the retry_flag
and does nothing.
Signed-off-by: Haim Daniel
---
drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/media/usb/pvrusb2/pvrusb2-encoder.c
b/drivers
