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 15049C43219 for ; Mon, 14 Nov 2022 16:22:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237471AbiKNQWk (ORCPT ); Mon, 14 Nov 2022 11:22:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56966 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237472AbiKNQWb (ORCPT ); Mon, 14 Nov 2022 11:22:31 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 96C3F2FC07; Mon, 14 Nov 2022 08:22:25 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 398C0612BE; Mon, 14 Nov 2022 16:22:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84DBAC433D7; Mon, 14 Nov 2022 16:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668442944; bh=1qhbjtrf4OBeymlcd5IJ17ytL34jXMNYYy2ti/5wf+8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WdZE0bgMsqEaxuR8BIVcBnFO5zLpsGWoIXXW/zhOzAXRvB+DMNeSsElwiNjTSLVkX MMQipvVKqO0F43RZCVFC9+Gc63TaDYzRUjuKMKd4p7+LnTPFVMsGfPqkgrHNfOQ4n6 +R8fggl04sAK1uWDIfwvNMmOKpITUZREPUfWb5MnfeXjYI4/8JgFH8x87ceYVRThqR 60CZYene5AsbkxfhAFhuOuUdLfwNkXZUfo6eU5PVMh01sIpyTqBaXZab7N0bFgw4JJ 6gXqdZPDgJd1VLMGxJzOu7X1jTpD/8KyJrxfiRSyyYbZ/Gy5QnbcTQU/zz2j313h8k 3J9e3QH9vCpsQ== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1oucDX-0004vF-Tb; Mon, 14 Nov 2022 17:21:52 +0100 Date: Mon, 14 Nov 2022 17:21:51 +0100 From: Johan Hovold To: Dmitry Baryshkov Cc: Johan Hovold , Vinod Koul , Andy Gross , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , 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> <42ae9612-43da-5f3a-534d-d30b9f399f90@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ae9612-43da-5f3a-534d-d30b9f399f90@linaro.org> Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Mon, Nov 14, 2022 at 06:31:02PM +0300, Dmitry Baryshkov wrote: > On 14/11/2022 16:37, Johan Hovold wrote: > > On Sat, Nov 12, 2022 at 02:43:03PM +0300, Dmitry Baryshkov wrote: > >> On 11/11/2022 12:24, Johan Hovold wrote: > >>> + "#clock-cells": > >>> + const: 1 > >>> + > >>> + clock-output-names: > >>> + items: > >>> + - const: usb3_pipe > >>> + - const: dp_link > >>> + - const: dp_vco_div > >>> + > >>> + "#phy-cells": > >>> + const: 1 > >>> + description: | > >>> + PHY index > >>> + - PHY_TYPE_USB3 > >>> + - PHY_TYPE_DP > >> > >> I'm stepping on Rob's and Krzysztof's ground here, but it might be more > >> logical and future proof to use indices instead of phy types. > > > > Why would that be more future-proof? > > > > I initially added defines for these indexes to a QMP header, but noticed > > that we already have PHY drivers that use the PHY types for this. So > > there's already a precedent for this and I didn't see any real benefit > > to adding multiple per-SoC defines for the same thing. > > As you guessed from my question, I was thinking about USB4 (for which we > do not have a separate PHY_TYPE, but that probably shouldn't matter). Yeah, that's easy enough to add. > Would it be a separate PHY here, or would it be a combo UBS3+USB4 plus > separate DP phy? We don't know yet. > Yes, we have other PHYs, which use types as an index, however it's > slightly more common to have indices instead. If you look at (yaml) bindings using a single phy-cell, the majority simply ignores describing what the index is used for and which values are valid. Of the few that do describe it, the cell index is either used for something which does not allow itself for mapping to PHY_TYPE or PHY_TYPE is used. > Anyway, this is a minor issue. It might be just that I'm more common to > using indices everywhere (in other words, I have preference here, but > it's not a strong requirement from my side). I don't have a strong preference here either. Let's see what Krzysztof and Rob says. Johan 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DE534C4332F for ; Mon, 14 Nov 2022 16:22:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JGD2ZdyoOOaQZ04Zm3F4QsCu4Rg62nFpUj7nNKVYov0=; b=iPWpKywfBY86NA FM80VDkAQC9q0aElgtmNZ4xN3ezCD9ZcIFv7Bm+zYNgBg4UzvP1PQCRuhuroBGKN+kECM0aG8CFa1 1/R70gzLVLBK0A0jEKSyOUefmYjpZOZwAwBnvIuvlNy2Kzlujahaq92osc+QplJrBZUCBd//WThAG pig80wc1jwbz3ZvMkwoBoO8sNUmEZWGgrYm6jOPhcJ5QY5+7MFY5wY6eabL3I/yi95LmiDAATJpWZ u3hMWkBK3pqsYWhRuvC7xizjiQYmLlGQXldsiw5CaMkW1pGhn8W6ycRGI8dhw3zMEnEK/zGbz6LuN G0027zjw2uoDu9tf+8MA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oucEA-002gAn-BB; Mon, 14 Nov 2022 16:22:30 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oucE8-002g8y-EC for linux-phy@lists.infradead.org; Mon, 14 Nov 2022 16:22:29 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id C3250612C9; Mon, 14 Nov 2022 16:22:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84DBAC433D7; Mon, 14 Nov 2022 16:22:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668442944; bh=1qhbjtrf4OBeymlcd5IJ17ytL34jXMNYYy2ti/5wf+8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WdZE0bgMsqEaxuR8BIVcBnFO5zLpsGWoIXXW/zhOzAXRvB+DMNeSsElwiNjTSLVkX MMQipvVKqO0F43RZCVFC9+Gc63TaDYzRUjuKMKd4p7+LnTPFVMsGfPqkgrHNfOQ4n6 +R8fggl04sAK1uWDIfwvNMmOKpITUZREPUfWb5MnfeXjYI4/8JgFH8x87ceYVRThqR 60CZYene5AsbkxfhAFhuOuUdLfwNkXZUfo6eU5PVMh01sIpyTqBaXZab7N0bFgw4JJ 6gXqdZPDgJd1VLMGxJzOu7X1jTpD/8KyJrxfiRSyyYbZ/Gy5QnbcTQU/zz2j313h8k 3J9e3QH9vCpsQ== Received: from johan by xi.lan with local (Exim 4.94.2) (envelope-from ) id 1oucDX-0004vF-Tb; Mon, 14 Nov 2022 17:21:52 +0100 Date: Mon, 14 Nov 2022 17:21:51 +0100 From: Johan Hovold To: Dmitry Baryshkov Cc: Johan Hovold , Vinod Koul , Andy Gross , Bjorn Andersson , Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , 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> <42ae9612-43da-5f3a-534d-d30b9f399f90@linaro.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <42ae9612-43da-5f3a-534d-d30b9f399f90@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221114_082228_572943_0A7A6A19 X-CRM114-Status: GOOD ( 25.20 ) X-BeenThere: linux-phy@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux Phy Mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-phy" Errors-To: linux-phy-bounces+linux-phy=archiver.kernel.org@lists.infradead.org On Mon, Nov 14, 2022 at 06:31:02PM +0300, Dmitry Baryshkov wrote: > On 14/11/2022 16:37, Johan Hovold wrote: > > On Sat, Nov 12, 2022 at 02:43:03PM +0300, Dmitry Baryshkov wrote: > >> On 11/11/2022 12:24, Johan Hovold wrote: > >>> + "#clock-cells": > >>> + const: 1 > >>> + > >>> + clock-output-names: > >>> + items: > >>> + - const: usb3_pipe > >>> + - const: dp_link > >>> + - const: dp_vco_div > >>> + > >>> + "#phy-cells": > >>> + const: 1 > >>> + description: | > >>> + PHY index > >>> + - PHY_TYPE_USB3 > >>> + - PHY_TYPE_DP > >> > >> I'm stepping on Rob's and Krzysztof's ground here, but it might be more > >> logical and future proof to use indices instead of phy types. > > > > Why would that be more future-proof? > > > > I initially added defines for these indexes to a QMP header, but noticed > > that we already have PHY drivers that use the PHY types for this. So > > there's already a precedent for this and I didn't see any real benefit > > to adding multiple per-SoC defines for the same thing. > > As you guessed from my question, I was thinking about USB4 (for which we > do not have a separate PHY_TYPE, but that probably shouldn't matter). Yeah, that's easy enough to add. > Would it be a separate PHY here, or would it be a combo UBS3+USB4 plus > separate DP phy? We don't know yet. > Yes, we have other PHYs, which use types as an index, however it's > slightly more common to have indices instead. If you look at (yaml) bindings using a single phy-cell, the majority simply ignores describing what the index is used for and which values are valid. Of the few that do describe it, the cell index is either used for something which does not allow itself for mapping to PHY_TYPE or PHY_TYPE is used. > Anyway, this is a minor issue. It might be just that I'm more common to > using indices everywhere (in other words, I have preference here, but > it's not a strong requirement from my side). I don't have a strong preference here either. Let's see what Krzysztof and Rob says. Johan -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy