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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tyo5etjwsfznuk6vzwqmcphbu4pz4lskrg3fjieojq5qc3mg6s@6jbwavmapwmf>
Date: Mon, 29 Jul 2024 11:19:22 +0200
From: Jacopo Mondi <jacopo.mondi@...asonboard.com>
To: Umang Jain <umang.jain@...asonboard.com>
Cc: Jacopo Mondi <jacopo.mondi@...asonboard.com>, 
	linux-media@...r.kernel.org, Kieran Bingham <kieran.bingham@...asonboard.com>, 
	Sakari Ailus <sakari.ailus@...ux.intel.com>, open list <linux-kernel@...r.kernel.org>, 
	Tommaso Merciai <tomm.merciai@...il.com>
Subject: Re: [PATCH] media: imx335: Fix reset-gpio handling

Hi Umang

On Mon, Jul 29, 2024 at 02:18:20PM GMT, Umang Jain wrote:
> Hi Jacopo
>
> On 29/07/24 1:42 pm, Jacopo Mondi wrote:
> > Hi Umang
> >
> > On Mon, Jul 29, 2024 at 11:35:35AM GMT, Umang Jain wrote:
> > > The imx335 reset-gpio is initialised with GPIO_OUT_LOW during probe.
> > How is this related to this change ? The value to which the GPIO is
> > initialized to in probe is the physical level.
> >
> > What matters is the gpio line active level, which should be described
> > in the sensor's datasheet. What's the active level of the reset gpio
> > line ?
>
> The XCLR active level is "Low" at the init time. It is set to "high" during
> power-on / normal operation
>

Sorry for not being clear, but the physical active level is a property
of the chip, and doesn't depend on the setting at init time made by
the driver.

According to the imx335 datasheet, the XCLR pin is said to be:
High: normal
Low: clear

Which I presume means a physical low level puts the chip in "reset"
state.

> >
> > > However, the reset-gpio logical value is set to 1 in during power-on
> > > and to 0 on power-off. This is incorrect as the reset line
> > > cannot be high during power-on and low during power-off.
> > If the line is physically high or low only depends on how the active
> > level is specified in DTS, not by the logical value provided to
> > gpiod_set_value[_cansleep]()
>
> True.
>
> AS far as I can see, the DT binding schema specifies 'reset-gpios:' -
> without the active level
>
> The active level is I suppose, intentionally left to the DT implementation ?

Not really a decision of the DT implementation, but rather a property
of the chip, so I guess the line should be described as active low in
bindings and initialized accordingly in DTS with the GPIO_ACTIVE_LOW
flag.

>
> > > Rectify the logical value of reset-gpio so that it is set to
> > > 0 during power-on and to 1 during power-off.
> > This is correct, the reset line should be set to logical 0 (inactive)
> > during power on and to logical 1 (active) when powering off. However
> > the GPIO active state should have been specified in bindings and as
> > this driver has been mainline quite some time, this change will break
> > .dtbo already used succesfully with previous kernel releases.
> >
> > Is this an issue ?
>
> Yes, if the patch is accepted, the Device-tree implementation for IMX335
> will need to be adjusted accordingly. This can be an issue definitely - but
> on the other hand, this attempts to rectify a mistake, no?
>

Indeed it does rectify a mistake, but I presume existing dtbos have the
gpio line described with GPIO_ACTIVE_HIGH, otherwise they wouldn't
work with the existing driver version. Now, you change (or rather,
fix) the driver, and existing dtbos in the wild (iow not in the
mainline code base (*)) won't work anymore. The
expectation is that we don't break working dtbos with new kernel
releases, however I'm not sure how much this is actually enforced.
I'll defer this call to maintainers.

In case it is fine to break existing dtbos, I think a patch to the
bindings to specify the gpio line active level would be required too ?

Thanks
  j

(*) as far as I can tell no dts in mainline uses imx335.

> >
> > > Signed-off-by: Umang Jain <umang.jain@...asonboard.com>
> > > ---
> > >   drivers/media/i2c/imx335.c | 6 +++---
> > >   1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/imx335.c b/drivers/media/i2c/imx335.c
> > > index cd150606a8a9..878d88b5f476 100644
> > > --- a/drivers/media/i2c/imx335.c
> > > +++ b/drivers/media/i2c/imx335.c
> > > @@ -1171,7 +1171,7 @@ static int imx335_power_on(struct device *dev)
> > >   	usleep_range(500, 550); /* Tlow */
> > >
> > >   	/* Set XCLR */
> > > -	gpiod_set_value_cansleep(imx335->reset_gpio, 1);
> > > +	gpiod_set_value_cansleep(imx335->reset_gpio, 0);
> > >
> > >   	ret = clk_prepare_enable(imx335->inclk);
> > >   	if (ret) {
> > > @@ -1184,7 +1184,7 @@ static int imx335_power_on(struct device *dev)
> > >   	return 0;
> > >
> > >   error_reset:
> > > -	gpiod_set_value_cansleep(imx335->reset_gpio, 0);
> > > +	gpiod_set_value_cansleep(imx335->reset_gpio, 1);
> > >   	regulator_bulk_disable(ARRAY_SIZE(imx335_supply_name), imx335->supplies);
> > >
> > >   	return ret;
> > > @@ -1201,7 +1201,7 @@ static int imx335_power_off(struct device *dev)
> > >   	struct v4l2_subdev *sd = dev_get_drvdata(dev);
> > >   	struct imx335 *imx335 = to_imx335(sd);
> > >
> > > -	gpiod_set_value_cansleep(imx335->reset_gpio, 0);
> > > +	gpiod_set_value_cansleep(imx335->reset_gpio, 1);
> > >   	clk_disable_unprepare(imx335->inclk);
> > >   	regulator_bulk_disable(ARRAY_SIZE(imx335_supply_name), imx335->supplies);
> > >
> > > --
> > > 2.45.0
> > >
> > >
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ