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 95BDAC4167B for ; Tue, 29 Nov 2022 08:58:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230011AbiK2I6E (ORCPT ); Tue, 29 Nov 2022 03:58:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231462AbiK2I6D (ORCPT ); Tue, 29 Nov 2022 03:58:03 -0500 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBAD21401C for ; Tue, 29 Nov 2022 00:57:59 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id j16so21398667lfe.12 for ; Tue, 29 Nov 2022 00:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=y3Xm8CTKI5pFBGHRduIfFpNiMz/YnZAtfkESDIfrZHU=; b=yAEQ0f7iiBFFT3zCiQNjmihHx5xLZxE6k/IeeXvqExp+xO+DPBKaqaxdKRPjwqjvfm LGiE/88+2dA8GBPDfU5fAaQ3Z/xIyM/1Q2wHRirgQvn4TyBIra65cSP5Se2/qbjCoKGc 1Hq557jg8voTc6j/UzZluOPwaXmy4GBopEX26WAIH5FqPhTqu9nz80AjXLac3MJp2C5g 10UfdNS/tnkujmQa2TuxvMMrc4swPsf08zlfgj/5oJCSrM8Yrtf/hnZWZFPGy9NRTOg/ 5H+ub/cqzstKJ9vwyX2QUwyFk6bzIK3YPyrSpYuCCEjZonNp91Y4cV2sIkrx4I/gpKTj /OMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=y3Xm8CTKI5pFBGHRduIfFpNiMz/YnZAtfkESDIfrZHU=; b=cC4Yfrpb0HQag+tCvSYp8fTpZIwKWP2EiyxD7HjmizlpHwyrqzgke0yxFZmzKOOVyo pBEq650uoiQ/y2cv2NipLB8gW3movY5Eqe3Rwq/paChLN55X8/Au2r/XibpLOp4ksblY Xf6tlbxDiSsOXOg5zaj2OUd24FUcsmUamCSts0O/EZm2rpUBUs+NFwba+pJJNYB/JOcf iZT6lzmcqs16/WwWC/Cmo1R2KKdAVzJqqmv1CqcnrzbRas1JChQ2mOmZuQrmKV8Z47gu 0UsUp34DZmcmhIdTUOrzEPBsQv7lNoRGCRd02szSumglugjDGbh7Ix7kdwnJZxun/zfK Ko9Q== X-Gm-Message-State: ANoB5pltOrDTyLjhVq9F9k+cUMwrO27rvl6j28yi3PgkFakZQVQeaUmp CrigMqvNzwZhqpQ+3ywDmJEntA== X-Google-Smtp-Source: AA0mqf4sCi5zsBb8QGQDZbosFwGoYJsQ5RMSlu7aY+oTQbrbtNWy43Z7xsQZ8C1sktxc1yAoujDyww== X-Received: by 2002:ac2:4919:0:b0:4b5:33d:1215 with SMTP id n25-20020ac24919000000b004b5033d1215mr6449072lfi.419.1669712278173; Tue, 29 Nov 2022 00:57:58 -0800 (PST) Received: from [192.168.0.20] (088156142067.dynamic-2-waw-k-3-2-0.vectranet.pl. [88.156.142.67]) by smtp.gmail.com with ESMTPSA id c13-20020a056512238d00b0049ebc44994fsm2140144lfv.128.2022.11.29.00.57.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Nov 2022 00:57:57 -0800 (PST) Message-ID: <79651cf2-7efd-b54c-65a0-8986cea071d5@linaro.org> Date: Tue, 29 Nov 2022 09:57:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH v6 05/10] dt-bindings: soc: mediatek: convert pwrap documentation Content-Language: en-US To: Alexandre Mergnat Cc: Krzysztof Kozlowski , Sean Wang , Rob Herring , Matthias Brugger , Chen Zhong , Fabien Parent , Alessandro Zummo , Mark Brown , Alexandre Belloni , Flora Fu , Tianping Fang , Pavel Machek , Lee Jones , Liam Girdwood , Dmitry Torokhov , Mattijs Korpershoek , Rob Herring , AngeloGioacchino Del Regno , linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org, Fabien Parent , linux-input@vger.kernel.org, devicetree@vger.kernel.org, linux-leds@vger.kernel.org References: <20221005-mt6357-support-v6-0-4f589756befa@baylibre.com> <20221005-mt6357-support-v6-5-4f589756befa@baylibre.com> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-input@vger.kernel.org On 28/11/2022 15:03, Alexandre Mergnat wrote: > >>>> +allOf: >>>> + - if: >>>> + properties: >>>> + compatible: >>>> + contains: >>>> + const: mediatek,mt8365-pwrap >>>> + then: >>>> + properties: >>>> + clocks: >>>> + minItems: 4 >>>> + >>>> + clock-names: >>>> + minItems: 4 >>> >>> else: >>> ??? >> >> Actually this looks less complete than your previous patch. >> >> else: >> clocks: >> maxItems: 2 >> same for clock-names >> > > I think I’ve followed the feedback done here [1] > I’ve declared `minItems: 2` globally and override it to 4 if > mediatek,mt8365-pwrap is used. Isn’t it the right way to implement it > ? Yes, just the other part of comment is missing: "If you really want to force a validation error when using mediatek,mt8365-pwrap and not providing `sys` and `tmr` clocks, you can just override minItems." but that's fine if this was your intention. > >>>> + compatible = "mediatek,mt8135-pwrap"; >>>> + reg = <0 0x1000f000 0 0x1000>, >>> >>> This does not match your unit address. No warnings when compile testing? >>> > > There are no warnings when compile testing. I will fix the unit > address anyway, sorry. > >>>> + <0 0x11017000 0 0x1000>; >>>> + reg-names = "pwrap", "pwrap-bridge"; >>>> + interrupts = ; >>>> + clocks = <&clk26m>, <&clk26m>; >>>> + clock-names = "spi", "wrap"; >>>> + resets = <&infracfg MT8135_INFRA_PMIC_WRAP_RST>, >>>> + <&pericfg MT8135_PERI_PWRAP_BRIDGE_SW_RST>; >>>> + reset-names = "pwrap", "pwrap-bridge"; >>> >>> Missing pmic. Make your example complete. >> >> Probably pmic should be skipped, I understand it is described in MFD >> binding. >> > > Put the pmic in the example have 2 constraints: > - The original pmic "mediatek,mt6397" isn’t supported by a yaml > schema, so I’ve a dt_binding_check fail: `failed to match any schema > with compatible: ['mediatek,mt6397']` > - If I put another pmic that supports a yaml schema, I need to put all > required properties for the pmic, which I thought was unnecessary > since it’s already done in its own schema and can change for another > pmic, so less consistent. > > Then yes, IMHO, PMIC should be skipped in the example. Yes, you're right. Best regards, Krzysztof