From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (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 20756379C2F for ; Mon, 20 Jul 2026 11:46:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784547967; cv=none; b=TN2ed7WbAcA+UYj0gJegdes2WbBYdG+hewqoUVC4ZJykfgi25QlDiD/l/+ZCc4Qiycko9Kr+Th6NLtJG7cxUqW0eS+QQR45s0meeHq3igyXxEd3svSpa39p0o7xVJo6bqIzP5vhfq9sEeBz5cbem/gm36jyNccTpzMJkew5H7JA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784547967; c=relaxed/simple; bh=fUp4cei3BPr8E914jW1LFi71X7u+EpY3vf8k/rOCOA8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pWuzjRxWyFoDVHcqoJ7Hqspl/8VTGlV7s2n8a8xf3LBQSDFkjD147MCbkobrnkkEfQpiOS8ZnVVTW9S18SllS6dlQSKFPhE7Oogs9B6vxLdumaIaLFSV0U/uC/bOi+mYkf6vPH8dIkKFuGFPHYfvsKRezcoYQ4ldAmCU7cJ/Ysc= 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=VkVnIS2H; arc=none smtp.client-ip=209.85.221.41 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="VkVnIS2H" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-47ddf7b09aaso6546918f8f.3 for ; Mon, 20 Jul 2026 04:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784547961; x=1785152761; 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=fsMxsXjpGTSr2po7Wxk96V1yFnPC/aTK9Y7JzwyoR2U=; b=VkVnIS2H5BufBwPLPEGC7BoPG8cuc+KdrzASdI+3t5OLH6rT+nV3I+0HAgKm9XeqeW lhVP9FYe89ZH7XCCaAQreJoXKvTJcDWKamSw407F+4StWo9bNxUr4/5Wp0e6LTS+XFEa V4/DaMuMrJngWP2WIaZYaBxZ3l6Z6oDPoIfQyiKnnzmCE+b2NYIusYXxYzLgLFL8I3Pg PcXG2+ChoD8K9D/6mgKmmV8fx+OMKM3P6C7T5ebV4gTzx2FlmUPZofLJYiRMwv7/dOxs KjDr+EUsLKk3qR94z1eMADNwEiGbXDIIWuT3rpv2LQo135URI/f9iwbqq4EMGQZ/ou8q nRLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784547961; x=1785152761; 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=fsMxsXjpGTSr2po7Wxk96V1yFnPC/aTK9Y7JzwyoR2U=; b=Vj/+cl9MBna5rhP6gk6UhVRbPS0TiWxEI4Gcqda5WB80ltbYbVdaamJn5JniYjcFsI lHqK0EcJF8ei7l4qFuNvHPpOB24VfV4Hj3mZWdK6mMUa131BlfpJ73mWwr4nngAt5sfp ZczYpVEtptS5xAFzdnq5SvkhmCP1bZk2GqVoMfxcFjaSlS06cjUo6Rgl7yDFdc18d3eP 0QZKhT8dcWcAVO/e01P4fmofpN+jPR6MMlDHLsyHC006y3S4jKOruihEDscvisSYFSb4 nDaISZ+0ThB/te9xzjXUZ9rfJOczzH8LlZ9b9jCzVXeWfgee7ZYWH175RhZFLZXnTvLu vfWw== X-Forwarded-Encrypted: i=1; AHgh+Rot+UjXvriJrTmRQhEJADK6/fyRBOyH8QAuGDzsqNUtCmPHKEea4K+1yGI7G6pZ+xYzcRWYYlfVjAhrpb8=@vger.kernel.org X-Gm-Message-State: AOJu0YwdI/qqyA4kXjEO99LPN96WnClrxRyaEmk1gwxUItl5g476W0W3 w7F34PANKxEioIkatKf3/vPnzND/l9dwEBaz330L12YMvdZh8nYRTwZT2XgXzcW0LBc= X-Gm-Gg: AR+sD11C7vT8AnVSMehZ5tqPv0X03haKSVx/Z5LM+gmDZpbTnAE3GJMrzb4FG4rA+AQ eU2as/jAZcievdyldePzXJ+t8lDrrhjDky55KBOlV8GHK4pE33jhTM5BO0PtEQ4U2e7Fkj7hPzd v2cPAzYrVpWZU8VdmZzF1dUqMEPJfmxmNDgYDxWaOTmUCprQT1+3s4WU34fsytrqHG07pfp6Jpc y3/lfz2yhKGYEvUXg3aBjibqaCOhOLP8aXLH9T2M67LolIQ/jmmL5UOPHEXM8vBvhQItzFp29Ih 6tA08w6Z4Ii5ORlz+xtKK2Xrl8xoUWsA87hQRhO4n8DP2XTf7iyAcI5vQIQIOZjo22owP+buSFT VaBEwby75Hbn7l8oFdtRpzhdy4N3/sKvjEewn6h//nNe9grpq5FozgKoFHRkj6Yi7bQ/QzA6/yw 7Ue5Zd X-Received: by 2002:adf:e351:0:b0:478:77c1:787c with SMTP id ffacd0b85a97d-47f6233bf07mr11020582f8f.56.1784547961445; Mon, 20 Jul 2026 04:46:01 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f63e65644sm27955963f8f.16.2026.07.20.04.46.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Jul 2026 04:46:00 -0700 (PDT) Date: Mon, 20 Jul 2026 13:45:58 +0200 From: Petr Mladek To: Karl Mehltretter Cc: Russell King , Greg Kroah-Hartman , Jiri Slaby , linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , linux-rt-devel@lists.linux.dev, Toshiyuki Sato , John Ogness Subject: Re: [PATCH 2/2] serial: amba-pl011: keep console clock enabled for atomic writes Message-ID: References: <20260719063502.18852-1-kmehltretter@gmail.com> <20260719063502.18852-3-kmehltretter@gmail.com> 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: <20260719063502.18852-3-kmehltretter@gmail.com> Adding ARM mailing list into Cc. On Sun 2026-07-19 08:35:02, Karl Mehltretter wrote: > pl011_console_write_atomic() runs from nbcon atomic context, where > sleeping is not allowed. It calls clk_enable(), which takes the > common-clk enable_lock. Under PREEMPT_RT that is a sleeping lock: > clk_enable_lock() first tries spin_trylock_irqsave(), but on contention > falls back to spin_lock_irqsave(), so an atomic-context printk on an RT > kernel with a clk-backed pl011 can trip: > > BUG: sleeping function called from invalid context at spinlock_rt.c:48 > __might_resched from rt_spin_lock > rt_spin_lock from clk_enable_lock > clk_enable_lock from clk_enable > clk_enable from pl011_console_write_atomic > ... from vprintk_emit > > This was found and reproduced on 32-bit ARM with PREEMPT_RT. In > addition, write_atomic() may be invoked from NMI context and is > documented to avoid locking. Since clk_enable() acquires the > common-clock enable_lock, removing it from the callback also avoids a > potentially unsafe NMI lock acquisition. > > An nbcon atomic-capable console must be printable from any context, so > the clock cannot be gated between writes. Enable the clock while the > console is registered: use clk_prepare_enable() in > pl011_console_setup(), release it via clk_disable_unprepare() in the > console .exit() callback, and drop the per-write > clk_enable()/clk_disable() pairs from write_atomic() and > write_thread(). > > Keeping UARTCLK enabled may increase idle power on platforms where it > would otherwise be gated between console writes. Just to be sure. Is this acceptable, please? I have no idea what is the real life effect. It might be negligible. Or maybe it does not effect production systems at all because they do not have the serial console enabled. I just wonder if it might considerably increase the battery usage of some devices, e.g. watches or earbuds, just because of the possibility to write emergency messages via the serial console. Best Regards, Petr