Thank you for the proposed patch.
My highest concern is: Is this patch going to be submitted officially without my involvement ?
I have multiple times tried getting something done, even when I was maintaing one driver. I got burned out fighting with stubborn maintainers that did not share the philosophy that it ought to work for everyone, and not just the group with the popular hardware.

Thank you, especially as you have the necessary information on PHY registers.

I must add one thing, from a long experience in hardware programming (my field).
Unless you are within a couple steps and strangling distance of whoever else might also be accessing those registers, never, never, ever, assume they are going to leave them set to the bank you want to use.

The reset to the proper bank ought to be an assumed necessity for any access to the PHY, and any hardware register. It will not break anything (usually).
Even if are close enough to negotiate by strangling, it is most often easiest to just make setting the register bank a part of register addressing every time.
I must assume that the BIOS is not going to be allowed to touch those registers again, or at least the bank select would have to be init again if any such BIOS call was allowed.

Yeah, it's very disturbing and frustrating when hardware vendors choose not to provide Qussi-free drivers. I can remember back in the day when you wanted to get Broadcom NICs working under Linux you had to use the bw-cutter package to download and repackage the Windows driver.

I find the phylib change odd for you, since phylib did not appear in 5.10. This has been a slow ongoing thing, and the maintainer must have been trying to bring the driver up to current expectations without knowing enough about the hardware to do it correctly.

Are you speaking of the realtek nic maintainers? Or other devs now like this? I've only seen the devs, especially the high level devs, really interested in just making things work. But it's been many many years since I've had to interact with them. I kind of figure it may be the attitude of the realtek maintainers, due to what they think of the vendor or something.

I also agree, this is always been my expectation to never assume the status of the registers. Of course, the devs just might have missed the existence of the pages, but still...

With the current philosophy of 'making nothing easy for hackers' it would be prudent to reset the register bank to the default every time and select (or randomize)your chosen bank. Anyhow, that's a moot point.

I was in hardware too, but the component side during the 80/90s/00s. I specialised where my customer needed expertise. I did only a little very low level programming. I didn't have a program to write - I had this filthy, smelly, hulking great machine to fix while the customer was losing hundreds/thousands per hour! Companies here can't afford that. Nobody went bankrupt over a breakdown I was called to but more than a few went close. I didn't die from getting zapped, either, but many others would have.

I got phy_id: 0xc2077002
bash-5.1$ find /sys -name phy_id
/sys/devices/pci0000:00/0000:00:0a.0/0000:04:00.0/mdio_bus/r8169-0-400/r8169-0-400:00/phy_id
bash-5.1$ cat /sys/devices/pci0000:00/0000:00:0a.0/0000:04:00.0/mdio_bus/r8169-0-400/r8169-0-400:00/phy_id
0xc2077002

---
No I am NOT speaking of the nic realtek maintainers, but several other drivers that I have had to patch (serial mouse, console, and something older that I forget).
The serial mouse was similar to this, where they updated the driver for unrelated reasons and broke the support for my serial mouse track ball.
They decided to fix it in a marginal way cause they thought my hardware was not worth supporting anymore (I do not know what hardware they used to test this fix) and would not use any part of my freely supplied patch, which I had tested. Shortly later the track ball broke.

---
Do not get to choose a bank. The device grew until there were too many hardware registers for the addressing window, so they must be bank accessed.
Messing with the bank select is not going to hinder any malicious code. Setting the bank is part of selecting the register access, and is too easy. The worst you could do is leave it set to a particular odd bank, and check later that it was still set to that odd bank (how??). Even that will not help much if the bank select can be read back (they usually cannot) or otherwise detected.
I actually had this problem occur in a corporate project. Fixed by going though entire code base and making the register bank select part of the device accessing function, removing assumptions that it must be left set in any particular way, and no longer returning it to previous bank settings.

I just realized now that even though the previous patch fixed the phy_id on boot, something trashes the necessary register and reading from phy_id here returns an incorrect result again. This means there is still a problem with the driver in the case of reading phy_id once more through /sys. I think this has pointed to the kernel driver being the culprit all along.

Has the driver maintainer been contacted with the new information?

I have scanned the thread but not read each and every word, so bear with me if it has been mentioned before:

You could recompile just the one kernel module you need. If I understood correctly, there is a driver coming with the stock kernel and you have a patch. It's the same for me with my onboard laptop sound card - without recompiling I won't get the internal microphone to work. It took too long for me to recompile a new kernel everytime (being on current there are many upgrades), so I chose to read into recompiling only one module and created an ugly bash script for my machine to apply the patch against the newest kernel, recompile that module, generate a new initrd.gz and do the needed boot loader modifications. This way I have a working kernel within a minute. Buying another NIC might be the easier solution, but surely my way should be the least cost and time intensive solution

If you need my script as an idea how to apply it on your machine and with your kernel module, please feel free to ask for it.

If you use slackpkg for the upgrades you could additionally add a reminder or something similiar towards the end of /usr/libexec/slackpkg/functions.d/post-functions.sh to remind you about recompiling that specific kernel module with the patch you have. So you could not forget as easily. Or if you are not faint-hearted hack it to apply the mentioned changes that I have in a separate bash script