| Message ID | 20230531212108.3252356-4-linus.walleij@linaro.org |
|---|---|
| State | Accepted, archived |
| Headers | show |
| Series | [1/4] gemini: Add kernel v6.1 patches | expand |
On 5/31/23 23:21, Linus Walleij wrote: > This bumps the Gemini kernel to use v6.1. There is no > reason to stay with v5.15, I personally use newer upstream > kernels constantly and they are tested and work well. Hmpf. Unfortunately, OpenWrt's 6.1 isn't ready yet. If I just set the KERNEL_VERSION to 6.1 then the build-bots will fail to produce images. If you want to look: There's this fortify-source bug in mac80211 ath9k that needs to be fixed first: https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568297522 https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568856473 https://github.com/openwrt/openwrt/pull/12764#issuecomment-1569473000 (And it looks like not all modules dependencies have been sorted out yet). For the time being. I could just change this to KERNEL_TESTING_PATCHVER=6.1 and leave KERNEL_PATCHVER at 5.15. (So, people can pick 6.1 when they do their own builds until the 6.1 woes have been sorted out?) Cheers, Christian > > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> > --- > target/linux/gemini/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile > index 4266db16cd37..b7f1962c9a59 100644 > --- a/target/linux/gemini/Makefile > +++ b/target/linux/gemini/Makefile > @@ -11,7 +11,7 @@ FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part > CPU_TYPE:=fa526 > SUBTARGETS:=generic > > -KERNEL_PATCHVER:=5.15 > +KERNEL_PATCHVER:=6.1 > > define Target/Description > Build firmware images for the StorLink/Cortina Gemini CS351x ARM FA526 CPU
On Thu, Jun 1, 2023 at 3:48 PM Christian Lamparter <chunkeey@gmail.com> wrote: > Hmpf. Unfortunately, OpenWrt's 6.1 isn't ready yet. If I just > set the KERNEL_VERSION to 6.1 then the build-bots will fail to > produce images. Aha how typical. > If you want to look: There's this fortify-source bug in mac80211 > ath9k that needs to be fixed first: > https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568297522 > https://github.com/openwrt/openwrt/pull/12764#issuecomment-1568856473 > https://github.com/openwrt/openwrt/pull/12764#issuecomment-1569473000 > > (And it looks like not all modules dependencies have been sorted out yet). Oh I really don't know my way around that code... > For the time being. I could just change this to > KERNEL_TESTING_PATCHVER=6.1 and leave KERNEL_PATCHVER at 5.15. > > (So, people can pick 6.1 when they do their own builds until the > 6.1 woes have been sorted out?) This works for me, it's nice to have it upstream rather than in my odd trees. Yours, Linus Walleij
On 6/1/23 15:50, Linus Walleij wrote: > On Thu, Jun 1, 2023 at 3:48 PM Christian Lamparter <chunkeey@gmail.com> wrote: > >> Hmpf. Unfortunately, OpenWrt's 6.1 isn't ready yet. If I just >> set the KERNEL_VERSION to 6.1 then the build-bots will fail to >> produce images. > > Aha how typical. hey, easy there ;) I think I might be able to explain why I resort to "sorry, but we are not ready yet" excuses based on this patch series. 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 . 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? Cheers, Christian 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")
On Thu, Jun 1, 2023 at 11:20 PM Christian Lamparter <chunkeey@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@bang-olufsen.dk> and Luiz Angelo Daros de Luca <luizluca@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@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
On 2.06.2023 10:18, Linus Walleij wrote: > On Thu, Jun 1, 2023 at 11:20 PM Christian Lamparter <chunkeey@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@bang-olufsen.dk> > and Luiz Angelo Daros de Luca <luizluca@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@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ç
On Sat, Jun 3, 2023 at 10:44 AM Arınç ÜNAL <arinc.unal@arinc9.com> wrote: > 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. My sympathies. Coming to OpenWrt from the outside I was amazed by the amount of out-of-tree efforts. But people have their reasons, such as making hardware useful for a wider audience. I personally try to compromise a bit, I backport if it is easy and effortless, otherwise I wait, that works for me. Yours, Linus Walleij
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@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@bang-olufsen.dk> > > and Luiz Angelo Daros de Luca <luizluca@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@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@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile index 4266db16cd37..b7f1962c9a59 100644 --- a/target/linux/gemini/Makefile +++ b/target/linux/gemini/Makefile @@ -11,7 +11,7 @@ FEATURES:=squashfs pci rtc usb dt gpio display ext4 rootfs-part boot-part CPU_TYPE:=fa526 SUBTARGETS:=generic -KERNEL_PATCHVER:=5.15 +KERNEL_PATCHVER:=6.1 define Target/Description Build firmware images for the StorLink/Cortina Gemini CS351x ARM FA526 CPU
This bumps the Gemini kernel to use v6.1. There is no reason to stay with v5.15, I personally use newer upstream kernels constantly and they are tested and work well. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> --- target/linux/gemini/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)