@naughty_panda - thank you!
@bruce - thank you, genuinely. Publishing the wrapper and approaching RT are very appreciated. It clearly showed the value of open source with @naughty_panda being able to immediately use the source to pin two real bugs. I just confirmed both against GPL upstream:
Bug 1 - the PVID guard: rtl8366ub_sw_set_vlan_ports() reads the port's current PVID, ignores it, and overwrites unconditionally. The upstream it's derived from guards that set with if (pvid == 0) (only assign if the port has none). Without it, a port in two VLANs takes whichever was applied last as its PVID. This is almost certainly what's behind the prior @dsouza "native drops."
Bug 2 - swapped accessors: set_vlan_enable and get_vlan_enable have transposed bodies for "set" reads, "get" writes. So swconfig set enable_vlan 1 does nothing and show reads 0. (global_vlan_enable isn't wired to any hardware call regardless.) The upstream has both oriented correctly.
Both bugs are already fixed in the GPL original.
On the GPL topic we certainly understand the frustration, but (as a long-time Llnux dev) it's worth being very straight. Posting the wrapper alone doesn't close the GPL sect 3 gap. rtl8366ub_mdio.ko is MODULE_LICENSE("GPL"), calls GPL-only register_switch(), and (byte-identical comment block) is derived from rtl8366_smi.c - the copyright holder is Gabor Juhos & the OpenWrt project, not GL or Realtek.
The Realtek SDK can't be separated: on a live Brume3 (tested now), the rtk_* symbols resolve in neither vmlinux nor any other module, and the .ko is 431KB for a ~1100-line wrapper. The SDK is compiled into the GPL module itself - and §3 requires "all the source code for all modules it contains."
Here's the part to be very clear about: this module is a derivative of Gabor Juhos's GPLv2 code (the byte-identical comment block proves it), so the GPL governs the whole thing. Realtek owns their SDK and can NDA it as a standalone library if they choose, but that NDA cannot provide GL (or anyone else) authorization to ship it linked into a GPL-derivative kernel module without complete source.
That was never Realtek's call to make; it's Juhos's license, and GPL sect 7 is explicit: if you can't satisfy the GPL and the NDA at once then you can't distribute. So negotiating with Realtek is courtesy, not necessity. You already hold the copyright owner's permission to distribute via his GPL provided YOU publish the source.
GL only has 2 legally compliant positions: 1) stop distributing the Brume3 and its published firmware files, or publish the complete corresponding source. FULL STOP. It's GL's legal obligation, and RT has no standing to disagree - neither they nor GL can NDA someone else's copyright. (Probably worth the licensing team looking at how an NDA ended up trying to wrap around GPL'd code to begin with.)
When it comes to actual publishing, the RT/GL legal exit is narrower than "open the entire SDK." The RTL8366/67 family already has fully-GPL'd drivers (rtl8366rb/s, rtl8367/b) with zero rtk_* calls in any of them. They're all direct register access. The -ub module isn't in that set and isn't copy/paste (it IDs at reg 0x4=0x8366 vs RB's 0x0509=0x5937), but it's the same class of work.
So the requirement is just the -ub's register map, not the entire SDK. It's a managed switch with no firmware blob in the driver path for the Brume3, so far less code to guard than a radio. I get that Realtek legitimately NDAs things like RF calibration and firmware blobs; a host-side switch driver isn't that category. This publishing fixes compliance and both bugs at once.