Message-ID: <20190305125407.GC3709@kwain>
Date:   Tue, 5 Mar 2019 13:54:07 +0100
From:   Antoine Tenart <antoine.tenart@...tlin.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Antoine Tenart <antoine.tenart@...tlin.com>,
        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

Hi Russell,

On Mon, Mar 04, 2019 at 04:10:47PM +0000, Russell King - ARM Linux admin wrote:
> On Mon, Mar 04, 2019 at 11:47:00AM +0100, Antoine Tenart wrote:
> > 
> > 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.

I see your point, in the WoL case the link would be reported as being up
as the PHY on board 1 would be functional (at least to process WoL
packets) so the link between the two PHYs would be established and
reporting a link being UP, but not entirely functional.

That's kind of a fair point, but not exactly the same. In such case some
packets might have an effect, whereas in the case I described earlier
not a single packet would make sense. But also I might not be aware of
other valid cases.

> 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.

This depends on the bootloader, but OK, that is what's happening in this
very case. I'm not fully convinced this relates to the scenario I
described. The link would be up and you're right could be not functional
because the way the bootloader works. And this is temporary.

> 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.

Right. The thing I find odd here is there is no physical connectivity
between the MACs (one is in reset), only between one MAC and the LP's
PHY. Given your definition of a link being up "between the interfaces",
OK, that makes sense if we talk about the PHYs. It also means we do not
have the same behaviour at boot time between an interface using a PHY,
and one directly connected to serdes lanes.

So, I don't have a strong opinion about this, and it's not a big issue
either way. I think the discussion moved into what should be the default
state of a PHY a probe time, as it seems there are no policy being
enforced right now.

Thanks,
Antoine

-- 
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Powered by blists - more mailing lists