lkml.org 
[lkml]   [2023]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Date
SubjectRe: [PATCH net-next v6 3/3] net: ethernet: ti: am65-cpsw: Add support for SERDES configuration
Hi Siddharth,

On Wed, Jan 4, 2023 at 11:37 AM Siddharth Vadapalli <s-vadapalli@ti.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@ti.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)...

> + 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);

> + 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?

> goto of_node_put;
> }
>
> + /* Initialize the Serdes PHY for the port */
> + ret = am65_cpsw_init_serdes_phy(dev, port_np, port);
> + if (ret)
> + return ret;
> +
> port->slave.mac_only =
> of_property_read_bool(port_np, "ti,mac-only");
>

Gr{oetje,eeting}s,
Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

\
 
 \ /
  Last update: 2023-03-26 23:44    [W:0.167 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site