All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jiawen Wu" <jiawenwu@trustnetic.com>
To: "'Russell King \(Oracle\)'" <linux@armlinux.org.uk>
Cc: "'Simon Horman'" <simon.horman@corigine.com>, <kabel@kernel.org>,
	<andrew@lunn.ch>, <hkallweit1@gmail.com>, <davem@davemloft.net>,
	<edumazet@google.com>, <kuba@kernel.org>, <pabeni@redhat.com>,
	<netdev@vger.kernel.org>
Subject: RE: [PATCH net] net: phy: marvell10g: fix 88x3310 power up
Date: Mon, 17 Jul 2023 18:51:38 +0800	[thread overview]
Message-ID: <011201d9b89c$a9a93d30$fcfbb790$@trustnetic.com> (raw)
In-Reply-To: <043501d9b580$31798870$946c9950$@trustnetic.com>

> > > > There are two places that mv3310_reset() is called, mv3310_config_mdix()
> > > > and mv3310_set_edpd(). One of them is in the probe function, after we
> > > > have powered up the PHY.
> > > >
> > > > I think we need much more information from the reporter before we can
> > > > guess which commit is a problem, if any.
> > > >
> > > > When does the reset time out?
> > > > What is the code path that we see mv3310_reset() timing out?
> > > > Does the problem happen while resuming or probing?
> > > > How soon after clearing the power down bit is mv3310_reset() called?
> > >
> > > I need to test it more times for more information.
> > >
> > > As far as I know, reset timeout appears in mv3310_set_edpd(), after mv3310_power_up()
> > > in mv3310_config_init().
> > >
> > > Now what I'm confused about is, sometimes there was weird values while probing, just
> > > to read out a weird firmware version, that caused the test to fail.
> > >
> > > And for this phy_read_mmd_poll_timeout(), it only succeeds when sleep_before_read = true.
> > > Otherwise, it would never succeed to clear the power down bit. Currently it looks like clearing
> > > the bit takes about 1ms.
> >
> > So, reading the bit before the first delay period results in the bit not
> > clearing, despite having written it to be zero?
> 
> Yes. So in the original code, there is no delay to read the register again for
> setting software reset bit. I think the power down bit is not actually cleared
> in my test.

Hi Russell,

I confirmed last week that this change is valid to make mv3310_reset() success.
But now reset fails again, only on port 0. Reset timeout still appears in
mv3310_config_init() -> mv3310_set_edpd() -> mv3310_reset(). I deleted this
change to test again, and the result shows that this change is valid for port 1.

So I'm a little confused. Since I don't have programming guidelines for this PHY,
but only a datasheet. Could you please help to check for any possible problems
with it?

Thanks.


  reply	other threads:[~2023-07-17 10:53 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-12  6:26 [PATCH net] net: phy: marvell10g: fix 88x3310 power up Jiawen Wu
2023-07-13 10:26 ` Simon Horman
2023-07-13 10:35   ` Russell King (Oracle)
2023-07-13 10:45     ` Simon Horman
2023-07-13 10:53       ` Russell King (Oracle)
2023-07-13 11:30         ` Jiawen Wu
2023-07-13 11:41           ` Russell King (Oracle)
2023-07-13 11:50             ` Jiawen Wu
2023-07-17 10:51               ` Jiawen Wu [this message]
2023-07-17 12:22                 ` Russell King (Oracle)
2023-07-18  9:12                   ` Jiawen Wu
2023-07-18  9:49                     ` Russell King (Oracle)
2023-07-18  9:58                       ` Jiawen Wu
2023-07-18 11:47                         ` Russell King (Oracle)
2023-07-19  2:29                           ` Jiawen Wu
2023-07-19  3:53                             ` Jiawen Wu
2023-07-19  6:50                             ` Russell King (Oracle)
2023-07-19  7:57                               ` Jiawen Wu
2023-07-19  8:27                                 ` Russell King (Oracle)
2023-07-19  8:38                                   ` Jiawen Wu
2023-07-19  8:52                                     ` Russell King (Oracle)
2023-07-13 12:18         ` Simon Horman
2023-07-13 10:46 ` Russell King (Oracle)

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='011201d9b89c$a9a93d30$fcfbb790$@trustnetic.com' \
    --to=jiawenwu@trustnetic.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kabel@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=simon.horman@corigine.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.