Message-ID: <69d39885-68df-7c94-5a98-5f1e174c7316@ti.com>
Date:   Wed, 18 Jan 2023 11:17:33 +0530
From:   Siddharth Vadapalli <s-vadapalli@...com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
CC:     <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
        <pabeni@...hat.com>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski@...aro.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <linux@...linux.org.uk>,
        <vladimir.oltean@....com>, <vigneshr@...com>, <nsekhar@...com>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <srk@...com>,
        <s-vadapalli@...com>
Subject: Re: [PATCH net-next v6 3/3] net: ethernet: ti: am65-cpsw: Add support
 for SERDES configuration

Hello Geert,

Thank you for reviewing the patch.

On 17/01/23 19:25, Geert Uytterhoeven wrote:
> Hi Siddharth,
> 
> On Wed, Jan 4, 2023 at 11:37 AM Siddharth Vadapalli <s-vadapalli@...com> wrote:
>> Use PHY framework APIs to initialize the SERDES PHY connected to CPSW MAC.
>>
>> Define the functions am65_cpsw_disable_phy(), am65_cpsw_enable_phy(),
>> am65_cpsw_disable_serdes_phy() and am65_cpsw_enable_serdes_phy().
>>
>> Add new member "serdes_phy" to struct "am65_cpsw_slave_data" to store the
>> SERDES PHY for each port, if it exists. Use it later while disabling the
>> SERDES PHY for each port.
>>
>> Power on and initialize the SerDes PHY in am65_cpsw_nuss_init_slave_ports()
>> by invoking am65_cpsw_enable_serdes_phy().
>>
>> Power off the SerDes PHY in am65_cpsw_nuss_remove() by invoking
>> am65_cpsw_disable_serdes_phy().
>>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@...com>
> 
> Thanks for your patch, which is now commit dab2b265dd23ef8f ("net:
> ethernet: ti: am65-cpsw: Add support for SERDES configuration")
> in net-next.
> 
>> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
>> @@ -1416,6 +1416,68 @@ static const struct net_device_ops am65_cpsw_nuss_netdev_ops = {
>>         .ndo_setup_tc           = am65_cpsw_qos_ndo_setup_tc,
>>  };
>>
>> +static void am65_cpsw_disable_phy(struct phy *phy)
>> +{
>> +       phy_power_off(phy);
>> +       phy_exit(phy);
>> +}
>> +
>> +static int am65_cpsw_enable_phy(struct phy *phy)
>> +{
>> +       int ret;
>> +
>> +       ret = phy_init(phy);
>> +       if (ret < 0)
>> +               return ret;
>> +
>> +       ret = phy_power_on(phy);
>> +       if (ret < 0) {
>> +               phy_exit(phy);
>> +               return ret;
>> +       }
>> +
>> +       return 0;
>> +}
>> +
>> +static void am65_cpsw_disable_serdes_phy(struct am65_cpsw_common *common)
>> +{
>> +       struct am65_cpsw_port *port;
>> +       struct phy *phy;
>> +       int i;
>> +
>> +       for (i = 0; i < common->port_num; i++) {
>> +               port = &common->ports[i];
>> +               phy = port->slave.serdes_phy;
>> +               if (phy)
>> +                       am65_cpsw_disable_phy(phy);
>> +       }
>> +}
>> +
>> +static int am65_cpsw_init_serdes_phy(struct device *dev, struct device_node *port_np,
>> +                                    struct am65_cpsw_port *port)
>> +{
>> +       const char *name = "serdes-phy";
>> +       struct phy *phy;
>> +       int ret;
>> +
>> +       phy = devm_of_phy_get(dev, port_np, name);
>> +       if (PTR_ERR(phy) == -ENODEV)
>> +               return 0;
>> +
>> +       /* Serdes PHY exists. Store it. */
> 
> "phy" may be a different error here (e.g. -EPROBE_DEFER)...

The Serdes is automatically configured for multi-link protocol (Example: PCIe +
QSGMII) by the Serdes driver, due to which it is not necessary to invoke the
Serdes configuration via phy_init(). However, for single-link protocol (Example:
Serdes has to be configured only for SGMII), the Serdes driver doesn't configure
the Serdes unless requested. For this case, the am65-cpsw driver explicitly
invokes phy_init() for the Serdes to be configured, by looking up the optional
device-tree phy named "serdes-phy". For this reason, the above section of code
is actually emulating a non-existent "devm_of_phy_optional_get()". The
"devm_of_phy_optional_get()" function is similar to the
"devm_phy_optional_get()" function in the sense that the "serdes-phy" phy in the
device-tree is optional and it is not truly an error if the property isn't present.

Thank you for pointing out that if the Serdes driver is built as a module and
the am65-cpsw driver runs first, then the "phy" returned for "serdes-phy" will
be "-EPROBE_DEFER".

> 
>> +       port->slave.serdes_phy = phy;
>> +
>> +       ret =  am65_cpsw_enable_phy(phy);
> 
> ... so it will crash when dereferencing phy in phy_init().
> 
> I think you want to add an extra check above:
> 
>     if (IS_ERR(phy))
>             return PTR_ERR(phy);

Please let me know if posting a "Fixes" patch for fixing this net-next commit is
the right process to address this.

> 
>> +       if (ret < 0)
>> +               goto err_phy;
>> +
>> +       return 0;
>> +
>> +err_phy:
>> +       devm_phy_put(dev, phy);
>> +       return ret;
>> +}
>> +
>>  static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned int mode,
>>                                       const struct phylink_link_state *state)
>>  {
>> @@ -1959,6 +2021,11 @@ static int am65_cpsw_nuss_init_slave_ports(struct am65_cpsw_common *common)
> 
> Right out of context we have:
> 
>                 port->slave.ifphy = devm_of_phy_get(dev, port_np, NULL);
>                 if (IS_ERR(port->slave.ifphy)) {
>                         ret = PTR_ERR(port->slave.ifphy);
>                         dev_err(dev, "%pOF error retrieving port phy: %d\n",
>                                 port_np, ret);
> 
> So if there is only one PHY (named "serdes-phy") in DT, it will be
> used for both ifphy and serdes_phy. Is that intentional?

The PHY corresponding to "ifphy" is meant to be the CPSW MAC's PHY and not the
Serdes PHY. The CPSW MAC's PHY is configured by the
drivers/phy/ti/phy-gmii-sel.c driver and this is NOT an optional PHY, unlike the
Serdes PHY. Therefore, it is assumed that the CPSW MAC's PHY is always provided
in the device-tree, while the Serdes PHY is optional, depending on whether the
Serdes is being configured for single-link protocol or multi-link protocol.
Please let me know if this appears to be an issue and I will fix it based on
your suggestion.

Regards,
Siddharth.

Powered by blists - more mailing lists