Re: [PATCH v2 0/2] Fix console probe delay when stdout-path isn't set
On Mon, Sep 19, 2022 at 5:56 PM Olof Johansson wrote: > > 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 top of driver-core-next. > > > > > > > > > > Even if stdout-path isn't set in DT, this patch should take console > > > > > probe times back to how they were before the deferred_probe_timeout > > > > > clean up series[1]. > > > > > > > > Now dropped from my queue due to lack of a response to other reviewer's > > > > questions. > > > > > > What happened to this patch? I have a 10 second timeout on console > > > probe on my SiFive Unmatched, and I don't see this flag being set for > > > the serial driver. In fact, I don't see it anywhere in-tree. I can't > > > seem to locate another patchset from Saravana around this though, so > > > I'm not sure where to look for a missing piece for the sifive serial > > > driver. > > > > > > This is the second boot time regression (this one not fatal, unlike > > > the Layerscape PCIe one) from the fw_devlink patchset. > > > > > > Greg, can you revert the whole set for 6.0, please? It's obviously > > > nowhere near tested enough to go in and I expect we'll see a bunch of > > > -stable fixups due to this if we let it remain in. > > > > What exactly is "the whole set"? I have the default option fix queued > > up and will send that to Linus later this week (am traveling back from > > Plumbers still), but have not heard any problems about any other issues > > at all other than your report. > > I stand corrected in this case, the issue on the Hifive Unmatched was > a regression due to a PWM clock change -- I just sent a patch for that > (serial driver fix). > > So it seems like as long as the fw_devlink.strict=1 patch is reverted, > things are back to a working state here. > > I still struggle with how the fw_devlink patchset is expected to work > though, since DT is expected to describe the hardware configuration, > and it has no knowledge of whether there are drivers that will be > bound to any referenced supplier devnodes. It's not going to work well > to assume that they will always be bound, and to add 10 second > timeouts for those cases isn't a good solution. Seems like the number > of special cases will keep adding up. Since the introduction of deferred probe, the kernel has always assumed if there is a device described, then there is or will be a driver for it. The result is you can't use new DTs (if they add providers) with older kernels. We've ended up with a timeout because no one has come up with a better way to handle it. What the kernel needs is userspace saying "I'm done loading modules", but it's debatable whether that's a good solution too. Rob ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 33/44] ftrace: WARN on rcuidle
Nit, the subject should have "tracing:" an not "ftrace:" as the former encompasses the tracing infrastructure and the latter is for the function hook part of that. On Mon, 19 Sep 2022 12:00:12 +0200 Peter Zijlstra wrote: > 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/tracepoint.h | 13 - > kernel/trace/trace.c |3 +++ > 2 files changed, 15 insertions(+), 1 deletion(-) > > --- a/include/linux/tracepoint.h > +++ b/include/linux/tracepoint.h > @@ -178,6 +178,16 @@ static inline struct tracepoint *tracepo > #endif /* CONFIG_HAVE_STATIC_CALL */ > > /* > + * CONFIG_GENERIC_ENTRY archs are expected to have sanitized entry and idle > + * code that disallow any/all tracing/instrumentation when RCU isn't > watching. > + */ > +#ifdef CONFIG_GENERIC_ENTRY > +#define RCUIDLE_COND(rcuidle)(rcuidle) > +#else Should probably move the below comment to here: /* srcu can't be used from NMI */ > +#define RCUIDLE_COND(rcuidle)(rcuidle && in_nmi()) > +#endif > + > +/* > * it_func[0] is never NULL because there is at least one element in the > array > * when the array itself is non NULL. > */ > @@ -189,7 +199,8 @@ static inline struct tracepoint *tracepo > return; \ > \ > /* srcu can't be used from NMI */ \ And remove the above. -- Steve > - WARN_ON_ONCE(rcuidle && in_nmi()); \ > + if (WARN_ON_ONCE(RCUIDLE_COND(rcuidle)))\ > + return; \ > \ > /* keep srcu and sched-rcu usage consistent */ \ > preempt_disable_notrace(); \ > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -3104,6 +3104,9 @@ void __trace_stack(struct trace_array *t > return; > } > > + if (WARN_ON_ONCE(IS_ENABLED(CONFIG_GENERIC_ENTRY))) > + return; > + > /* >* When an NMI triggers, RCU is enabled via ct_nmi_enter(), >* but if the above rcu_is_watching() failed, then the NMI > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 37/44] arm,omap2: Use WFI for omap2_pm_idle()
* Peter Zijlstra [220919 10:09]: > 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 cpuidle driver; but adding one would be the > recourse to (re)gain the other idle states. Looks good to me thanks: Acked-by: Tony Lindgren ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2 00/44] cpuidle,rcu: Clean up the mess
Hi, * Peter Zijlstra [220919 10:08]: > 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. I just gave these a quick test and things still work for me. The old omap3 off mode during idle still works. No more need to play the whack the mole game with RCU-idle :) I did not test on x86, or on other ARMs, but considering the test pretty much covered the all the affected RCU-idle related paths, where suitable, feel free to add: Tested-by: Tony Lindgren ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
