| 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
| ||
|
Message-ID: <20250908134735.GF26062@pendragon.ideasonboard.com>
Date: Mon, 8 Sep 2025 15:47:35 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Richard Leitner <richard.leitner@...ux.dev>
Cc: Sakari Ailus <sakari.ailus@...ux.intel.com>,
Dave Stevenson <dave.stevenson@...pberrypi.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Lee Jones <lee@...nel.org>, Pavel Machek <pavel@...nel.org>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-leds@...r.kernel.org, Hans Verkuil <hverkuil@...nel.org>
Subject: Re: [PATCH v7 06/10] media: i2c: ov9282: add hardware strobe signal
v4l2 control
On Mon, Sep 08, 2025 at 02:09:06PM +0200, Richard Leitner wrote:
> On Sun, Sep 07, 2025 at 10:08:11PM +0200, Laurent Pinchart wrote:
> > On Wed, Sep 03, 2025 at 08:58:04AM +0200, Richard Leitner wrote:
> > > On Mon, Sep 01, 2025 at 11:57:15PM +0300, Sakari Ailus wrote:
> > > > On Mon, Sep 01, 2025 at 05:05:11PM +0200, Richard Leitner wrote:
> > > > > Add V4L2_CID_FLASH_HW_STROBE_SIGNAL enable/disable support using the
> > > > > "strobe output enable" feature of the sensor.
> > > > >
> > > > > All values are based on the OV9281 datasheet v1.53 (january 2019) and
> > > > > tested using an ov9281 VisionComponents module.
> > > > >
> > > > > Signed-off-by: Richard Leitner <richard.leitner@...ux.dev>
> > > > > ---
> > > > > drivers/media/i2c/ov9282.c | 25 ++++++++++++++++++++++++-
> > > > > 1 file changed, 24 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/media/i2c/ov9282.c b/drivers/media/i2c/ov9282.c
> > > > > index f42e0d439753e74d14e3a3592029e48f49234927..ff0f69f0dc3a2d0518806b9ea65c1b520b5c55fb 100644
> > > > > --- a/drivers/media/i2c/ov9282.c
> > > > > +++ b/drivers/media/i2c/ov9282.c
> > > > > @@ -670,6 +670,23 @@ static int ov9282_set_ctrl_vflip(struct ov9282 *ov9282, int value)
> > > > > current_val);
> > > > > }
> > > > >
> > > > > +static int ov9282_set_ctrl_flash_hw_strobe_signal(struct ov9282 *ov9282, bool enable)
> > > > > +{
> > > > > + u32 current_val;
> > > > > + int ret = ov9282_read_reg(ov9282, OV9282_REG_OUTPUT_ENABLE6, 1,
> > > > > + ¤t_val);
> > > > > + if (ret)
> > > > > + return ret;
> > > >
> > > > Please don't do assignments in variable declaration if that involves error
> > > > handling.
> > >
> > > Sure. Will fix that!
> > >
> > > > > +
> > > > > + if (enable)
> > > > > + current_val |= OV9282_OUTPUT_ENABLE6_STROBE;
> > > > > + else
> > > > > + current_val &= ~OV9282_OUTPUT_ENABLE6_STROBE;
> > > > > +
> > > > > + return ov9282_write_reg(ov9282, OV9282_REG_OUTPUT_ENABLE6, 1,
> > > > > + current_val);
> >
> > It would be nice to cache the register value instead of reading it back.
> > Regmap may help (and then the driver should use the CCI helpers). This
> > can be done separately.
>
> Currently all set_ctrl calls in the ov9282 driver have this
> read/modify/write pattern. As mentioned in the cover letter I'm planning
> to migrate to cci helpers in a future series to keep the set smaller.
> But if you prefer the migration in this series I can try to rebase on
> it?
No, it's fine on top. I ask for enough yak-shaving already :-)
> > > > > +}
> > > > > +
> > > > > /**
> > > > > * ov9282_set_ctrl() - Set subdevice control
> > > > > * @ctrl: pointer to v4l2_ctrl structure
> > > > > @@ -736,6 +753,9 @@ static int ov9282_set_ctrl(struct v4l2_ctrl *ctrl)
> > > > > ret = ov9282_write_reg(ov9282, OV9282_REG_TIMING_HTS, 2,
> > > > > (ctrl->val + ov9282->cur_mode->width) >> 1);
> > > > > break;
> > > > > + case V4L2_CID_FLASH_HW_STROBE_SIGNAL:
> > > > > + ret = ov9282_set_ctrl_flash_hw_strobe_signal(ov9282, ctrl->val);
> > > > > + break;
> > > > > default:
> > > > > dev_err(ov9282->dev, "Invalid control %d", ctrl->id);
> > > > > ret = -EINVAL;
> > > > > @@ -1326,7 +1346,7 @@ static int ov9282_init_controls(struct ov9282 *ov9282)
> > > > > u32 lpfr;
> > > > > int ret;
> > > > >
> > > > > - ret = v4l2_ctrl_handler_init(ctrl_hdlr, 10);
> > > > > + ret = v4l2_ctrl_handler_init(ctrl_hdlr, 11);
> > > > > if (ret)
> > > > > return ret;
> > > > >
> > > > > @@ -1391,6 +1411,9 @@ static int ov9282_init_controls(struct ov9282 *ov9282)
> > > > > OV9282_TIMING_HTS_MAX - mode->width,
> > > > > 1, hblank_min);
> > > > >
> > > > > + /* Flash/Strobe controls */
> > > > > + v4l2_ctrl_new_std(ctrl_hdlr, &ov9282_ctrl_ops, V4L2_CID_FLASH_HW_STROBE_SIGNAL, 0, 1, 1, 0);
> > > >
> > > > This seems rather long.
> > >
> > > It's exactly 100 chars wide, so from a policy point of view it should be
> > > fine ;-). But I'm also fine with breaking it to 80 if you prefer?
> >
> > That's the usual policy in V4L2, yes. 80 columns is the preferred soft
> > limit.
>
> So I should break this line in this case? Tbh I'm often unsure on
> breaking on 80 or 100... Personally 100 is fine for me, but that's
> "your" subsystem/driver, so I guess it's your descision ;-)
Sakari is even more strict than me about line lengths :-)
It a line is just a couple of charaters about 80 columns and doesn't
have a nice split point I would avoid breaking it as I feel the result
would be less readable.
In this particular case, breaking the line would lead to
v4l2_ctrl_new_std(ctrl_hdlr, &ov9282_ctrl_ops,
V4L2_CID_FLASH_HW_STROBE_SIGNAL, 0, 1, 1, 0);
which I think is OK. It's very subjective of course.
> > > > > +
> > > > > ret = v4l2_fwnode_device_parse(ov9282->dev, &props);
> > > > > if (!ret) {
> > > > > /* Failure sets ctrl_hdlr->error, which we check afterwards anyway */
> > > > >
--
Regards,
Laurent Pinchart
Powered by blists - more mailing lists