netdev - Re: [PATCH net-next v2 3/3] net: phy: marvell10g: set the PHY in low power by default

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, 4 Mar 2019 16:10:47 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Antoine Tenart <antoine.tenart@...tlin.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>, davem@...emloft.net,
        hkallweit1@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, thomas.petazzoni@...tlin.com,
        maxime.chevallier@...tlin.com, gregory.clement@...tlin.com,
        miquel.raynal@...tlin.com, nadavh@...vell.com, stefanc@...vell.com,
        mw@...ihalf.com
Subject: Re: [PATCH net-next v2 3/3] net: phy: marvell10g: set the PHY in low
 power by default

On Mon, Mar 04, 2019 at 11:47:00AM +0100, Antoine Tenart wrote:
> Hi Florian,
> 
> I agree having a per-driver behaviour is not something we want. As I
> understand it, there is no behaviour enforced currently regarding this
> matter. I agree both cases have their pros and cons:
> - It's weird to have an interface reporting being UP when it's not
>   really.

What about when an interface is listening for wake-on-lan packets?

Let's say board 1 is powered down and has WoL enabled.  Board 2 is
as per your configuration.  Board 2's interface reports that the
link is up.  Most of the packets that would be sent out the
interface end up disappearing into a black hole in the same way
as your original scenario.

How is this "weird" ?

There are many cases where exactly this happens - you are trying to
make one particular scenario behave "better" without considering
whether it's possible with all or even the majority of scenarios.

The only case where what you're suggesting makes sense is a point-to-
point link between two systems, which is not the norm.

More than that, when board 1 boots, initially the link will be up
from reset.  When the kernel eventually boots with your patch, the
link will then go down until board 1 configures the interface.  So,
board 2 sees that the interface comes up, and could assume that
board 1 is alive and well - but it isn't because (eg) it's in the
boot loader.

Basically, what I'm pointing out is that even in your minority
scenario, reasoning that board 2 should not see "link up" status
until board 1's interface is configured is not reasonable.

The link status is about the physical connectivity on the local
interface, it is not about the link between the interfaces on the
two machines.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up