realtek: Setup all VLANs with default configurations

[Birger Koblitz]

Hi,
> Actually, you don't have to disable the profile_setups.  This change is
> sufficient to make VLANs work (at least in the limited testing I've done):
>
>
> diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
> index dfd773c5e6fc..5d764b6a32d6 100644
> --- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
> +++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
> @@ -398,7 +398,7 @@ static void rtl838x_vlan_profile_setup(int profile)
>           * On RTL93XX, the portmask is directly set in the profile,
>           * see e.g. rtl9300_vlan_profile_setup
>           */
> -       rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0xfffffff);
> +       rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x1fffffff);
>   }
>   
>   static inline int rtl838x_vlan_port_egr_filter(int port)
>
>
> No idea why or how.  Just a magic value with a magic result, like most
> of the code.
Come on Björn, it wasn't so magic if you could figure that out although 
you hadn't seen the code before. There is more and more understanding on 
how this piece of hardware works, even though we only have an SDK which 
is spaghetti and magic sauce and you might have noticed there are more 
and more comments in the latest additions.

Yes, that was indeed my mistake, the second parameter is the mask of 
ports MC packets are flooded to as long as a multicast group has not 
been set up by the bridge, port 28 (= BIT 28) being the CPU port on the 
8380. I thought all relevant traffic would anyway be trapped to the CPU, 
I did quite some testing setting up the traps. I was evidently wrong.
> I really don't think these changes have been tested well enough to be
> pushed into openwrt master yet.  Based on this first impression, I would
> be surprised if there isn't more broken stuff.
I asked for testing of this set of patches in the rtl83xx irc a week ago 
and the code was on GitHub since then. I got no feedback up til now when 
it ended up in master.
I'll post a patch for all the architectures for this problem.


Cheers,
   Birger