On Thu, 1 Dec 2022 at 14:43, Christian Marangi <[email protected]> wrote: > > On Thu, Dec 01, 2022 at 02:39:56PM +0100, Robert Marko wrote: > > On Thu, 1 Dec 2022 at 14:34, Christian Marangi <[email protected]> wrote: > > > > > > On Thu, Dec 01, 2022 at 02:23:08PM +0100, Josef Schlehofer wrote: > > > > On 01. 12. 22 14:19, Bjørn Mork wrote: > > > > > > > > > I assume KERNEL_PATCHVER in target/linux/mvebu/Makefile will be fixed > > > > > in > > > > > master as well, given that 5.10 is unsupportable on this target? > > > > > > > > > AFAIK What should be done is to put the kernel 5.15 as the default > > > > kernel > > > > for mvebu. Currently, it is only as the testing kernel. > > > > > > > > > > My 2 cent on this... A kernel upgrade is not viable for a stable > > > release. The problem here is simple... > > > > > > Things related to VLAN are broken in 5.10 and got fixed in 5.15. DSA is > > > ""easy enough"" to check all the changes related to VLAN and mvebu > > > switch and backport them to 5.10. (even warning some kernel guy once the > > > affected patch are found and sent to stable mailing list to ask greg to > > > be backported) > > > > > > Problem is that we currently lack manpower to bisect this and ideally by > > > disabling these target we will push the community on finding the > > > problem. > > > > > > Require some time but the fact that things are broken on 5.10 and are > > > fixed in 5.15 makes everything less hard to bisect... Someone can > > > totally have some fun building intermediate kernel 5.11, 5.12, 5.13 once > > > things starts to work so he can reduce the patch to check... > > > > > > AFAIK there were many changes to VLAN part and were totally related to > > > mvebu so it just require some user with the device and time to actually > > > bisect this. Once we have the affected commit we can totally backport > > > them and put the patch for the mvebu target and we will reenable the > > > affected devices. > > > > My bet is on one of the patches that are not backports but rather > > hacks/hotfixes > > carried only in OpenWrt. > > Even if it was just an upstream change that fixed it, its probably one > > of the hundreds > > that dont look even remotely related. > > > > Personally I dont have any of these devices and the switch is a rather > > rare model. > > > > That can also be a reason... But again it's just having fun with > starting from a clear start and see what it's broken... > > mvebu platform is full supported upstream so in theory someone can just > use a buildroot and compile a kernel... everything should work right > away
Yeah, it shouldn't be "that" hard, its just gonna take the time if you have the HW. Regards, Robert > > -- > Ansuel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
