[PATCH] ramips/mt7621: drop two obsolete patches

[Ilya Lipnitskiy]

On Tue, Mar 30, 2021 at 2:43 AM Rui Salvaterra <rsalvaterra at gmail.com> wrote:
>
> On Tue, 16 Mar 2021 at 09:02, Rui Salvaterra <rsalvaterra at gmail.com> 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 <ilya.lipnitskiy at gmail.com>
> > Tested-by: Donald Hoskins <grommish at gmail.com>
> > Signed-off-by: Rui Salvaterra <rsalvaterra at gmail.com>
>
> [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