[PATCH v2 0/2] realtek: fix L2 entry setup and learning on CPU port

[Jan Hoffmann]

On 26.10.22 at 10:20, Sander Vanheule wrote:
> Hi Jan,
> 
> On Wed, 2022-10-26 at 00:20 +0200, Jan Hoffmann wrote:
>> This is a follow-up to the patch "realtek: don't set L2LEARNING flag in
>> rtl83xx TX header". An undesired effect of that patch is flooding of
>> some packets destined for the switch CPU port, which is addressed by
>> this additional patch series.
>>
>> This patch series switches to assisted learning for the CPU port on all
>> devices, and also fixes some existing issues with setup of unicast L2
>> entries.
>>
>> Together with the kernel 5.15 pull request, entries for local/bridge
>> addresses are added to the switch. I am still not sure why that doesn't
>> work with the patches in the current kernel. However, the pull request
>> for the kernel update seems to be in a good shape, so I don't think it
>> is worth it to investigate that any further.
>>
>> Tested on RTL838x (HPE 1920-8G) and RTL839x (HPE 1920-48G).
>>
>> Changes in v2:
>>   - don't explicitly specify struct name as parameter to sizeof
>>   - make calculation of SALRN shift offset clearer
>>   - define SALRN values, mask and shift offset in header
>>
>> Jan Hoffmann (2):
>>    realtek: set up L2 table entries properly
>>    realtek: use assisted learning on CPU port
>>
>>   .../files-5.10/drivers/net/dsa/rtl83xx/dsa.c  | 45 ++++++++++++++-----
>>   .../drivers/net/dsa/rtl83xx/rtl838x.h         |  6 +++
>>   2 files changed, 41 insertions(+), 10 deletions(-)
> 
> Thanks for the respin! Both patches have been applied on master.

Thank you for applying the patches.

My intention for this series was for it to be applied in addition to the 
previous patch "realtek: don't set L2LEARNING flag in rtl83xx TX 
header", but that patch isn't applied. I guess my wording in the cover 
letter was somewhat ambiguous here, and maybe I should have just 
included the change in this series.

However, in terms of actual functionality it shouldn't matter anyways, 
as the L2LEARNING flag in the TX header doesn't have any effect now that 
learning is disabled using the SALRN register. In the end, it just means 
that the explanation of the FDB corruption issue isn't in the Git 
history, and the commit message of eb456aedfe24 ("realtek: use assisted 
learning on CPU port") is now slightly confusing, as it references the 
change to the TX header which doesn't actually exist.

Best,
Jan