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 4B263C433FE for ; Mon, 14 Nov 2022 15:49:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236963AbiKNPtn (ORCPT ); Mon, 14 Nov 2022 10:49:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37962 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236523AbiKNPtm (ORCPT ); Mon, 14 Nov 2022 10:49:42 -0500 Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 19FDF140A4 for ; Mon, 14 Nov 2022 07:49:41 -0800 (PST) Received: by mail-lj1-x22a.google.com with SMTP id a15so13729838ljb.7 for ; Mon, 14 Nov 2022 07:49:41 -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=6wSuGB76l81gaOZPm77HZM6lioiS7r+dfc+W7xsVPIc=; b=HskIouhVyi2ue7+LEhRN1RNzMQvR2PC9gCYjtggrfbJLkrjQSaDW8HSkDC2ngq/GGY T7CvhwkLZcQEP7RHrGRISmnitfx1GOUeqhMkImP7385hiYtqtnfPuY/NtKgTeaQqK3Xe pgnx9nvuaNp7VJQmCWdEWilqgSbOoYiQaafmZWrfPz3T5RNkTyrhRLcqj8zrIUN70ITz +sC3HeCliR8IXBCJsa3SMVIofiy0Tji4L7fXbJSgzNGYnkKuJ7GwIYGgnCvLzdst8IxB U3bTqm76MPVBtBftuH8k2gpUyo6abWhlTUVle9NCp/FMZf2QYl7CRVCjNFI1i/z+XNXn GgAg== 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=6wSuGB76l81gaOZPm77HZM6lioiS7r+dfc+W7xsVPIc=; b=AS0epJqa3tcqwuvJ/5FLqoQA/opvFTigw4hkyFref4nhMlNaWe2Jzleo79OLrQgaf6 IL6hd7dst56p/HpKRwYMtiQdJPia2ALntHhVzIe6ayyTNNG8g6Q+Lg9KrX+nBOOwrPXZ szOc08hTK10SVDKE0oBeH6UhMp7s5ajC36ElcqMPlGqkGJqEaLMmfA2Vva9ZtNFsXA2A 4AAFXaQrR3SBLTBdqN2uy6fbY8qhIlMbrhT2jfQUpZ9o8Dm59dNzag1RFNJuvQA5OgrC Fj2ClMl+NQcx/ZvqBG6P/xUgWDCp4dKe9TwSCOBgBEXEmnapqs6O/ZpORejZdXVMER2Q lzvQ== X-Gm-Message-State: ANoB5plAMqJQxliBuMSf7V5p7hX+zUKiFxU9JRnYR5G84LSRlk0I7CbC UTU7scy2M36CGL9rlQq6Rzh9rg== X-Google-Smtp-Source: AA0mqf6z1dI9nYxuRJzt3DSAk7mzSPHDwCDS+Nlxum6G3BtXxkcMr8KPa73iixm4aEeEjQ4yKM8BNQ== X-Received: by 2002:a2e:460a:0:b0:26f:ab25:8a77 with SMTP id t10-20020a2e460a000000b0026fab258a77mr4098788lja.93.1668440979411; Mon, 14 Nov 2022 07:49:39 -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 e10-20020a19674a000000b0049311968ca4sm1855621lfj.261.2022.11.14.07.49.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 07:49:38 -0800 (PST) Message-ID: <02725b78-04ad-8f4a-25c2-9cdaa1e37ab7@linaro.org> Date: Mon, 14 Nov 2022 16:49:37 +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> 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 15:18, Johan Hovold wrote: > On Mon, Nov 14, 2022 at 03:07:41PM +0100, Krzysztof Kozlowski wrote: >> On 14/11/2022 14:27, Johan Hovold wrote: >>> On Fri, Nov 11, 2022 at 04:17:29PM +0100, Krzysztof Kozlowski wrote: >>>> On 11/11/2022 10:24, Johan Hovold wrote: >>>>> The current QMP USB3-DP PHY bindings are based on the original MSM8996 >>>>> binding which provided multiple PHYs per IP block and these in turn were >>>>> described by child nodes. > >>>>> + "#clock-cells": >>>>> + const: 1 >>>>> + >>>>> + clock-output-names: >>>>> + items: >>>>> + - const: usb3_pipe >>>>> + - const: dp_link >>>>> + - const: dp_vco_div >>>> >>>> Why defining here fixed names? The purpose of this field is to actually >>>> allow customizing these - at least in most cases. If these have to be >>>> fixed, then driver should just instantiate these clocks with such names, >>>> right? >>> >>> I'm only using these names as documentation of the indexes. The driver >> >> What do you mean by documentation of indexes? You require these specific >> entries and do not allow anything else. > > I'm using this property as documentation of the valid indexes that can > be used when referring to clocks provided by this device. > > There are currently three and the mapping is described by the > 'clock-output-names' property. That's not the purpose of this property. Drop it then. The names do not define the ABI and do not document it, actually. You require now that every DTB, if providing clock-output-names, will have exactly such names instead of having fixed IDs. DTBs are not for defining the ABI. > >>> doesn't use these names, but that's a Linux-specific implementation >>> detail. >>> >>> I noticed that several bindings leave the clock indexes unspecified, or >>> have header files defining some or all of them. I first added a QMP >>> header but that seemed like overkill, especially if we'd end up with >>> one header per SoC (cf. the GCC headers) due to (known and potential) >>> platform differences. >> >> Headers for the names? I do not recall such but that does not seem right. > > Headers for the indexes. > >>> >>> On the other hand reproducing this list in each node is admittedly a bit >>> redundant. >>> >>> Shall I add back a shared header for all PHYs handled by this driver >>> (another implementation detail) even if this could eventually lead to >>> describing clocks not supported by a particular SoC (so such constraints >>> would still need to be described by the binding somehow): >>> >>> /* QMP clocks */ >>> #define QMP_USB3_PIPE_CLK 0 >>> #define QMP_DP_LINK_CLK 1 >>> #define QMP_DP_VCO_DIV_CLK 2 >> >> What are these about? To remind - we talk about names of clocks this >> device creates. The output names. Whatever IDs you have are not related >> to the names. > > As I mentioned above, this is not about the names that Linux gives to > its representation of these clocks. Its just about defining the valid > indexes in the binding. With or without the header, the IDs are part of ABI and are fixed. The headers are I think always encouraged because it makes above sentence explicit. Without the headers developers might want to change the IDs. > > If you think that that using 'clock-output-names' for this is a bit too > unconventional, I can add back the header with defines like the above > instead. > > Note that the clock schema has: > > clock-output-names: > description: | > Recommended to be a list of strings of clock output signal > names indexed by the first cell in the clock specifier. Exactly. Not to describe the ABI behind the ID. > However, the meaning of clock-output-names is domain > specific to the clock provider, ... ... because you might have more cells. Just because clock-output-names do not fit some drivers it does not mean you can use it any way you wish. It is still for names of provided clocks. Best regards, Krzysztof