netdev - Re: mvneta: comphy regression with SolidRun ClearFog

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 19 Feb 2020 06:49:51 -0700
From:   Joel Johnson <mrjoel@...il.net>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Baruch Siach <baruch@...s.co.il>,
        Gregory Clement <gregory.clement@...tlin.com>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Rob Herring <robh@...nel.org>, netdev@...r.kernel.org
Subject: Re: mvneta: comphy regression with SolidRun ClearFog

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!

Joel