[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d78ee41f-ca6c-4dd9-8266-c55993ca1313@gmail.com>
Date: Tue, 7 Jan 2025 08:06:48 +0100
From: Heiner Kallweit <hkallweit1@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Realtek linux nic maintainers <nic_swsd@...ltek.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Eric Dumazet <edumazet@...gle.com>, David Miller <davem@...emloft.net>,
Andrew Lunn <andrew+netdev@...n.ch>, Simon Horman <horms@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/2] r8169: add support for reading over-temp
threshold
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
Powered by blists - more mailing lists