lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 29 Oct 2021 12:01:57 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc:     Linuxarm <linuxarm@...wei.com>, mauro.chehab@...wei.com,
        Aditya Srivastava <yashsri421@...il.com>,
        Alex Dewar <alex.dewar90@...il.com>,
        Aline Santana Cordeiro <alinesantanacordeiro@...il.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Arnd Bergmann <arnd@...db.de>,
        Baokun Li <libaokun1@...wei.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hans Verkuil <hverkuil-cisco@...all.nl>,
        Kaixu Xia <kaixuxia@...cent.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
        Tsuchiya Yuto <kitakar@...il.com>,
        Yang Li <abaci-bugfix@...ux.alibaba.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        linux-staging@...ts.linux.dev
Subject: Re: [PATCH 1/2] media: atomisp: better describe get_frame_info issues

On Fri, Oct 29, 2021 at 11:50 AM Mauro Carvalho Chehab
<mchehab+huawei@...nel.org> wrote:
>
> When atomisp is used by a normal client, it fails to get
> frame info. However, the information is confusing and misleading,
> as there are several wrappers for such function, and the error
> could be on different places.
>
> So, improve the error log in order to allow narrowing down
> where the error is actually occuring.

...

> +       switch (type) {
> +       case ATOMISP_CSS_VF_FRAME:
> +               *info = p_info.vf_output_info[0];
> +               dev_dbg(isp->dev, "getting vf frame info.\n");
> +               break;
> +       case ATOMISP_CSS_SECOND_VF_FRAME:
> +               *info = p_info.vf_output_info[1];
> +               dev_dbg(isp->dev, "getting second vf frame info.\n");
> +               break;
> +       case ATOMISP_CSS_OUTPUT_FRAME:
> +               *info = p_info.output_info[0];
> +               dev_dbg(isp->dev, "getting main frame info.\n");
> +               break;
> +       case ATOMISP_CSS_SECOND_OUTPUT_FRAME:
> +               *info = p_info.output_info[1];
> +               dev_dbg(isp->dev, "getting second main frame info.\n");
> +               break;
> +       case ATOMISP_CSS_RAW_FRAME:
> +               *info = p_info.raw_output_info;
> +               dev_dbg(isp->dev, "getting raw frame info.\n");

Can we get break; here followed by default case?

>         }
> +       dev_dbg(isp->dev, "get frame info: w=%d, h=%d, num_invalid_frames %d.\n",
> +               info->res.width, info->res.height, p_info.num_invalid_frames);
> +
> +       return 0;


-- 
With Best Regards,
Andy Shevchenko

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ