netdev - Re: [PATCH 0/2] net: stmmac: add DT parameter to keep RX

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: <Y8/mrhWDa6DuauZY@lunn.ch>
Date:   Tue, 24 Jan 2023 15:09:50 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Andrey Konovalov <andrey.konovalov@...aro.org>
Cc:     davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
        pabeni@...hat.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, alexandre.torgue@...s.st.com,
        peppe.cavallaro@...com, joabreu@...opsys.com,
        mcoquelin.stm32@...il.com, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 0/2] net: stmmac: add DT parameter to keep RX_CLK running
 in LPI state

> > Could
> > dwmac-qcom-ethqos.c just do this unconditionally?
> 
> Never stopping RX_CLK in Rx LPI state would always work, but the power
> consumption would somewhat increase (in Rx LPI state). Some people do care
> about it.
>
> > Is the interrupt
> > controller part of the licensed IP, or is it from QCOM? If it is part
> > of the licensed IP, it is probably broken for other devices as well,
> > so maybe it should be a quirk for all devices of a particular version
> > of the IP?
> 
> Most probably this is the part of the ethernet MAC IP. And this is quite
> possible that the issue is specific for particular versions of the IP.
> Unfortunately I don't have the documentation related to this particular
> issue.

Please could you ask around. Do you have contacts in Qualcomm?
Contacts at Synopsys?

Ideally it would be nice to fix it for everybody, not just one SoC.

As for power consumption, EEE is negotiated. You could look at the
results of autoneg, and only enable this workaround if EEE is actually
part of the resolved results. And maybe look into the clock source,
and only enable this work around if the PHY is the clock source.

	Andrew