linux-kernel - Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options

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]

Message-ID: <1479307890.17538.40.camel@baylibre.com>
Date:   Wed, 16 Nov 2016 15:51:30 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, Carlo Caione <carlo@...one.org>,
        Kevin Hilman <khilman@...libre.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre TORGUE <alexandre.torgue@...com>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Andre Roth <neolynx@...il.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        linux-amlogic@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net 1/3] net: phy: realtek: add eee advertisement
 disable options

On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> > 
> > There two kind of PHYs supporting eee, the one advertising eee by
> > default (like realtek) and the one not advertising it (like
> > micrel).

This is just the default register value.

> 
> I don't know too much about EEE. So maybe a dumb question. Does the
> MAC need to be involved? Or is it just the PHY?
> 
> If the MAC needs to be involved, the PHY should not be advertising
> EEE
> unless the MAC asks for it by calling phy_init_eee(). If this is
> true,
> maybe we need to change the realtek driver, and others in that class.

As far I understand, the advertised capabilities are exchanged during
the auto-negotiation.

At this stage, if the advertisement is disabled (regarless of the
actual support) on either side of the link, there will be no low power
idle state on the Tx nor the Rx path.

If the advertisement is enabled on both side but we don't call
phy_init_eee, I suppose Tx won't enter LPI, but Rx could.


> 
>       Andrew