From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F1E44C43334 for ; Thu, 21 Jul 2022 13:11:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234016AbiGUNLd (ORCPT ); Thu, 21 Jul 2022 09:11:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49082 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233931AbiGUNLa (ORCPT ); Thu, 21 Jul 2022 09:11:30 -0400 Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4409C28E2B for ; Thu, 21 Jul 2022 06:11:24 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id d8so2211793wrp.6 for ; Thu, 21 Jul 2022 06:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=2GDU2IRydfXQkfqrUDMU1D/n3Z3JpQ7CUV8m7kZHOXo=; b=zM6uqqJD0zUpxrXvqvUJTtgzK7C8wI0w7+NobGNxJFW/oU2rftvyIufnMzzsksbQfo UPL6bIwDPZSX2erGUifThY2H1sG1qGDQM31W5Umj8L55JPcbgUJ+cO+aXCfAaeSJxRc3 myUrxdjxtk9d5svXSSZra335QyPA3OCo5I+I3Hnp+g+6il7yE8imHH9KCq0lfrM3YMEg HRzpljYsgy8TtyJV8zSBIpAxN9W5F+b4p9vLrSp75U1Jufzo1WbGPolvsp4cUx6Pn5cD DsCs0sYDiem6ZuqbEt1ZrQFRxc5RhdUk5wrtjJo5b9rf5hw4s7m0p7UieJO7pPFlbwCz wHng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=2GDU2IRydfXQkfqrUDMU1D/n3Z3JpQ7CUV8m7kZHOXo=; b=hwktCXyZdXXl6uYzwaYSUH1ekUQ+4B0Lmc9GSDZ06uBUVpO7aztSF75yTtbDicpXUg ktw0/uWIftighTWljNGrs8UEtU8NXMNMrZnTl2o7joPl7gGOznAji4YOF0jhVIhWkMFf QBNRFXgqD+SkcmDflo2OpH+/KzlHaGW1cW7xcfDI9e3lBQkAj3Q+hZZ1aF0X5qnSU6GV rfXWLttkMrfgzyoRTwDNj7kdQxlu9LjKsJ6fE/WRpP9gaDRVetpo6hEOL0TXCcGcRg31 SWTMjzId2rBDKLD0YtGEH8AOgsn2tfZ9iECaLrkP11JhZqIEUUO5I/ABgK2Mq4cKQw0G L6Yg== X-Gm-Message-State: AJIora/h6yN3PVvg4O7FgZDCUL38QAwBte3lT3hzcoOBJ/1YWcr6BQXn vG+86+VbAQ67ckUH7ryYuuKEiA== X-Google-Smtp-Source: AGRyM1vMWJglV7kWdNrjYZOUhLc5gsJSA6p5P1/egh9annTDsloDA+h8irZ0fOR8tFshFQMxXCNoOQ== X-Received: by 2002:a05:6000:1d9c:b0:21e:4a6d:664d with SMTP id bk28-20020a0560001d9c00b0021e4a6d664dmr6415826wrb.673.1658409082764; Thu, 21 Jul 2022 06:11:22 -0700 (PDT) Received: from localhost ([82.66.159.240]) by smtp.gmail.com with ESMTPSA id l37-20020a05600c1d2500b003a33227e49bsm1635651wms.4.2022.07.21.06.11.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 06:11:22 -0700 (PDT) From: Mattijs Korpershoek To: Krzysztof Kozlowski , Rob Herring , Krzysztof Kozlowski , Dmitry Torokhov , Matthias Brugger Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, Fabien Parent , devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org, Fabien Parent , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1 2/6] dt-bindings: mediatek,mt6779-keypad: use unevaluatedProperties In-Reply-To: <734ed3cf-1461-6067-e718-663ca4be47a6@linaro.org> References: <20220720-mt8183-keypad-v1-0-ef9fc29dbff4@baylibre.com> <20220720-mt8183-keypad-v1-2-ef9fc29dbff4@baylibre.com> <874jzaj0m5.fsf@baylibre.com> <734ed3cf-1461-6067-e718-663ca4be47a6@linaro.org> Date: Thu, 21 Jul 2022 15:11:21 +0200 Message-ID: <87tu7ahapy.fsf@baylibre.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org On Thu, Jul 21, 2022 at 11:16, Krzysztof Kozlowski wrote: > On 21/07/2022 11:06, Mattijs Korpershoek wrote: >> On Wed, Jul 20, 2022 at 19:14, Krzysztof Kozlowski 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 > Better to mention the device, not driver. I mixed up driver versus device (hardware). Sorry about that. For successful key detection, the hardware (called MediaTek keypad) requires that we program rows/columns via the KP_SEL register. So num-rows and num-cols are valid properties for this device. The MediaTek keypad has a set of bits representing keys, from KEY0 to KEY77. These keys are organized in a 8x8 hardware matrix. Therefore, linux,keymap is also a valid property for this device. > >> >> 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. >> > SoC DTSI should have only SoC properties. The keyboard module is part of > SoC. The keys and how it is wired to them - not. Indeed. So the split I send in v1 is "valid", from a device(hardware) point of view. In that case i'll not make the properties from matrix-keymap.yaml *required* in v2. Thanks again for your feedback. Mattijs > > Best regards, > Krzysztof From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 89998C433EF for ; Thu, 21 Jul 2022 13:28:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-ID:Date:References :In-Reply-To:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=2UigKp5Vo/+Nx4Mv3DoYMQrbN2UE5BicVmr1t+qVylM=; b=kX0sJmR793pjFu 6OEBQf5bnhLP/V0szxdWQVPFAa7du+iBHDOxu17SlODp6E1sH9u76x26Ahpk/MqcLohmJeCQ3TmXR Q4G75rfEdG4BmDGO62dLaZTlngRQWRKNvBkXfgug2Yznvd39v2ROCWOGimBy0yiHgrF5ZLyjgW27S yMfhQf5AbcyQ7AiBQmHVzfBQ0I/6PnV8KQPmLmqcxMZgCqK4KmjXP+zrwI23199kpPnMHao3ZIjhK ta0Bf8yvjlyCARfj1azum67hEjeb33aT0V8AMcBbIhzou5xDpqe5TdJ72m8bW8tQ2BsA/FZiinoln PL/bwyvXPqOTdq6REsOQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEWDI-0071Cy-EH; Thu, 21 Jul 2022 13:27:36 +0000 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEVxd-006oNI-DI for linux-arm-kernel@lists.infradead.org; Thu, 21 Jul 2022 13:11:30 +0000 Received: by mail-wr1-x42e.google.com with SMTP id a5so2183297wrx.12 for ; Thu, 21 Jul 2022 06:11:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=2GDU2IRydfXQkfqrUDMU1D/n3Z3JpQ7CUV8m7kZHOXo=; b=zM6uqqJD0zUpxrXvqvUJTtgzK7C8wI0w7+NobGNxJFW/oU2rftvyIufnMzzsksbQfo UPL6bIwDPZSX2erGUifThY2H1sG1qGDQM31W5Umj8L55JPcbgUJ+cO+aXCfAaeSJxRc3 myUrxdjxtk9d5svXSSZra335QyPA3OCo5I+I3Hnp+g+6il7yE8imHH9KCq0lfrM3YMEg HRzpljYsgy8TtyJV8zSBIpAxN9W5F+b4p9vLrSp75U1Jufzo1WbGPolvsp4cUx6Pn5cD DsCs0sYDiem6ZuqbEt1ZrQFRxc5RhdUk5wrtjJo5b9rf5hw4s7m0p7UieJO7pPFlbwCz wHng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=2GDU2IRydfXQkfqrUDMU1D/n3Z3JpQ7CUV8m7kZHOXo=; b=GCLe/ZluYM1zIJb6qduXZDQSslGQVHgS43ZHnV6IFwL/CP0kzV9drSG/TptRDa3Eq3 NxT4H6fUSyxQMb35C9RIvf1Byhl1QV3N6Um42FXvFot+qD01b48JX6cZsJm4HcvnktZ+ ewSY/vFPHBWh6iIR5hJluaXqSKKiEb+TrXodhZW0DuHQLK/Jf+MYlprrDUKJFmCfQhDH mElN8GtIx6HAHWpJhfEOXh/PIwhVKIyaZ9poyao0RNqKP09oEi7+F50lzfNhjPWNSJzX m/wtNltM0p0y4w5npLQp181xENnYqNGEXYI6eEKrd7t27dEhE2jPR3+Unq5i+6ODBIdB +rmw== X-Gm-Message-State: AJIora8ErzEIlFNS1L6tgHIG0eGb9GXFsUdygsR6WzgNuOwQLVnxoj0t vzmNAf5mdSwz6IkWqFChr1nlcxugsqsTyA== X-Google-Smtp-Source: AGRyM1vMWJglV7kWdNrjYZOUhLc5gsJSA6p5P1/egh9annTDsloDA+h8irZ0fOR8tFshFQMxXCNoOQ== X-Received: by 2002:a05:6000:1d9c:b0:21e:4a6d:664d with SMTP id bk28-20020a0560001d9c00b0021e4a6d664dmr6415826wrb.673.1658409082764; Thu, 21 Jul 2022 06:11:22 -0700 (PDT) Received: from localhost ([82.66.159.240]) by smtp.gmail.com with ESMTPSA id l37-20020a05600c1d2500b003a33227e49bsm1635651wms.4.2022.07.21.06.11.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jul 2022 06:11:22 -0700 (PDT) From: Mattijs Korpershoek To: Krzysztof Kozlowski , Rob Herring , Krzysztof Kozlowski , Dmitry Torokhov , Matthias Brugger Cc: linux-kernel@vger.kernel.org, linux-input@vger.kernel.org, Fabien Parent , devicetree@vger.kernel.org, linux-mediatek@lists.infradead.org, Fabien Parent , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v1 2/6] dt-bindings: mediatek,mt6779-keypad: use unevaluatedProperties In-Reply-To: <734ed3cf-1461-6067-e718-663ca4be47a6@linaro.org> References: <20220720-mt8183-keypad-v1-0-ef9fc29dbff4@baylibre.com> <20220720-mt8183-keypad-v1-2-ef9fc29dbff4@baylibre.com> <874jzaj0m5.fsf@baylibre.com> <734ed3cf-1461-6067-e718-663ca4be47a6@linaro.org> Date: Thu, 21 Jul 2022 15:11:21 +0200 Message-ID: <87tu7ahapy.fsf@baylibre.com> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220721_061125_730769_93CF7BC5 X-CRM114-Status: GOOD ( 19.28 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jul 21, 2022 at 11:16, Krzysztof Kozlowski wrote: > On 21/07/2022 11:06, Mattijs Korpershoek wrote: >> On Wed, Jul 20, 2022 at 19:14, Krzysztof Kozlowski 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 > Better to mention the device, not driver. I mixed up driver versus device (hardware). Sorry about that. For successful key detection, the hardware (called MediaTek keypad) requires that we program rows/columns via the KP_SEL register. So num-rows and num-cols are valid properties for this device. The MediaTek keypad has a set of bits representing keys, from KEY0 to KEY77. These keys are organized in a 8x8 hardware matrix. Therefore, linux,keymap is also a valid property for this device. > >> >> 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. >> > SoC DTSI should have only SoC properties. The keyboard module is part of > SoC. The keys and how it is wired to them - not. Indeed. So the split I send in v1 is "valid", from a device(hardware) point of view. In that case i'll not make the properties from matrix-keymap.yaml *required* in v2. Thanks again for your feedback. Mattijs > > Best regards, > Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel