linux-kernel - Re: [PATCH v2 3/3] net: stmmac: Bring down the clocks to lower frequencies when mac link goes down

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 1 Jul 2024 12:18:19 -0700
From: Sagar Cheluvegowda <quic_scheluve@...cinc.com>
To: Andrew Halaney <ahalaney@...hat.com>
CC: Vinod Koul <vkoul@...nel.org>,
        Alexandre Torgue
	<alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        "David S.
 Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        "Jakub
 Kicinski" <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
        Maxime Coquelin
	<mcoquelin.stm32@...il.com>,
        Russell King <linux@...linux.org.uk>, "Rob
 Herring" <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        "Conor
 Dooley" <conor+dt@...nel.org>,
        Bhupesh Sharma <bhupesh.sharma@...aro.org>, <kernel@...cinc.com>,
        Andrew Lunn <andrew@...n.ch>, <linux-arm-msm@...r.kernel.org>,
        <netdev@...r.kernel.org>, <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] net: stmmac: Bring down the clocks to lower
 frequencies when mac link goes down



On 6/28/2024 2:50 PM, Sagar Cheluvegowda wrote:
> 
> 
> On 6/26/2024 7:58 AM, Andrew Halaney wrote:
>> On Tue, Jun 25, 2024 at 04:49:30PM GMT, Sagar Cheluvegowda wrote:
>>> When mac link goes down we don't need to mainitain the clocks to operate
>>> at higher frequencies, as an optimized solution to save power when
>>> the link goes down we are trying to bring down the clocks to the
>>> frequencies corresponding to the lowest speed possible.
>>>
>>> Signed-off-by: Sagar Cheluvegowda <quic_scheluve@...cinc.com>
>>> ---
>>>  drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 ++++++++
>>>  1 file changed, 8 insertions(+)
>>>
>>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> index ec7c61ee44d4..f0166f0bc25f 100644
>>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
>>> @@ -996,6 +996,9 @@ static void stmmac_mac_link_down(struct phylink_config *config,
>>>  {
>>>  	struct stmmac_priv *priv = netdev_priv(to_net_dev(config->dev));
>>>  
>>> +	if (priv->plat->fix_mac_speed)
>>> +		priv->plat->fix_mac_speed(priv->plat->bsp_priv, SPEED_10, mode);
>>> +
The above fix_mac_speed needs to be removed, i lately realized this mistake.
>>>  	stmmac_mac_set(priv, priv->ioaddr, false);
>>>  	priv->eee_active = false;
>>>  	priv->tx_lpi_enabled = false;
>>> @@ -1004,6 +1007,11 @@ static void stmmac_mac_link_down(struct phylink_config *config,
>>>  
>>>  	if (priv->dma_cap.fpesel)
>>>  		stmmac_fpe_link_state_handle(priv, false);
>>> +
>>> +	stmmac_set_icc_bw(priv, SPEED_10);
>>> +
>>> +	if (priv->plat->fix_mac_speed)
>>> +		priv->plat->fix_mac_speed(priv->plat->bsp_priv, SPEED_10, mode);
>>
>>
>> I think you're doing this at the beginning and end of
>> stmmac_mac_link_down(), is that intentional?
>>
>>
> 
> I realised that bringing down the clock to 10Mbps should be the last operation
> of the link down process, the reason being if we bring down the clocks first it will
> deprive essential internal clocks to DMA/MTL modules which are required for
> Cleanup operations this might cause excessive delays in stopping DMA
> or flusing MTL queues.
>  
>>