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
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
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,
Hans
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/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?
Regards,
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 is
In case a command is timed out, current flow sets the retry_flag
and does nothing.
Signed-off-by: Haim Daniel haim.dan...@gmail.com
---
drivers/media/usb/pvrusb2/pvrusb2-encoder.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git
