[PATCH v2 0/2] media: imx335: Fix reset-gpio handling

[PATCH v2 0/2] media: imx335: Fix reset-gpio handling

[Umang Jain]

These couple of patches intends to fix the reset-gpio handling
for imx335 driver.

Patch 1/2 mentions reset-gpio polarity in DT binding example.
It is ACTIVE_LOW according to the data sheet.

Patch 2/2 fixes the logical value of reset-gpio during
power-on/power-off sequence.

--
Changes in v2:
- Also include reset-gpio polarity, mention in DT binding
- Add Fixes tag in 2/2
- Set the reset line to high during init time in 2/2

Link to v1:
https://lore.kernel.org/linux-media/tyo5etjwsfznuk6vzwqmcphbu4pz4lskrg3fjieojq5qc3mg6s@6jbwavmapwmf/T/#m189ccfa77ddceda6c3b29be3306f1a27ed0934d6

Umang Jain (2):
  dt-bindings: imx335: Mention reset-gpio polarity
  media: imx335: Fix reset-gpio handling

 .../devicetree/bindings/media/i2c/sony,imx335.yaml        | 2 ++
 drivers/media/i2c/imx335.c                                | 8 ++++----
 2 files changed, 6 insertions(+), 4 deletions(-)

-- 
2.45.0

[PATCH v2 1/2] dt-bindings: imx335: Mention reset-gpio polarity

[Umang Jain]

Mention the reset-gpio polarity in the device tree bindings.
It is GPIO_ACTIVE_LOW according to the datasheet.

Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
---
 Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
index 106c36ee966d..fb4c9d42ed1c 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
@@ -92,6 +92,8 @@ examples:
             ovdd-supply = <&camera_vddo_1v8>;
             dvdd-supply = <&camera_vddd_1v2>;
 
+            reset-gpios = <&gpio 50 GPIO_ACTIVE_LOW>;
+
             port {
                 imx335: endpoint {
                     remote-endpoint = <&cam>;
-- 
2.45.0

Re: [PATCH v2 1/2] dt-bindings: imx335: Mention reset-gpio polarity

[Laurent Pinchart]

Hi Umang,

Thank you for the patch.

On Mon, Jul 29, 2024 at 04:34:36PM +0530, Umang Jain wrote:
> Mention the reset-gpio polarity in the device tree bindings.
> It is GPIO_ACTIVE_LOW according to the datasheet.
> 
> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> ---
>  Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
> index 106c36ee966d..fb4c9d42ed1c 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
> @@ -92,6 +92,8 @@ examples:
>              ovdd-supply = <&camera_vddo_1v8>;
>              dvdd-supply = <&camera_vddd_1v2>;
>  
> +            reset-gpios = <&gpio 50 GPIO_ACTIVE_LOW>;
> +

I think it's good to include this in the example, but it doesn't match
the commit message. I was expecting to see a change to the binding
rules, not to the example.

>              port {
>                  imx335: endpoint {
>                      remote-endpoint = <&cam>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/2] dt-bindings: imx335: Mention reset-gpio polarity

[Umang Jain]

Hi Laurent,

On 29/07/24 4:40 pm, Laurent Pinchart wrote:
> Hi Umang,
>
> Thank you for the patch.
>
> On Mon, Jul 29, 2024 at 04:34:36PM +0530, Umang Jain wrote:
>> Mention the reset-gpio polarity in the device tree bindings.
>> It is GPIO_ACTIVE_LOW according to the datasheet.
>>
>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
>> ---
>>   Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
>> index 106c36ee966d..fb4c9d42ed1c 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
>> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
>> @@ -92,6 +92,8 @@ examples:
>>               ovdd-supply = <&camera_vddo_1v8>;
>>               dvdd-supply = <&camera_vddd_1v2>;
>>   
>> +            reset-gpios = <&gpio 50 GPIO_ACTIVE_LOW>;
>> +
> I think it's good to include this in the example, but it doesn't match
> the commit message. I was expecting to see a change to the binding
> rules, not to the example.

Currently the binding already states reset-gpio as

```
   reset-gpios:
     description: Reference to the GPIO connected to the XCLR pin, if any.
     maxItems: 1
```

Pardon my limited knowledge here, do you mean something like :

```
   reset-gpios:
     description: Reference to the GPIO connected to the XCLR pin 
(active LOW), if any.
     maxItems: 1
```

or something else?
>
>>               port {
>>                   imx335: endpoint {
>>                       remote-endpoint = <&cam>;

Re: [PATCH v2 1/2] dt-bindings: imx335: Mention reset-gpio polarity

[Laurent Pinchart]

Hi Umang,

On Mon, Jul 29, 2024 at 05:36:11PM +0530, Umang Jain wrote:
> On 29/07/24 4:40 pm, Laurent Pinchart wrote:
> > On Mon, Jul 29, 2024 at 04:34:36PM +0530, Umang Jain wrote:
> >> Mention the reset-gpio polarity in the device tree bindings.
> >> It is GPIO_ACTIVE_LOW according to the datasheet.
> >>
> >> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> >> ---
> >>   Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
> >> index 106c36ee966d..fb4c9d42ed1c 100644
> >> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
> >> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx335.yaml
> >> @@ -92,6 +92,8 @@ examples:
> >>               ovdd-supply = <&camera_vddo_1v8>;
> >>               dvdd-supply = <&camera_vddd_1v2>;
> >>   
> >> +            reset-gpios = <&gpio 50 GPIO_ACTIVE_LOW>;
> >> +
> > I think it's good to include this in the example, but it doesn't match
> > the commit message. I was expecting to see a change to the binding
> > rules, not to the example.
> 
> Currently the binding already states reset-gpio as
> 
> ```
>    reset-gpios:
>      description: Reference to the GPIO connected to the XCLR pin, if any.
>      maxItems: 1
> ```
> 
> Pardon my limited knowledge here, do you mean something like :
> 
> ```
>    reset-gpios:
>      description: Reference to the GPIO connected to the XCLR pin 
> (active LOW), if any.
>      maxItems: 1
> ```
> 
> or something else?

No, I meant updating the commit message to something like:

dt-bindings: media: imx335: Add reset-gpios to the DT example

It's easy to get the polarity of GPIOs in the device tree wrong, as
shown by a recently fixed bug in the imx335 driver. To lower the chance
of future mistakes, especially in new bindings that would take the
imx335 binding as a starting point, add the reset-gpios property to the
DT example. This showcases the correct polarity of the XCLR signal for
Sony sensors in the most common case of the signal not being inverted on
the board.

> >>               port {
> >>                   imx335: endpoint {
> >>                       remote-endpoint = <&cam>;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/2] dt-bindings: imx335: Mention reset-gpio polarity

[kernel test robot]

Hi,

Thanks for your patch.

FYI: kernel test robot notices the stable kernel rule is not satisfied.

The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1

Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree.
Subject: [PATCH v2 1/2] dt-bindings: imx335: Mention reset-gpio polarity
Link: https://lore.kernel.org/stable/20240729110437.199428-2-umang.jain%40ideasonboard.com

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v2 1/2] dt-bindings: imx335: Mention reset-gpio polarity

[Krzysztof Kozlowski]

On 29/07/2024 13:04, Umang Jain wrote:
> Mention the reset-gpio polarity in the device tree bindings.
> It is GPIO_ACTIVE_LOW according to the datasheet.
> 
> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> ---

IdeasOnBoard folks are seasoned developers, although I noticed from time
to time you do not cc all necessary addresses. I wonder why? Something
is missing in internal guideline?

That's not the first case, but pasting same form letter is a bit
annoying, especially considering that *tools tell you to do correct
stuff* and you do not need *person to tell you that*.


<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.

Please kindly resend and include all necessary To/Cc entries.
</form letter>

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: imx335: Mention reset-gpio polarity

[Laurent Pinchart]

On Mon, Jul 29, 2024 at 04:08:18PM +0200, Krzysztof Kozlowski wrote:
> On 29/07/2024 13:04, Umang Jain wrote:
> > Mention the reset-gpio polarity in the device tree bindings.
> > It is GPIO_ACTIVE_LOW according to the datasheet.
> > 
> > Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> > ---
> 
> IdeasOnBoard folks are seasoned developers, although I noticed from time
> to time you do not cc all necessary addresses. I wonder why? Something
> is missing in internal guideline?

We have no guidelines that prevent CC'ing anyone, so it's down to
case-by-case mistakes I suppose. get_maintainer.pl should have turned up
the DT list and the DT maintainers on this patch. Umang (and everybody
else), please make sure to not strip that in the future.

> That's not the first case, but pasting same form letter is a bit
> annoying, especially considering that *tools tell you to do correct
> stuff* and you do not need *person to tell you that*.
> 
> 
> <form letter>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
> 
> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> people, so fix your workflow. Tools might also fail if you work on some
> ancient tree (don't, instead use mainline) or work on fork of kernel
> (don't, instead use mainline). Just use b4 and everything should be
> fine, although remember about `b4 prep --auto-to-cc` if you added new
> patches to the patchset.
> 
> You missed at least devicetree list (maybe more), so this won't be
> tested by automated tooling. Performing review on untested code might be
> a waste of time.
> 
> Please kindly resend and include all necessary To/Cc entries.
> </form letter>

-- 
Regards,

Laurent Pinchart

[PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Umang Jain]

Rectify the logical value of reset-gpio so that it is set to
0 (disabled) during power-on and to 1 (enabled) during power-off.

Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
time to make sure it starts off in reset.

Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
---
 drivers/media/i2c/imx335.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/i2c/imx335.c b/drivers/media/i2c/imx335.c
index cd150606a8a9..7241fc87ef84 100644
--- a/drivers/media/i2c/imx335.c
+++ b/drivers/media/i2c/imx335.c
@@ -1057,7 +1057,7 @@ static int imx335_parse_hw_config(struct imx335 *imx335)
 
 	/* Request optional reset pin */
 	imx335->reset_gpio = devm_gpiod_get_optional(imx335->dev, "reset",
-						     GPIOD_OUT_LOW);
+						     GPIOD_OUT_HIGH);
 	if (IS_ERR(imx335->reset_gpio)) {
 		dev_err(imx335->dev, "failed to get reset gpio %ld\n",
 			PTR_ERR(imx335->reset_gpio));
@@ -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

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Laurent Pinchart]

Hi Umang,

Thank you for the patch.

On Mon, Jul 29, 2024 at 04:34:37PM +0530, Umang Jain wrote:
> Rectify the logical value of reset-gpio so that it is set to
> 0 (disabled) during power-on and to 1 (enabled) during power-off.
> 
> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
> time to make sure it starts off in reset.
> 
> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> ---
>  drivers/media/i2c/imx335.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/i2c/imx335.c b/drivers/media/i2c/imx335.c
> index cd150606a8a9..7241fc87ef84 100644
> --- a/drivers/media/i2c/imx335.c
> +++ b/drivers/media/i2c/imx335.c
> @@ -1057,7 +1057,7 @@ static int imx335_parse_hw_config(struct imx335 *imx335)
>  
>  	/* Request optional reset pin */
>  	imx335->reset_gpio = devm_gpiod_get_optional(imx335->dev, "reset",
> -						     GPIOD_OUT_LOW);
> +						     GPIOD_OUT_HIGH);
>  	if (IS_ERR(imx335->reset_gpio)) {
>  		dev_err(imx335->dev, "failed to get reset gpio %ld\n",
>  			PTR_ERR(imx335->reset_gpio));
> @@ -1171,7 +1171,7 @@ static int imx335_power_on(struct device *dev)
>  	usleep_range(500, 550); /* Tlow */
>  
>  	/* Set XCLR */

I would replace this with

	/* Deassert the reset (XCLR) signal. */

or something similar.

Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>

> -	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);
>  

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Sakari Ailus]

On Mon, Jul 29, 2024 at 02:13:15PM +0300, Laurent Pinchart wrote:
> > @@ -1171,7 +1171,7 @@ static int imx335_power_on(struct device *dev)
> >  	usleep_range(500, 550); /* Tlow */
> >  
> >  	/* Set XCLR */
> 
> I would replace this with
> 
> 	/* Deassert the reset (XCLR) signal. */
> 
> or something similar.

On my behalf the comment could be removed as well, it's not informative.

-- 
Sakari Ailus

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Krzysztof Kozlowski]

On 29/07/2024 13:04, Umang Jain wrote:
> Rectify the logical value of reset-gpio so that it is set to
> 0 (disabled) during power-on and to 1 (enabled) during power-off.
> 
> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
> time to make sure it starts off in reset.
> 
> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> ---
>  drivers/media/i2c/imx335.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 

This will break all the users, so no. At least not without mentioning
ABI break and some sort of investigating how customers or users are
affected.

Best regards,
Krzysztof

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Sakari Ailus]

Hi Krzysztof,

On Mon, Jul 29, 2024 at 04:09:39PM +0200, Krzysztof Kozlowski wrote:
> On 29/07/2024 13:04, Umang Jain wrote:
> > Rectify the logical value of reset-gpio so that it is set to
> > 0 (disabled) during power-on and to 1 (enabled) during power-off.
> > 
> > Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
> > time to make sure it starts off in reset.
> > 
> > Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
> > Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> > ---
> >  drivers/media/i2c/imx335.c | 8 ++++----
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> 
> This will break all the users, so no. At least not without mentioning
> ABI break and some sort of investigating how customers or users are
> affected.

I know the original authors aren't using the driver anymore and it took
quite a bit of time until others started to contribute to it so I suspect
the driver hasn't been in use for that long. There are no instances of the
device in the in-kernel DTS either.

Any DTS author should have also noticed the issue but of course there's a
risk someone could have just changed the polarity and not bothered to chech
what it was supposed to be.

I agree the commit message should be more vocal about the effects on
existing DTS.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Krzysztof Kozlowski]

On 30/07/2024 10:24, Sakari Ailus wrote:
> Hi Krzysztof,
> 
> On Mon, Jul 29, 2024 at 04:09:39PM +0200, Krzysztof Kozlowski wrote:
>> On 29/07/2024 13:04, Umang Jain wrote:
>>> Rectify the logical value of reset-gpio so that it is set to
>>> 0 (disabled) during power-on and to 1 (enabled) during power-off.
>>>
>>> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
>>> time to make sure it starts off in reset.
>>>
>>> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
>>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
>>> ---
>>>  drivers/media/i2c/imx335.c | 8 ++++----
>>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>>
>>
>> This will break all the users, so no. At least not without mentioning
>> ABI break and some sort of investigating how customers or users are
>> affected.
> 
> I know the original authors aren't using the driver anymore and it took
> quite a bit of time until others started to contribute to it so I suspect
> the driver hasn't been in use for that long. There are no instances of the
> device in the in-kernel DTS either.
> 
> Any DTS author should have also noticed the issue but of course there's a
> risk someone could have just changed the polarity and not bothered to chech
> what it was supposed to be.
> 
> I agree the commit message should be more vocal about the effects on
> existing DTS.

I can imagine that all users (out of tree, in this case) inverted
polarity in DTS based on what's implemented. You could go with some
trivial hack, like I did for one of codecs - see 738455858a2d ("ASoC:
codecs: wsa881x: Use proper shutdown GPIO polarity"), but I remember
Mark Brown rejected similar commit for newer drivers.

Best regards,
Krzysztof

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Laurent Pinchart]

On Tue, Jul 30, 2024 at 10:42:01AM +0200, Krzysztof Kozlowski wrote:
> On 30/07/2024 10:24, Sakari Ailus wrote:
> > Hi Krzysztof,
> > 
> > On Mon, Jul 29, 2024 at 04:09:39PM +0200, Krzysztof Kozlowski wrote:
> >> On 29/07/2024 13:04, Umang Jain wrote:
> >>> Rectify the logical value of reset-gpio so that it is set to
> >>> 0 (disabled) during power-on and to 1 (enabled) during power-off.
> >>>
> >>> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
> >>> time to make sure it starts off in reset.
> >>>
> >>> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
> >>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> >>> ---
> >>>  drivers/media/i2c/imx335.c | 8 ++++----
> >>>  1 file changed, 4 insertions(+), 4 deletions(-)
> >>>
> >>
> >> This will break all the users, so no. At least not without mentioning
> >> ABI break and some sort of investigating how customers or users are
> >> affected.
> > 
> > I know the original authors aren't using the driver anymore and it took
> > quite a bit of time until others started to contribute to it so I suspect
> > the driver hasn't been in use for that long. There are no instances of the
> > device in the in-kernel DTS either.
> > 
> > Any DTS author should have also noticed the issue but of course there's a
> > risk someone could have just changed the polarity and not bothered to chech
> > what it was supposed to be.
> > 
> > I agree the commit message should be more vocal about the effects on
> > existing DTS.
> 
> I can imagine that all users (out of tree, in this case) inverted
> polarity in DTS based on what's implemented. You could go with some
> trivial hack, like I did for one of codecs - see 738455858a2d ("ASoC:
> codecs: wsa881x: Use proper shutdown GPIO polarity"), but I remember
> Mark Brown rejected similar commit for newer drivers.

I don't think there's any out-of-tree user, because when we started
using the recently driver, it required lots of fixes to even work at
all. I'll let Kieran and Umang comment on that, I haven't follow the
development in details.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Umang Jain]

Hi all,

On 30/07/24 2:40 pm, Laurent Pinchart wrote:
> On Tue, Jul 30, 2024 at 10:42:01AM +0200, Krzysztof Kozlowski wrote:
>> On 30/07/2024 10:24, Sakari Ailus wrote:
>>> Hi Krzysztof,
>>>
>>> On Mon, Jul 29, 2024 at 04:09:39PM +0200, Krzysztof Kozlowski wrote:
>>>> On 29/07/2024 13:04, Umang Jain wrote:
>>>>> Rectify the logical value of reset-gpio so that it is set to
>>>>> 0 (disabled) during power-on and to 1 (enabled) during power-off.
>>>>>
>>>>> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
>>>>> time to make sure it starts off in reset.
>>>>>
>>>>> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
>>>>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
>>>>> ---
>>>>>   drivers/media/i2c/imx335.c | 8 ++++----
>>>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>>>
>>>> This will break all the users, so no. At least not without mentioning
>>>> ABI break and some sort of investigating how customers or users are
>>>> affected.
>>> I know the original authors aren't using the driver anymore and it took
>>> quite a bit of time until others started to contribute to it so I suspect
>>> the driver hasn't been in use for that long. There are no instances of the
>>> device in the in-kernel DTS either.
>>>
>>> Any DTS author should have also noticed the issue but of course there's a
>>> risk someone could have just changed the polarity and not bothered to chech
>>> what it was supposed to be.
>>>
>>> I agree the commit message should be more vocal about the effects on
>>> existing DTS.
>> I can imagine that all users (out of tree, in this case) inverted
>> polarity in DTS based on what's implemented. You could go with some
>> trivial hack, like I did for one of codecs - see 738455858a2d ("ASoC:
>> codecs: wsa881x: Use proper shutdown GPIO polarity"), but I remember
>> Mark Brown rejected similar commit for newer drivers.
> I don't think there's any out-of-tree user, because when we started
> using the recently driver, it required lots of fixes to even work at
> all. I'll let Kieran and Umang comment on that, I haven't follow the
> development in details.

indeed, initially we had to put up fixes like :

14a60786d72e ("media: imx335: Set reserved register to default value")
81495a59baeba ("media: imx335: Fix active area height discrepency")

to make the sensor work properly on our platforms. Only after that we 
had a base to support more capabilities on the sensor (multiple lanes 
support, flips, TPG etc.)

>

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Kieran Bingham]

Quoting Umang Jain (2024-07-31 06:41:35)
> Hi all,
> 
> On 30/07/24 2:40 pm, Laurent Pinchart wrote:
> > On Tue, Jul 30, 2024 at 10:42:01AM +0200, Krzysztof Kozlowski wrote:
> >> On 30/07/2024 10:24, Sakari Ailus wrote:
> >>> Hi Krzysztof,
> >>>
> >>> On Mon, Jul 29, 2024 at 04:09:39PM +0200, Krzysztof Kozlowski wrote:
> >>>> On 29/07/2024 13:04, Umang Jain wrote:
> >>>>> Rectify the logical value of reset-gpio so that it is set to
> >>>>> 0 (disabled) during power-on and to 1 (enabled) during power-off.
> >>>>>
> >>>>> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
> >>>>> time to make sure it starts off in reset.
> >>>>>
> >>>>> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
> >>>>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> >>>>> ---
> >>>>>   drivers/media/i2c/imx335.c | 8 ++++----
> >>>>>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>>>>
> >>>> This will break all the users, so no. At least not without mentioning
> >>>> ABI break and some sort of investigating how customers or users are
> >>>> affected.
> >>> I know the original authors aren't using the driver anymore and it took
> >>> quite a bit of time until others started to contribute to it so I suspect
> >>> the driver hasn't been in use for that long. There are no instances of the
> >>> device in the in-kernel DTS either.
> >>>
> >>> Any DTS author should have also noticed the issue but of course there's a
> >>> risk someone could have just changed the polarity and not bothered to chech
> >>> what it was supposed to be.
> >>>
> >>> I agree the commit message should be more vocal about the effects on
> >>> existing DTS.
> >> I can imagine that all users (out of tree, in this case) inverted
> >> polarity in DTS based on what's implemented. You could go with some
> >> trivial hack, like I did for one of codecs - see 738455858a2d ("ASoC:
> >> codecs: wsa881x: Use proper shutdown GPIO polarity"), but I remember
> >> Mark Brown rejected similar commit for newer drivers.
> > I don't think there's any out-of-tree user, because when we started
> > using the recently driver, it required lots of fixes to even work at
> > all. I'll let Kieran and Umang comment on that, I haven't follow the
> > development in details.
> 
> indeed, initially we had to put up fixes like :
> 
> 14a60786d72e ("media: imx335: Set reserved register to default value")
> 81495a59baeba ("media: imx335: Fix active area height discrepency")
> 
> to make the sensor work properly on our platforms. Only after that we 
> had a base to support more capabilities on the sensor (multiple lanes 
> support, flips, TPG etc.)

I would also add that we had to provide control for the regulators to be
able to power the device as well in fea91ee73b7c ("media: i2c: imx335:
Enable regulator supplies").

Given the driver was posted from Intel, I would have anticipated perhaps
the driver was in fact only actually tested by Intel on ACPI platforms -
yet with no ACPI table registered in the driver - even that could likely
be considered broken.

Based on that I have a high confidence that there are no current users
of this driver (except us).

Umang, I see we need an updated patch with commit message to cover this,
please consider the above to add in there too.
--
Kieran

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Krzysztof Kozlowski]

On 31/07/2024 11:02, Kieran Bingham wrote:
> Quoting Umang Jain (2024-07-31 06:41:35)
>> Hi all,
>>
>> On 30/07/24 2:40 pm, Laurent Pinchart wrote:
>>> On Tue, Jul 30, 2024 at 10:42:01AM +0200, Krzysztof Kozlowski wrote:
>>>> On 30/07/2024 10:24, Sakari Ailus wrote:
>>>>> Hi Krzysztof,
>>>>>
>>>>> On Mon, Jul 29, 2024 at 04:09:39PM +0200, Krzysztof Kozlowski wrote:
>>>>>> On 29/07/2024 13:04, Umang Jain wrote:
>>>>>>> Rectify the logical value of reset-gpio so that it is set to
>>>>>>> 0 (disabled) during power-on and to 1 (enabled) during power-off.
>>>>>>>
>>>>>>> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
>>>>>>> time to make sure it starts off in reset.
>>>>>>>
>>>>>>> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
>>>>>>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
>>>>>>> ---
>>>>>>>   drivers/media/i2c/imx335.c | 8 ++++----
>>>>>>>   1 file changed, 4 insertions(+), 4 deletions(-)
>>>>>>>
>>>>>> This will break all the users, so no. At least not without mentioning
>>>>>> ABI break and some sort of investigating how customers or users are
>>>>>> affected.
>>>>> I know the original authors aren't using the driver anymore and it took
>>>>> quite a bit of time until others started to contribute to it so I suspect
>>>>> the driver hasn't been in use for that long. There are no instances of the
>>>>> device in the in-kernel DTS either.
>>>>>
>>>>> Any DTS author should have also noticed the issue but of course there's a
>>>>> risk someone could have just changed the polarity and not bothered to chech
>>>>> what it was supposed to be.
>>>>>
>>>>> I agree the commit message should be more vocal about the effects on
>>>>> existing DTS.
>>>> I can imagine that all users (out of tree, in this case) inverted
>>>> polarity in DTS based on what's implemented. You could go with some
>>>> trivial hack, like I did for one of codecs - see 738455858a2d ("ASoC:
>>>> codecs: wsa881x: Use proper shutdown GPIO polarity"), but I remember
>>>> Mark Brown rejected similar commit for newer drivers.
>>> I don't think there's any out-of-tree user, because when we started
>>> using the recently driver, it required lots of fixes to even work at
>>> all. I'll let Kieran and Umang comment on that, I haven't follow the
>>> development in details.
>>
>> indeed, initially we had to put up fixes like :
>>
>> 14a60786d72e ("media: imx335: Set reserved register to default value")
>> 81495a59baeba ("media: imx335: Fix active area height discrepency")
>>
>> to make the sensor work properly on our platforms. Only after that we 
>> had a base to support more capabilities on the sensor (multiple lanes 
>> support, flips, TPG etc.)
> 
> I would also add that we had to provide control for the regulators to be
> able to power the device as well in fea91ee73b7c ("media: i2c: imx335:
> Enable regulator supplies").

Hm? That's not a proof of anything. Supplies are often turned on by default.

> 
> Given the driver was posted from Intel, I would have anticipated perhaps
> the driver was in fact only actually tested by Intel on ACPI platforms -
> yet with no ACPI table registered in the driver - even that could likely
> be considered broken.

Nope, that does not work like that. Their platforms and such sensors are
often used on DT based boards. Not mentioning even PRP0001.

> 
> Based on that I have a high confidence that there are no current users
> of this driver (except us).

Nope, wrong conclusions, not that many arguments.



Best regards,
Krzysztof

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Laurent Pinchart]

On Wed, Jul 31, 2024 at 11:06:38AM +0200, Krzysztof Kozlowski wrote:
> On 31/07/2024 11:02, Kieran Bingham wrote:
> > Quoting Umang Jain (2024-07-31 06:41:35)
> >> On 30/07/24 2:40 pm, Laurent Pinchart wrote:
> >>> On Tue, Jul 30, 2024 at 10:42:01AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 30/07/2024 10:24, Sakari Ailus wrote:
> >>>>> Hi Krzysztof,
> >>>>>
> >>>>> On Mon, Jul 29, 2024 at 04:09:39PM +0200, Krzysztof Kozlowski wrote:
> >>>>>> On 29/07/2024 13:04, Umang Jain wrote:
> >>>>>>> Rectify the logical value of reset-gpio so that it is set to
> >>>>>>> 0 (disabled) during power-on and to 1 (enabled) during power-off.
> >>>>>>>
> >>>>>>> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
> >>>>>>> time to make sure it starts off in reset.
> >>>>>>>
> >>>>>>> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
> >>>>>>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> >>>>>>> ---
> >>>>>>>   drivers/media/i2c/imx335.c | 8 ++++----
> >>>>>>>   1 file changed, 4 insertions(+), 4 deletions(-)
> >>>>>>>
> >>>>>> This will break all the users, so no. At least not without mentioning
> >>>>>> ABI break and some sort of investigating how customers or users are
> >>>>>> affected.
> >>>>>
> >>>>> I know the original authors aren't using the driver anymore and it took
> >>>>> quite a bit of time until others started to contribute to it so I suspect
> >>>>> the driver hasn't been in use for that long. There are no instances of the
> >>>>> device in the in-kernel DTS either.
> >>>>>
> >>>>> Any DTS author should have also noticed the issue but of course there's a
> >>>>> risk someone could have just changed the polarity and not bothered to chech
> >>>>> what it was supposed to be.
> >>>>>
> >>>>> I agree the commit message should be more vocal about the effects on
> >>>>> existing DTS.
> >>>>
> >>>> I can imagine that all users (out of tree, in this case) inverted
> >>>> polarity in DTS based on what's implemented. You could go with some
> >>>> trivial hack, like I did for one of codecs - see 738455858a2d ("ASoC:
> >>>> codecs: wsa881x: Use proper shutdown GPIO polarity"), but I remember
> >>>> Mark Brown rejected similar commit for newer drivers.
> >>>
> >>> I don't think there's any out-of-tree user, because when we started
> >>> using the recently driver, it required lots of fixes to even work at
> >>> all. I'll let Kieran and Umang comment on that, I haven't follow the
> >>> development in details.
> >>
> >> indeed, initially we had to put up fixes like :
> >>
> >> 14a60786d72e ("media: imx335: Set reserved register to default value")
> >> 81495a59baeba ("media: imx335: Fix active area height discrepency")
> >>
> >> to make the sensor work properly on our platforms. Only after that we 
> >> had a base to support more capabilities on the sensor (multiple lanes 
> >> support, flips, TPG etc.)
> > 
> > I would also add that we had to provide control for the regulators to be
> > able to power the device as well in fea91ee73b7c ("media: i2c: imx335:
> > Enable regulator supplies").
> 
> Hm? That's not a proof of anything. Supplies are often turned on by default.
> 
> > Given the driver was posted from Intel, I would have anticipated perhaps
> > the driver was in fact only actually tested by Intel on ACPI platforms -
> > yet with no ACPI table registered in the driver - even that could likely
> > be considered broken.
> 
> Nope, that does not work like that. Their platforms and such sensors are
> often used on DT based boards.

What DT-platforms would that be ?

> Not mentioning even PRP0001.

I don't think PRP0001 is used by Intel for camera sensors.

Sakari, do you have any information about all this ? Do you think
there's a risk that the driver is currently used by anyone with a
mainline kernel ?

> > Based on that I have a high confidence that there are no current users
> > of this driver (except us).
> 
> Nope, wrong conclusions, not that many arguments.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 2/2] media: imx335: Fix reset-gpio handling

[Sakari Ailus]

Hi Laurent, Krzysztof,

On Wed, Jul 31, 2024 at 12:39:05PM +0300, Laurent Pinchart wrote:
> On Wed, Jul 31, 2024 at 11:06:38AM +0200, Krzysztof Kozlowski wrote:
> > On 31/07/2024 11:02, Kieran Bingham wrote:
> > > Quoting Umang Jain (2024-07-31 06:41:35)
> > >> On 30/07/24 2:40 pm, Laurent Pinchart wrote:
> > >>> On Tue, Jul 30, 2024 at 10:42:01AM +0200, Krzysztof Kozlowski wrote:
> > >>>> On 30/07/2024 10:24, Sakari Ailus wrote:
> > >>>>> Hi Krzysztof,
> > >>>>>
> > >>>>> On Mon, Jul 29, 2024 at 04:09:39PM +0200, Krzysztof Kozlowski wrote:
> > >>>>>> On 29/07/2024 13:04, Umang Jain wrote:
> > >>>>>>> Rectify the logical value of reset-gpio so that it is set to
> > >>>>>>> 0 (disabled) during power-on and to 1 (enabled) during power-off.
> > >>>>>>>
> > >>>>>>> Meanwhile at it, set the reset-gpio to GPIO_OUT_HIGH at initialization
> > >>>>>>> time to make sure it starts off in reset.
> > >>>>>>>
> > >>>>>>> Fixes: 45d19b5fb9ae ("media: i2c: Add imx335 camera sensor driver")
> > >>>>>>> Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
> > >>>>>>> ---
> > >>>>>>>   drivers/media/i2c/imx335.c | 8 ++++----
> > >>>>>>>   1 file changed, 4 insertions(+), 4 deletions(-)
> > >>>>>>>
> > >>>>>> This will break all the users, so no. At least not without mentioning
> > >>>>>> ABI break and some sort of investigating how customers or users are
> > >>>>>> affected.
> > >>>>>
> > >>>>> I know the original authors aren't using the driver anymore and it took
> > >>>>> quite a bit of time until others started to contribute to it so I suspect
> > >>>>> the driver hasn't been in use for that long. There are no instances of the
> > >>>>> device in the in-kernel DTS either.
> > >>>>>
> > >>>>> Any DTS author should have also noticed the issue but of course there's a
> > >>>>> risk someone could have just changed the polarity and not bothered to chech
> > >>>>> what it was supposed to be.
> > >>>>>
> > >>>>> I agree the commit message should be more vocal about the effects on
> > >>>>> existing DTS.
> > >>>>
> > >>>> I can imagine that all users (out of tree, in this case) inverted
> > >>>> polarity in DTS based on what's implemented. You could go with some
> > >>>> trivial hack, like I did for one of codecs - see 738455858a2d ("ASoC:
> > >>>> codecs: wsa881x: Use proper shutdown GPIO polarity"), but I remember
> > >>>> Mark Brown rejected similar commit for newer drivers.
> > >>>
> > >>> I don't think there's any out-of-tree user, because when we started
> > >>> using the recently driver, it required lots of fixes to even work at
> > >>> all. I'll let Kieran and Umang comment on that, I haven't follow the
> > >>> development in details.
> > >>
> > >> indeed, initially we had to put up fixes like :
> > >>
> > >> 14a60786d72e ("media: imx335: Set reserved register to default value")
> > >> 81495a59baeba ("media: imx335: Fix active area height discrepency")
> > >>
> > >> to make the sensor work properly on our platforms. Only after that we 
> > >> had a base to support more capabilities on the sensor (multiple lanes 
> > >> support, flips, TPG etc.)
> > > 
> > > I would also add that we had to provide control for the regulators to be
> > > able to power the device as well in fea91ee73b7c ("media: i2c: imx335:
> > > Enable regulator supplies").
> > 
> > Hm? That's not a proof of anything. Supplies are often turned on by default.
> > 
> > > Given the driver was posted from Intel, I would have anticipated perhaps
> > > the driver was in fact only actually tested by Intel on ACPI platforms -
> > > yet with no ACPI table registered in the driver - even that could likely
> > > be considered broken.
> > 
> > Nope, that does not work like that. Their platforms and such sensors are
> > often used on DT based boards.
> 
> What DT-platforms would that be ?
> 
> > Not mentioning even PRP0001.
> 
> I don't think PRP0001 is used by Intel for camera sensors.

The original author is no longer using the driver nor it is used for its
original purpose any more. The next users were quite probably Kieran and
Umang late last year.

> 
> Sakari, do you have any information about all this ? Do you think
> there's a risk that the driver is currently used by anyone with a
> mainline kernel ?

I think it's extremely unlikely the driver has been or continues to be in
use on ACPI based systems.

-- 
Kind regards,

Sakari Ailus