All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tim Harvey <tharvey@gateworks.com>
To: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: u-boot <u-boot@lists.denx.de>,
	Joe Hershberger <joe.hershberger@ni.com>,
	 Ramon Fried <rfried.dev@gmail.com>
Subject: Re: [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY
Date: Fri, 25 Mar 2022 09:53:20 -0700	[thread overview]
Message-ID: <CAJ+vNU1UvBGm7drnC_eM0SkSa4ZqWW-Rkzz=jtDr0i7MpJ_W4g@mail.gmail.com> (raw)
In-Reply-To: <20211204230035.4136596-2-vladimir.oltean@nxp.com>

On Sat, Dec 4, 2021 at 3:01 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
>
> If the DSA API is going to allow drivers to do things such as:
>
> - phy_config in dsa_ops :: port_probe
> - phy_startup in dsa_ops :: port_enable
>
> then it would actually be good if the ->port_probe() method would
> actually be called in all cases before the ->port_enable() is.
>
> Currently this is true for user ports, but not true for the CPU port,
> because the CPU port does not have a udevice registered for it (this is
> all part of DSA's design). So the current issue is that after
> phy_startup has finished for the CPU port, its phydev->speed is an
> uninitialized value, because phy_config() was never called for the
> priv->cpu_port_fixed_phy, and it is precisely phy_config() who copies
> the speed into the phydev in the case of the fixed PHY driver.
>
> So we need to simulate a probing event for the CPU port by manually
> calling the driver's ->port_probe() method for the CPU port.
>
> Fixes: 8a2982574854 ("net: dsa: introduce a .port_probe() method in struct dsa_ops")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  net/dsa-uclass.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 606b1539a776..9ff55a02fb23 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -466,6 +466,8 @@ static int dsa_pre_probe(struct udevice *dev)
>  {
>         struct dsa_pdata *pdata = dev_get_uclass_plat(dev);
>         struct dsa_priv *priv = dev_get_uclass_priv(dev);
> +       struct dsa_ops *ops = dsa_get_ops(dev);
> +       int err;
>
>         priv->num_ports = pdata->num_ports;
>         priv->cpu_port = pdata->cpu_port;
> @@ -477,6 +479,15 @@ static int dsa_pre_probe(struct udevice *dev)
>
>         uclass_find_device_by_ofnode(UCLASS_ETH, pdata->master_node,
>                                      &priv->master_dev);
> +
> +       /* Simulate a probing event for the CPU port */
> +       if (ops->port_probe) {
> +               err = ops->port_probe(dev, priv->cpu_port,
> +                                     priv->cpu_port_fixed_phy);
> +               if (err)
> +                       return err;
> +       }
> +
>         return 0;
>  }
>
> --
> 2.25.1
>

Vladimir,

I came across this while looking for the best place to configure cpu
port interface mode (ie rgmii id) for the mv88e61xx dsa driver I'm
working on. Note that this patch causes port_probe to be called on the
cpu port 'before' the master device has been probed. I'm not sure if
this is intended or not?

In my case I was looking to configure the cpu port interface mode when
the port was probed but I can't do that because it happens before the
switch is probed because of some things that need to happen there.
Best Regards,

Tim

  parent reply	other threads:[~2022-03-25 16:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-04 23:00 [PATCH 0/2] DSA switch fixes Vladimir Oltean
2021-12-04 23:00 ` [PATCH 1/2] net: dsa: fix phydev->speed being uninitialized for the CPU port fixed PHY Vladimir Oltean
2022-01-15 16:46   ` Ramon Fried
2022-01-15 16:47     ` Ramon Fried
2022-03-25 16:53   ` Tim Harvey [this message]
2022-03-25 18:07     ` Vladimir Oltean
2022-03-25 21:03       ` Tim Harvey
2022-03-28  9:26         ` Vladimir Oltean
2022-03-28 22:23           ` Tim Harvey
2022-03-29  0:03             ` Vladimir Oltean
2022-03-29 21:19               ` Tim Harvey
2021-12-04 23:00 ` [PATCH 2/2] net: dsa: sja1105: fix device id detection Vladimir Oltean
2022-01-15 16:48   ` Ramon Fried
2022-01-15 16:48     ` Ramon Fried

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ+vNU1UvBGm7drnC_eM0SkSa4ZqWW-Rkzz=jtDr0i7MpJ_W4g@mail.gmail.com' \
    --to=tharvey@gateworks.com \
    --cc=joe.hershberger@ni.com \
    --cc=rfried.dev@gmail.com \
    --cc=u-boot@lists.denx.de \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.