[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZK/i3Ta2mcr7xVot@shell.armlinux.org.uk>
Date: Thu, 13 Jul 2023 12:41:17 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Jiawen Wu <jiawenwu@...stnetic.com>
Cc: 'Simon Horman' <simon.horman@...igine.com>, kabel@...nel.org,
andrew@...n.ch, hkallweit1@...il.com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
netdev@...r.kernel.org
Subject: Re: [PATCH net] net: phy: marvell10g: fix 88x3310 power up
On Thu, Jul 13, 2023 at 07:30:17PM +0800, Jiawen Wu wrote:
> On Thursday, July 13, 2023 6:54 PM, Russell King (Oracle) wrote:
> > On Thu, Jul 13, 2023 at 11:45:59AM +0100, Simon Horman wrote:
> > > On Thu, Jul 13, 2023 at 11:35:05AM +0100, Russell King (Oracle) wrote:
> > > > On Thu, Jul 13, 2023 at 11:26:40AM +0100, Simon Horman wrote:
> > > > > On Wed, Jul 12, 2023 at 02:26:34PM +0800, Jiawen Wu wrote:
> > > > > > Clear MV_V2_PORT_CTRL_PWRDOWN bit to set power up for 88x3310 PHY,
> > > > > > it sometimes does not take effect immediately. This will cause
> > > > > > mv3310_reset() to time out, which will fail the config initialization.
> > > > > > So add to poll PHY power up.
> > > > > >
> > > > > > Signed-off-by: Jiawen Wu <jiawenwu@...stnetic.com>
> > > > >
> > > > > Hi Jiawen Wu,
> > > > >
> > > > > should this have the following?
> > > > >
> > > > > Fixes: 0a5550b1165c ("bpftool: Use "fallthrough;" keyword instead of comments")
> > > >
> > > > What is that commit? It doesn't appear to be in Linus' tree, it doesn't
> > > > appear to be in the net tree, nor the net-next tree.
> > >
> > > Hi Russell,
> > >
> > > Sorry, it is bogus. Some sort of cut and paste error on my side
> > > that pulled in the local commit of an unrelated patch.
> > >
> > > What I should have said is:
> > >
> > > Fixes: 8f48c2ac85ed ("net: marvell10g: soft-reset the PHY when coming out of low power")
> >
> > Thanks, but I don't think that's appropriate either.
> >
> > The commit adds a software reset after clearing the power down bit, but
> > that doesn't have anything to do with mv3310_reset().
> >
> > 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?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists