From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Joel Johnson <mrjoel@lixil.net>
Cc: "David S. Miller" <davem@davemloft.net>,
Baruch Siach <baruch@tkos.co.il>,
Gregory Clement <gregory.clement@bootlin.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Rob Herring <robh@kernel.org>,
netdev@vger.kernel.org
Subject: Re: mvneta: comphy regression with SolidRun ClearFog
Date: Thu, 20 Feb 2020 10:12:32 +0000 [thread overview]
Message-ID: <20200220101232.GU25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <8099d231594f1785e7149e4c6c604a5c@lixil.net>
On Wed, Feb 19, 2020 at 06:49:51AM -0700, Joel Johnson wrote:
> On 2020-02-19 02:22, Russell King - ARM Linux admin wrote:
> > On Tue, Feb 18, 2020 at 10:14:48PM -0700, Joel Johnson wrote:
> > > In updating recently I'm encountering a regression with the mvneta
> > > driver on
> > > SolidRun ClearFog Base devices. I originally filed the bug with Debian
> > > (https://bugs.debian.org/951409) since I was using distro provided
> > > packages,
> > > but after further investigation I have isolated the issue as related
> > > to
> > > comphy support added during development for kernel version 5.1.
> > >
> > > When booting stock kernels up to 5.0 everything works as expected
> > > with three
> > > ethernet devices identified and functional. However, running any
> > > kernel 5.1
> > > or later, I only have a single ethernet device available. The single
> > > device
> > > available appears to be the one attached to the SoC itself and not
> > > connected
> > > via SerDes lanes using comphy, i.e. the one defined at
> > > f1070000.ethernet.
> > >
> > > With some log/diff assisted bisecting, I've been able to confirm
> > > that the
> > > "tipping point" changeset is f548ced15f90, which actually performs
> > > the DT
> > > change for the ClearFog family of devices. That's the commit at
> > > which the
> > > failure starts, but is just the final enablement of the added
> > > feature in the
> > > overall series. I've also tested booting the same kernel binary
> > > (including
> > > up to v5.6-rc1) and only swapping the dtb for one excluding the
> > > problematic
> > > commit and confirmed that simply changing the dtb results in all three
> > > devices being functional, albeit obviously without comphy support.
> >
> > Does debian have support for the comphy enabled in their kernel,
> > which is controlled by CONFIG_PHY_MVEBU_A38X_COMPHY ?
>
> Well, doh! I stared at the patch series for way to long, but the added
> Kconfig symbol failed to register mentally somehow. I had been using the
> last known good Debian config with make olddefconfig, but it obviously
> wasn't included in earlier configs and not enabled by default.
>
> I tested a build with v5.6-rc1 and actually enabled the platform driver and
> it worked as expected, including log output of "configuring for sgmii link
> mode". Back to moving forward on other testing. Sorry for the noise, I'll
> update the Debian bug with a patch to enable the config symbol for armmp
> kernels.
>
> Many thanks to you and Willy Tarreau for pointing out my glaring omission!
Thanks for letting us know that you've fixed it now.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
next prev parent reply other threads:[~2020-02-20 10:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-19 5:14 mvneta: comphy regression with SolidRun ClearFog Joel Johnson
2020-02-19 6:00 ` Willy Tarreau
2020-02-19 9:22 ` Russell King - ARM Linux admin
2020-02-19 13:49 ` Joel Johnson
2020-02-20 10:12 ` Russell King - ARM Linux admin [this message]
2020-02-20 15:34 ` Joel Johnson
2020-02-20 15:45 ` Russell King - ARM Linux admin
2020-02-20 16:08 ` Willy Tarreau
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=20200220101232.GU25745@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=baruch@tkos.co.il \
--cc=davem@davemloft.net \
--cc=gregory.clement@bootlin.com \
--cc=mrjoel@lixil.net \
--cc=netdev@vger.kernel.org \
--cc=robh@kernel.org \
--cc=thomas.petazzoni@bootlin.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.