[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170828065545.GC2568@kwain>
Date: Mon, 28 Aug 2017 08:55:45 +0200
From: Antoine Tenart <antoine.tenart@...e-electrons.com>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Antoine Tenart <antoine.tenart@...e-electrons.com>,
davem@...emloft.net, kishon@...com, andrew@...n.ch,
jason@...edaemon.net, sebastian.hesselbarth@...il.com,
gregory.clement@...e-electrons.com,
thomas.petazzoni@...e-electrons.com, nadavh@...vell.com,
linux-kernel@...r.kernel.org, mw@...ihalf.com, stefanc@...vell.com,
miquel.raynal@...e-electrons.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 05/14] net: mvpp2: do not force the link mode
Hi Russell,
On Fri, Aug 25, 2017 at 11:43:13PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 25, 2017 at 04:48:12PM +0200, Antoine Tenart wrote:
> > The link mode (speed, duplex) was forced based on what the phylib
> > returns. This should not be the case, and only forced by ethtool
> > functions manually. This patch removes the link mode enforcement from
> > the phylib link_event callback.
>
> So how does RGMII work (which has no in-band signalling between the PHY
> and MAC)?
>
> phylib expects the network driver to configure it according to the PHY
> state at link_event time - I think you need to explain more why you
> think that this is not necessary.
Good catch, this won't work properly with RGMII. This could be done
out-of-band according to the spec, but that would use PHY polling and we
do not want that (the same concern was raised by Andrew on another
patch).
I'll keep this mode enforcement for RGMII then.
Thanks!
Antoine
--
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists