Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp2389040pxy; Tue, 3 Aug 2021 05:26:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz3GOtpmfEM4N8s+E1SObUAM561/4/sMlfXEQ2pmA2HAmA6bcuf+vK5n/eUwVUi3jgjfJV6 X-Received: by 2002:a05:6638:418f:: with SMTP id az15mr19560731jab.8.1627993608910; Tue, 03 Aug 2021 05:26:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627993608; cv=none; d=google.com; s=arc-20160816; b=jV7kU/PVFwqMMHMhGN8S75oYHE/rM6MG3i0kKQM0VORevb5Gh0H5MKxT3JVB8cPg/i hcwfQqFsoS29scwboHeA+OksZbHR1NCrfGo0pvxaCmnY+KR+NasQE1VuhThjidoZowLn fm5tDxmW9e1HaeX5HwCaEoKCuKvw+AiZ0FeuAhMeUqrB6yG4sSJQ+ZJo+YpSqVS/5GF3 mDNiF4AveH33GW6tr6W6QjCG2B4MjdL/cguVdWMHu7TkYG3toO3mdDxPW7ygLTulljgD AkQjdljN55t2xgAvFPGa/NwuXA5Or8F9DswxKFNZv4qF7k4BYdQbGBbGqvKmofPWdOee yRSA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=sSAJdBXerSiLD/jae6wSlhsV/AYk+DynXxE+wOZYVUg=; b=QrKOReP4cOL60ei5E9qPdQSAHhboBPytC+xKlah5YNDlHJJ3Zyb1fmL8pi5qSkWbfn rRcaTpDPxTfmWzlW3jtmj0xmzvl04PeKrV0gfxhvrFrfD3l3B0WV4yxbE6VeGvUjUi0k cJQW2XCqloXDxXVYJPyL2NvYBPrKeluzTUbWIuhoPIg0Qq1uPZTLUv0HR7K2NxvFYAhX 78RrBPv+20kmhN1OnBu/zqYrkRulCTcQh0PaUqh/8CZf5ZYL9lvbg3YP20WqmcL/Gqxv ppRVEGxw0RghQ+9EgV8fEwBtgs2mL5KploDXnV6Cf9qSxg5eipI48MJfuc+nWulM1B6z JeGA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ieee.org header.s=google header.b=bRVwX6iP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=ieee.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x12si14838860iom.57.2021.08.03.05.26.36; Tue, 03 Aug 2021 05:26:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ieee.org header.s=google header.b=bRVwX6iP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=ieee.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235942AbhHCMYV (ORCPT + 99 others); Tue, 3 Aug 2021 08:24:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55624 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235700AbhHCMYT (ORCPT ); Tue, 3 Aug 2021 08:24:19 -0400 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81630C0613D5 for ; Tue, 3 Aug 2021 05:24:08 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id z7so23196691iog.13 for ; Tue, 03 Aug 2021 05:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sSAJdBXerSiLD/jae6wSlhsV/AYk+DynXxE+wOZYVUg=; b=bRVwX6iPyAZEcpuyB4yiUnUe+peBOZ6yDCqxfRHK/MWWbE8extM3sSfAt80FJslR6X w7dtV2Q8CnEkU3c2O9xunDbtV6DjsudWluolBahN/iVlRWXcGhWPKHd5aioLLzH8Ee7g S4xBD5bemnxGWjWWt/Sahnh3ca8DkVBQ29A70= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sSAJdBXerSiLD/jae6wSlhsV/AYk+DynXxE+wOZYVUg=; b=BLQUyamACcfzYVqxf7JtKw2yxmwYMq9PM1vxh9RERloaiK5ppDP7NFRPB8DSA9cbDu NG2l+NemJGpztB4dl4U7a5wP43oP6ofd4gQlJHeWesEagb9TSbGHZy2wZ9f7BNqyqT8Q NJo1XUuCc+O9YpiEKXFGaK9ehT04NUdLn8PnZt4RYVWT0TptFl+k7JkymAlqPHQ5a5md T9jU5uBDjJGSJWuFDA/mx8/BADbimsRU8VjlNnCSeUahU++gQ95PuD5oBkbWkoouqPtp 9UZkG5ews/egEoQWtv9GQMta1vlXDBbzk5RntwHUi61hlmm2K09giOdun72wsqnT0zqG pSZg== X-Gm-Message-State: AOAM532JclOswOBQGC5gr0wRHs0Hv++BGZuCKpkxTIhugDe7XZ97HtN0 NsA7+bMVCBZCDmZ24xYkIu7kAnSc//ivynE1 X-Received: by 2002:a5d:9284:: with SMTP id s4mr605937iom.131.1627993447634; Tue, 03 Aug 2021 05:24:07 -0700 (PDT) Received: from [172.22.22.4] (c-73-185-129-58.hsd1.mn.comcast.net. [73.185.129.58]) by smtp.googlemail.com with ESMTPSA id k2sm6244589ior.40.2021.08.03.05.24.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 03 Aug 2021 05:24:06 -0700 (PDT) Subject: Re: [PATCH net-next 1/3] dt-bindings: net: qcom,ipa: make imem interconnect optional To: Rob Herring Cc: Alex Elder , Bjorn Andersson , "Gross, Andy" , David Miller , Jakub Kicinski , Evan Green , cpratapa@codeaurora.org, subashab@codeaurora.org, Alex Elder , linux-arm-msm , netdev , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" References: <20210719212456.3176086-1-elder@linaro.org> <20210719212456.3176086-2-elder@linaro.org> <20210723205252.GA2550230@robh.at.kernel.org> <6c1779aa-c90c-2160-f8b9-497fb8c32dc5@ieee.org> From: Alex Elder Message-ID: <8e75f8b0-5677-42b0-54fe-06e7c69f6669@ieee.org> Date: Tue, 3 Aug 2021 07:24:06 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/28/21 10:33 AM, Rob Herring wrote: > On Mon, Jul 26, 2021 at 9:59 AM Alex Elder wrote: >> >> On 7/23/21 3:52 PM, Rob Herring wrote: >>> On Mon, Jul 19, 2021 at 04:24:54PM -0500, Alex Elder wrote: >>>> On some newer SoCs, the interconnect between IPA and SoC internal >>>> memory (imem) is not used. Reflect this in the binding by moving >>>> the definition of the "imem" interconnect to the end and defining >>>> minItems to be 2 for both the interconnects and interconnect-names >>>> properties. >>>> >>>> Signed-off-by: Alex Elder >>>> --- >>>> .../devicetree/bindings/net/qcom,ipa.yaml | 18 ++++++++++-------- >>>> 1 file changed, 10 insertions(+), 8 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml >>>> index ed88ba4b94df5..4853ab7017bd9 100644 >>>> --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml >>>> +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml >>>> @@ -87,16 +87,18 @@ properties: >>>> - const: ipa-setup-ready >>>> >>>> interconnects: >>>> + minItems: 2 >>>> items: >>>> - - description: Interconnect path between IPA and main memory >>>> - - description: Interconnect path between IPA and internal memory >>>> - - description: Interconnect path between IPA and the AP subsystem >>>> + - description: Path leading to system memory >>>> + - description: Path between the AP and IPA config space >>>> + - description: Path leading to internal memory >>>> >>>> interconnect-names: >>>> + minItems: 2 >>>> items: >>>> - const: memory >>>> - - const: imem >>>> - const: config >>>> + - const: imem >>> >>> What about existing users? This will generate warnings. Doing this for >>> the 2nd item would avoid the need for .dts updates: >>> >>> - enum: [ imem, config ] In other words: interconnect-names: minItems: 2 items: - const: memory - enum: [ imem, config ] - const: imem What do I do with the "interconnects" descriptions in that case? How do I make the "interconnect-names" specified this way align with the described interconnect values? Is that necessary? >> If I understand correctly, the effect of this would be that >> the second item can either be "imem" or "config", and the third >> (if present) could only be "imem"? > > Yes for the 2nd, but the 3rd item could only be 'config'. Sorry, yes, that's what I meant. I might have misread the diff output. >> And you're saying that otherwise, existing users (the only >> one it applies to at the moment is "sdm845.dtsi") would >> produce warnings, because the interconnects are listed >> in an order different from what the binding specifies. >> >> Is that correct? > > Yes. > >> If so, what you propose suggests "imem" could be listed twice. >> It doesn't make sense, and maybe it's precluded in other ways >> so that's OK. > > Good observation. There are generic checks that the strings are unique. I think I don't like that quite as much, because that "no duplicates" rule is implied. It also avoids any confusion in the "respectively" relationship between interconnects and interconnect-names. I understand what you're suggesting though, and I would be happy to update the binding in the way you suggest. I'd like to hear what you say about my questions above before doing so. >> But I'd be happy to update "sdm845.dtsi" to >> address your concern. (Maybe that's something you would rather >> avoid?) > > Better to not change DT if you don't have to. You're probably okay if > all clients (consumers of the dtb) used names and didn't care about In the IPA driver, wherever names are specified for things in DT, names (only) are used to look them up. So I'm "probably okay." > the order. And I have no idea if all users of SDM845 are okay with a > DTB change being required. That's up to QCom maintainers. I only care > that ABI breakages are documented as such. > >> Also, I need to make a separate update to "sm8350.dtsi" because >> that was defined before I understood what I do now about the >> interconnects. It uses the wrong names, and should combine >> its first two interconnects into just one. > > If the interconnects was ignored in that case, then the change doesn't matter. That platform is not yet fully supported by the IPA driver, thus there is (so far) no instance where it is used. Resolving this is part of enabling support for that. Thanks. -Alex > Rob >