Re: [PATCH v2 21/44] arch/idle: Change arch_cpu_idle() IRQ behaviour

On Mon, Sep 19, 2022 at 6:18 PM Peter Zijlstra wrote: > > Current arch_cpu_idle() is called with IRQs disabled, but will return > with IRQs enabled. > > However, the very first thing the generic code does after calling > arch_cpu_idle() is raw_local_irq_disable(). This means that > architectures t

Re: [PATCH v2 25/44] printk: Remove trace_.*_rcuidle() usage

On (22/09/19 12:00), Peter Zijlstra wrote: > The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console > tracepoint"), was printk usage from the cpuidle path where RCU was > already disabled. > > Per the patches earlier in this series, this is no longer the case. > > Signed-off-by: Peter

Re: [PATCH v2 0/2] Fix console probe delay when stdout-path isn't set

On Mon, Sep 19, 2022 at 1:44 AM Greg Kroah-Hartman wrote: > > On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote: > > On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman > > wrote: > > > > > > On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote: > > > > These patches are on

Re: [PATCH v2 00/44] cpuidle,rcu: Clean up the mess

On Mon, Sep 19, 2022 at 12:17 PM Peter Zijlstra wrote: > > Hi All! > > At long last, a respin of the cpuidle vs rcu cleanup patches. > > v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org > > These here patches clean up the mess that is cpuidle vs rcuidle. > > At the end of the r

Re: [PATCH v2 09/44] cpuidle,omap3: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 04:31:42PM +0200, Frederic Weisbecker wrote: > On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote: > > Doing RCU-idle outside the driver, only to then teporarily enable it > > again before going idle is daft. > > That doesn't tell where those calls are. cpu_pm_

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 05:03:04PM +0200, Peter Zijlstra wrote: > On Mon, Sep 19, 2022 at 04:49:41PM +0200, Frederic Weisbecker wrote: > > On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > > > Doing RCU-idle outside the driver, only to then temporarily enable it > > > again, at leas

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 04:49:41PM +0200, Frederic Weisbecker wrote: > On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > > Doing RCU-idle outside the driver, only to then temporarily enable it > > again, at least twice, before going idle is daft. > > > > Signed-off-by: Peter Zijlst

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 04:49:41PM +0200, Frederic Weisbecker wrote: > On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > > Doing RCU-idle outside the driver, only to then temporarily enable it > > again, at least twice, before going idle is daft. > > > > Signed-off-by: Peter Zijlst

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 04:21:23PM +0200, Frederic Weisbecker wrote: > On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > > Doing RCU-idle outside the driver, only to then temporarily enable it > > again, at least twice, before going idle is daft. > > Hmm, what ends up calling RCU_I

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) > --- > arch/arm/mach-imx/cpuidle-imx6sx.c |5 - > 1 file

Re: [PATCH v2 09/44] cpuidle,omap3: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then teporarily enable it > again before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) > Reviewed-by: Tony Lindgren > Tested-by: Tony Lindgren Ok now with the cpu_pm_*()

Re: [PATCH v2 10/44] cpuidle,armada: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 11:59:49AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again before going idle is daft. Ah wait, now I see, that's cpu_pm_enter()/cpu_pm_exit() -> cpu_pm_notify*() the culprits. Might be worth adding a short note a

Re: [PATCH v2 09/44] cpuidle,omap3: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then teporarily enable it > again before going idle is daft. That doesn't tell where those calls are. Thanks. ___ linux-snps-arc mailing list l

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. Hmm, what ends up calling RCU_IDLE() here? Also what about cpu_do_idle()? Thanks. > > Signed-off-by: Peter

Re: [PATCH v2 07/44] cpuidle,psci: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 11:59:46AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker ___

Re: [PATCH v2 06/44] cpuidle,tegra: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 11:59:45AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker ___

Re: [PATCH v2 05/44] cpuidle,riscv: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 11:59:44AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker ___

Re: [PATCH v2 03/44] cpuidle/poll: Ensure IRQ state is invariant

On Mon, Sep 19, 2022 at 11:59:42AM +0200, Peter Zijlstra wrote: > cpuidle_state::enter() methods should be IRQ invariant Got a bit confused with the invariant thing since the first chunck I see in this patch is a conversion to an non-traceable local_irq_enable(). Maybe just add a short mention ab

Re: [PATCH v2 05/44] cpuidle,riscv: Push RCU-idle into driver

On Mon, Sep 19, 2022 at 3:47 PM Peter Zijlstra wrote: > > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) Looks good to me. For RISC-V cpuidle: Reviewed-by: Anup Patel Regards,

[PATCH v2 21/44] arch/idle: Change arch_cpu_idle() IRQ behaviour

Current arch_cpu_idle() is called with IRQs disabled, but will return with IRQs enabled. However, the very first thing the generic code does after calling arch_cpu_idle() is raw_local_irq_disable(). This means that architectures that can idle with IRQs disabled end up doing a pointless 'enable-dis

[PATCH v2 16/44] cpuidle: Annotate poll_idle()

The __cpuidle functions will become a noinstr class, as such they need explicit annotations. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Rafael J. Wysocki --- drivers/cpuidle/poll_state.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/cpuidle/poll_state.c ++

[PATCH v2 35/44] cpuidle,omap3: Push RCU-idle into omap_sram_idle()

OMAP3 uses full SoC suspend modes as idle states, as such it needs the whole power-domain and clock-domain code from the idle path. All that code is not suitable to run with RCU disabled, as such push RCU-idle deeper still. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Tony Lindgren Tested

[PATCH v2 00/44] cpuidle,rcu: Clean up the mess

Hi All! At long last, a respin of the cpuidle vs rcu cleanup patches. v1: https://lkml.kernel.org/r/20220608142723.103523...@infradead.org These here patches clean up the mess that is cpuidle vs rcuidle. At the end of the ride there's only on RCU_NONIDLE user left: arch/arm64/kernel/suspend.

[PATCH v2 26/44] time/tick-broadcast: Remove RCU_NONIDLE usage

No callers left that have already disabled RCU. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mark Rutland --- kernel/time/tick-broadcast-hrtimer.c | 29 - 1 file changed, 12 insertions(+), 17 deletions(-) --- a/kernel/time/tick-broadcast-hrtimer.c +++ b/kernel/

[PATCH v2 34/44] cpuidle,omap3: Use WFI for omap3_pm_idle()

arch_cpu_idle() is a very simple idle interface and exposes only a single idle state and is expected to not require RCU and not do any tracing/instrumentation. As such, omap_sram_idle() is not a valid implementation. Replace it with the simple (shallow) omap3_do_wfi() call. Leaving the more compli

[PATCH v2 20/44] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IBRS

vmlinux.o: warning: objtool: intel_idle_ibrs+0x17: call to spec_ctrl_current() leaves .noinstr.text section vmlinux.o: warning: objtool: intel_idle_ibrs+0x27: call to wrmsrl.constprop.0() leaves .noinstr.text section Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/kernel/cpu/bugs.c |2 +

[PATCH v2 44/44] arm64,riscv,perf: Remove RCU_NONIDLE() usage

The PM notifiers should no longer be ran with RCU disabled (per the previous patches), as such this hack is no longer required either. Signed-off-by: Peter Zijlstra (Intel) --- drivers/perf/arm_pmu.c | 11 +-- drivers/perf/riscv_pmu_sbi.c |8 +--- 2 files changed, 2 inser

[PATCH v2 12/44] cpuidle,dt: Push RCU-idle into driver

Doing RCU-idle outside the driver, only to then temporarily enable it again before going idle is daft. Notably: this converts all dt_init_idle_driver() and __CPU_PM_CPU_IDLE_ENTER() users for they are inextrably intertwined. Signed-off-by: Peter Zijlstra (Intel) --- arch/arm/mach-omap2/cpuidle3

[PATCH v2 14/44] cpuidle,cpu_pm: Remove RCU fiddling from cpu_pm_{enter,exit}()

All callers should still have RCU enabled. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mark Rutland --- kernel/cpu_pm.c |9 - 1 file changed, 9 deletions(-) --- a/kernel/cpu_pm.c +++ b/kernel/cpu_pm.c @@ -30,16 +30,9 @@ static int cpu_pm_notify(enum cpu_pm_eve { int re

[PATCH v2 30/44] cpuidle,xenpv: Make more PARAVIRT_XXL noinstr clean

vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wbinvd() leaves .noinstr.text section vmlinux.o: warning: objtool: default_idle+0x4: call to arch_safe_halt() leaves .noinstr.text section vmlinux.o: warning: objtool: xen_safe_halt+0xa: call to HYPERVISOR_sched_op.constprop.0() l

[PATCH v2 40/44] ubsan: Fix objtool UACCESS warns

clang-14 allyesconfig gives: vmlinux.o: warning: objtool: emulator_cmpxchg_emulated+0x705: call to __ubsan_handle_load_invalid_value() with UACCESS enabled vmlinux.o: warning: objtool: paging64_update_accessed_dirty_bits+0x39e: call to __ubsan_handle_load_invalid_value() with UACCESS enabled vml

[PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

Doing RCU-idle outside the driver, only to then temporarily enable it again, at least twice, before going idle is daft. Signed-off-by: Peter Zijlstra (Intel) --- arch/arm/mach-imx/cpuidle-imx6sx.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) --- a/arch/arm/mach-imx/cpuidle-imx6s

[PATCH v2 01/44] x86/perf/amd: Remove tracing from perf_lopwr_cb()

The perf_lopwr_cb() is called from the idle routines; there is no RCU there, we must not enter tracing. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/events/amd/brs.c | 13 + arch/x86/include/asm/perf_event.h |2 +- 2 files changed, 6 insertions(+), 9 deletions(-)

[PATCH v2 18/44] cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE *again*

vmlinux.o: warning: objtool: intel_idle_irq+0x10c: call to trace_hardirqs_off() leaves .noinstr.text section As per commit 32d4fd5751ea ("cpuidle,intel_idle: Fix CPUIDLE_FLAG_IRQ_ENABLE"): "must not have tracing in idle functions" Clearly people can't read and tinker along until splat dissa

[PATCH v2 24/44] arm64,smp: Remove trace_.*_rcuidle() usage

Ever since commit d3afc7f12987 ("arm64: Allow IPIs to be handled as normal interrupts") this function is called in regular IRQ context. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mark Rutland Acked-by: Marc Zyngier --- arch/arm64/kernel/smp.c |4 ++-- 1 file changed, 2 insertions(+),

[PATCH v2 42/44] entry,kasan,x86: Disallow overriding mem*() functions

KASAN cannot just hijack the mem*() functions, it needs to emit __asan_mem*() variants if it wants instrumentation (other sanitizers already do this). vmlinux.o: warning: objtool: sync_regs+0x24: call to memcpy() leaves .noinstr.text section vmlinux.o: warning: objtool: vc_switch_off_ist+0xbe: ca

[PATCH v2 41/44] intel_idle: Add force_irq_on module param

For testing purposes. Signed-off-by: Peter Zijlstra (Intel) --- drivers/idle/intel_idle.c |7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/idle/intel_idle.c +++ b/drivers/idle/intel_idle.c @@ -1787,6 +1787,9 @@ static bool __init intel_idle_verify_cst return

[PATCH v2 19/44] cpuidle,intel_idle: Fix CPUIDLE_FLAG_INIT_XSTATE

vmlinux.o: warning: objtool: intel_idle_s2idle+0xd5: call to fpu_idle_fpregs() leaves .noinstr.text section vmlinux.o: warning: objtool: intel_idle_xstate+0x11: call to fpu_idle_fpregs() leaves .noinstr.text section vmlinux.o: warning: objtool: fpu_idle_fpregs+0x9: call to xfeatures_in_use() lea

[PATCH v2 23/44] arm,smp: Remove trace_.*_rcuidle() usage

None of these functions should ever be ran with RCU disabled anymore. Specifically, do_handle_IPI() is only called from handle_IPI() which explicitly does irq_enter()/irq_exit() which ensures RCU is watching. The problem with smp_cross_call() was, per commit 7c64cc0531fa ("arm: Use _rcuidle for s

[PATCH v2 28/44] cpuidle,mwait: Make noinstr clean

vmlinux.o: warning: objtool: intel_idle_s2idle+0x6e: call to __monitor.constprop.0() leaves .noinstr.text section vmlinux.o: warning: objtool: intel_idle_irq+0x8c: call to __monitor.constprop.0() leaves .noinstr.text section vmlinux.o: warning: objtool: intel_idle+0x73: call to __monitor.constpro

Re: [PATCH v2 30/44] cpuidle,xenpv: Make more PARAVIRT_XXL noinstr clean

On 19.09.22 12:00, Peter Zijlstra wrote: vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wbinvd() leaves .noinstr.text section vmlinux.o: warning: objtool: default_idle+0x4: call to arch_safe_halt() leaves .noinstr.text section vmlinux.o: warning: objtool: xen_safe_halt+0xa: c

[PATCH v2 36/44] cpuidle,omap4: Push RCU-idle into omap4_enter_lowpower()

From: Tony Lindgren OMAP4 uses full SoC suspend modes as idle states, as such it needs the whole power-domain and clock-domain code from the idle path. All that code is not suitable to run with RCU disabled, as such push RCU-idle deeper still. Signed-off-by: Tony Lindgren Signed-off-by: Peter

[PATCH v2 25/44] printk: Remove trace_.*_rcuidle() usage

The problem, per commit fc98c3c8c9dc ("printk: use rcuidle console tracepoint"), was printk usage from the cpuidle path where RCU was already disabled. Per the patches earlier in this series, this is no longer the case. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Sergey Senozhatsky Acked

[PATCH v2 39/44] cpuidle,clk: Remove trace_.*_rcuidle()

OMAP was the one and only user. Signed-off-by: Peter Zijlstra (Intel) --- drivers/clk/clk.c |8 1 file changed, 4 insertions(+), 4 deletions(-) --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -978,12 +978,12 @@ static void clk_core_disable(struct clk_ if (--core->enable_

[PATCH v2 43/44] sched: Always inline __this_cpu_preempt_check()

vmlinux.o: warning: objtool: in_entry_stack+0x9: call to __this_cpu_preempt_check() leaves .noinstr.text section vmlinux.o: warning: objtool: default_do_nmi+0x10: call to __this_cpu_preempt_check() leaves .noinstr.text section vmlinux.o: warning: objtool: fpu_idle_fpregs+0x41: call to __this_cpu

[PATCH v2 37/44] arm,omap2: Use WFI for omap2_pm_idle()

arch_cpu_idle() is a very simple idle interface and exposes only a single idle state and is expected to not require RCU and not do any tracing/instrumentation. As such, omap2_pm_idle() is not a valid implementation. Replace it with a simple (shallow) omap2_do_wfi() call. Omap2 doesn't have a cpui

[PATCH v2 38/44] cpuidle,powerdomain: Remove trace_.*_rcuidle()

OMAP was the one and only user. Signed-off-by: Peter Zijlstra (Intel) --- arch/arm/mach-omap2/powerdomain.c | 10 +- drivers/base/power/runtime.c | 24 2 files changed, 17 insertions(+), 17 deletions(-) --- a/arch/arm/mach-omap2/powerdomain.c +++ b/arch

[PATCH v2 27/44] cpuidle,sched: Remove annotations from TIF_{POLLING_NRFLAG,NEED_RESCHED}

vmlinux.o: warning: objtool: mwait_idle+0x5: call to current_set_polling_and_test() leaves .noinstr.text section vmlinux.o: warning: objtool: acpi_processor_ffh_cstate_enter+0xc5: call to current_set_polling_and_test() leaves .noinstr.text section vmlinux.o: warning: objtool: cpu_idle_poll.isra.0

[PATCH v2 32/44] cpuidle,acpi: Make noinstr clean

vmlinux.o: warning: objtool: io_idle+0xc: call to __inb.isra.0() leaves .noinstr.text section vmlinux.o: warning: objtool: acpi_idle_enter+0xfe: call to num_online_cpus() leaves .noinstr.text section vmlinux.o: warning: objtool: acpi_idle_enter+0x115: call to acpi_idle_fallback_to_c1.isra.0() le

[PATCH v2 29/44] cpuidle,tdx: Make tdx noinstr clean

vmlinux.o: warning: objtool: __halt+0x2c: call to hcall_func.constprop.0() leaves .noinstr.text section vmlinux.o: warning: objtool: __halt+0x3f: call to __tdx_hypercall() leaves .noinstr.text section vmlinux.o: warning: objtool: __tdx_hypercall+0x66: call to __tdx_hypercall_failed() leaves .noi

[PATCH v2 31/44] cpuidle,nospec: Make noinstr clean

vmlinux.o: warning: objtool: mwait_idle+0x47: call to mds_idle_clear_cpu_buffers() leaves .noinstr.text section vmlinux.o: warning: objtool: acpi_processor_ffh_cstate_enter+0xa2: call to mds_idle_clear_cpu_buffers() leaves .noinstr.text section vmlinux.o: warning: objtool: intel_idle+0x91: call t

[PATCH v2 33/44] ftrace: WARN on rcuidle

CONFIG_GENERIC_ENTRY disallows any and all tracing when RCU isn't enabled. XXX if s390 (the only other GENERIC_ENTRY user as of this writing) isn't comfortable with this, we could switch to HAVE_NOINSTR_VALIDATION which is x86_64 only atm. Signed-off-by: Peter Zijlstra (Intel) --- include/linux

[PATCH v2 17/44] objtool/idle: Validate __cpuidle code as noinstr

Idle code is very like entry code in that RCU isn't available. As such, add a little validation. Signed-off-by: Peter Zijlstra (Intel) Acked-by: Geert Uytterhoeven --- arch/alpha/kernel/vmlinux.lds.S |1 - arch/arc/kernel/vmlinux.lds.S|1 - arch/arm/include/asm/vmlinux.lds.

[PATCH v2 15/44] acpi_idle: Remove tracing

All the idle routines are called with RCU disabled, as such there must not be any tracing inside. While there; clean-up the io-port idle thing. Signed-off-by: Peter Zijlstra (Intel) --- drivers/acpi/processor_idle.c | 24 +--- 1 file changed, 13 insertions(+), 11 deletions

[PATCH v2 13/44] cpuidle: Fix ct_idle_*() usage

The whole disable-RCU, enable-IRQS dance is very intricate since changing IRQ state is traced, which depends on RCU. Add two helpers for the cpuidle case that mirror the entry code. Signed-off-by: Peter Zijlstra (Intel) --- arch/arm/mach-imx/cpuidle-imx6q.c|4 +-- arch/arm/mach-imx/cpui

[PATCH v2 22/44] x86/tdx: Remove TDX_HCALL_ISSUE_STI

Now that arch_cpu_idle() is expected to return with IRQs disabled, avoid the useless STI/CLI dance. Per the specs this is supposed to work, but nobody has yet relied up this behaviour so broken implementations are possible. Signed-off-by: Peter Zijlstra (Intel) --- arch/x86/coco/tdx/tdcall.S

[PATCH v2 10/44] cpuidle,armada: Push RCU-idle into driver

Doing RCU-idle outside the driver, only to then temporarily enable it again before going idle is daft. Signed-off-by: Peter Zijlstra (Intel) --- drivers/cpuidle/cpuidle-mvebu-v7.c |7 +++ 1 file changed, 7 insertions(+) --- a/drivers/cpuidle/cpuidle-mvebu-v7.c +++ b/drivers/cpuidle/cpui

[PATCH v2 02/44] x86/idle: Replace x86_idle with a static_call

Typical boot time setup; no need to suffer an indirect call for that. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker Reviewed-by: Rafael J. Wysocki --- arch/x86/kernel/process.c | 50 +- 1 file changed, 28 insertions(+), 22

[PATCH v2 03/44] cpuidle/poll: Ensure IRQ state is invariant

cpuidle_state::enter() methods should be IRQ invariant Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Rafael J. Wysocki --- drivers/cpuidle/poll_state.c |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/cpuidle/poll_state.c +++ b/drivers/cpuidle/poll_state.c @@ -17,

[PATCH v2 05/44] cpuidle,riscv: Push RCU-idle into driver

Doing RCU-idle outside the driver, only to then temporarily enable it again, at least twice, before going idle is daft. Signed-off-by: Peter Zijlstra (Intel) --- drivers/cpuidle/cpuidle-riscv-sbi.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) --- a/drivers/cpuidle/cpuidle-r

[PATCH v2 09/44] cpuidle,omap3: Push RCU-idle into driver

Doing RCU-idle outside the driver, only to then teporarily enable it again before going idle is daft. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Tony Lindgren Tested-by: Tony Lindgren --- arch/arm/mach-omap2/cpuidle34xx.c | 16 1 file changed, 16 insertions(+) --- a

[PATCH v2 04/44] cpuidle: Move IRQ state validation

Make cpuidle_enter_state() consistent with the s2idle variant and verify ->enter() always returns with interrupts disabled. Signed-off-by: Peter Zijlstra (Intel) --- drivers/cpuidle/cpuidle.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/drivers/cpuidle/cpuidle.c +++

[PATCH v2 11/44] cpuidle,omap4: Push RCU-idle into driver

Doing RCU-idle outside the driver, only to then temporarily enable it again, some *four* times, before going idle is daft. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Tony Lindgren Tested-by: Tony Lindgren --- arch/arm/mach-omap2/cpuidle44xx.c | 29 ++--- 1 fil

[PATCH v2 06/44] cpuidle,tegra: Push RCU-idle into driver

Doing RCU-idle outside the driver, only to then temporarily enable it again, at least twice, before going idle is daft. Signed-off-by: Peter Zijlstra (Intel) --- drivers/cpuidle/cpuidle-tegra.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) --- a/drivers/cpuidle/

[PATCH v2 07/44] cpuidle,psci: Push RCU-idle into driver

Doing RCU-idle outside the driver, only to then temporarily enable it again, at least twice, before going idle is daft. Signed-off-by: Peter Zijlstra (Intel) --- drivers/cpuidle/cpuidle-psci.c |9 + 1 file changed, 5 insertions(+), 4 deletions(-) --- a/drivers/cpuidle/cpuidle-psci.c

Re: [PATCH v2 0/2] Fix console probe delay when stdout-path isn't set

On Sun, Sep 18, 2022 at 08:44:27PM -0700, Olof Johansson wrote: > On Tue, Aug 23, 2022 at 8:37 AM Greg Kroah-Hartman > wrote: > > > > On Thu, Jun 30, 2022 at 06:26:38PM -0700, Saravana Kannan wrote: > > > These patches are on top of driver-core-next. > > > > > > Even if stdout-path isn't set in DT