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] [day] [month] [year] [list]

Date:   Thu, 20 Feb 2020 17:08:56 +0100
From:   Willy Tarreau <w@....eu>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Joel Johnson <mrjoel@...il.net>,
        "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 Thu, Feb 20, 2020 at 03:45:21PM +0000, Russell King - ARM Linux admin wrote:
> > 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.

On this point I can confirm that my mcbin does require
CONFIG_PHY_MVEBU_CP110_COMPHY to work correctly.

> There is no clear answer to whether should something default to Y,
> M or N - different people have different ideas and different levels
> of frustration with which-ever are picked.
> 
> The root problem is that there are way too many configuration
> options that it's become quite time consuming to put together the
> proper kernel configuration for any particular platform, and things
> get even more interesting when it comes to a kernel supporting
> multiple platforms, where one may wish to avoid having a huge
> kernel image, but want to use modules for the platform specific
> bits.
> 
> I wonder whether we ought to be considering something like:
> 
> menuconfig ARCH_MVEBU_DEFAULTS
> 	tristate "Marvell Engineering Business Unit (MVEBU) SoCs"
> 
> config ARCH_MVEBU
> 	def_bool y if ARCH_MVEBU_DEFAULTS
> 	...
> 
> and then have mvebu drivers default to the state of
> ARCH_MVEBU_DEFAULTS.  That means, if you want to build the
> platform with modular drivers, or built-in drivers there's one top
> level config that will default all the appropriate options that way,
> and any new drivers added later can pick up on the state of that
> option.
> 
> Just a thought.

I found that phys are actually a very obscure area for many users, a
bit like codecs for sound, and that even when you think you know what
you're doing you can get it wrong. Part of the reason is the common
total disconnection between certain phy chips and the places they're
used (sometimes different vendors for the PHY and the MAC), and actually
a very good approach would be to clearly enumerate a list of candidate
platforms instead of families. Typically for A38X and CP110 it's clearly
mentioned in the help messages that they're for Armada 38x/7k/8k but
often it's obscure (e.g. the USB phy descriptions in the same Kconfig
are less easy to figure, such as "28nm SoC" or "Berlin SoCs").

I tend to also agree with Russell you that having an option to turn
on sane defaults for a given platform that's well maintained like
mvebu could save quite some time.

Willy