[PATCH v2 3/3] ramips/mt7621: enable support for cpuidle

2021-03-30 Thread Rui Salvaterra
MIPS Coherent Processor Systems (CPS), which include the MT7621 SoC, support deep sleep idle states and have a specific cpuidle driver for them. Enable support for it, while also switching from constant timer ticks to the idle dynticks model, with the TEO governor. Run-tested on a Redmi AC2100. S

[PATCH v2 1/3] ramips/mt7621: drop the weak reordering patch

2021-03-30 Thread Rui Salvaterra
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 backpor

[PATCH v2 2/3] ramips/mt7621: drop the timer recalibration patch

2021-03-30 Thread Rui Salvaterra
We've been carrying this patch for many years [1], in order to fix a timer calibration issue on MT7621. Turns out, after retesting with a recent kernel (Linux 5.10), the system works perfectly fine without it (no rcu_sched stalls or inconsistent BogoMIPS values across CPUs). Manually refreshed: 32

[PATCH v2 0/3] misc 5.10 kernel work

2021-03-30 Thread Rui Salvaterra
Drop two obsolete kernel patches and enable support for cpuidle. More details in each individual patch. v2: Don't include the generic clock events broadcast patch, as SMP already selects GENERIC_CLOCKEVENTS_BROADCAST. Rui Salvaterra (3): ramips/mt7621: drop the weak reordering patch ramips/mt

Re: [PATCH 2/3] ramips/mt7621: drop the timer recalibration patch

2021-03-30 Thread Daniel Golle
On Tue, Mar 30, 2021 at 10:52:35PM +0100, Rui Salvaterra wrote: > Hi, Ilya, > > On Tue, 30 Mar 2021 at 20:56, Ilya Lipnitskiy > wrote: > > > > "config MIPS_CPS_CPUIDLE" has "select GENERIC_CLOCKEVENTS_BROADCAST if > > SMP", so it doesn't seem necessary to force it in a dedicated patch. > > Oh,

Re: [PATCH 2/3] ramips/mt7621: drop the timer recalibration patch

2021-03-30 Thread Rui Salvaterra
Hi, Ilya, On Tue, 30 Mar 2021 at 20:56, Ilya Lipnitskiy wrote: > > "config MIPS_CPS_CPUIDLE" has "select GENERIC_CLOCKEVENTS_BROADCAST if > SMP", so it doesn't seem necessary to force it in a dedicated patch. Oh, indeed? *goes to look* Crap, don't know how I missed it [1]. Thanks for the heads

Re: [PATCH 2/3] ramips/mt7621: drop the timer recalibration patch

2021-03-30 Thread Ilya Lipnitskiy
Hi Rui, On Tue, Mar 30, 2021 at 12:36 PM Rui Salvaterra wrote: > The GENERIC_CLOCKEVENTS_BROADCAST selection, however, is an unrelated change, > and must be kept. It's required by cpuidle, which is supported by the > architecture and will be enabled in the future. Thus, create a new patch > exclu

[PATCH 3/3] ramips/mt7621: enable support for cpuidle

2021-03-30 Thread Rui Salvaterra
MIPS Coherent Processor Systems (CPS), which include the MT7621 SoC, support deep sleep idle states and have a specific cpuidle driver for them. Enable support for it, while also switching from constant timer ticks to the idle dynticks model, with the TEO governor. Run-tested on a Redmi AC2100. S

[PATCH 0/3] ramips/mt7621: misc 5.10 kernel work

2021-03-30 Thread Rui Salvaterra
Drop two obsolete kernel patches and enable support for cpuidle. More details in each individual patch. Rui Salvaterra (3): ramips/mt7621: drop the weak reordering patch ramips/mt7621: drop the timer recalibration patch ramips/mt7621: enable support for cpuidle target/linux/ramips/mt7621/c

[PATCH 1/3] ramips/mt7621: drop the weak reordering patch

2021-03-30 Thread Rui Salvaterra
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 backpor

[PATCH 2/3] ramips/mt7621: drop the timer recalibration patch

2021-03-30 Thread Rui Salvaterra
We've been carrying this patch for many years [1], in order to fix a timer calibration issue on MT7621. Turns out, after retesting with a recent kernel (Linux 5.10), the system works perfectly fine without it (no rcu_sched stalls or inconsistent BogoMIPS values across CPUs). The GENERIC_CLOCKEVENT

Re: [PATCH] ramips/mt7621: drop two obsolete patches

2021-03-30 Thread Rui Salvaterra
On Tue, 30 Mar 2021 at 19:27, Ilya Lipnitskiy wrote: > > 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. That as my reasoning too. Will respin, thanks! ___

Re: [PATCH keyring] usign: drop personal + outdated keys except 21.02

2021-03-30 Thread Hauke Mehrtens
On 3/30/21 10:53 AM, Paul Spooren wrote: The ./usign folder is added to every OpenWrt image, it should only contain the most necessary keys. At this point it contains both a selection of personal developer keys and keys of EOL releases. Remove them all and only keep the 21.02 key. A future comm

Re: [PATCH] ramips/mt7621: drop two obsolete patches

2021-03-30 Thread Ilya Lipnitskiy
On Tue, Mar 30, 2021 at 2:43 AM Rui Salvaterra wrote: > > On Tue, 16 Mar 2021 at 09:02, Rui Salvaterra 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_reorderi

Re: [PATCH] ramips/mt7621: drop two obsolete patches

2021-03-30 Thread Rui Salvaterra
On Tue, 16 Mar 2021 at 09:02, Rui Salvaterra 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

[PATCH keyring] usign: drop personal + outdated keys except 21.02

2021-03-30 Thread Paul Spooren
The ./usign folder is added to every OpenWrt image, it should only contain the most necessary keys. At this point it contains both a selection of personal developer keys and keys of EOL releases. Remove them all and only keep the 21.02 key. A future commit should add a "next release" key, which i