The irq-gpios description misleading, apparently saying that driving the
IRQ GPIO resets the device, which is even more puzzling as there is a reset
GPIO as well.

In reality the IRQ pin can be driven during the reset sequence to configure
the client address, as it becomes clear after checking both the datasheet
and the driver code. Improve the text to clarify that.

Also rephrase to remove reference to the driver, which is not appropriate
in the bindings.

Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

---

Changed in v2:
 - reworded to clarify even further
---
 .../devicetree/bindings/input/touchscreen/goodix.yaml        | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
index 3d016b87c8df..2a2d86cfd104 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
@@ -37,8 +37,9 @@ properties:
     maxItems: 1
 
   irq-gpios:
-    description: GPIO pin used for IRQ. The driver uses the interrupt gpio pin
-      as output to reset the device.
+    description: GPIO pin used for IRQ input. Additionally, this line is
+      sampled by the device on reset deassertion to select the I2C client
+      address, thus it can be driven by the host during the reset sequence.
     maxItems: 1
 
   reset-gpios:
-- 
2.34.1

Hi Luca,

On Mon, Sep 25, 2023 at 05:22:08AM +0200, Luca Ceresoli wrote:
> The irq-gpios description misleading, apparently saying that driving the
> IRQ GPIO resets the device, which is even more puzzling as there is a reset
> GPIO as well.
> 
> In reality the IRQ pin can be driven during the reset sequence to configure
> the client address, as it becomes clear after checking both the datasheet
> and the driver code. Improve the text to clarify that.
> 
> Also rephrase to remove reference to the driver, which is not appropriate
> in the bindings.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>

Reviewed-by: Jeff LaBundy <jeff@labundy.com>

> 
> ---
> 
> Changed in v2:
>  - reworded to clarify even further
> ---
>  .../devicetree/bindings/input/touchscreen/goodix.yaml        | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
> index 3d016b87c8df..2a2d86cfd104 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
> +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.yaml
> @@ -37,8 +37,9 @@ properties:
>      maxItems: 1
>  
>    irq-gpios:
> -    description: GPIO pin used for IRQ. The driver uses the interrupt gpio pin
> -      as output to reset the device.
> +    description: GPIO pin used for IRQ input. Additionally, this line is
> +      sampled by the device on reset deassertion to select the I2C client
> +      address, thus it can be driven by the host during the reset sequence.
>      maxItems: 1
>  
>    reset-gpios:
> -- 
> 2.34.1
> 

Thanks for considering my feedback; the messaging is clear now.

Kind regards,
Jeff LaBundy

On Mon, 25 Sep 2023 05:22:08 +0200, Luca Ceresoli wrote:
> The irq-gpios description misleading, apparently saying that driving the
> IRQ GPIO resets the device, which is even more puzzling as there is a reset
> GPIO as well.
> 
> In reality the IRQ pin can be driven during the reset sequence to configure
> the client address, as it becomes clear after checking both the datasheet
> and the driver code. Improve the text to clarify that.
> 
> Also rephrase to remove reference to the driver, which is not appropriate
> in the bindings.
> 
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> 
> ---
> 
> Changed in v2:
>  - reworded to clarify even further
> ---
>  .../devicetree/bindings/input/touchscreen/goodix.yaml        | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

Hello Rob,

On Mon, 25 Sep 2023 11:25:09 -0500
Rob Herring <robh@kernel.org> wrote:

> Acked-by: Rob Herring <robh@kernel.org>

I can't find this patch in your for-next, is there any blocker I should
handle?

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

On 28/11/2023 10:21, Luca Ceresoli wrote:
> Hello Rob,
> 
> On Mon, 25 Sep 2023 11:25:09 -0500
> Rob Herring <robh@kernel.org> wrote:
> 
>> Acked-by: Rob Herring <robh@kernel.org>
> 
> I can't find this patch in your for-next, is there any blocker I should
> handle?

This was an Ack, not applied from Rob. Intention is that bindings go via
subsystem maintainer (here: Dmitry).

Best regards,
Krzysztof

Hello Krzysztof,

On Tue, 28 Nov 2023 10:22:27 +0100
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote:

> On 28/11/2023 10:21, Luca Ceresoli wrote:
> > Hello Rob,
> > 
> > On Mon, 25 Sep 2023 11:25:09 -0500
> > Rob Herring <robh@kernel.org> wrote:
> >   
> >> Acked-by: Rob Herring <robh@kernel.org>  
> > 
> > I can't find this patch in your for-next, is there any blocker I should
> > handle?  
> 
> This was an Ack, not applied from Rob. Intention is that bindings go via
> subsystem maintainer (here: Dmitry).

Thanks for the clarification!

Luca

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com