From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9D35544D681 for ; Wed, 8 Jul 2026 14:00:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783519225; cv=none; b=MOoD2xCkeNS6jomd6Uvy4uSeFkU7BztLQzDgsQJdky2Qs9pnsTcId3xYMgMiAx3Gu/QuxaVLsQzbpOE54nNQU3xA22dhIrHi9bKXWlnKLb/jsGw+iWsG19AV/REazjDSmWH4BlvWWbTbGGDef5wGa5cD7gao9+wOk4FB/zpAgQE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783519225; c=relaxed/simple; bh=+MyyKOo8bICk/aJFc/E236U1cUIY6gKGxNFTDl8Ow44=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=M99dYnEFncqoM3scAFiqQBqupWdkAtJFd1qM4H7s9mxj1Hogq/zZdZmkxLIT7dEF4V8Px2Cxz2mmCkNa1PmDJ7zqIqrn323uI/ygWwbd4RWWH7q73JxF0ajQIxNCm1x9JHKk7ufjj3Jli7nTm7u2MKf5BvTpiTmM1x7zv8O+e4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=PtlKW2G8; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="PtlKW2G8" Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-493b77b150aso5616395e9.2 for ; Wed, 08 Jul 2026 07:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1783519222; x=1784124022; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=gyOhrDiD3HZi1C97C5b5wI4tA2tqQIhwOgRgckqnDRQ=; b=PtlKW2G8sgpLPi7bxb8WN9wL8SCo6vYHsgP4D+IGFCSMwcCTwtuDoe+ZMYPQTv3Ktu C+J0BDoN6EJ6/lhZTNWo8Jluu+N6sb5ZVbhNMRRy1k2y4beT6BYLcWJti/5f9PPiXU76 gNSBuQD7tq86WjQwn8B1swZTQ5g8WaajphiSFGC5rVwm4tU4agpj97s735QSm8t2aiJS XtGb3kRd+XY5+t7vXP6MHvnyWH4lXa21n1nz0NfTtYNw3T013kX6rqRHNSXTohejVvMW 30QPZMKyt3AcOz8zM14AwbADVBdx6Kj4Nm0iCVjX7feWXnI1zo1dfIFQ4lnbYkoP0jMW 97oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783519222; x=1784124022; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=gyOhrDiD3HZi1C97C5b5wI4tA2tqQIhwOgRgckqnDRQ=; b=RDk0t7CAUYVJidoKRovavrIscxmB39MHjr81bgxnRDf1hPJPfZOJnWLvko8VGztitC DvCxgh8qAG7tpdRLz5F5wFsjs9Y9UbUYnHdwClmsw6ukFRJ9vmsxvpmCpGe0KJ6GkJh7 BV6qUa6zXi06+zk1SitcYoo5DAavYlpk/OPZHeSB+0fyOew2r38XDnSSYEB5OM9FL95n OG8qe8T1L5/C22xkZm4d8nm7I5OdBUT+YO9JIeyJ9NIYSKvWMPKJFG/jiy/8N/WUKzrw 69glQscxqCeQxYRmM/k8c+fR4wjph6jPH+lXV5UefhNsdXq/Xf+t3daq15Et1euJ1jtN SqfA== X-Forwarded-Encrypted: i=1; AHgh+RpZdaR8U0dHy6uSDnCaR8+BgB3OB7+euHYFo1U6cY3NiuJM/RQ3xG1Iups6ySMQq2ZUJSC1iCoyA46jhuY=@vger.kernel.org X-Gm-Message-State: AOJu0YxL3y7EIwmgHG12FRPTG4l0yEI2t4AR049EnU7zBiIWajpoc/pO hTtyTQhwNOSbSd5u0EhPQEZ+NHUKsz2d52+yOShEMHd1Ii4Np5282cuGkNJkvYXVEbw= X-Gm-Gg: AfdE7ckZYIY9RuJv2HukYtiC9bZ90v/W7J7yOsbiZrvUMW/DtLImX8AUqsoj5Feu/XG kZLdEoD4mGeeH2jcc7fBqiJaTMXg2OuOFwnwvDN0bWUItN5TAeDWYR4Jkvgu8N7FvPL/u2nKb6u xCibf/RJ9qSNLJYuBCvvxXZ1v1TmwJxbOBDXYEjlVPWUVL0b1p0gYC5dwZ2YmJzCAyx+21kCtYB 6M6A6InjEVQvrXI2IM7r68Ek1NjtzVljTNorc9w/48nZaGzssT5otOJhqxZFZCjag6i7r80m93w DQqQw8ozXpwlU1uenXEdP4aa74P4cmaz1h5TjCWU9OionkDApE9TSuFAZtYlcEWJV85sd2M8+n8 77wyLWeGR5ZgaWc3cJZF3KBMSEYH48SJFdj1ZMd6QWcevPbBM3RQ4GhGII0WJZeejjOlhTww+YC HA/sxAjAxeK8YJu0Q= X-Received: by 2002:a05:600c:3acf:b0:492:68bc:3237 with SMTP id 5b1f17b1804b1-493e7a2b209mr20847575e9.32.1783519218219; Wed, 08 Jul 2026 07:00:18 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-493e0faee30sm120828745e9.10.2026.07.08.07.00.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 07:00:17 -0700 (PDT) Date: Wed, 8 Jul 2026 16:00:15 +0200 From: Petr Mladek To: John Ogness Cc: Andrew Murray , Jonathan Corbet , Shuah Khan , Russell King , Florian Fainelli , Broadcom internal kernel review list , Ray Jui , Scott Branden , Steven Rostedt , Sergey Senozhatsky , Andrew Morton , Sebastian Andrzej Siewior , Clark Williams , Randy Dunlap , Linus Torvalds , Greg Kroah-Hartman , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH v2 3/4] printk: nbcon: move printk_delay to console emiting code Message-ID: References: <20260630-deprecate_boot_delay-v2-0-f9883d36aa4b@thegoodpenguin.co.uk> <20260630-deprecate_boot_delay-v2-3-f9883d36aa4b@thegoodpenguin.co.uk> <87zf08w7qo.fsf@jogness.linutronix.de> <87echdvkd5.fsf@jogness.linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87echdvkd5.fsf@jogness.linutronix.de> On Wed 2026-07-08 12:42:22, John Ogness wrote: > On 2026-07-07, Petr Mladek wrote: > >> This is too deep (also pointed out by Sashiko) because it multiplies the > >> delay times the number of consoles. For the legacy printing, it would be > >> more appropriate to put the delay inside console_flush_all() and > >> legacy_kthread_func(). > > > > True. The question is if the proper solution is worth the complexity. > > We would need to pass the information down two level of the API. > > It would require adding a new (output) parameter to console_flush_one_record(), > > nbcon_legacy_emit_next_record(), and console_emit_next_record(). > > > > It is not that complicated but these functions are already hairy > > enough so we should be careful. > > Fair enough. But then it should be consistent and > console_emit_next_record() should perform the delay before allowing the > handover. Something like this: Great catch! > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > index 2fe9a963c823a..62fd6a5ebef66 100644 > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -3161,6 +3161,8 @@ static bool console_emit_next_record(struct console *con, bool *handover, int co > */ > > con->write(con, outbuf, pmsg.outbuf_len); > + printk_delay(false); > + > con->seq = pmsg.seq + 1; > } else { > /* > @@ -3182,6 +3184,7 @@ static bool console_emit_next_record(struct console *con, bool *handover, int co > printk_legacy_allow_spinlock_enter(); > con->write(con, outbuf, pmsg.outbuf_len); > printk_legacy_allow_spinlock_exit(); > + printk_delay(true); It is pity that this is inside printk_safe context with IRQs disabled. A solution might be to call it before the write. But maybe, this is good enough. This code path is called from vprintk_emit() and it might be in an atomic context anyway. Also it increases the chance of successful handover which might help as well. Anyway, it would be nice to mention these pitfalls into commit message. > > start_critical_timings(); > > > John