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]

Message-ID: <fd5c86d8-4243-43d6-a07d-919ceeb12d82@quicinc.com>
Date: Fri, 28 Jun 2024 14:50:12 -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/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);
>> +
>>  	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.
 
>