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 66F3AC4332F for ; Mon, 14 Nov 2022 16:57:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236810AbiKNQ5b (ORCPT ); Mon, 14 Nov 2022 11:57:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238181AbiKNQ5B (ORCPT ); Mon, 14 Nov 2022 11:57:01 -0500 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 0681E2F64F for ; Mon, 14 Nov 2022 08:56:25 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id g7so20299242lfv.5 for ; Mon, 14 Nov 2022 08:56:24 -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=Y58GC68qONNsMENmg/gVzchuwfipMrSIXXvNyA3gkbg=; b=erS66v2Lwbd/Bxw+cRVGXpnK35dtxrMBXRB+gqK+ylQztNcHOO9KdsKrDgfgjZcEX+ ouaZTMB5YfsbyHkyDGm6jELbRu5So6/39tYq+IF6XHddJfI5TTmJ4z6iAg8DVsHMGfl0 HaJS/gZBtc22idWiPmbWpoymiy/5C7d267VVNe/NDMKjydsr3ooRdpDux5wD1rFsajuf 7siXOYyiajlxTPPIFiuXXDqe/6sddtRVNlm3w3MN/yBBk+Bcfsh4/TSgWH0yt5p50G56 2ymTpYLIj7UDHMugg/DMFidpg2JVq3pWUw/KNzYlaCzSBmeDP7NsY+xy/0oLaJSQmZxz U4vA== 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=Y58GC68qONNsMENmg/gVzchuwfipMrSIXXvNyA3gkbg=; b=N/EMb/8sDXJ3Uufmj60zAzYbI/9kDK4L7HU8taCndIUxunJPaWbboYy9oWhHJiriJh yuQ/RwDbTAcESMlPYr848JRjCnD7rO4RCAQAni/Z+zKg5UyxarO2N2+uthyuSfOWxpnB BmNpEiCMMZ0aDPTBqhULGMrx0mDFI14bLg4+mwpX1fHlZr4OZ1qPtCaBqa5KaL83MMh1 wecPdQ+4SzKlhlc2+sWDK69yWbnKaE9zedxTVWHoKvlTBaBflMADLOC4/ax3I8xOcOY5 eQcF8J4ApsQfrqnAjusWsUT730HCalyvNgtCJ46/rSKvKjEbob7MzU8rQDfp+w27f2BN A5zw== X-Gm-Message-State: ANoB5pnERuEy6gSZ84dAItLm7btsEwiMwYjiKAeCjNfhvAJZf+pMk5Fa Hx0GqWk8P1Yobo/X0oo2SJDwiQ== X-Google-Smtp-Source: AA0mqf6nd4/xXmES0TovIm34CZ9x5BlOLPTUbu60+ZDPXCjvtXdVhANJep/PDnB+Ud+HWFXHnhLUzQ== X-Received: by 2002:a05:6512:3414:b0:4a2:2b23:f17f with SMTP id i20-20020a056512341400b004a22b23f17fmr4121950lfr.688.1668444983295; Mon, 14 Nov 2022 08:56:23 -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 q3-20020a19f203000000b00493014c3d7csm1882169lfh.309.2022.11.14.08.56.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 08:56:22 -0800 (PST) Message-ID: <8420c342-9dce-aea7-8d1e-f141e0c1ebb5@linaro.org> Date: Mon, 14 Nov 2022 17:56:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH 02/14] dt-bindings: phy: qcom,qmp-usb3-dp: fix sc8280xp bindings Content-Language: en-US To: Johan Hovold Cc: Johan Hovold , Vinod Koul , Andy Gross , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Dmitry Baryshkov , linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20221111092457.10546-1-johan+linaro@kernel.org> <20221111092457.10546-3-johan+linaro@kernel.org> <02725b78-04ad-8f4a-25c2-9cdaa1e37ab7@linaro.org> From: Krzysztof Kozlowski In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 14/11/2022 17:48, Johan Hovold wrote: > On Mon, Nov 14, 2022 at 05:39:26PM +0100, Krzysztof Kozlowski wrote: >> On 14/11/2022 17:32, Johan Hovold wrote: > >>> Fair enough, I'll drop it. But there doesn't seem to be a good way to >>> describe the indexes currently and most bindings simply ignore to do so. >>> >>> So what is the preference then? Just leave things undocumented, listing >>> indexes in a free-text 'description', or adding a free-text reference to >>> a binding header file and using those define names in a free-text >>> 'description'? >> >> Either 2 or 3. Several bindings for small number of constants choose >> option 2. > > Ok, we have three now, but USB4 will bump this to ten or so. Then probably header file is the way to go. > >>> And if going with the last option, does this mean that every SoC and PHY >>> type needs its own header for those three clocks or so to avoid having >>> a common dumping ground header file where indexes will not necessarily >>> be 0-based and consecutive. >> >> phy-qcom-qmp-combo.c has one qcom_qmp_dp_clks_hw_get(), so why would you >> have many of header files? > > We don't know what kind of clock outputs later revisions of these PHYs > will have. The only way to guarantee 0-based consecutive indexes appears > to be to use per-SoC defines (e.g. as for the GCC bindings). Which is also fine. I don't understand still why it is a problem - even if you have multiple files, one for each SoC/phy. If USB4 brings here 10 more clocks and other SoCs/phys might bring many more options, then what else can you do? Grow the binding file with big text-based mapping of IDs? It's not a viable solution. Header or headers is the only maintainable way for such cases. Best regards, Krzysztof