[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <32662205-67f5-694d-b5cb-6e7fce40e3eb@gmail.com>
Date: Fri, 26 May 2023 09:13:55 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: Andrew Lunn <andrew@...n.ch>, Oleksij Rempel <o.rempel@...gutronix.de>
Cc: netdev <netdev@...r.kernel.org>, Heiner Kallweit <hkallweit1@...il.com>,
Russell King <rmk+kernel@...linux.org.uk>,
Oleksij Rempel <linux@...pel-privat.de>
Subject: Re: [RFC/RFTv3 00/24] net: ethernet: Rework EEE
On 5/26/23 05:08, Andrew Lunn wrote:
> On Fri, May 26, 2023 at 10:56:04AM +0200, Oleksij Rempel wrote:
>> Hi Andrew,
>>
>> On Fri, Mar 31, 2023 at 02:54:54AM +0200, Andrew Lunn wrote:
>>> Most MAC drivers get EEE wrong. The API to the PHY is not very
>>> obvious, which is probably why. Rework the API, pushing most of the
>>> EEE handling into phylib core, leaving the MAC drivers to just
>>> enable/disable support for EEE in there change_link call back, or
>>> phylink mac_link_up callback.
>>>
>>> MAC drivers are now expect to indicate to phylib/phylink if they
>>> support EEE. If not, no EEE link modes are advertised. If the MAC does
>>> support EEE, on phy_start()/phylink_start() EEE advertisement is
>>> configured.
>>>
>>> v3
>>> --
>>
>> I was able to test some drivers and things seems to work ok so far. Do you
>> need more tests for a non RFC version?
>
> No, i just need time to rebase and post them. Plus check if there are
> more drivers which added support for EEE and fix them up. There is a
> new Broadcom driver which i think will need work.
The Broadcom ASP driver should have EEE stripped off as we just found
out that the MAC does not drive the PHY signals properly yet. This
should allow your series to proceed through, without having to care
about that particular driver.
Thanks for doing this work Andrew!
--
Florian
Powered by blists - more mailing lists