All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierluigi Passaro <pierluigi.passaro@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: hkallweit1@gmail.com, linux@armlinux.org.uk, davem@davemloft.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	eran.m@variscite.com, nate.d@variscite.com,
	francesco.f@variscite.com, pierluigi.p@variscite.com
Subject: Re: [PATCH] net: mdio: force deassert MDIO reset signal
Date: Sun, 15 Jan 2023 21:34:57 +0100	[thread overview]
Message-ID: <CAJ=UCjXr=GBieTvUE7O2LqEg4Q_UpmOEAxUVwy2wuitfHT+2ow@mail.gmail.com> (raw)
In-Reply-To: <Y8RNzIuiNdAi0dnV@lunn.ch>

On Sun, Jan 15, 2023 at 8:02 PM Andrew Lunn <andrew@lunn.ch> wrote:
> > This behaviour is generally not visible, but easily reproducible with all NXP
> > platforms with dual fec (iMX28, iMX6UL, iMX7, iMX8QM, iMX8QXP)
> > where the MDIO bus is owned by the 1st interface but shared with the 2nd.
> > When the 1st interface is probed, this causes the probe of the MDIO bus
> > when the 2nd interface is not yet set up.
>
> This sounds like a different issue.
>
> We need to split the problem up into two.
>
> 1) Does probing the MDIO bus find both PHYs?
>
> 2) Do the MACs get linked to the PHYs.
>
> If the reset is asserted at the point the MDIO bus is probed, you
> probably don't find the PHY because it does not respond to register
> reads. Your patch probably ensures it is out of reset so it is
> enumerated.
>
You are perfectly right: this patch fixes only the 1st problem.
For the 2nd problem, I've already sent a dedicated patch:
https://lore.kernel.org/all/20230115174910.18353-1-pierluigi.p@variscite.com/
>
> For fec1, if the PHY is found during probe, connecting to the PHY will
> work without issues. However, fec2 can potentially have ordering
> issues. Has the MDIO bus finished being probed by the time fec2 looks
> for it? If it is not there you want to return -EPROBE_DEFERED so that
> the driver code will try again later.
>
> There have been patches to do with ordering recently, but they have
> been more to do with suspend/resume. So please make sure you are
> testing net-next, if ordering is your real problem. You also appear to
> be missing a lot of stable patches, so please bring you kernel up to
> date on the 5.15 branch, you are way out of date.
>
>      Andrew

  reply	other threads:[~2023-01-15 20:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-15 16:10 [PATCH] net: mdio: force deassert MDIO reset signal Pierluigi Passaro
2023-01-15 17:08 ` Andrew Lunn
2023-01-15 18:38   ` Pierluigi Passaro
2023-01-15 19:02     ` Andrew Lunn
2023-01-15 20:34       ` Pierluigi Passaro [this message]
2023-01-15 21:58   ` Lars-Peter Clausen
2023-01-15 22:33     ` Pierluigi Passaro
2023-01-15 22:56       ` Lars-Peter Clausen
2023-01-15 23:16         ` Pierluigi Passaro
2023-01-16  0:11       ` Andrew Lunn
2023-01-16  9:44         ` Pierluigi Passaro
2023-01-16 10:21           ` Russell King (Oracle)
2023-01-17 14:01           ` Andrew Lunn
2023-01-17 15:20             ` Pierluigi Passaro
2023-01-15 23:55     ` Andrew Lunn
2023-01-16  2:21       ` Lars-Peter Clausen
2023-01-16  9:51         ` Pierluigi Passaro
2023-01-17 13:40         ` Andrew Lunn
2023-01-17 13:48           ` Lars-Peter Clausen
2023-01-17 14:13             ` Andrew Lunn
2023-01-16  8:39       ` Pierluigi Passaro
2023-01-17 13:43         ` Andrew Lunn
2023-01-16  8:43 ` kernel test robot
2023-01-16 10:32   ` Pierluigi Passaro
2023-01-16 10:34     ` Russell King (Oracle)
2023-01-16 14:35   ` Pierluigi Passaro
2023-01-17 19:25 kernel test robot
2023-01-17 20:30 ` Dan Carpenter

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=UCjXr=GBieTvUE7O2LqEg4Q_UpmOEAxUVwy2wuitfHT+2ow@mail.gmail.com' \
    --to=pierluigi.passaro@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eran.m@variscite.com \
    --cc=francesco.f@variscite.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=nate.d@variscite.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pierluigi.p@variscite.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.