[PATCH 1/2] dt-bindings: input: add Semtech SX951x binding

[PATCH 1/2] dt-bindings: input: add Semtech SX951x binding

[David Bauer]

Add device-tree binding for the Semtech SX9512/SX9513 family of touch
controllers with integrated LED driver.

Signed-off-by: David Bauer <mail@david-bauer.net>
---
 .../bindings/input/semtech,sx951x.yaml        | 180 ++++++++++++++++++
 1 file changed, 180 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/semtech,sx951x.yaml

diff --git a/Documentation/devicetree/bindings/input/semtech,sx951x.yaml b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
new file mode 100644
index 000000000000..e4f938decd86
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/semtech,sx951x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Semtech SX9512/SX9513 based capacitive touch sensors
+
+description: |
+  The Semtech SX9512/SX9513 Family of capacitive touch controllers
+  with integrated LED drivers. The device communication is using I2C only.
+
+maintainers:
+  - David Bauer <mail@david-bauer.net>
+
+properties:
+  compatible:
+    enum:
+      - semtech,sx9512
+      - semtech,sx9513
+
+  reg:
+    maxItems: 1
+
+  '#address-cells':
+    const: 1
+
+  '#size-cells':
+    const: 0
+
+  poll-interval:
+    default: 100
+    description: |
+      The polling interval for touch events in milliseconds.
+
+patternProperties:
+  "^channel@[0-7]$":
+    $ref: input.yaml#
+    type: object
+    description: |
+      Each node represents a channel of the touch controller.
+      Each channel provides a capacitive touch sensor input and
+      an LED driver output.
+
+    properties:
+      reg:
+        enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+      linux,keycodes:
+        maxItems: 1
+        description: |
+          Specifies an array of numeric keycode values to
+          be used for the channels. If this property is
+          omitted, the channel is not used as a key.
+
+      semtech,cin-delta:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        minimum: 0
+        maximum: 3
+        default: 3
+        description: |
+          The capacitance delta which is used to detect a touch
+          or release event. The property value is mapped to a
+          farad range between 7pF and 2.3pF internally. The delta
+          becomes smaller the higher the value is.
+
+      semtech,sense-threshold:
+        $ref: /schemas/types.yaml#/definitions/uint32
+        minimum: 0
+        maximum: 255
+        default: 4
+        description: |
+          The threshold value after which the channel detects a touch.
+          Refer to the datasheet for the internal calculation of the
+          resulting touch sensitivity.
+
+      led:
+        $ref: /schemas/leds/common.yaml#
+        type: object
+        unevaluatedProperties: false
+        description: |
+          Presence of this property indicates the channel
+          is used as an LED driver.
+
+    required:
+      - reg
+
+    additionalProperties: false
+
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/input/input.h>
+    #include <dt-bindings/leds/common.h>
+    i2c {
+      #address-cells = <1>;
+      #size-cells = <0>;
+
+      touch@2b {
+        compatible = "semtech,sx9512";
+
+        reg = <0x2b>;
+
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        poll-interval = <100>;
+
+        channel@1 {
+          reg = <1>;
+
+          semtech,cin-delta = <0x3>;
+          semtech,sense-threshold = <0xff>;
+
+          linux,keycodes = <KEY_A>;
+        };
+
+        channel@2 {
+          reg = <2>;
+
+          semtech,cin-delta = <0x3>;
+          semtech,sense-threshold = <0xff>;
+
+          linux,keycodes = <KEY_B>;
+        };
+
+        channel@3 {
+          reg = <3>;
+
+          semtech,cin-delta = <0x3>;
+          semtech,sense-threshold = <0xff>;
+
+          linux,keycodes = <KEY_WPS_BUTTON>;
+        };
+
+        channel@4 {
+          reg = <4>;
+
+          led {
+            color = <LED_COLOR_ID_RED>;
+            function = LED_FUNCTION_WAN;
+          };
+        };
+
+        channel@5 {
+          reg = <5>;
+
+          led {
+            color = <LED_COLOR_ID_GREEN>;
+            function = LED_FUNCTION_WAN;
+          };
+        };
+
+        channel@6 {
+          reg = <6>;
+
+          led {
+            color = <LED_COLOR_ID_GREEN>;
+            function = LED_FUNCTION_WLAN;
+            linux,default-trigger = "phy1tx";
+          };
+        };
+
+        channel@7 {
+          reg = <7>;
+
+          led {
+            color = <LED_COLOR_ID_GREEN>;
+            function = LED_FUNCTION_WLAN;
+            linux,default-trigger = "phy0tx";
+          };
+        };
+      };
+    };
-- 
2.47.2

Re: [PATCH 1/2] dt-bindings: input: add Semtech SX951x binding

[Krzysztof Kozlowski]

On 05/05/2025 22:38, David Bauer wrote:
> Add device-tree binding for the Semtech SX9512/SX9513 family of touch
> controllers with integrated LED driver.
> 
> Signed-off-by: David Bauer <mail@david-bauer.net>

You CC-ed an address, which suggests you do not work on mainline kernel
or you do not use get_maintainers.pl/b4/patman. Please rebase and always
work on mainline or start using mentioned tools, so correct addresses
will be used.

Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC (and consider --no-git-fallback argument, so you will
not CC people just because they made one commit years ago). 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.


> ---
>  .../bindings/input/semtech,sx951x.yaml        | 180 ++++++++++++++++++
>  1 file changed, 180 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/semtech,sx951x.yaml
> 
> diff --git a/Documentation/devicetree/bindings/input/semtech,sx951x.yaml b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
> new file mode 100644
> index 000000000000..e4f938decd86
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
> @@ -0,0 +1,180 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/semtech,sx951x.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Semtech SX9512/SX9513 based capacitive touch sensors
> +
> +description: |

Do not need '|' unless you need to preserve formatting.

> +  The Semtech SX9512/SX9513 Family of capacitive touch controllers
> +  with integrated LED drivers. The device communication is using I2C only.
> +
> +maintainers:
> +  - David Bauer <mail@david-bauer.net>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - semtech,sx9512
> +      - semtech,sx9513

Devices are not compatible? What are the differences?

> +
> +  reg:
> +    maxItems: 1
> +
> +  '#address-cells':
> +    const: 1
> +
> +  '#size-cells':
> +    const: 0
> +
> +  poll-interval:
> +    default: 100
> +    description: |

Do not need '|' unless you need to preserve formatting. Same comment
everywhere.

> +      The polling interval for touch events in milliseconds.

Missing -ms property unit suffix... unless you are using existing
property from common schema, but I do not see any reference (and thus
unevaluatedProperties at the end).

> +
> +patternProperties:
> +  "^channel@[0-7]$":
> +    $ref: input.yaml#
> +    type: object
> +    description: |
> +      Each node represents a channel of the touch controller.
> +      Each channel provides a capacitive touch sensor input and
> +      an LED driver output.
> +
> +    properties:
> +      reg:
> +        enum: [0, 1, 2, 3, 4, 5, 6, 7]
> +
> +      linux,keycodes:
> +        maxItems: 1
> +        description: |
> +          Specifies an array of numeric keycode values to
> +          be used for the channels. If this property is
> +          omitted, the channel is not used as a key.
> +
> +      semtech,cin-delta:

Use proper unit suffix and express it in pF.

> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 3
> +        default: 3
> +        description: |
> +          The capacitance delta which is used to detect a touch
> +          or release event. The property value is mapped to a
> +          farad range between 7pF and 2.3pF internally. The delta
> +          becomes smaller the higher the value is.
> +
> +      semtech,sense-threshold:
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +        minimum: 0
> +        maximum: 255
> +        default: 4
> +        description: |
> +          The threshold value after which the channel detects a touch.
> +          Refer to the datasheet for the internal calculation of the
> +          resulting touch sensitivity.
> +
> +      led:

I think subnode is here not needed. This should be part of the channel,
probably.

> +        $ref: /schemas/leds/common.yaml#
> +        type: object
> +        unevaluatedProperties: false
> +        description: |
> +          Presence of this property indicates the channel
> +          is used as an LED driver.
> +
> +    required:
> +      - reg
> +
> +    additionalProperties: false

unevaluatedProperties instead

> +
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/input/input.h>
> +    #include <dt-bindings/leds/common.h>
> +    i2c {
> +      #address-cells = <1>;
> +      #size-cells = <0>;
> +
> +      touch@2b {
> +        compatible = "semtech,sx9512";
> +

Drop blank line

> +        reg = <0x2b>;
> +


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: input: add Semtech SX951x binding

[David Bauer]

Hi Krzysztof,

thanks for the review.

On 5/6/25 08:21, Krzysztof Kozlowski wrote:
> On 05/05/2025 22:38, David Bauer wrote:
>> Add device-tree binding for the Semtech SX9512/SX9513 family of touch
>> controllers with integrated LED driver.
>>
>> Signed-off-by: David Bauer <mail@david-bauer.net>
> 
> You CC-ed an address, which suggests you do not work on mainline kernel
> or you do not use get_maintainers.pl/b4/patman. Please rebase and always
> work on mainline or start using mentioned tools, so correct addresses
> will be used.
I'm a bit unsure what you are referring to - maybe I've set the options
for get_maintainer.pl wrong, but i use

get_maintainer.pl --nogit --nogit-fallback --norolestats --nol

to determine TO recipients and

get_maintainer.pl --nogit --nogit-fallback --norolestats --nom

for CC destinations.

Granted, my tree was a bit out of date but it was from mainline
and after rebase both commands returned consistent results.

Hope you can provide me with some guidance there.

> 
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument, so you will
> not CC people just because they made one commit years ago). 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.
> 
> 
>> ---
>>   .../bindings/input/semtech,sx951x.yaml        | 180 ++++++++++++++++++
>>   1 file changed, 180 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/input/semtech,sx951x.yaml b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>> new file mode 100644
>> index 000000000000..e4f938decd86
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>> @@ -0,0 +1,180 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/input/semtech,sx951x.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Semtech SX9512/SX9513 based capacitive touch sensors
>> +
>> +description: |
> 
> Do not need '|' unless you need to preserve formatting.
> 
>> +  The Semtech SX9512/SX9513 Family of capacitive touch controllers
>> +  with integrated LED drivers. The device communication is using I2C only.
>> +
>> +maintainers:
>> +  - David Bauer <mail@david-bauer.net>
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - semtech,sx9512
>> +      - semtech,sx9513
> 
> Devices are not compatible? What are the differences?

The SX9513 is a cost-reduced version which does not
support proximity sensing. With the current support
of the driver they work identical. Should i add this
information as a comment?

> 
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  '#address-cells':
>> +    const: 1
>> +
>> +  '#size-cells':
>> +    const: 0
>> +
>> +  poll-interval:
>> +    default: 100
>> +    description: |
> 
> Do not need '|' unless you need to preserve formatting. Same comment
> everywhere.
> 
>> +      The polling interval for touch events in milliseconds.
> 
> Missing -ms property unit suffix... unless you are using existing
> property from common schema, but I do not see any reference (and thus
> unevaluatedProperties at the end).
> 
>> +
>> +patternProperties:
>> +  "^channel@[0-7]$":
>> +    $ref: input.yaml#
>> +    type: object
>> +    description: |
>> +      Each node represents a channel of the touch controller.
>> +      Each channel provides a capacitive touch sensor input and
>> +      an LED driver output.
>> +
>> +    properties:
>> +      reg:
>> +        enum: [0, 1, 2, 3, 4, 5, 6, 7]
>> +
>> +      linux,keycodes:
>> +        maxItems: 1
>> +        description: |
>> +          Specifies an array of numeric keycode values to
>> +          be used for the channels. If this property is
>> +          omitted, the channel is not used as a key.
>> +
>> +      semtech,cin-delta:
> 
> Use proper unit suffix and express it in pF.

To represent 2.3 and 3.8 pF, would it be better to represent in
femtofarad?

> 
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        minimum: 0
>> +        maximum: 3
>> +        default: 3
>> +        description: |
>> +          The capacitance delta which is used to detect a touch
>> +          or release event. The property value is mapped to a
>> +          farad range between 7pF and 2.3pF internally. The delta
>> +          becomes smaller the higher the value is.
>> +
>> +      semtech,sense-threshold:
>> +        $ref: /schemas/types.yaml#/definitions/uint32
>> +        minimum: 0
>> +        maximum: 255
>> +        default: 4
>> +        description: |
>> +          The threshold value after which the channel detects a touch.
>> +          Refer to the datasheet for the internal calculation of the
>> +          resulting touch sensitivity.
>> +
>> +      led:
> 
> I think subnode is here not needed. This should be part of the channel,
> probably.

Just to be sure - you mean to have a property "led" upon which instructs
the channel to be used to drive an LED and include the LED specific
properties in the node of the channel?

> 
>> +        $ref: /schemas/leds/common.yaml#
>> +        type: object
>> +        unevaluatedProperties: false
>> +        description: |
>> +          Presence of this property indicates the channel
>> +          is used as an LED driver.
>> +
>> +    required:
>> +      - reg
>> +
>> +    additionalProperties: false
> 
> unevaluatedProperties instead
> 
>> +
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    #include <dt-bindings/input/input.h>
>> +    #include <dt-bindings/leds/common.h>
>> +    i2c {
>> +      #address-cells = <1>;
>> +      #size-cells = <0>;
>> +
>> +      touch@2b {
>> +        compatible = "semtech,sx9512";
>> +
> 
> Drop blank line
> 
>> +        reg = <0x2b>;
>> +
> 
> 
> Best regards,
> Krzysztof

Re: [PATCH 1/2] dt-bindings: input: add Semtech SX951x binding

[Rob Herring]

On Tue, May 06, 2025 at 12:05:43PM +0200, David Bauer wrote:
> Hi Krzysztof,
> 
> thanks for the review.
> 
> On 5/6/25 08:21, Krzysztof Kozlowski wrote:
> > On 05/05/2025 22:38, David Bauer wrote:
> > > Add device-tree binding for the Semtech SX9512/SX9513 family of touch
> > > controllers with integrated LED driver.
> > > 
> > > Signed-off-by: David Bauer <mail@david-bauer.net>
> > 
> > You CC-ed an address, which suggests you do not work on mainline kernel
> > or you do not use get_maintainers.pl/b4/patman. Please rebase and always
> > work on mainline or start using mentioned tools, so correct addresses
> > will be used.
> I'm a bit unsure what you are referring to - maybe I've set the options
> for get_maintainer.pl wrong, but i use
> 
> get_maintainer.pl --nogit --nogit-fallback --norolestats --nol
> 
> to determine TO recipients and
> 
> get_maintainer.pl --nogit --nogit-fallback --norolestats --nom
> 
> for CC destinations.
> 
> Granted, my tree was a bit out of date but it was from mainline
> and after rebase both commands returned consistent results.
> 
> Hope you can provide me with some guidance there.

Probably that I don't use 'robh+dt' for a while now. Just 'robh'.

> > 
> > Please use scripts/get_maintainers.pl to get a list of necessary people
> > and lists to CC (and consider --no-git-fallback argument, so you will
> > not CC people just because they made one commit years ago). 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.
> > 
> > 
> > > ---
> > >   .../bindings/input/semtech,sx951x.yaml        | 180 ++++++++++++++++++
> > >   1 file changed, 180 insertions(+)
> > >   create mode 100644 Documentation/devicetree/bindings/input/semtech,sx951x.yaml
> > > 
> > > diff --git a/Documentation/devicetree/bindings/input/semtech,sx951x.yaml b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
> > > new file mode 100644
> > > index 000000000000..e4f938decd86
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
> > > @@ -0,0 +1,180 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/semtech,sx951x.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Semtech SX9512/SX9513 based capacitive touch sensors
> > > +
> > > +description: |
> > 
> > Do not need '|' unless you need to preserve formatting.
> > 
> > > +  The Semtech SX9512/SX9513 Family of capacitive touch controllers
> > > +  with integrated LED drivers. The device communication is using I2C only.
> > > +
> > > +maintainers:
> > > +  - David Bauer <mail@david-bauer.net>
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - semtech,sx9512
> > > +      - semtech,sx9513
> > 
> > Devices are not compatible? What are the differences?
> 
> The SX9513 is a cost-reduced version which does not
> support proximity sensing. With the current support
> of the driver they work identical. Should i add this
> information as a comment?

In the 'description' above, but not the driver support part.

> > > +
> > > +  reg:
> > > +    maxItems: 1
> > > +
> > > +  '#address-cells':
> > > +    const: 1
> > > +
> > > +  '#size-cells':
> > > +    const: 0
> > > +
> > > +  poll-interval:
> > > +    default: 100
> > > +    description: |
> > 
> > Do not need '|' unless you need to preserve formatting. Same comment
> > everywhere.
> > 
> > > +      The polling interval for touch events in milliseconds.
> > 
> > Missing -ms property unit suffix... unless you are using existing
> > property from common schema, but I do not see any reference (and thus
> > unevaluatedProperties at the end).
> > 
> > > +
> > > +patternProperties:
> > > +  "^channel@[0-7]$":
> > > +    $ref: input.yaml#
> > > +    type: object
> > > +    description: |
> > > +      Each node represents a channel of the touch controller.
> > > +      Each channel provides a capacitive touch sensor input and
> > > +      an LED driver output.
> > > +
> > > +    properties:
> > > +      reg:
> > > +        enum: [0, 1, 2, 3, 4, 5, 6, 7]

maximum: 7

> > > +
> > > +      linux,keycodes:
> > > +        maxItems: 1
> > > +        description: |
> > > +          Specifies an array of numeric keycode values to
> > > +          be used for the channels. If this property is
> > > +          omitted, the channel is not used as a key.
> > > +
> > > +      semtech,cin-delta:
> > 
> > Use proper unit suffix and express it in pF.
> 
> To represent 2.3 and 3.8 pF, would it be better to represent in
> femtofarad?

Yes.


> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        minimum: 0
> > > +        maximum: 3
> > > +        default: 3
> > > +        description: |
> > > +          The capacitance delta which is used to detect a touch
> > > +          or release event. The property value is mapped to a
> > > +          farad range between 7pF and 2.3pF internally. The delta
> > > +          becomes smaller the higher the value is.
> > > +
> > > +      semtech,sense-threshold:
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        minimum: 0
> > > +        maximum: 255
> > > +        default: 4
> > > +        description: |
> > > +          The threshold value after which the channel detects a touch.
> > > +          Refer to the datasheet for the internal calculation of the
> > > +          resulting touch sensitivity.
> > > +
> > > +      led:
> > 
> > I think subnode is here not needed. This should be part of the channel,
> > probably.
> 
> Just to be sure - you mean to have a property "led" upon which instructs
> the channel to be used to drive an LED and include the LED specific
> properties in the node of the channel?

Actually, I think it is fine as-is if the LED driver works 
simultaneously with the touch input and isn't mutually exclusive. The 
'led' node is for the LED. The parent node is the driver/controller.

If they are mutually exclusive, then I'd say you want channel@[0-7] and 
led@[0-7] nodes at the same level.

Rob

Re: [PATCH 1/2] dt-bindings: input: add Semtech SX951x binding

[Krzysztof Kozlowski]

On 06/05/2025 12:05, David Bauer wrote:
> Hi Krzysztof,
> 
> thanks for the review.
> 
> On 5/6/25 08:21, Krzysztof Kozlowski wrote:
>> On 05/05/2025 22:38, David Bauer wrote:
>>> Add device-tree binding for the Semtech SX9512/SX9513 family of touch
>>> controllers with integrated LED driver.
>>>
>>> Signed-off-by: David Bauer <mail@david-bauer.net>
>>
>> You CC-ed an address, which suggests you do not work on mainline kernel
>> or you do not use get_maintainers.pl/b4/patman. Please rebase and always
>> work on mainline or start using mentioned tools, so correct addresses
>> will be used.
> I'm a bit unsure what you are referring to - maybe I've set the options
> for get_maintainer.pl wrong, but i use
> 
> get_maintainer.pl --nogit --nogit-fallback --norolestats --nol
> 
> to determine TO recipients and
> 
> get_maintainer.pl --nogit --nogit-fallback --norolestats --nom
> 
> for CC destinations.
> 
> Granted, my tree was a bit out of date but it was from mainline

Mainline means latest RC or maintainer tree or linux next. v5.0 is not
mainline anymoer.

> and after rebase both commands returned consistent results.
> 
> Hope you can provide me with some guidance there.

Well, read full reply. It is impossible to get such email address from
above commands. Such email address does not exist since long time and it
easy to prove - just git grep for it. No results, so how could it be
printed by get_maintainers.pl?

If you disagree then please paste full output of:

$ git describe
$ git status
$ scripts/get_maintainer.pl 0*

I provided you extensive guideline exactly to avoid further trivial
discussions about that triviality, so I would really appreciate if you
followed it.

> 
>>
>> Please use scripts/get_maintainers.pl to get a list of necessary people
>> and lists to CC (and consider --no-git-fallback argument, so you will
>> not CC people just because they made one commit years ago). 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.
>>
>>
>>> ---
>>>   .../bindings/input/semtech,sx951x.yaml        | 180 ++++++++++++++++++
>>>   1 file changed, 180 insertions(+)
>>>   create mode 100644 Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/semtech,sx951x.yaml b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>>> new file mode 100644
>>> index 000000000000..e4f938decd86
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>>> @@ -0,0 +1,180 @@
>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/input/semtech,sx951x.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Semtech SX9512/SX9513 based capacitive touch sensors
>>> +
>>> +description: |
>>
>> Do not need '|' unless you need to preserve formatting.
>>
>>> +  The Semtech SX9512/SX9513 Family of capacitive touch controllers
>>> +  with integrated LED drivers. The device communication is using I2C only.
>>> +
>>> +maintainers:
>>> +  - David Bauer <mail@david-bauer.net>
>>> +
>>> +properties:
>>> +  compatible:
>>> +    enum:
>>> +      - semtech,sx9512
>>> +      - semtech,sx9513
>>
>> Devices are not compatible? What are the differences?
> 
> The SX9513 is a cost-reduced version which does not
> support proximity sensing. With the current support
> of the driver they work identical. Should i add this
> information as a comment?

So they are compatible and this should be expressed via fallback.


> 
>>
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  '#address-cells':
>>> +    const: 1
>>> +
>>> +  '#size-cells':
>>> +    const: 0
>>> +
>>> +  poll-interval:
>>> +    default: 100
>>> +    description: |
>>
>> Do not need '|' unless you need to preserve formatting. Same comment
>> everywhere.
>>
>>> +      The polling interval for touch events in milliseconds.
>>
>> Missing -ms property unit suffix... unless you are using existing
>> property from common schema, but I do not see any reference (and thus
>> unevaluatedProperties at the end).
>>
>>> +
>>> +patternProperties:
>>> +  "^channel@[0-7]$":
>>> +    $ref: input.yaml#
>>> +    type: object
>>> +    description: |
>>> +      Each node represents a channel of the touch controller.
>>> +      Each channel provides a capacitive touch sensor input and
>>> +      an LED driver output.
>>> +
>>> +    properties:
>>> +      reg:
>>> +        enum: [0, 1, 2, 3, 4, 5, 6, 7]
>>> +
>>> +      linux,keycodes:
>>> +        maxItems: 1
>>> +        description: |
>>> +          Specifies an array of numeric keycode values to
>>> +          be used for the channels. If this property is
>>> +          omitted, the channel is not used as a key.
>>> +
>>> +      semtech,cin-delta:
>>
>> Use proper unit suffix and express it in pF.
> 
> To represent 2.3 and 3.8 pF, would it be better to represent in
> femtofarad?
> 
>>
>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>> +        minimum: 0
>>> +        maximum: 3
>>> +        default: 3
>>> +        description: |
>>> +          The capacitance delta which is used to detect a touch
>>> +          or release event. The property value is mapped to a
>>> +          farad range between 7pF and 2.3pF internally. The delta
>>> +          becomes smaller the higher the value is.
>>> +
>>> +      semtech,sense-threshold:
>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>> +        minimum: 0
>>> +        maximum: 255
>>> +        default: 4
>>> +        description: |
>>> +          The threshold value after which the channel detects a touch.
>>> +          Refer to the datasheet for the internal calculation of the
>>> +          resulting touch sensitivity.
>>> +
>>> +      led:
>>
>> I think subnode is here not needed. This should be part of the channel,
>> probably.
> 
> Just to be sure - you mean to have a property "led" upon which instructs
> the channel to be used to drive an LED and include the LED specific
> properties in the node of the channel?
No, I do not mean a property led. I mean that child node should be
folded into parent.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: input: add Semtech SX951x binding

[Krzysztof Kozlowski]

On 20/05/2025 15:58, Krzysztof Kozlowski wrote:
> On 06/05/2025 12:05, David Bauer wrote:
>> Hi Krzysztof,
>>
>> thanks for the review.
>>
>> On 5/6/25 08:21, Krzysztof Kozlowski wrote:
>>> On 05/05/2025 22:38, David Bauer wrote:
>>>> Add device-tree binding for the Semtech SX9512/SX9513 family of touch
>>>> controllers with integrated LED driver.
>>>>
>>>> Signed-off-by: David Bauer <mail@david-bauer.net>
>>>
>>> You CC-ed an address, which suggests you do not work on mainline kernel
>>> or you do not use get_maintainers.pl/b4/patman. Please rebase and always
>>> work on mainline or start using mentioned tools, so correct addresses
>>> will be used.
>> I'm a bit unsure what you are referring to - maybe I've set the options
>> for get_maintainer.pl wrong, but i use
>>
>> get_maintainer.pl --nogit --nogit-fallback --norolestats --nol
>>
>> to determine TO recipients and
>>
>> get_maintainer.pl --nogit --nogit-fallback --norolestats --nom
>>
>> for CC destinations.
>>
>> Granted, my tree was a bit out of date but it was from mainline
> 
> Mainline means latest RC or maintainer tree or linux next. v5.0 is not
> mainline anymoer.
> 
>> and after rebase both commands returned consistent results.
>>
>> Hope you can provide me with some guidance there.
> 
> Well, read full reply. It is impossible to get such email address from
> above commands. Such email address does not exist since long time and it
> easy to prove - just git grep for it. No results, so how could it be
> printed by get_maintainers.pl?
> 
> If you disagree then please paste full output of:
> 
> $ git describe
> $ git status
> $ scripts/get_maintainer.pl 0*
> 
> I provided you extensive guideline exactly to avoid further trivial
> discussions about that triviality, so I would really appreciate if you
> followed it.

Huh, I noticed I responded after two weeks so pretty late... Huh,
exactly because of the reason why I asked to use up2date addresses - the
mailbox used in this patchset is not being used/checked/accessed since
long time and kernel since long time has correct address.

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: input: add Semtech SX951x binding

[David Bauer]

Hi Krzysztof,

On 5/20/25 15:58, Krzysztof Kozlowski wrote:
> On 06/05/2025 12:05, David Bauer wrote:
>> Hi Krzysztof,
>>
>> thanks for the review.
>>
>> On 5/6/25 08:21, Krzysztof Kozlowski wrote:
>>> On 05/05/2025 22:38, David Bauer wrote:
>>>> Add device-tree binding for the Semtech SX9512/SX9513 family of touch
>>>> controllers with integrated LED driver.
>>>>
>>>> Signed-off-by: David Bauer <mail@david-bauer.net>
>>>
>>> You CC-ed an address, which suggests you do not work on mainline kernel
>>> or you do not use get_maintainers.pl/b4/patman. Please rebase and always
>>> work on mainline or start using mentioned tools, so correct addresses
>>> will be used.
>> I'm a bit unsure what you are referring to - maybe I've set the options
>> for get_maintainer.pl wrong, but i use
>>
>> get_maintainer.pl --nogit --nogit-fallback --norolestats --nol
>>
>> to determine TO recipients and
>>
>> get_maintainer.pl --nogit --nogit-fallback --norolestats --nom
>>
>> for CC destinations.
>>
>> Granted, my tree was a bit out of date but it was from mainline
> 
> Mainline means latest RC or maintainer tree or linux next. v5.0 is not
> mainline anymoer.
> 
>> and after rebase both commands returned consistent results.
>>
>> Hope you can provide me with some guidance there.
> 
> Well, read full reply. It is impossible to get such email address from
> above commands. Such email address does not exist since long time and it
> easy to prove - just git grep for it. No results, so how could it be
> printed by get_maintainers.pl?
> 
> If you disagree then please paste full output of:
> 
> $ git describe
> $ git status
> $ scripts/get_maintainer.pl 0*
> 
> I provided you extensive guideline exactly to avoid further trivial
> discussions about that triviality, so I would really appreciate if you
> followed it.

I did a complete new clone of my repository without changing the base-branch
and now the script outputs the correct set of addresses. Be assured v2
will reach the correct inbox(es).

Sorry for the confusion here. Still appreciate you did point this
out to me.

> 
>>
>>>
>>> Please use scripts/get_maintainers.pl to get a list of necessary people
>>> and lists to CC (and consider --no-git-fallback argument, so you will
>>> not CC people just because they made one commit years ago). 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.
>>>
>>>
>>>> ---
>>>>    .../bindings/input/semtech,sx951x.yaml        | 180 ++++++++++++++++++
>>>>    1 file changed, 180 insertions(+)
>>>>    create mode 100644 Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/input/semtech,sx951x.yaml b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>>>> new file mode 100644
>>>> index 000000000000..e4f938decd86
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/input/semtech,sx951x.yaml
>>>> @@ -0,0 +1,180 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/input/semtech,sx951x.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Semtech SX9512/SX9513 based capacitive touch sensors
>>>> +
>>>> +description: |
>>>
>>> Do not need '|' unless you need to preserve formatting.
>>>
>>>> +  The Semtech SX9512/SX9513 Family of capacitive touch controllers
>>>> +  with integrated LED drivers. The device communication is using I2C only.
>>>> +
>>>> +maintainers:
>>>> +  - David Bauer <mail@david-bauer.net>
>>>> +
>>>> +properties:
>>>> +  compatible:
>>>> +    enum:
>>>> +      - semtech,sx9512
>>>> +      - semtech,sx9513
>>>
>>> Devices are not compatible? What are the differences?
>>
>> The SX9513 is a cost-reduced version which does not
>> support proximity sensing. With the current support
>> of the driver they work identical. Should i add this
>> information as a comment?
> 
> So they are compatible and this should be expressed via fallback.
> 
> 
>>
>>>
>>>> +
>>>> +  reg:
>>>> +    maxItems: 1
>>>> +
>>>> +  '#address-cells':
>>>> +    const: 1
>>>> +
>>>> +  '#size-cells':
>>>> +    const: 0
>>>> +
>>>> +  poll-interval:
>>>> +    default: 100
>>>> +    description: |
>>>
>>> Do not need '|' unless you need to preserve formatting. Same comment
>>> everywhere.
>>>
>>>> +      The polling interval for touch events in milliseconds.
>>>
>>> Missing -ms property unit suffix... unless you are using existing
>>> property from common schema, but I do not see any reference (and thus
>>> unevaluatedProperties at the end).
>>>
>>>> +
>>>> +patternProperties:
>>>> +  "^channel@[0-7]$":
>>>> +    $ref: input.yaml#
>>>> +    type: object
>>>> +    description: |
>>>> +      Each node represents a channel of the touch controller.
>>>> +      Each channel provides a capacitive touch sensor input and
>>>> +      an LED driver output.
>>>> +
>>>> +    properties:
>>>> +      reg:
>>>> +        enum: [0, 1, 2, 3, 4, 5, 6, 7]
>>>> +
>>>> +      linux,keycodes:
>>>> +        maxItems: 1
>>>> +        description: |
>>>> +          Specifies an array of numeric keycode values to
>>>> +          be used for the channels. If this property is
>>>> +          omitted, the channel is not used as a key.
>>>> +
>>>> +      semtech,cin-delta:
>>>
>>> Use proper unit suffix and express it in pF.
>>
>> To represent 2.3 and 3.8 pF, would it be better to represent in
>> femtofarad?
>>
>>>
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        minimum: 0
>>>> +        maximum: 3
>>>> +        default: 3
>>>> +        description: |
>>>> +          The capacitance delta which is used to detect a touch
>>>> +          or release event. The property value is mapped to a
>>>> +          farad range between 7pF and 2.3pF internally. The delta
>>>> +          becomes smaller the higher the value is.
>>>> +
>>>> +      semtech,sense-threshold:
>>>> +        $ref: /schemas/types.yaml#/definitions/uint32
>>>> +        minimum: 0
>>>> +        maximum: 255
>>>> +        default: 4
>>>> +        description: |
>>>> +          The threshold value after which the channel detects a touch.
>>>> +          Refer to the datasheet for the internal calculation of the
>>>> +          resulting touch sensitivity.
>>>> +
>>>> +      led:
>>>
>>> I think subnode is here not needed. This should be part of the channel,
>>> probably.
>>
>> Just to be sure - you mean to have a property "led" upon which instructs
>> the channel to be used to drive an LED and include the LED specific
>> properties in the node of the channel?
> No, I do not mean a property led. I mean that child node should be
> folded into parent.

Okay, now i get it. The hardware supports the exclusive as well as combined
use of channels as LED-driver and touch input.

In case the channel is not wired up to work as an input, the linux,keycodes
property can be omitted, not creating the input channel.

In turn if the channel is not wired up to an LED, omitting the led subnode
prevents an led device from being created for this channel.

If I were to fold the led subnode into the channel node I would still need
a way to indicate if an LED is actually present in hardware, correct? This
was what i was aiming for with the "led" property. However if I've had to
choose between these two approaches, I prefer the subnode.

If you have a different idea how to handle this apart from Rob's suggestion,
It could also be the case I'm creating more problems than I solve with this
approach :)

Best
David