Re: [PATCH v2 4/4] dt-bindings: input: mt-matrix-keypad: add guardian mt matrix keypad bindings definition

[Krzysztof Kozlowski]

On 06/05/2022 09:27, Gireesh.Hiremath@xxxxxxxxxxxx wrote:
> From: Gireesh Hiremath <Gireesh.Hiremath@xxxxxxxxxxxx>
> 
> Add binding definition for the support of the Guardian
> mt matrix keypad driver.
> 
> Signed-off-by: Gireesh Hiremath <Gireesh.Hiremath@xxxxxxxxxxxx>
> ---
> Hi Krzysztof
> 
> Changes since v1: addressed review comments
> 
>>> Add binding definition for the support of the Guardian
>>> mt matrix keypad driver.
>>>
>>> Signed-off-by: Gireesh Hiremath <Gireesh.Hiremath@xxxxxxxxxxxx>
>>> ---
>>>  .../bindings/input/mt-matrix-keypad.yaml      | 134 ++++++++++++++++++
>>>  1 file changed, 134 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/input/mt-matrix-keypad.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/input/mt-matrix-keypad.yaml b/Documentation/devicetree/bindings/input/mt-matrix-keypad.yaml
>>> new file mode 100644
>>> index 000000000000..b52cd478f638
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/input/mt-matrix-keypad.yaml
>>> @@ -0,0 +1,134 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/input/mt-matrix-keypad.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: GPIO driven mt matrix keypad device tree bindings
>>> +
>>> +maintainers:
>>> +  - vinay <VinayKumar.Shettar@xxxxxxxxxxxx>
>>> +
>>> +description: |
>>> +  GPIO driven mt matrix keypad is used to interface a SoC with a mt matrix
>>> +  keypad. The mt matrix keypad supports multiple gpio line, all gpio line act
>>
>> s/line/lines/
> 
> modified
> 
>>> +  as row as wel as column lines, a key can be placed at each intersection
>>
>> s/wel/well/
> 
> modified
> 
>>> +  of a unique row number not equal to a unique column and they are diagonally
>>> +  symmetric.
>>> +
>>
>> What is "mt" in the "mt matrix"?
>>
> 
> mt is bosch measuring tools matrix keypad

Then it is a specific Bosch device, isn't it? If it is, you should have
vendor prefixes - to the file name and compatible. If it is not, then
"mt" is irrelevant here because it is Bosch product name.

> 
>>> +  Example- For 5 gpio lines, possible matrix is 5x5 and maximum possible
>>> +        keys are 10.
>>> +
>>> +        Sample matrix table for 7 button and 5 gpio line
>>> +
>>> +        ------------------------------------------------------
>>> +        |Row\Col |GPIO 0 | GPIO 1 | GPIO 2 | GPIO 3 | GPIO 4 |
>>> +        ------------------------------------------------------
>>> +        | GPIO 0 |  X    | KEY_9  | KEY_2  |   X    | KEY_1  |
>>> +        ------------------------------------------------------
>>> +        | GPIO 1 | KEY_9 |  X     | KEY_6  |   X    |  X     |
>>> +        ------------------------------------------------------
>>> +        | GPIO 2 | KEY_2 | KEY_6  |  X     | KEY_4  | KEY_7  |
>>> +        ------------------------------------------------------
>>> +        | GPIO 3 |  X    |  X     | KEY_4  |  X     | KEY_8  |
>>> +        ------------------------------------------------------
>>> +        | GPIO 4 | KEY_1 |  X     | KEY_7  | KEY_8  |  X     |
>>> +        ------------------------------------------------------
>>> +        X - invalid key
>>> +        KEY_x - preferred key code
>>> +
>>> +  The mt matrix keypad can sense a key-press and key-release by means of GPIO
>>> +  lines and report the event using GPIO interrupts to the cpu.
>>> +
>>> +properties:
>>> +  compatible:
>>> +    oneOf:
>>> +      - const: gpio-mt-matrix-keypad
>>> +      - items:
>>> +          - enum:
>>> +              - gpio-mt-matrix-keypad
>>> +          - const: gpio-mt-matrix-keypad
>>
>> Aren't all these compatibles the same?
> 
> modified
> 
>>> +
>>> +  debounce-delay-ms:
>>> +    description: Delay after the first bounce of button.
>>> +    default: 0
>>> +
>>> +  col-scan-delay-us:
>>> +    description: Delay before scanning next active line.
>>> +    default: 0
>>> +
>>> +  number-of-button:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description: Number of button connected to the keypad controller.
>>
>> s/button/buttons/ I presume.
> 
> modified
> 
>>> +
>>> +  linux,no-autorepeat:
>>> +    description: |
>>> +      Disable the Linux input system's autorepeat feature on the input device.
>>> +
>>> +  gpio-activelow:
>>> +    description: Gpio line are active low.
>>
>> No, GPIOs should instead use common flags.
> 
> this flag is used to compare with the gpio read value

Which is not an answer to my concerns and still a no. Just use the
flags. What's the point to code it like:
	line-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
	gpio-activelow;
?

Or even worse:
	line-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
	gpio-activelow;

With such coding, enabled is 0 or 1? Which flag is correct?

No, just use existing flags, don't duplicate standard Linux stuff.

> 
>>> +
>>> +  line-gpios:
>>> +    description: |
>>> +      Gpio lines connected to keypad controller.
>>> +      all gpio line act as row as wel as column lines.
>>> +
>>> +  linux,keymap:
>>> +    $ref: '/schemas/types.yaml#/definitions/uint32-array'
>>> +    description: |
>>> +      An array of packed 1-cell entries containing the equivalent of row,
>>> +      column and linux key-code. The 32-bit big endian cell is packed as:
>>> +          row << 24 | column << 16 | key-code
>>
>> But anyway this should be just merged into matrix-keypad. It's a simpler
>> set of that binding.
> 
> we have special keypad for Bosch measuring tools, which is not completely
> matric keypad so we have derived from matrix_kepad.c to make our keypad
> to work.

Just customize the original keypad, don't duplicate features. Again it's
not the answer to my concerns. You implement a driver for device with a
smaller set of features, so there should be no problem in merging it
into original driver (which supports more features).

Best regards,
Krzysztof