netdev - Re: [PATCH v7 09/11] net: pch_gbe: Convert to mdiobus and phylib

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, 27 Jun 2018 11:09:59 -0700
From:   Paul Burton <paul.burton@...s.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, "David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH v7 09/11] net: pch_gbe: Convert to mdiobus and phylib

Hi Andrew,

On Wed, Jun 27, 2018 at 07:51:44PM +0200, Andrew Lunn wrote:
> > @@ -5,7 +5,8 @@
> >  config PCH_GBE
> >  	tristate "OKI SEMICONDUCTOR IOH(ML7223/ML7831) GbE"
> >  	depends on PCI && (X86_32 || COMPILE_TEST)
> > -	select MII
> > +	select PHYLIB
> > +	imply AT803X_PHY if X86_32
> >  	select PTP_1588_CLOCK_PCH
> >  	select NET_PTP_CLASSIFY
> 
> That is unusual. I don't think any other MAC driver does this.
> 
> If the AT803X driver is not available, it will fall back to the
> generic PHY driver. That means RGMII delays will not get set
> correctly, no interrupts, no wol, and no workaround for the 8030.
> 
> Are any of these relevant to your board?

Well, my board uses an RTL8211E PHY, doesn't support suspending so WoL
isn't applicable & with this series isn't yet using PHY interrupts
(though that would be ideal as a later addition). So for my board I
enable CONFIG_REALTEK_PHY & I don't have CONFIG_AT8031X_PHY enabled.

It seems the Minnowboard uses the AT8031 PHY, but it's not the only X86
board that includes the EG20T & not all of those use the AT8031. For
example I have access to an Aaeon NanoCOM-TC module[1] which uses the
EG20T & pch_gbe, but its datasheet lists an RTL8211CL PHY (which is
presumably misconfigured by current kernels, though at least for basic
network access is functional).

The idea behind using imply was that it allows kernel configurations
that have up to now only supported the AT8031 PHY via pch_gbe's custom
code to automatically continue to support that PHY, but also allows
support for it to be disabled for systems that do not use that PHY (for
example mine or the Aaeon system).

Would you prefer that the MAC driver instead selects the PHY drivers for
all PHYs known to have been used with the MAC? Or would you be happy if
I added the equivalent in patch 11:

  imply REALTEK_PHY if MIPS

Though perhaps REALTEK_PHY would be good to enable for X86_32 too to
cover that Aaeon system...

Thanks,
    Paul

[1] http://www.aaeon.com/en/p/com-express-modules-nanocom-tc