Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

On 12.07.2018 21:53, Florian Fainelli wrote: > > > On 07/12/2018 12:25 PM, Florian Fainelli wrote: >> >> >> On 07/12/2018 12:10 PM, Heiner Kallweit wrote: >>> On 12.07.2018 21:09, Andrew Lunn wrote: > Like r8169 also tg3 driver doesn't wait for the speed-down-renegotiation > to finish. Th

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

On 07/12/2018 12:25 PM, Florian Fainelli wrote: > > > On 07/12/2018 12:10 PM, Heiner Kallweit wrote: >> On 12.07.2018 21:09, Andrew Lunn wrote: Like r8169 also tg3 driver doesn't wait for the speed-down-renegotiation to finish. Therefore, even though I share Andrew's concerns, there

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

On 07/12/2018 12:10 PM, Heiner Kallweit wrote: > On 12.07.2018 21:09, Andrew Lunn wrote: >>> Like r8169 also tg3 driver doesn't wait for the speed-down-renegotiation >>> to finish. Therefore, even though I share Andrew's concerns, there seem >>> to be chips where it's safe to not wait for the re

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

On 12.07.2018 21:09, Andrew Lunn wrote: >> Like r8169 also tg3 driver doesn't wait for the speed-down-renegotiation >> to finish. Therefore, even though I share Andrew's concerns, there seem >> to be chips where it's safe to not wait for the renegotiation to finish >> (e.g. because device is in PCI

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

> Like r8169 also tg3 driver doesn't wait for the speed-down-renegotiation > to finish. Therefore, even though I share Andrew's concerns, there seem > to be chips where it's safe to not wait for the renegotiation to finish > (e.g. because device is in PCI D3 already and can't generate an interrupt)

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

On 11.07.2018 23:59, Heiner Kallweit wrote: > On 11.07.2018 23:33, Florian Fainelli wrote: >> >> >> On 07/11/2018 02:08 PM, Heiner Kallweit wrote: >>> On 11.07.2018 22:55, Andrew Lunn wrote: > +/** > + * phy_speed_down - set speed to lowest speed supported by both link > partners >

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

On 11.07.2018 23:33, Florian Fainelli wrote: > > > On 07/11/2018 02:08 PM, Heiner Kallweit wrote: >> On 11.07.2018 22:55, Andrew Lunn wrote: +/** + * phy_speed_down - set speed to lowest speed supported by both link partners + * @phydev: the phy_device struct + * @sync:

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

On 07/11/2018 02:08 PM, Heiner Kallweit wrote: > On 11.07.2018 22:55, Andrew Lunn wrote: >>> +/** >>> + * phy_speed_down - set speed to lowest speed supported by both link >>> partners >>> + * @phydev: the phy_device struct >>> + * @sync: perform action synchronously >>> + * >>> + * Description

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

On 11.07.2018 22:55, Andrew Lunn wrote: >> +/** >> + * phy_speed_down - set speed to lowest speed supported by both link >> partners >> + * @phydev: the phy_device struct >> + * @sync: perform action synchronously >> + * >> + * Description: Typically used to save energy when waiting for a WoL pack

Re: [PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

> +/** > + * phy_speed_down - set speed to lowest speed supported by both link partners > + * @phydev: the phy_device struct > + * @sync: perform action synchronously > + * > + * Description: Typically used to save energy when waiting for a WoL packet > + */ > +int phy_speed_down(struct phy_device

[PATCH net-next 2/2] net: phy: add phy_speed_down and phy_speed_up

Some network drivers include functionality to speed down the PHY when suspending and just waiting for a WoL packet because this saves energy. This functionality is quite generic, therefore let's factor it out to phylib. Signed-off-by: Heiner Kallweit --- drivers/net/phy/phy.c | 78 ++