On Tue, Mar 30, 2021 at 2:43 AM Rui Salvaterra <[email protected]> wrote:
>
> On Tue, 16 Mar 2021 at 09:02, Rui Salvaterra <[email protected]> wrote:
> >
> > Although the title is trivial, the potential impact of these changes is 
> > enough
> > in itself to warrant more extensive justification, which follows:
> >
> > 202-weak_reordering.patch - In order to fix random hangs on MT7621, we've 
> > been
> > selecting WEAK_REORDERING_BEYOND_LLSC for years [1]. However, these random 
> > hangs
> > have been most likely caused by an oversight in the MIPS implementation of 
> > the
> > kernel memory consistency model, which has already been fixed for some time 
> > (and
> > stable-backported) [2].
> >
> > 321-mt7621-timer.patch - We've also been carrying this patch for many years 
> > [3],
> > in order to fix a timer calibration issue on MT7621. Turns out, after 
> > retesting
> > with a recent kernel (5.10), the system works perfectly fine without it (no
> > rcu_sched stalls or inconsistent BogoMIPS values across CPUs).
> >
> > The GENERIC_CLOCKEVENTS_BROADCAST selection, however, is an unrelated 
> > change,
> > should be kept (although we're not building with cpuidle support), and is 
> > thus
> > moved to a new patch, 202-generic-clockevents-broadcast.patch. This change 
> > also
> > requires a manual refresh of both 322-mt7621-fix-cpu-clk-add-clkdev.patch 
> > and
> > 323-mt7621-memory-detect.patch.
> >
> > [1] 
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=5c971cd6fdd7298a2017bdb6bea870088eddb8b9
> > [2] 
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/mips?h=linux-5.4.y&id=42344113ba7a1ed7b5654cd5270af0d5698d8521
> > [3] 
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6f4a903533361a2906a4d94ac6f597cd9c6c47bc
> >
> > Suggested-by: Ilya Lipnitskiy <[email protected]>
> > Tested-by: Donald Hoskins <[email protected]>
> > Signed-off-by: Rui Salvaterra <[email protected]>
>
> [patch snipped]
>
> Ping. Any comments on this? I'm thinking of splitting it in two
> patches to make reviewing easier, adding the cpuidle patch as the last
> one and resend as a series of three. Thoughts?
My opinion is go ahead and supersede the series with your proposed
updates, since no maintainer appears to have spent any time on this
yet.

Ilya

_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to