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 DE17FC433EF for ; Sat, 21 May 2022 14:33:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355230AbiEUOdO (ORCPT ); Sat, 21 May 2022 10:33:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59758 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1355225AbiEUOdM (ORCPT ); Sat, 21 May 2022 10:33:12 -0400 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0CF6F5FF1D for ; Sat, 21 May 2022 07:33:10 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id bu29so18763531lfb.0 for ; Sat, 21 May 2022 07:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=Hn1tpaExx4W+/e0w4YZThPk8OvIZPTL/mPjUx1/h2t4=; b=cKZtkaIjNKIn8y6S+OXauTN4MPMFZ8458LigpDSBhWV76hYXxYBdqHWjYYzTFz9gzK 9J8yEJ9NsTW4U0FxzdG4RKJr4DMj81BSBvuJgKyYZ77lvujT3ufH15rxd+/L8KtBb5le LeQSrU494fo6TMGAJQOP2cTf+5AIZ6EO/EIzZIRIpF5Lpp8/AwKlx79/PRfwcHw93UrB kr/NZdnBb0ysyfY96bSS0k4xXjPormKhzj5JKYhy/rspkqFDzHc4Cnr8TVt0YDItzc+o 9Rd63W88lrb2ERvIb9uW6v5IKs0EmuW2S+GdliJIqeuQzRlG1AI9rtaxLb4F2rwojlAm Vlcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=Hn1tpaExx4W+/e0w4YZThPk8OvIZPTL/mPjUx1/h2t4=; b=mb2RsedUafHhUCGsa9OvAxNAe0V1ESM2BLHC+qRbro0LjQ9H35nMN3Oa4m3sKJ2/9j kTaNccCFzZvYt8VUtUKgizpy6Y8WL3rJJSmuNA4bGjAADLPeLowQDHzG4ObxZZrzo0B+ d266k1j9l2k5QWCV3zIE66QijXfFD3UeBbkNvX55QUZM86f/K7eRinbSfxxTkeLqe9Gz U8ZlS278+ZpE2X+3MSJurRY2LGc9dEh3e72CJSrptjpun4F4quxOIiBKMCeWs1WbWMM8 UKALjzcx5uyQr82/A1ATl9CmNsDA/k3HQCPNltmj9IxZHNoNaRUVeoqekViLrgHLjAvX NRYQ== X-Gm-Message-State: AOAM532n8yZLTTJ3ip56JdouJEKduQ1zEzm5xgA4ThVmFHEH8D5sZ2xQ uZBYkXj8mk3sXB5a5DuFnoQOig== X-Google-Smtp-Source: ABdhPJyx6Mwjo8UHnCdnLrCqjRw6qNRdRwXtYGACm3ClOhYNuNa7LoKqXYd5gtbZXBA3V855VgXOlQ== X-Received: by 2002:a05:6512:ad2:b0:478:623e:ca73 with SMTP id n18-20020a0565120ad200b00478623eca73mr1771941lfu.290.1653143588422; Sat, 21 May 2022 07:33:08 -0700 (PDT) Received: from [192.168.0.17] (78-11-189-27.static.ip.netia.com.pl. [78.11.189.27]) by smtp.gmail.com with ESMTPSA id s25-20020a2e81d9000000b00253bb2564cbsm726024ljg.134.2022.05.21.07.33.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 May 2022 07:33:07 -0700 (PDT) Message-ID: <2a7ff8d1-9ef8-af6c-e541-80417aba7782@linaro.org> Date: Sat, 21 May 2022 16:33:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v4 2/3] dt-bindings: remoteproc: qcom: Convert SC7280 MSS bindings to YAML Content-Language: en-US To: Sibi Sankar , Stephen Boyd , bjorn.andersson@linaro.org, krzysztof.kozlowski+dt@linaro.org, robh+dt@kernel.org Cc: ohad@wizery.com, agross@kernel.org, mathieu.poirier@linaro.org, linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, mka@chromium.org References: <1652978825-5304-1-git-send-email-quic_sibis@quicinc.com> <1652978825-5304-3-git-send-email-quic_sibis@quicinc.com> <1289c2e4-5607-b515-88b1-f44585e62cd3@quicinc.com> From: Krzysztof Kozlowski In-Reply-To: <1289c2e4-5607-b515-88b1-f44585e62cd3@quicinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org On 20/05/2022 20:46, Sibi Sankar wrote: >>> + memory-region: >>> + maxItems: 2 >>> + description: Phandle reference to the reserved-memory for the MBA region followed >>> + by the modem region. >>> + >>> + firmware-name: >>> + $ref: /schemas/types.yaml#/definitions/string-array >>> + maxItems: 2 >> >> Instead of maxItems can this be >> >> items: >> - description: Name of MBA firmware >> - description: Name of modem firmware >> >> so that we know the order? Same for 'memory-region' above. > > ack > >> >>> + description: >>> + The name of the MBA and modem firmware to be loaded for this remote processor. >>> + >>> + qcom,halt-regs: >>> + $ref: /schemas/types.yaml#/definitions/phandle-array >> >> Should this have maxItems: 1? Or that's implicit from description? > > It's implicit! I am not aware of such implicit rule in schema. maxItems are always required. If this is maxItems:1 it is not even an array. > >> >>> + description: >>> + Phandle reference to a syscon representing TCSR followed by the >>> + four offsets within syscon for q6, modem, nc and vq6 halt registers. >>> + >>> + qcom,ext-regs: >>> + $ref: /schemas/types.yaml#/definitions/phandle-array >> >> Should this have min/maxItems: 2? > > ack You should also define the items. This applies to all such fields. Check the examples of syscon consumers. > >> >>> + description: >>> + Two phandle references to syscons representing TCSR_REG and TCSR register >>> + space followed by the two offsets within the syscon to force_clk_en/rscc_disable >>> + and axim1_clk_off/crypto_clk_off registers respectively. >>> + >>> + qcom,qaccept-regs: >>> + $ref: /schemas/types.yaml#/definitions/phandle-array >>> + description: >>> + Phandle reference to a syscon representing TCSR followed by the >>> + three offsets within syscon for mdm, cx and axi qaccept registers. >>> + >>> + qcom,qmp: >>> + $ref: /schemas/types.yaml#/definitions/phandle >>> + description: Reference to the AOSS side-channel message RAM. >>> + >>> + qcom,smem-states: >>> + $ref: /schemas/types.yaml#/definitions/phandle-array >>> + description: States used by the AP to signal the Hexagon core >>> + items: >>> + - description: Stop the modem >> >> This one did items for a phandle array so I think we should follow the >> same above. > > ack > >> >>> + >>> + qcom,smem-state-names: >>> + description: The names of the state bits used for SMP2P output >>> + const: stop >>> + >>> + glink-edge: >>> + $ref: qcom,glink-edge.yaml# >>> + description: >>> + Qualcomm G-Link subnode which represents communication edge, channels >>> + and devices related to the DSP. >> [..] >>> + power-domain-names = "cx", "mss"; >>> + >>> + memory-region = <&mba_mem>, <&mpss_mem>; >>> + >>> + qcom,qmp = <&aoss_qmp>; >>> + >>> + qcom,smem-states = <&modem_smp2p_out 0>; >>> + qcom,smem-state-names = "stop"; >>> + >>> + resets = <&aoss_reset AOSS_CC_MSS_RESTART>, >>> + <&pdc_reset PDC_MODEM_SYNC_RESET>; >>> + reset-names = "mss_restart", "pdc_reset"; >>> + >>> + qcom,halt-regs = <&tcsr_mutex 0x23000 0x25000 0x28000 0x33000>; >>> + qcom,ext-regs = <&tcsr 0x10000 0x10004 &tcsr_mutex 0x26004 0x26008>; >> >> Because it's two items I'd expect: >> >> <&tcsr 0x10000 0x10004>, <&tcsr_mutex 0x26004 0x26008>; > > I guess both the ways work since the driver uses > of_parse_phandle_with_fixed_args. But only one is correct... Best regards, Krzysztof