Re: [PATCH net-next 2/2] r8169: add support for reading over-temp threshold

[Heiner Kallweit <hkallweit1@gmail.com>]

On 07.01.2025 00:16, Andrew Lunn wrote:
>>> Does it reduce the speed in the same way as downshift? Can the user
>>> tell it has happened, other than networking is slower?
>>>
>> It internally disables 2.5G/5G advertisement and triggers an autoneg.
>> So you get the usual message on console/dmesg indicating the new speed.
>> This internal action sets a register bit, and it can also trigger an interrupt.
>> So it should be possible to check in the link_change_notify() callback
>> whether an over-temp event occurred. The silent change of the advertisement
>> may also result in the phylib-cached advertisement being out-of-sync.
>> So we would have to re-sync it. But I didn't fully test this yet.
>>
>> This patch only allows to read the over-temp threshold set as power-on default
>> or by the boot loader. It doesn't change the existing behavior.
> 
> Thanks for the details. So it does seem to be different to downshift,
> where generally advertised link modes in the registers is not changed,
> and the speed indicated in BMSR generally does not indicate the
> downshifted speed, you need vendor registers to get the actual
> speed. But downshift happens at link up, not latter when the device
> starts to overheat.
> 
> Does it restore advertisement to 2.5G/5G when it cools down? There is
> an interesting policy decision here. Do you want 1s downtime very so
> often as it speeds up and slows down, or should it keep at the slower
> speed until the user kicks it back up to the higher speed?
> 
I will do more testing and provide an update.

> 	Andrew
> 
Heiner