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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <0f5dbce4-7d8e-4644-9a72-866ef256d26a@aquantia.com>
Date:   Fri, 14 Dec 2018 11:43:09 +0000
From:   Igor Russkikh <Igor.Russkikh@...antia.com>
To:     David Miller <davem@...emloft.net>,
        "andrew@...n.ch" <andrew@...n.ch>
CC:     "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Dmitry Bezrukov <Dmitry.Bezrukov@...antia.com>
Subject: Re: [PATCH net 0/2] aqc111: Thermal throttling feature

On 13.12.2018 3:43, David Miller wrote:
> From: Andrew Lunn <andrew@...n.ch>
> Date: Wed, 12 Dec 2018 21:38:46 +0100
> 
>> 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.
> 
> I completely agree with Andrew.
> 

Hi David, all,

Thank you all for your feedback. I basically agree with your arguments - 
at this stage it's really a better idea to put such a logic into HW/FW.

I've passed on that info to our FW team.

We are still relatively safe because I've got an info the FW already has
a thermal safety trigger. Now it just powers off the chip to eliminate the risk
of burnout.
In addition to that they've agreed to integrate the same hysteresis speeddown logic into FW.

I will resubmit the patch, but without the throttling logic, just
hwmon temperature sensor interface.

Regards,
  Igor