netdev - Re: [PATCH net-next 4/5] net: phy: don't export gen10g_read

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]

Message-ID: <20190304155202.GE18622@lunn.ch>
Date:   Mon, 4 Mar 2019 16:52:02 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Jose Abreu <jose.abreu@...opsys.com>
Cc:     Heiner Kallweit <hkallweit1@...il.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        David Miller <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 4/5] net: phy: don't export gen10g_read_status

On Mon, Mar 04, 2019 at 03:26:56PM +0000, Jose Abreu wrote:
> On 3/3/2019 4:12 PM, Heiner Kallweit wrote:
> > Not sure whether anybody is relying on the gen10g driver currently.
> 
> I do for stmmac (code not upstreamed yet) and it works okay. For
> debug purposes I ended up writing my own phy driver but this is a
> plain copy of Generic 10G driver + reset and suspend/resume
> callbacks.

I strongly suggest you write a proper PHY driver. There are horrible
assumptions in the gen10g, like only 10G support. In order to make it
more general purpose, asking the PHY what it actually supports, etc
might break your use case. We then need to decided, is that a
regression, are we forced to leave it alone, or since your code is not
yet upstream, it is not a regression, and we are O.K. breaking it, in
order to make upstream code better?

    Andrew