This patches introduce the thermal throttling feature to prevent possible
heat damage to the hardware.
Dmitry Bezrukov (2):
net: usb: aqc111: Add read_mdio operation
net: usb: aqc111: Support for thermal throttling feature
drivers/net/usb/aqc111.c | 83 ++++++++++++++++++++++++++++++++++++++++
drivers/net/usb/aqc111.h | 19 +++++++++
2 files changed, 102 insertions(+)
Hi David, all,
This is of course designated for the "net-next" tree.
I'll resubmit this after review.
The idea of having the PHY/network device as a cooling agent is
something valuable, but as Andrew pointed out, you need to expose this
as a standard HWMON device, and you need to let user-space implement the
appropriate thermal policy, not do that in the network driver underneath
the user's feet with no feedback other than link dropped, got
re-negotiated at a different speed. How would one be able to
differentiate those events from a faulty link partner for instance?
None of what you are doing here is specific to your device driver and
the policy of downgrading the link speed to lower the thermal budget is
something that is nearly universally applicable to all network
equipments because higher speeds just require higher power.
--
Florian
From: Igor Russkikh <hidden> Date: 2018-12-12 20:08:16
The idea of having the PHY/network device as a cooling agent is
something valuable, but as Andrew pointed out, you need to expose this
as a standard HWMON device, and you need to let user-space implement the
appropriate thermal policy, not do that in the network driver underneath
the user's feet with no feedback other than link dropped, got
re-negotiated at a different speed. How would one be able to
differentiate those events from a faulty link partner for instance?
None of what you are doing here is specific to your device driver and
the policy of downgrading the link speed to lower the thermal budget is
something that is nearly universally applicable to all network
equipments because higher speeds just require higher power.
Hi Florian,
Partially agreed with you, but as far as I know there is no much of
ready to use infrastructure for this to use right now?
IMHO that could be a both-way solution, where short term driver patch
will secure against hardware burn out right now, and long term hwmon
based infrastructure could handle that on userspace level.
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.
Regards,
Igor
The idea of having the PHY/network device as a cooling agent is
something valuable, but as Andrew pointed out, you need to expose this
as a standard HWMON device, and you need to let user-space implement the
appropriate thermal policy, not do that in the network driver underneath
the user's feet with no feedback other than link dropped, got
re-negotiated at a different speed. How would one be able to
differentiate those events from a faulty link partner for instance?
quoted
None of what you are doing here is specific to your device driver and
the policy of downgrading the link speed to lower the thermal budget is
something that is nearly universally applicable to all network
equipments because higher speeds just require higher power.
Hi Florian,
Partially agreed with you, but as far as I know there is no much of
ready to use infrastructure for this to use right now?
If you use programs like thermald, I am quite positive you could script
and action which involves re-negotiation of the link at a lower speed
and that would be something applicable to a variety of network devices.
IMHO that could be a both-way solution, where short term driver patch
will secure against hardware burn out right now, and long term hwmon
based infrastructure could handle that on userspace level.
The short term and most effective solution would be to have the firmware
running on the device do the thermal throttling, that way, if the host
CPU is crashed/unresponsive, you can still take corrective actions. Your
response to Andrew seems to suggest this is not possible, so if we are
reaching the critical junction temperature of your chip and that in
turn, causes the enclosure to melt down, then clearly the runaway
solution is not good.
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.
My problem with your approach is people doing the same thing to each and
every one of their driver and building policy, as opposed to mechanisms
in the kernel. If the argument is "user space may not be running a
thermal solution", then clearly you need a hardware driven (or firmware
driven) approach) which works across all possible use cases, including
those where appropriate SW is not there.
If you look at how your desktop PC likely manages the fans in the
chassis, they can be SW controlled, or ACPI controlled, for the same
reasons.
--
Florian
From: Andrew Lunn <andrew@lunn.ch> Date: 2018-12-12 20:38:51
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
From: David Miller <davem@davemloft.net> Date: 2018-12-13 00:18:26
From: Igor Russkikh <redacted>
Date: Wed, 12 Dec 2018 13:50:06 +0000
This patches introduce the thermal throttling feature to prevent possible
heat damage to the hardware.
I see what seems to be a bit of a conflict here, maybe you can explain
the situation better to me.
Andrew suggested that the firmware manage the thermal aspects of the
PHY since it manages all other aspects of the PHY too.
And then the feedback was that the firmware folks don't want to do
that right now.
But then it was also stated that the long term goal is to support
what Andrew asked for, firmware update in the driver and updated
firmwares submitted to linux-firmware.
If the firwmare will eventually have support for thermal management
added, then the code in this series is going to be not used and
just taking up space.
Please explain how all of this is going to fit together, and how we'll
not end up with having to keep this thermal code around forever.
Thanks.
From: David Miller <davem@davemloft.net> Date: 2018-12-13 00:43:05
From: Andrew Lunn <andrew@lunn.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.
From: Igor Russkikh <hidden> Date: 2018-12-14 11:43:13
On 13.12.2018 3:43, David Miller wrote:
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 12 Dec 2018 21:38:46 +0100
quoted
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