[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180710214003.GB29156@lunn.ch>
Date: Tue, 10 Jul 2018 23:40:03 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: David Miller <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Realtek linux nic maintainers <nic_swsd@...ltek.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next v2 07/10] r8169: migrate speed_down function to
phylib
On Tue, Jul 10, 2018 at 11:26:13PM +0200, Heiner Kallweit wrote:
> On 10.07.2018 22:44, Andrew Lunn wrote:
> >> static void rtl_speed_down(struct rtl8169_private *tp)
> >> {
> >> - u32 adv;
> >> - int lpa;
> >> + struct phy_device *phydev = tp->dev->phydev;
> >> + u32 adv = phydev->lp_advertising & phydev->supported;
> >>
> >> - rtl_writephy(tp, 0x1f, 0x0000);
> >> - lpa = rtl_readphy(tp, MII_LPA);
> >> + if (adv & BASET10)
> >> + phydev->advertising &= ~(BASET100 | BASET1000);
> >> + else if (adv & BASET100)
> >> + phydev->advertising &= ~BASET1000;
> >
> > Please use phy_set_max_speed(). We need MAC drivers to stop directly
> > accessing phydev members. Otherwise we are going to have problems
> > supporting 2.5G PHYs.
> >
> The issue I see with phy_set_max_speed() is that it also adjusts
> phydev->supported and I don't think that's what we want.
> What the chip supports doesn't change, just what we want to
> advertise.
True.
Which is one more reason to do it inside phylib.
Andrew
Powered by blists - more mailing lists