On Mon, Jul 17, 2017 at 3:45 PM, Hans Verkuil hverkuil@xs4all.nl wrote:
On 14/07/17 11:36, Arnd Bergmann wrote:
@@ -201,8 +202,9 @@ static int cx18_g_fmt_sliced_vbi_cap(struct file *file, void *fh, * digitizer/slicer. Note, cx18_av_vbi() wipes the passed in * fmt->fmt.sliced under valid calling conditions */
if (v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced))return -EINVAL;
ret = v4l2_subdev_call(cx->sd_av, vbi, g_sliced_fmt, &fmt->fmt.sliced);if (ret)return ret;Please keep the -EINVAL here. I can't be 100% certain that returning 'ret' wouldn't break something.
I think Dan was recommending the opposite here, if I understood you both correctly: he said we should propagate the error code unless we know it's wrong, while you want to keep the current behavior to avoid introducing changes ;-)
I guess in either case, looking at the callers more carefully would be a good idea.
return 0;
return ret;}
int atomisp_flash_enable(struct atomisp_sub_device *asd, int num_frames)
This is all very hackish, though. I'm not terribly keen on this patch. It's not clear to me *why* these warnings appear in your setup.
it's possible that this only happened with 'ccache', which first preprocesses the source and the passes it with v4l2_subdev_call expanded into the compiler. This means the line looks like
if ((!(cx->sd_av) ? -ENODEV : (((cx->sd_av)->ops->vbi && (cx->sd_av)->ops->vbi->g_sliced_fmt) ? (cx->sd_av)->ops->vbi->g_sliced_fmt(cx->sd_av)), &fmt->fmt.sliced) : -ENOIOCTLCMD))
The compiler now complains about the sub-expression that it sees for cx->sd_av==NULL:
if (-ENODEV)
which it considers nonsense because it is always true and the value gets ignored.
Let me try again without ccache for now and see what warnings remain. We can find a solution for those first, and then decide how to deal with ccache.
Arnd