[PATCH 4/4] gemini: Bump to kernel v6.1

[Arınç ÜNAL]

On 2.06.2023 10:18, Linus Walleij wrote:
> On Thu, Jun 1, 2023 at 11:20 PM Christian Lamparter <chunkeey at 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 <alsi at bang-olufsen.dk>
> and Luiz Angelo Daros de Luca <luizluca at 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.unal at 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ç