[PATCH 1/2] net: rtl8169: add minimal support for 8125B variant

[Eugen Hristev]

On 4/30/23 22:44, Ramon Fried wrote:
> On Tue, Apr 25, 2023 at 10:47 PM Eugen Hristev
> <eugen.hristev at collabora.com> wrote:
>>
>> On 4/25/23 22:22, Ramon Fried wrote:
>>> On Tue, Apr 25, 2023 at 4:17 PM Eugen Hristev
>>> <eugen.hristev at collabora.com> wrote:
>>>>
>>>> On 4/25/23 16:06, Eugen Hristev wrote:
>>>>> Add minimal support for 8125B version.
>>>>> Changes are based on the Linux driver.
>>>>> Tested on Radxa Rock 5B Rk3588 board.
>>>>>
>>>>> Connection to a laptop worked fine in 100 Mbps mode.
>>>>> 1000 Mbps mode is not working at the moment.
>>>>>
>>>>> Signed-off-by: Eugen Hristev <eugen.hristev at collabora.com>
>>>>> ---
>>>>
>>>> The one thing that impacts all the rtl chips is the way the pci BAR is
>>>> now mapped.
>>>> I could not test this on another platform so help on this matter is
>>>> appreciated.
>>>>
>>>> Thanks!
>>>> Eugen
>>> Let's wait a bit to see if someone can test it. why did you change the
>>> mapping of the BAR ?
>>
>> It did not work with the old code. It provided a bad address, to some
>> area which did not have the right registers.
>> I looked into similar drivers and they were using this call, which works
>> perfectly for 8125b device
>>
>> Eugen
> Ok.
> Hopefully nothing breaks.
> Reviewed-by: Ramon Fried <rfried.dev at gmail.com>


Hello Ramon,

I have a question if you don't mind, maybe you are better suited to 
answer this :

In the case of rtl8169 which is a pci express device, the probing is 
done on demand (pci enum) or with MISC_INIT_R, anyway, the probing is 
done *after* the board init is done, and in case of rockchip, the board 
init will check if there is any 'ethaddr' set, and if not, set the 
ethaddr by generating an unique cpuid-based MAC. This happens, no 
ethaddr is set, and the MAC is generated.
However, when the rtl8169 probes, it has ofcourse a different hardware 
written MAC, but the uboot subsystem will deny it, and claim ethaddr is 
already set, and it will call the 8169 driver to rewrite its MAC.
This then happens, and Uboot will use the initial ethaddr (the one 
generated) for any kind of packets.
While this is not a problem at first glance, when Linux boots, it will 
read the MAC from rtl8169 ROM (even if uboot attempted to rewrite its 
MAC, being a ROM, it will not be written), and Linux will use a 
different MAC now.
Do you have any idea on how to solve this problem ? I would like that 
once rtl8169 driver probes, the initial ethaddr would be overwritten.

Thanks !