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 3CA5CC88CB2 for ; Tue, 13 Jun 2023 07:53:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240522AbjFMHxI (ORCPT ); Tue, 13 Jun 2023 03:53:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238593AbjFMHxG (ORCPT ); Tue, 13 Jun 2023 03:53:06 -0400 Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67A67E7C for ; Tue, 13 Jun 2023 00:53:05 -0700 (PDT) Received: by mail-vk1-xa29.google.com with SMTP id 71dfb90a1353d-46288dcacb5so1692122e0c.3 for ; Tue, 13 Jun 2023 00:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20221208.gappssmtp.com; s=20221208; t=1686642784; x=1689234784; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ksmnYzaAZG4SFOtuZwLT0Gj07ow0mCiA7tlTY9FP1/Y=; b=d/XOUvzXq7CkULBNjOF5cPQ9T8PQ4GUN2VTUb4tV5GYUOU/bcCMFJER5wRcTiOAxaO VEqeTPG5/GSimPhYdVoDC/uqRBqssvbhFmMqZ2UPpATKuDu0zcPmCBugjzLiimaHg+0O 9wZ1rW7T5SAVt/6r/SykeSUB1kSjjeu1v/QF9yZNVYeWYL/CqPipZS2RqbveG9GDYWQl 3yZcujcboW/sNqe2RjBd/XPxGCpKyPsA5S0Wt8H20ztGP/P8e2a+LHAM1iWQz7y5UEUU byzRaCp7blF315uAiXD/wO22ggP+a/pLSa4fq9EoyeAoPW6lXUTFE4Oe4EeVpTJurQyN Z0bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686642784; x=1689234784; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ksmnYzaAZG4SFOtuZwLT0Gj07ow0mCiA7tlTY9FP1/Y=; b=cAg8WOVmqRSTdFl5YLxQld3lvcu0LIZd4T710o0N6LK91Fhj1JWEhPFQPPU8yZKPTE 9S6KFpXgBZ3N4OkXzHyFsNklfQg/p/TKPETtxT96TbA4+jFRhUPAv0NO4N6lhMfi3E1c y84EWdxApP2AmDUfuCcOXfzyFMOa3AMf2fjokX7ex/x5CGbH76lnXQZzFoq1+xiGkc40 wEr+LT5Yj+x9LfQioXd1hJpst9gwTehVzRxfDzNxK0BbyZ+znaKmeCTt11UZ0QI8csvp wZCX0pLqnQrVDIxHopRpWcrSzRjaNMNSup7Swhmk2cik7nvPf3wSnOmuS7497bHnzrVG miRQ== X-Gm-Message-State: AC+VfDwBKX5wArqj46bbnFkfTW56+LtnJCGSA4jIrwSWKbZVvrwkGqjs H40h1+hnhQv2VasxWCvBf+7+DjSxd+fegMgeGPjJMQ== X-Google-Smtp-Source: ACHHUZ7i+EBDY2WITwEIRgKogtaSChdc3S4PwWz2Qp9PZP5xCpoeIGDCpD2gClqT3kwLonr4MotjvY3YKsBM2PtVtCk= X-Received: by 2002:a1f:bd58:0:b0:46d:fd21:76fb with SMTP id n85-20020a1fbd58000000b0046dfd2176fbmr580943vkf.10.1686642784529; Tue, 13 Jun 2023 00:53:04 -0700 (PDT) MIME-Version: 1.0 References: <20230612092355.87937-1-brgl@bgdev.pl> <20230612092355.87937-13-brgl@bgdev.pl> <20230612203255.72t52ucry7zzq3em@halaney-x13s> In-Reply-To: <20230612203255.72t52ucry7zzq3em@halaney-x13s> From: Bartosz Golaszewski Date: Tue, 13 Jun 2023 09:52:53 +0200 Message-ID: Subject: Re: [PATCH 12/26] net: stmmac: dwmac-qcom-ethqos: add support for the optional serdes phy To: Andrew Halaney Cc: Vinod Koul , Bhupesh Sharma , Andy Gross , Bjorn Andersson , Konrad Dybcio , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Kishon Vijay Abraham I , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , netdev@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Mon, Jun 12, 2023 at 10:33=E2=80=AFPM Andrew Halaney wrote: > > On Mon, Jun 12, 2023 at 11:23:41AM +0200, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski > > > > On sa8775p platforms, there's a SGMII SerDes PHY between the MAC and > > external PHY that we need to enable and configure. > > > > Signed-off-by: Bartosz Golaszewski > > --- > > .../stmicro/stmmac/dwmac-qcom-ethqos.c | 37 +++++++++++++++++++ > > 1 file changed, 37 insertions(+) > > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/= drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c > > index 8ed05f29fe8b..3438b6229351 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c > > @@ -6,6 +6,7 @@ > > #include > > #include > > #include > > +#include > > #include > > > > #include "stmmac.h" > > @@ -93,6 +94,7 @@ struct qcom_ethqos { > > > > unsigned int rgmii_clk_rate; > > struct clk *rgmii_clk; > > + struct phy *serdes_phy; > > unsigned int speed; > > > > const struct ethqos_emac_por *por; > > @@ -566,6 +568,30 @@ static void ethqos_fix_mac_speed(void *priv, unsig= ned int speed) > > ethqos_configure(ethqos); > > } > > > > +static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *p= riv) > > +{ > > + struct qcom_ethqos *ethqos =3D priv; > > + int ret; > > + > > + ret =3D phy_set_speed(ethqos->serdes_phy, ethqos->speed); > > + if (ret) > > + return ret; > > + > > + ret =3D phy_init(ethqos->serdes_phy); > > + if (ret) > > + return ret; > > + > > + return phy_power_on(ethqos->serdes_phy); > > The docs say (phy.rst): > > The general order of calls should be:: > > [devm_][of_]phy_get() > phy_init() > phy_power_on() > [phy_set_mode[_ext]()] > ... > phy_power_off() > phy_exit() > [[of_]phy_put()] > > Some PHY drivers may not implement :c:func:`phy_init` or :c:func:`phy= _power_on`, > but controllers should always call these functions to be compatible w= ith other > PHYs. Some PHYs may require :c:func:`phy_set_mode `= , while > others may use a default mode (typically configured via devicetree or= other > firmware). For compatibility, you should always call this function if= you know > what mode you will be using. Generally, this function should be calle= d after > :c:func:`phy_power_on`, although some PHY drivers may allow it at any= time. > > Not really dictating you need to do that order, but if possible I think > calling phy_set_speed after init + power_on is more generic. Not sure if > that plays nice with the phy driver in this series or not. > > Otherwise, I think this looks good. > I had to rework the PHY driver code a bit for this order to work but it'll be good now in v2. Thanks! Bart > > +} > > + > > +static void qcom_ethqos_serdes_powerdown(struct net_device *ndev, void= *priv) > > +{ > > + struct qcom_ethqos *ethqos =3D priv; > > + > > + phy_power_off(ethqos->serdes_phy); > > + phy_exit(ethqos->serdes_phy); > > +} > > + > > static int ethqos_clks_config(void *priv, bool enabled) > > { > > struct qcom_ethqos *ethqos =3D priv; > > @@ -651,6 +677,12 @@ static int qcom_ethqos_probe(struct platform_devic= e *pdev) > > if (ret) > > goto out_config_dt; > > > > + ethqos->serdes_phy =3D devm_phy_optional_get(dev, "serdes"); > > + if (IS_ERR(ethqos->serdes_phy)) { > > + ret =3D PTR_ERR(ethqos->serdes_phy); > > + goto out_config_dt; > > + } > > + > > ethqos->speed =3D SPEED_1000; > > ethqos_update_rgmii_clk(ethqos, SPEED_1000); > > ethqos_set_func_clk_en(ethqos); > > @@ -666,6 +698,11 @@ static int qcom_ethqos_probe(struct platform_devic= e *pdev) > > if (of_device_is_compatible(np, "qcom,qcs404-ethqos")) > > plat_dat->rx_clk_runs_in_lpi =3D 1; > > > > + if (ethqos->serdes_phy) { > > + plat_dat->serdes_powerup =3D qcom_ethqos_serdes_powerup; > > + plat_dat->serdes_powerdown =3D qcom_ethqos_serdes_powerd= own; > > + } > > + > > ret =3D stmmac_dvr_probe(dev, plat_dat, &stmmac_res); > > if (ret) > > goto out_config_dt; > > -- > > 2.39.2 > > >