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:   Fri, 5 Mar 2021 20:26:41 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Michael Chan <mchan@...adcom.com>,
        "open list:BROADCOM ETHERNET PHY DRIVERS" 
        <bcm-kernel-feedback-list@...adcom.com>,
        open list <linux-kernel@...r.kernel.org>, michael@...le.cc
Subject: Re: [PATCH net-next v2 3/3] net: phy: broadcom: Allow BCM54210E to
 configure APD



On 3/4/2021 5:08 PM, Vladimir Oltean wrote:
> On Tue, Mar 02, 2021 at 07:37:34PM -0800, Florian Fainelli wrote:
>> Took a while but for the 54210E reference board here are the numbers,
>> your mileage will vary depending on the supplies, regulator efficiency
>> and PCB design around the PHY obviously:
>>
>> BMCR.PDOWN:			86.12 mW
>> auto-power down:		77.84 mW
> 
> Quite curious that the APD power is lower than the normal BMCR.PDOWN
> value. As far as my understanding goes, when in APD mode, the PHY even
> wakes up from time to time to send pulses to the link partner?

Auto-power down kicks in when the cable is disconnected. There is
another IDDQ mode that supports energy detection though I am unsure of
when it would be useful for most Linux enabled systems.

> 
>> auto-power-down, DLL disabled:  30.83 mW
> 
> The jump from simple APD to APD with DLL disabled is pretty big.
> Correct me if I'm wrong, but there's an intermediary step which was not
> measured, where the CLK125 is disabled but the internal DLL (Delay
> Locked Loop?) is still enabled. I think powering off the internal DLL
> also implies powering off the CLK125 pin, at least that's how the PHY
> driver treats things at the moment. But we don't know if the huge
> reduction in power is due just to CLK125 or the DLL (it's more likely
> it's due to both, in equal amounts).

Agree, I do not have the break down though.

> 
> Anyway, it's great to have some results which tell us exactly what is
> worthwhile and what isn't. In other news, I've added the BCM5464 to the
> list of PHYs with APD and I didn't see any issues thus far.
> 
>> IDDQ-low power:			 9.85 mW (requires a RESETn toggle)
>> IDDQ with soft recovery:	10.75 mW
>>
>> Interestingly, the 50212E that I am using requires writing the PDOWN bit
>> and only that bit (not a RMW) in order to get in a correct state, both
>> LEDs keep flashing when that happens, fixes coming.
>>
>> When net-next opens back up I will submit patches to support IDDQ with
>> soft recovery since that is clearly much better than the standard power
>> down and it does not require a RESETn toggle.
> 
> Iddq must be the quiescent supply current, isn't it (but in that case,
> I'm a bit confused to not see a value in mA)? Is it an actual operating
> mode (I don't see anything about that mentioned in the BCM5464 sheet)
> and if it is, what is there exactly to support?

You would put the PHY in IDDQ with soft recovery (or ultra low power)
when you are administratively bringing down the network interface (and
its PHY), or when suspending to a low power state where Wake-on-LAN is
not enabled.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ