netdev - Re: [PATCH net 0/2] aqc111: Thermal throttling feature

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 12 Dec 2018 21:38:46 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Igor Russkikh <Igor.Russkikh@...antia.com>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Dmitry Bezrukov <Dmitry.Bezrukov@...antia.com>
Subject: Re: [PATCH net 0/2] aqc111: Thermal throttling feature

> A whole separate concern is how much userspace should be involved here.
> It could be a very device specific (and therefore driver specific) logic
> on how to do device's thermal control.

Hi Igor

Well, if you fully expose the PHY to Linux using a PHY driver, it
would not be device specific at all. The PHY layer knows how to ask
the PHY to drop to lower speeds. The Marvell PHYs with their
temperature sensors could also use this core code.

You are running into trouble because you want to both to hide the PHY
from Linux, but also have Linux control the PHY to avoid it melting.
This is why i actually think you should be doing this in firmware.

     Andrew