On 2.06.2023 10:18, Linus Walleij wrote:
On Thu, Jun 1, 2023 at 11:20 PM Christian Lamparter <chunk...@gmail.com> wrote:
I looked into "how to get the old and new usb-fotg210" into one
"define KernelPackage/usb-fotg210". Thing is, you put backported
fotg's 6.2 infrastructure into your gemini's patches:
0002-usb-fotg210-Collect-pieces-of-dual-mode-controller.patch
(that's a big one!)
...
So, your gemini's 6.1 isn't the same as every other target in
regard to fotg210 there (that said, gemini is currently the
only user due to @TARGET_gemini. phew!). Due to the Makefile
and KConfig changes: in OpenWrt's vanilla 6.1 the module is still
fotg210-hcd(.ko), whereas gemini's 6.1 its been changed to fotg210(.ko).
So, to deal with this at least a little bit, I just moved it to
target/linux/gemini/modules.mk .
I checked it, wow these @lt6.1 etc I would never have figured out
so thanks a lot for stepping in on this!
That said: This should be worth it? Reason being that since all
this extra time spend, should make the target+fotg210 ready for
the upcoming, next stable release (v6.6/7?), right?
Apart from tidying up the code, it makes the device mode work on
the DNS-313 actually, so it's not just cosmetic, I have been able
to use the USB port for serial, I just need to figure out how to get
OpenWrt to open a secondary console on it and people can get
serial access without soldering.
(The original use of the device USB port on that device is USB mass
storage, but that was an extreme hack on the original device, including
a plastic cover that shift over the USB port when connected to network
so you cannot use network and USB at the same time to access the
same file partition...)
BTW: Do you have some time to look into realtek's DSA for the
RTL8363SB? I'm converting some of the APM821xx Devices
to DSA and the rtl8365mb seems promising. I've seen that you did
some major work there. But there are some snags that I'm not sure
are limited to the RTL8363SB (access through MDIO needs different
code. And what's up with the CPU-Port or Extif?) or not.
(will post to the appropriate ML for that in the "upcoming months")
I don't have any device with this DSA on it, but certainly I'm available
for questions and review. But Alvin Šipraga <a...@bang-olufsen.dk>
and Luiz Angelo Daros de Luca <luizl...@gmail.com> have been very
helpful with the upstream code for RTL8365MB, and it also "should"
support RTL8363SC so I would be surprised if RTL8363SB is any
different.
So best case if you can boot the upstream kernel (or backport all the
patches to drivers/net/dsa/realtek...) the RTL8365MB driver:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/dsa/realtek/rtl8365mb.c
just edit rtl8365mb_chip_infos[] to include the magic for RTL8363SB
and see if it magically works. You probably need a jam table magic
sequence from the vendor driver if you have that.
The upstream device tree for ASUS RT AC88U has the
8365MB courtesy of Arınç ÜNAL <arinc.u...@arinc9.com>:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/bcm47094-asus-rt-ac88u.dts
If you just copy/paste that +/- some changes it should probe, all
devices use compatible = "realtek,rtl8365mb"; no matter which
variant it is. Arınç has also been very helpful with this code, and I
think we wanna bring in the RTL8365MB patches at least for
BCM53xx for v6.1 (but I think we should probably put them into
linux/generic).
I think Arınç already has plans to bring this to OpenWrt for v6.1
though, Arınç?
I prefer to stay away from backporting features to older Linux versions.
The reasons being:
- OpenWrt will eventually use a kernel version by default which will
have the feature. It doesn't satisfy me to do all that work just for
some OpenWrt devices to use this feature earlier. I would rather just
make OpenWrt use the kernel version that's already got the feature. I
already have some efforts to improve the current way to do this, I had a
presentation on Battlemesh v15 regarding this and more.
- The backporting process can become messy, and the backported code is
prone to all sorts of possible issues. I don't want to debug any issues
either caused or possibly caused by backporting features.
These aside, I would refrain from using the RTL8365MB DSA subdriver
until the bridge offloading feature is implemented. Me, Luiz, and Alvin
had a private conversation regarding this back on 15th of January 2023.
Shortly put, Alvin's working on an implementation which uses Independent
VLAN Learning (IVL) rather than Shared VLAN Learning, and makes use of
isolated filtering databases.
Arınç
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
