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

Sat Jun 3 10:20:39 PDT 2023

On Sat, Jun 03, 2023 at 11:44:04AM +0300, Arınç ÜNAL wrote:
> 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.

I agree that in an ideal world this how it should be.
However, in the practical world as it is that will result in massive
delays and add hardware support at a point in time that the hardware
is already EOL in many cases.

Let's look at one example: The BananaPi R3 devboard

MediaTek had already done a good job and managed to get basic support
for the MT7986 SoC landed in v5.17. Note that this is exceptional, most
chip vendors do not care at all to have support in mainline Linux ahead
of time.

First hardware samples of the R3 became available in May 2022, a few
months after you could buy the final hardware.

Upstreaming of board support and peripheral drivers started right away
when the hardware became available, most things are in v6.4 now but
some minor patches are still pending.

So that means that in order to support this hardware in OpenWrt 23.05
which is based on Linux 5.15 we needed to backport everything. Even for
v6.1 (ie. OpenWrt 2024.xx) we will still need to backport quite a bunch
of things, or wait for the next stable kernel release (and hence that
would mean OpenWrt 2025.xx).

As you can imagine, having the board supported only in 2025 is not a
viable option, supporting a devboard three years after it was launched
is too late.

> 
> - 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.

I understand your point, and especially DSA and phylink have been
problematic in that sense in the past. However, I don't see any other
good option than at least partially backporting also infrastructure
changes, at least to the level needed to support the hardware drivers
we need.

> 
> 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 at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel