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:   Mon, 20 Mar 2017 10:43:48 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Niklas Cassel <niklas.cassel@...s.com>, peppe.cavallaro@...com,
        alexandre.torgue@...com, Joao.Pinto@...opsys.com
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Niklas Cassel <niklass@...s.com>
Subject: Re: [PATCH net-next] stmmac: call stmmac_init_phy from
 stmmac_dvr_probe

On 03/20/2017 10:29 AM, Niklas Cassel wrote:
> From: Niklas Cassel <niklas.cassel@...s.com>
> 
> It is usually possible to do
> ethtool -s autoneg on
> so that you trigger an autoneg before calling
> ip link set dev eth0 up

This is completely driver specific and there is no guarantee for this to
work universally across all device drivers because when your interface
is brought down, the most sensible thing to expect in return is that
your PHY is powered down (unless your interface participates in
Wake-on-LAN).

> 
> However, stmmac returns -EBUSY if !netif_running.
> The only reason for this appears to be that stmmac_init_phy
> is called from stmmac_open instead of from stmmac_dvr_probe.
> 
> Move stmmac_init_phy to stmmac_dvr_probe so that ethool
> works as soon as register_netdev has been called.
> stmmac_check_ether_addr was also moved to probe,
> so that the ordering doesn't change.

Are you sure this is a good idea? There are many drivers that moved the
PHY probe into ndo_open() for mainly two things:

- phy_connect() starts the PHY state machine and starting the state
machine without a network device running is kind of wasting cycles

- if the interface is probed, but not used, you are keeping the Ethernet
link running without being able to service packets, which is at best a
waste of power
--
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ