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

[Linus Walleij]

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ç?

Yours,
Linus Walleij