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 EB9F5C4167D for ; Mon, 14 Nov 2022 16:50:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237150AbiKNQup (ORCPT ); Mon, 14 Nov 2022 11:50:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237813AbiKNQu0 (ORCPT ); Mon, 14 Nov 2022 11:50:26 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 09F3F3F06A; Mon, 14 Nov 2022 08:49:15 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B054BB8109E; Mon, 14 Nov 2022 16:49:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E2CCC433D6; Mon, 14 Nov 2022 16:49:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668444552; bh=LuJxQ9ZanWwnw6gRktwMAxkqB/xkzJBmxo3YkByYA9w=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ceHRkkVHhXHdYIA5qM3TOM53J0yknkuAm0/hqLxZTaEEg7wILiap84KIy08zO+IqN WRpfRlwc23A7NxuimodBlrgbL58XAk/YjRN269HxMKl0Ekg7iXs1efW1GSd7qZXYSd 5jdg6nthpl+hAAyykmMdUAaPzE/mOI5KV8wKLXwW4MeBWo1F2MD3kjM+dik+l5df2F bFQ/EmKVmd/rTDSXTAUenNoOGaq4TiOPFVs4/7UAjw7n4HPfu2ZyGqsAO9agkvAESY PNp1nW1iVj3mHemhWa3sMLmQtoAQNQs3r+2QpOMxh2A1+z002TmPI+MlUc/Q740YZ3 FgEOVC0+2fPfQ== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1oucdT-0005EO-Oy; Mon, 14 Nov 2022 17:48:40 +0100 Date: Mon, 14 Nov 2022 17:48:39 +0100 From: Johan Hovold To: Krzysztof Kozlowski 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 Subject: Re: [PATCH 02/14] dt-bindings: phy: qcom,qmp-usb3-dp: fix sc8280xp bindings Message-ID: References: <20221111092457.10546-1-johan+linaro@kernel.org> <20221111092457.10546-3-johan+linaro@kernel.org> <02725b78-04ad-8f4a-25c2-9cdaa1e37ab7@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > 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). Johan