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 B8DB2C4332F for ; Wed, 14 Dec 2022 09:56:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238040AbiLNJ41 (ORCPT ); Wed, 14 Dec 2022 04:56:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58946 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237995AbiLNJ4V (ORCPT ); Wed, 14 Dec 2022 04:56:21 -0500 Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B4C2DCFE for ; Wed, 14 Dec 2022 01:56:20 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id j4so9608811lfk.0 for ; Wed, 14 Dec 2022 01:56:20 -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=aNJNTOII/kcONJd8CaNcXxHzCuywHLZopRKDpGjPQGY=; b=I2ZYbEUz/VnpqOOO9tLIGFPE++82w7iP+LU8JFd5EAl5dEsxMlntD+vTpOtmeINzKk xLJ7Kt7W2MyRT+ZwBwDGJLY0UbNNBnQx2sqJ2KxsVtlVRrOcSWklj4JbYfZ+IwqjAfl4 jzTXG+olvbujK5q4FfGwLItl3Qpi1qJtMNZMVb0kphfCXUENQ16qLzoXuouKTrGfTJNe m9Dhy5D59N1UJSZTdaJggEEAowq3H/3mbcZJzuTbapyCkt1d8+HNArH0zNwx5g7aMuPc T7e9PDffMRHodpazN/LoMIcHZJQazT46dRaFzmAh3w+pk2KVBmlkK9mOzbK1ty7Ql6lT r5Dg== 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=aNJNTOII/kcONJd8CaNcXxHzCuywHLZopRKDpGjPQGY=; b=7le8f2taiFudj+wTLF1yaYCd1lmgh8VW3Rn6zSnI+AS9jNZBEgz5h4+UEeF6L9ko+8 hw+v/7LBGUBWDwShcL0QPCTYwu1rysYOiV6yXsTVLc0bV3vt5SU48LQUy3Ie6tVhjYMU BCTkeOibRjWOM3O4nMq3tUlOAcXK+IJrNJ2j+dzFI7ahQNV0XyXlMLMdJPpZpVY7LTWO MSOCL6JqIxEjJ4Qn346ORqDt/y4Y4ymCzaESq4getUPP04dL+2a3W3Xg/5XCbedUbJwm rgrDm6Xt4QgSiXtMnomm0Mbs8eNycuALg+NwyWkNI66oVfYxroXz6hYFBES2eWfPy8Hg qfow== X-Gm-Message-State: ANoB5pnrb79mEK1FmrgD+pJMvdtDzlDUUZCIp+rF4uGgHMa0qdhZBDoq XQcxPB8MprxLJYSQdX+lJ8aMEg== X-Google-Smtp-Source: AA0mqf4xW64tVM5DPefPl+m+tqJT3zPBAIQOsntrDEuumQIYumNk5ua9B4HLuOQeoT7ewEkVS0u9RQ== X-Received: by 2002:a05:6512:39d2:b0:4b6:fdc3:a65f with SMTP id k18-20020a05651239d200b004b6fdc3a65fmr1987539lfu.11.1671011779131; Wed, 14 Dec 2022 01:56:19 -0800 (PST) Received: from [192.168.1.101] (abxh44.neoplus.adsl.tpnet.pl. [83.9.1.44]) by smtp.gmail.com with ESMTPSA id w3-20020a05651234c300b004a9b9ccfbe6sm746744lfr.51.2022.12.14.01.56.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Dec 2022 01:56:18 -0800 (PST) Message-ID: Date: Wed, 14 Dec 2022 10:56:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: [PATCH 3/3] arm64: dts: qcom: sm6115: Add USB SS qmp phy node Content-Language: en-US To: Bhupesh Sharma , Krzysztof Kozlowski Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, agross@kernel.org, bhupesh.linux@gmail.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, andersson@kernel.org References: <20221213123823.455731-1-bhupesh.sharma@linaro.org> <20221213123823.455731-4-bhupesh.sharma@linaro.org> <39ff2174-6d04-ec21-b762-377ed28088cb@linaro.org> From: Konrad Dybcio 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.12.2022 06:20, Bhupesh Sharma wrote: > On Wed, 14 Dec 2022 at 00:29, Krzysztof Kozlowski > wrote: >> >> On 13/12/2022 19:52, Bhupesh Sharma wrote: >>> Hi Krzysztof, >>> >>> On Tue, 13 Dec 2022 at 18:26, Krzysztof Kozlowski >>> wrote: >>>> >>>> On 13/12/2022 13:38, Bhupesh Sharma wrote: >>>>> Add USB superspeed qmp phy node to dtsi. >>>>> >>>>> Signed-off-by: Bhupesh Sharma >>>>> --- >>>>> arch/arm64/boot/dts/qcom/sm6115.dtsi | 38 ++++++++++++++++++++++++++-- >>>>> 1 file changed, 36 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>> index e4ce135264f3d..9c5c024919f92 100644 >>>>> --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>> +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi >>>>> @@ -579,6 +579,40 @@ usb_hsphy: phy@1613000 { >>>>> status = "disabled"; >>>>> }; >>>>> >>>>> + usb_qmpphy: phy@1615000 { >>>>> + compatible = "qcom,sm6115-qmp-usb3-phy"; >>>>> + reg = <0x01615000 0x200>; >>>>> + #clock-cells = <1>; >>>>> + #address-cells = <1>; >>>>> + #size-cells = <1>; >>>>> + ranges; >>>>> + clocks = <&gcc GCC_USB3_PRIM_PHY_COM_AUX_CLK>, >>>>> + <&gcc GCC_USB3_PRIM_CLKREF_CLK>, >>>>> + <&gcc GCC_AHB2PHY_USB_CLK>; >>>>> + clock-names = "com_aux", >>>>> + "ref", >>>>> + "cfg_ahb"; >>>>> + resets = <&gcc GCC_USB3_PHY_PRIM_SP0_BCR>, >>>>> + <&gcc GCC_USB3PHY_PHY_PRIM_SP0_BCR>; >>>>> + reset-names = "phy", "phy_phy"; >>>>> + status = "disabled"; >>>> >>>> Hm, you add a disabled PHY which is used by existing controller. The >>>> controller is enabled in board DTS, but new PHY node isn't. Aren't you >>>> now breaking it? >>> >>> The USB controller is connected to two PHYs - one is HS PHY and the other is SS >>> QMP Phy. So while the exiting board dts describes and uses only the HS >>> PHY, newer >>> board dts files (which will soon be sent out as a separate patch), >> >> Then I miss how do you narrow the existing DTS to use only one PHY. I >> don't see anything in this patchset. >> >>> will use both the HS and SS >>> USB PHYs. >>> >>> So, this will not break the existing board dts files. >> >> I still think it will be. The board boots with USB with one phy enabled >> and one disabled. The driver gets phys unconditionally and one of them >> is disabled. >> >> Even if Linux implementation will work (devm_usb_get_phy_by_phandle will >> return -ENXIO or -ENODEV for disabled node), it is still a bit confusing >> and I wonder how other users of such DTS should behave. Although it will >> affect only one board, so maybe there are no other users? > > Ah, now I get your point. So how does the following fix in > sm4250-oneplus-billie2.dts look like. It allows the base dtsi to carry > the usb nodes as exposed by the SoC and allows other board dts files > to use both the USB2 and UBS3 PHYs. > > Please let me know. > > --- a/arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dts > +++ b/arch/arm64/boot/dts/qcom/sm4250-oneplus-billie2.dts > @@ -232,6 +232,9 @@ &usb { > &usb_dwc3 { > maximum-speed = "high-speed"; > dr_mode = "peripheral"; > + > + phys = <&usb_hsphy>; > + phy-names = "usb2-phy"; > }; Looks good now! Konrad > > Thanks.