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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 20 Feb 2020 08:34:07 -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-20 03:12, Russell King - ARM Linux admin wrote:
> 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:
>> > 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.
>> 
>> Many thanks to you and Willy Tarreau for pointing out my glaring 
>> omission!
> 
> Thanks for letting us know that you've fixed it now.

Sure thing, I've submitted a Debian patch, and was pointed to an 
existing Debian bug with the same issue and patch, so hopefully that 
will get incorporated soon. I'll also keep an eye on OpenWRT when they 
move to an affected kernel version to make sure it's included.

One lingering question that wasn't clear to me is the apparent 
inconsistency in default enablement for PHYs in 
drivers/phy/marvell/Kconfig. Is there a technical reason why 
PHY_MVEBU_A3700_COMPHY defaults to 'y' but PHY_MVEBU_A38X_COMPHY (and 
PHY_MVEBU_CP110_COMPHY) default to 'n', or is it just an artifact of 
being added at different times? Similarly, is there a reason that 
PHY_MVEBU_A3700_COMPHY and PHY_MVEBU_A3700_UTMI default to 'y' instead 
of 'm' for all ARCH_MVEBU builds? In my testing, building with 
PHY_MVEBU_A38X_COMPHY as a module still seemed to autoload the module as 
needed on boot, so modules for different platforms seems off-hand more 
lightweight that building the driver in for all MVEBU boards which don't 
use all drivers.

With the current defaults, it seems like PHY_MVEBU_CP110_COMPHY may be 
affected in Debian the same way as PHY_MVEBU_A38X_COMPHY, but I don't 
have available Armada 7K/8K hardware yet to confirm.

Joel