[PATCH 22.03] mvebu: cortexa9: disable devices using broken mv88e6176 switch

Robert Marko robimarko at gmail.com
Thu Dec 1 05:49:37 PST 2022


On Thu, 1 Dec 2022 at 14:43, Christian Marangi <ansuelsmth at gmail.com> wrote:
>
> On Thu, Dec 01, 2022 at 02:39:56PM +0100, Robert Marko wrote:
> > On Thu, 1 Dec 2022 at 14:34, Christian Marangi <ansuelsmth at gmail.com> 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



More information about the openwrt-devel mailing list