From: Vinod Koul <vkoul@kernel.org>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Andrew Lunn <andrew@lunn.ch>, Jason Cooper <jason@lakedaemon.net>,
devicetree@vger.kernel.org,
Gregory CLEMENT <gregory.clement@bootlin.com>,
Kishon Vijay Abraham I <kishon@ti.com>,
Rob Herring <robh+dt@kernel.org>,
linux-arm-kernel@lists.infradead.org,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Subject: Re: [PATCH 2/2] phy: armada-38x: fix NETA lockup when repeatedly switching speeds
Date: Thu, 16 Jul 2020 11:16:22 +0530 [thread overview]
Message-ID: <20200716054622.GD55478@vkoul-mobl> (raw)
In-Reply-To: <20200713180737.GU1551@shell.armlinux.org.uk>
On 13-07-20, 19:07, Russell King - ARM Linux admin wrote:
> On Mon, Jul 13, 2020 at 06:21:40PM +0100, Russell King - ARM Linux admin wrote:
> > On Mon, Jul 13, 2020 at 05:36:54PM +0200, Gregory CLEMENT wrote:
> > > Hello,
> > >
> > > > On 10-07-20, 16:19, Russell King - ARM Linux admin wrote:
> > > >> On Wed, Jul 01, 2020 at 12:27:27PM +0530, Vinod Koul wrote:
> > > >> > On 30-06-20, 17:05, Russell King wrote:
> > > >> > > The mvneta hardware appears to lock up in various random ways when
> > > >> > > repeatedly switching speeds between 1G and 2.5G, which involves
> > > >> > > reprogramming the COMPHY. It is not entirely clear why this happens,
> > > >> > > but best guess is that reprogramming the COMPHY glitches mvneta clocks
> > > >> > > causing the hardware to fail. It seems that rebooting resolves the
> > > >> > > failure, but not down/up cycling the interface alone.
> > > >> > >
> > > >> > > Various other approaches have been tried, such as trying to cleanly
> > > >> > > power down the COMPHY and then take it back through the power up
> > > >> > > initialisation, but this does not seem to help.
> > > >> > >
> > > >> > > It was finally noticed that u-boot's last step when configuring a
> > > >> > > COMPHY for "SGMII" mode was to poke at a register described as
> > > >> > > "GBE_CONFIGURATION_REG", which is undocumented in any external
> > > >> > > documentation. All that we have is the fact that u-boot sets a bit
> > > >> > > corresponding to the "SGMII" lane at the end of COMPHY initialisation.
> > > >> > >
> > > >> > > Experimentation shows that if we clear this bit prior to changing the
> > > >> > > speed, and then set it afterwards, mvneta does not suffer this problem
> > > >> > > on the SolidRun Clearfog when switching speeds between 1G and 2.5G.
> > > >> > >
> > > >> > > This problem was found while script-testing phylink.
> > > >> > >
> > > >> > > Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> > > >> > > ---
> > > >> > > arch/arm/boot/dts/armada-38x.dtsi | 3 +-
> > > >> >
> > > >> > lgtm, i need ack for dts parts before I can apply this
> > > >>
> > > >> I'm not sure what the situation is for Bootlin, but they don't seem to
> > > >> be very responsive right now (covid related?)
> > > >>
> > > >> What I know from what I've been party to on netdev is that Bootlin
> > > >> sent a patch for the MVPP2 driver, and the very next day someone
> > > >> reported that the patch caused a bug. Unfortunately, the patch got
> > > >> picked up anyway, but there was no response from Bootlin. After a
> > > >> month or so, -final was released containing this patch, so now it
> > > >> had become a regression - and still no response from Bootlin.
> > > >>
> > > >> Eventually the bug got fixed - not because Bootlin fixed it, but
> > > >> because I ended up spending the time researching how that part of
> > > >> the network driver worked, diagnosing what was going on, and
> > > >> eventually fixing it in the most obvious way - but it's not clear
> > > >> that the fix was the right approach. Bootlin never commented. See
> > > >> 3138a07ce219 ("net: mvpp2: fix RX hashing for non-10G ports").
> > > >>
> > > >> So, I think we have to assume that Bootlin are struggling right now,
> > > >> and as it's been over a week, it's unlikely that they are going to
> > > >> respond soon. What do you think we should do?
> > > >>
> > > >> I also note that Rob has not responded to the DT binding change
> > > >> either, despite me gently prodding, and Rob processing a whole raft
> > > >> of DT binding stuff yesterday.
> > > >>
> > > >> I can split the DTS change from the rest of the patch, but I don't
> > > >> think that really helps without at least the binding change being
> > > >> agreed.
> > > >
> > > > I would prefer splitting, you may sent the DTS to arm arch folks if no
> > > > response from subarch folks
> > >
> > > Yes please could you split the patch to put the dts apart ? And if the
> > > binding is accepted we will apply it.
> >
> > I don't see any sign that Rob will ever review the DTS part, so I'm
> > at the point of just not caring about this anymore. I will carry it
> > in my tree, but I'm going to do nothing further.
> >
> > That means that switching speed on mvneta on the Armada 38x is can
> > cause the network to die, but hey, if people can't be bothered to
> > review, and wish to impose rules such as "you can't change anything
> > with DT without my express say so" which have the effect of blocking
> > fixes, that's really not my problem.
> >
> > So, shrug, I'm giving up with these patches. Sorry.
>
> To be clear, this is not aimed at either Vinod or Gregory.
Rob has acked, so if you can respin and split, I can apply
--
~Vinod
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2020-07-16 5:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-30 16:04 [PATCH 0/2] Fix Armada 38x mvneta lockups when switching speeds Russell King - ARM Linux admin
2020-06-30 16:05 ` [PATCH 1/2] dt: update Marvell Armada 38x COMPHY binding Russell King
2020-07-09 10:28 ` Russell King - ARM Linux admin
2020-07-15 20:33 ` Rob Herring
2020-06-30 16:05 ` [PATCH 2/2] phy: armada-38x: fix NETA lockup when repeatedly switching speeds Russell King
2020-06-30 16:06 ` Russell King - ARM Linux admin
2020-07-01 6:57 ` Vinod Koul
2020-07-10 15:19 ` Russell King - ARM Linux admin
2020-07-13 6:18 ` Vinod Koul
2020-07-13 15:36 ` Gregory CLEMENT
2020-07-13 17:21 ` Russell King - ARM Linux admin
2020-07-13 18:07 ` Russell King - ARM Linux admin
2020-07-16 5:46 ` Vinod Koul [this message]
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=20200716054622.GD55478@vkoul-mobl \
--to=vkoul@kernel.org \
--cc=andrew@lunn.ch \
--cc=devicetree@vger.kernel.org \
--cc=gregory.clement@bootlin.com \
--cc=jason@lakedaemon.net \
--cc=kishon@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).