[PATCH 22.03] mvebu: cortexa9: disable devices using broken mv88e6176 switch
Christian Marangi
ansuelsmth at gmail.com
Thu Dec 1 05:43:42 PST 2022
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
--
Ansuel
More information about the openwrt-devel
mailing list