public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Changhuang Liang <changhuang.liang@starfivetech.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Jack Zhu <jack.zhu@starfivetech.com>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-staging@lists.linux.dev" <linux-staging@lists.linux.dev>
Subject: Re: 回复: 回复: 回复: 回复: 回复: [PATCH] staging: media: starfive: Add multiple resolution support
Date: Fri, 23 Aug 2024 17:46:43 +0300	[thread overview]
Message-ID: <20240823144643.GM26098@pendragon.ideasonboard.com> (raw)
In-Reply-To: <ZQ0PR01MB130204B8D11C2D13E3248870F28C2@ZQ0PR01MB1302.CHNPR01.prod.partner.outlook.cn>

On Mon, Aug 19, 2024 at 01:18:01PM +0000, Changhuang Liang wrote:
> > On Mon, Aug 19, 2024 at 01:37:30AM +0000, Changhuang Liang wrote:
> > > > On Mon, Aug 12, 2024 at 12:13:03PM +0000, Changhuang Liang wrote:
> > > > > > On Mon, Aug 12, 2024 at 09:43:47AM +0000, Changhuang Liang wrote:
> > > > > > > > On Fri, Aug 09, 2024 at 12:12:01PM +0000, Changhuang Liang wrote:
> > > > > > > > > > On Fri, Apr 19, 2024 at 01:19:55AM -0700, Changhuang Liang wrote:
> > > > > > > > > > > Add multiple resolution support for video "capture_raw" device.
> > > > > > > > > > > Otherwise it will capture the wrong image data if the width is not 1920.
> > > > > > > > > > >
> > > > > > > > > > > Fixes: e080f339c80a ("media: staging: media: starfive: camss: Add capture driver")
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
> > > > > > > > > > > ---
> > > > > > > > > > >  drivers/staging/media/starfive/camss/stf-capture.c | 5 ++++-
> > > > > > > > > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git
> > > > > > > > > > > a/drivers/staging/media/starfive/camss/stf-capture.c
> > > > > > > > > > > b/drivers/staging/media/starfive/camss/stf-capture.c
> > > > > > > > > > > index ec5169e7b391..9e853ff2596a 100644
> > > > > > > > > > > --- a/drivers/staging/media/starfive/camss/stf-capture.c
> > > > > > > > > > > +++ b/drivers/staging/media/starfive/camss/stf-capture.c
> > > > > > > > > > > @@ -177,9 +177,12 @@ static void stf_channel_set(struct stfcamss_video *video)  {
> > > > > > > > > > >  	struct stf_capture *cap = to_stf_capture(video);
> > > > > > > > > > >  	struct stfcamss *stfcamss = cap->video.stfcamss;
> > > > > > > > > > > +	struct v4l2_pix_format *pix;
> > > > > > > > > >
> > > > > > > > > > This variable can be const as you don't modify the format.
> > > > > > > > > >
> > > > > > > > > > >  	u32 val;
> > > > > > > > > > >
> > > > > > > > > > >  	if (cap->type == STF_CAPTURE_RAW) {
> > > > > > > > > > > +		pix = &video->active_fmt.fmt.pix;
> > > > > > > > > >
> > > > > > > > > > And it can be declared and initialized here:
> > > > > > > > > >
> > > > > > > > > > 		const struct v4l2_pix_format *pix = &video->active_fmt.fmt.pix;
> > > > > > > > > >
> > > > > > > > > > > +
> > > > > > > > > > >  		val = stf_syscon_reg_read(stfcamss, VIN_CHANNEL_SEL_EN);
> > > > > > > > > > >  		val &= ~U0_VIN_CHANNEL_SEL_MASK;
> > > > > > > > > > >  		val |= CHANNEL(0);
> > > > > > > > > > > @@ -193,7 +196,7 @@ static void stf_channel_set(struct stfcamss_video *video)
> > > > > > > > > > >  		val |= PIXEL_HEIGH_BIT_SEL(0);
> > > > > > > > > > >
> > > > > > > > > > >  		val &= ~U0_VIN_PIX_CNT_END_MASK;
> > > > > > > > > > > -		val |= PIX_CNT_END(IMAGE_MAX_WIDTH / 4 - 1);
> > > > > > > > > > > +		val |= PIX_CNT_END(pix->width / 4 - 1);
> > > > > > > > > >
> > > > > > > > > > Is there no need to consider the image height as well ?
> > > > > > > > > > How does the driver prevent buffer overflows if the
> > > > > > > > > > sensor sends more data than expected ?
> > > > > > > > >
> > > > > > > > > Our hardware will confirm a frame of data through vblank
> > > > > > > > > signal, so there is no image height configuration.
> > > > > > > >
> > > > > > > > What happens if the system expects, for instance, a 1920x1080
> > > > > > > > RAW8 image, and allocates a buffer of of 1920x1080 bytes,
> > > > > > > > but the sensor outputs more lines ? Does the camera hardware
> > > > > > > > in the SoC offer an option to prevent buffer overruns ?
> > > > > > >
> > > > > > > The hardware can confirm the image height by using the VSYNC signal.
> > > > > > >
> > > > > > > Image will transfer when VSYNC is high.
> > > > > > >
> > > > > > > VSYNC time = (width + h_blank) * height;
> > > > > >
> > > > > > What I'm trying to understand is what happens if the ISP is configured for
> > > > > > 1080 lines, but the camera sensor sends more than 1080 lines
> > > > > > (the VSYNC signal is active for more than 1080 lines). Where in
> > > > > > the driver is the hardware configure with the 1080 lines
> > > > > > limit to avoid buffer overflows ?
> > > > >
> > > > > If is "capture_raw" video device, no image height can be configured.
> > > >
> > > > In that case what happens if the camera sensor sends more lines than
> > > > expected ? Will the raw video device write past the end of the buffer ?
> > >
> > > Yes, the buffer will overflows, so we will use the software restrictions.
> > > Implement .link_validate hooks for the CSI2RX subdev and
> > > "capture_raw" video device.
> > 
> > Is there an IOMMU in the system that could help preventing buffer overflows
> > to reach system memory ?
> 
> JH7110 SoC has no IOMMU.

Thank you for the information.

Based on this, the best we can do is hoping that the video source will
never send more lines than expected. In most cases there will be no
issue, but signal glitches or other hardware glitches on the sensor side
may cause memory corruption. That sounds like a worrying hardware
vulnerability :-(

> > > > If so, is there a way to guard against that ?
> > > >
> > > > > If is "capture_yuv" video device, it will be set by stf_isp_config_crop.
> > > >
> > > > Thank you, that's the information I was looking for.

-- 
Regards,

Laurent Pinchart

      reply	other threads:[~2024-08-23 14:46 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19  8:19 [PATCH] staging: media: starfive: Add multiple resolution support Changhuang Liang
2024-08-09  8:29 ` 回复: " Changhuang Liang
2024-08-09  8:48   ` Hans Verkuil
2024-08-09  9:57 ` Laurent Pinchart
2024-08-09 12:12   ` 回复: " Changhuang Liang
2024-08-09 13:26     ` Laurent Pinchart
2024-08-12  9:43       ` 回复: " Changhuang Liang
2024-08-12 10:33         ` Laurent Pinchart
2024-08-12 12:13           ` 回复: " Changhuang Liang
2024-08-19  0:13             ` Laurent Pinchart
2024-08-19  1:37               ` 回复: " Changhuang Liang
2024-08-19  8:19                 ` Laurent Pinchart
2024-08-19 13:18                   ` 回复: " Changhuang Liang
2024-08-23 14:46                     ` Laurent Pinchart [this message]

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=20240823144643.GM26098@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=changhuang.liang@starfivetech.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=jack.zhu@starfivetech.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=mchehab@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox