On Wed, Jul 20, 2022 at 19:14, Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > On 20/07/2022 16:48, Mattijs Korpershoek wrote: >> writing-bindings.rst states: >>> - If schema includes other schema (e.g. /schemas/i2c/i2c-controller.yaml) use >>> "unevaluatedProperties:false". In other cases, usually use >>> "additionalProperties:false". >> >> mt6779-keypad includes matrix-keymap.yaml so replace additionalProperties:false >> by unevaluatedProperties:false. > > This is not sufficient explanation. You now allow all properties from > matrix-keymap.yaml, which might be desired or might be not (e.g. they > are not valid for this device). Please investigate it and mention the > outcome. Hi Krzysztof, Thank you for your prompt review. In mt6779_keypad_pdrv_probe(), we call * matrix_keypad_parse_properties() which requires keypad,num-rows and keypad,num-cols. * matrix_keypad_build_keymap() which uses linux,keymap Therefore, all properties from matrix-keymap.yaml are required by the mt6779-keypad driver. In v2, I will add the above justification and also add all 3 properties in the "required" list. Initially, I did not do this because from a dts/code perspective it seemed interesting to split out SoC specific keyboard node vs board specific key configuration: * [PATCH v1 5/6] arm64: dts: mediatek: mt8183: add keyboard node # SoC specific * [PATCH v1 6/6] arm64: dts: mediatek: mt8183-pumpkin: add keypad support # board specific What would be the recommend approach for above? I see at least 2: * "move the whole keyboard node into the board file (mt8183-pumpkin.dts)" even if it generates duplication between boards using the same SoC. * "add a "dummy keymap,row,cols" properties in the soc node which can be overriden in board file. For example, use rows and cols = 0 which would have the driver early exit. Thanks, Mattijs > > Best regards, > Krzysztof
