All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH 10/13] media: adv7604 prevent underflow condition when reporting colorspace
Date: Wed, 16 Oct 2024 13:24:48 +0200	[thread overview]
Message-ID: <20241016132448.15e5a4fa@foz.lan> (raw)
In-Reply-To: <e591ffa7-4214-4ec0-91f3-65c809aedce9@xs4all.nl>

Em Wed, 16 Oct 2024 12:57:53 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:

> On 16/10/2024 12:22, Mauro Carvalho Chehab wrote:
> > Currently, adv76xx_log_status() reads some date using
> > io_read() which may return negative values. The current logi
> > doesn't check such errors, causing colorspace to be reported
> > on a wrong way at adv76xx_log_status().
> > 
> > If I/O error happens there, print a different message, instead
> > of reporting bogus messages to userspace.
> > 
> > Fixes: 54450f591c99 ("[media] adv7604: driver for the Analog Devices ADV7604 video decoder")
> > Cc: stable@vger.kernel.org  
> 
> Not really a fix since this would just affect logging for debugging
> purposes. I would personally just drop the Fixes and Cc tag.

The issue is on a VIDIOC_ ioctl, so part of media API. Ok, this is
used only for debugging purposes and should, instead be implemented
via debugfs, etc, but, in summary: it is what it is: part of the V4L2
uAPI.

-

Now, the question about what should have Fixes: tag and what
shouldn't is a different matter. I've saw long discussions about
that at the kernel mailing lists. In the particular case of y2038,
I'm pretty sure I saw some of them with Fixes tag on it.

> 
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>  
> 
> Reviewed-by: Hans Verkuil <hverkuil@xs4all.nl>
> 
> Regards,
> 
> 	Hans
> 
> > ---
> >  drivers/media/i2c/adv7604.c | 26 +++++++++++++++++---------
> >  1 file changed, 17 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> > index 48230d5109f0..272945a878b3 100644
> > --- a/drivers/media/i2c/adv7604.c
> > +++ b/drivers/media/i2c/adv7604.c
> > @@ -2519,10 +2519,10 @@ static int adv76xx_log_status(struct v4l2_subdev *sd)
> >  	const struct adv76xx_chip_info *info = state->info;
> >  	struct v4l2_dv_timings timings;
> >  	struct stdi_readback stdi;
> > -	u8 reg_io_0x02 = io_read(sd, 0x02);
> > +	int ret;
> > +	u8 reg_io_0x02;
> >  	u8 edid_enabled;
> >  	u8 cable_det;
> > -
> >  	static const char * const csc_coeff_sel_rb[16] = {
> >  		"bypassed", "YPbPr601 -> RGB", "reserved", "YPbPr709 -> RGB",
> >  		"reserved", "RGB -> YPbPr601", "reserved", "RGB -> YPbPr709",
> > @@ -2621,13 +2621,21 @@ static int adv76xx_log_status(struct v4l2_subdev *sd)
> >  	v4l2_info(sd, "-----Color space-----\n");
> >  	v4l2_info(sd, "RGB quantization range ctrl: %s\n",
> >  			rgb_quantization_range_txt[state->rgb_quantization_range]);
> > -	v4l2_info(sd, "Input color space: %s\n",
> > -			input_color_space_txt[reg_io_0x02 >> 4]);
> > -	v4l2_info(sd, "Output color space: %s %s, alt-gamma %s\n",
> > -			(reg_io_0x02 & 0x02) ? "RGB" : "YCbCr",
> > -			(((reg_io_0x02 >> 2) & 0x01) ^ (reg_io_0x02 & 0x01)) ?
> > -				"(16-235)" : "(0-255)",
> > -			(reg_io_0x02 & 0x08) ? "enabled" : "disabled");
> > +
> > +	ret = io_read(sd, 0x02);
> > +	if (ret < 0) {
> > +		v4l2_info(sd, "Can't read Input/Output color space\n");
> > +	} else {
> > +		reg_io_0x02 = ret;
> > +
> > +		v4l2_info(sd, "Input color space: %s\n",
> > +				input_color_space_txt[reg_io_0x02 >> 4]);
> > +		v4l2_info(sd, "Output color space: %s %s, alt-gamma %s\n",
> > +				(reg_io_0x02 & 0x02) ? "RGB" : "YCbCr",
> > +				(((reg_io_0x02 >> 2) & 0x01) ^ (reg_io_0x02 & 0x01)) ?
> > +					"(16-235)" : "(0-255)",
> > +				(reg_io_0x02 & 0x08) ? "enabled" : "disabled");
> > +	}
> >  	v4l2_info(sd, "Color space conversion: %s\n",
> >  			csc_coeff_sel_rb[cp_read(sd, info->cp_csc) >> 4]);
> >    
> 



Thanks,
Mauro

  reply	other threads:[~2024-10-16 11:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-16 10:22 [PATCH 00/13] Media: fix several issues on drivers Mauro Carvalho Chehab
2024-10-16 10:22 ` [PATCH 01/13] media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl() Mauro Carvalho Chehab
2024-10-16 10:56   ` Hans Verkuil
2024-10-16 10:22 ` [PATCH 02/13] media: v4l2-tpg: prevent the risk of a division by zero Mauro Carvalho Chehab
2024-10-16 10:49   ` Hans Verkuil
2024-10-16 10:22 ` [PATCH 03/13] media: dvbdev: prevent the risk of out of memory access Mauro Carvalho Chehab
2024-10-16 10:22 ` [PATCH 04/13] media: dvb_frontend: don't play tricks with underflow values Mauro Carvalho Chehab
2024-10-16 10:22 ` [PATCH 05/13] media: mgb4: protect driver against spectre Mauro Carvalho Chehab
2024-10-16 11:59   ` Martin Tůma
2024-10-18  4:32     ` Mauro Carvalho Chehab
2024-10-18 11:21       ` Martin Tůma
2024-10-16 10:22 ` [PATCH 06/13] media: av7110: fix a spectre vulnerability Mauro Carvalho Chehab
2024-10-16 10:22 ` [PATCH 07/13] media: s5p-jpeg: prevent buffer overflows Mauro Carvalho Chehab
2024-10-17 10:34   ` Jacek Anaszewski
2024-10-16 10:22 ` [PATCH 08/13] media: ar0521: don't overflow when checking PLL values Mauro Carvalho Chehab
2024-10-16 12:57   ` Sakari Ailus
2024-10-16 10:22 ` [PATCH 09/13] media: cx24116: prevent overflows on SNR calculus Mauro Carvalho Chehab
2024-10-16 10:22 ` [PATCH 10/13] media: adv7604 prevent underflow condition when reporting colorspace Mauro Carvalho Chehab
2024-10-16 10:57   ` Hans Verkuil
2024-10-16 11:24     ` Mauro Carvalho Chehab [this message]
2024-10-16 11:58       ` Hans Verkuil
2024-10-18  5:01         ` Mauro Carvalho Chehab
2024-10-16 10:22 ` [PATCH 11/13] media: stb0899_algo: initialize cfr before using it Mauro Carvalho Chehab
2024-10-16 10:22 ` [PATCH 12/13] media: cec: extron-da-hd-4k-plus: don't use -1 as an error code Mauro Carvalho Chehab
2024-10-16 10:36   ` Hans Verkuil
2024-10-16 10:22 ` [PATCH 13/13] media: pulse8-cec: fix data timestamp at pulse8_setup() Mauro Carvalho Chehab
2024-10-16 10:40   ` Hans Verkuil

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=20241016132448.15e5a4fa@foz.lan \
    --to=mchehab+huawei@kernel.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=stable@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.