Received: by 2002:a05:7412:3b8b:b0:fc:a2b0:25d7 with SMTP id nd11csp109400rdb; Wed, 7 Feb 2024 23:56:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IEA2j6Y9Q6WHqo+XlEt7MJW7lcd4fW7ZrPVOajjV8ccex37onEgTzeWjwx1n0dkPBSmDo5w X-Received: by 2002:a17:903:2606:b0:1d9:93d2:5208 with SMTP id jd6-20020a170903260600b001d993d25208mr5922862plb.49.1707379007420; Wed, 07 Feb 2024 23:56:47 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707379007; cv=pass; d=google.com; s=arc-20160816; b=CC6dXIilpvtXK7anTv+LuEpE58wVj0huWzR3okctLAso7DLuTWsww10AZqMqPrAFBZ u6CefvTDgZwDzmOqHduY6ZTVAy2VWfbyIUvhNy4YZG/vFCkQM7W9Ar0B1BBbZWFWXebi 1F6lCQbWWNUGe/9L/S63An+In0DkCBi7ouUHKN9/TkTbw1ZUyap8egtDXyubXrwBpo3P FjB5tOamDQciN8KSgVV8+I6KcSz2wwy2z9afmESoseSgrabTQ3eTsbtyIQ+9v44OgijO fl7NTCGQKVNsCOU0SmzepYeZZ32FU6Uxo3x2GK5kQv3Z2dZUR0BL+ElHknrWv89ypkRY 9ndw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=ThpdSkP7lKmmhfNEmI3N8b3ozWtZQIfgyB+XXgAd5SU=; fh=EDgH/vHN1jFvyBOfXY9XKZ+BDIO/FFzai33d1hJ5DVk=; b=Ic8UkMwlt0n8YEX80qfboTVmga6XNxAjQTQ16CsAbRuKg/T+L5HRs88PZcP+iI3ha2 q/7xfFffyoJuy38PtUP2fxWgenuK+VLx9dsYTI5jzIqTaplws3zeSXPksv4VgUP+DPt+ brzvQ6djy1W8awU+M9ZbMEZP6WJ00rpe83AdXYoy4dzo5m99/lO36RsCZi5njEQnrQl9 t7TL3EX6kdv7P5NumPcYDXFS0JrpsOEmBufW98PX5aAxryvwh4e3+rSjKwVS/MYa3+KN pwxGMojPmTlWou6YTibc2EyziHQW3l2053y4fE7Ltjv0lQSJi+ZpohLB8KrhC3EO4Bsd GBrg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-57577-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-57577-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com X-Forwarded-Encrypted: i=2; AJvYcCW0JtJ1bCUh2hLeGnnd+7fC+scvwvzcHQAn8/8NIbVh+48c5hTMSzsgvBa4T+EYRxyq4TAr5JJso3g7qbrih/tYsbh+liURDmgnNFOhNQ== Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id i5-20020a170902c28500b001d953aa2206si3333591pld.82.2024.02.07.23.56.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Feb 2024 23:56:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-57577-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huawei.com dmarc=pass fromdomain=huawei.com); spf=pass (google.com: domain of linux-kernel+bounces-57577-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-57577-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 13630284E79 for ; Thu, 8 Feb 2024 07:56:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 93B9769E1C; Thu, 8 Feb 2024 07:56:40 +0000 (UTC) Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 513E669E00; Thu, 8 Feb 2024 07:56:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.32 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707379000; cv=none; b=o634+OJ+hgj5PGzoszPpkPGmRhlt3gCD5MuAPE98zShwfsiuXCUgeEykKYHUNZH31bqWpmNgFIQga9Bvc1up9ET6hq0dzurgEfL5T5TCXu4aa9FwTUH5u9J0ExYxXvMLFN0PKwAGP68JqDMlAAPlO0fJtWwMoxqmStiKWZuuIOo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707379000; c=relaxed/simple; bh=2STkhIj0WFVqUpOVShUJc9z+p/pw7S2gBImDUWUPLXk=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=V/jkllYu+tgUyToT6aOzNoa/i4peqzcB2xsOOc+fU68HqDc/k2RXjRNnrCwZu4WcYesG2ZqdTXTOL8K0XYcKv+EoyegpCdMNO1OEBCVdE3a71WX804XYeNgIxcCeK/jkXsInnb/lY6AtAtqJWLhubK+xa3kMM7hdiU9pz0iMoZI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.32 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.234]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4TVq6t0K9kz1vsbR; Thu, 8 Feb 2024 15:56:06 +0800 (CST) Received: from canpemm500009.china.huawei.com (unknown [7.192.105.203]) by mail.maildlp.com (Postfix) with ESMTPS id 8B845140444; Thu, 8 Feb 2024 15:56:34 +0800 (CST) Received: from localhost.localdomain (10.50.165.33) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Thu, 8 Feb 2024 15:56:27 +0800 From: Yicong Yang To: , , , , CC: , , , , , , , Subject: [PATCH v3] serial: port: Don't suspend if the port is still busy Date: Thu, 8 Feb 2024 15:52:15 +0800 Message-ID: <20240208075216.48915-1-yangyicong@huawei.com> X-Mailer: git-send-email 2.31.0 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="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To canpemm500009.china.huawei.com (7.192.105.203) From: Yicong Yang We accidently met the issue that the bash prompt is not shown after the previous command done and until the next input if there's only one CPU (In our issue other CPUs are isolated by isolcpus=). Further analysis shows it's because the port entering runtime suspend even if there's still pending chars in the buffer and the pending chars will only be processed in next device resuming. We are using amba-pl011 and the problematic flow is like below: Bash                                         kworker tty_write()   file_tty_write()     n_tty_write()       uart_write()         __uart_start()           pm_runtime_get() // wakeup waker             queue_work()                                     pm_runtime_work()                                                rpm_resume()                                                 status = RPM_RESUMING                                                 serial_port_runtime_resume()                                                   port->ops->start_tx()                                                     pl011_tx_chars()                                                       uart_write_wakeup()         […]         __uart_start()           pm_runtime_get() < 0 // because runtime status = RPM_RESUMING                                // later data are not commit to the port driver                                                 status = RPM_ACTIVE                                                 rpm_idle() -> rpm_suspend() This patch tries to fix this by checking the port busy before entering runtime suspending. A runtime_suspend callback is added for the port driver. When entering runtime suspend the callback is invoked, if there's still pending chars in the buffer then flush the buffer. Cc: Tony Lindgren Cc: Andy Shevchenko Fixes: 84a9582fd203 ("serial: core: Start managing serial controllers to enable runtime PM") Signed-off-by: Yicong Yang Reviewed-by: Tony Lindgren --- Change since v2: - Narrow the spinlock region per Andy - Make __serial_port_busy() return -EBUSY if port has pending chars per Andy Thanks. Link: https://lore.kernel.org/all/20240206073322.5560-1-yangyicong@huawei.com/ Change since v1: - Use port lock wrapper per John - Flush the pending chars and return -EBUSY per Tony. Thanks. Link: https://lore.kernel.org/all/20240204031957.58176-1-yangyicong@huawei.com/ drivers/tty/serial/serial_port.c | 36 +++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/drivers/tty/serial/serial_port.c b/drivers/tty/serial/serial_port.c index 88975a4df306..8d72f7d95009 100644 --- a/drivers/tty/serial/serial_port.c +++ b/drivers/tty/serial/serial_port.c @@ -19,8 +19,13 @@ /* Only considers pending TX for now. Caller must take care of locking */ static int __serial_port_busy(struct uart_port *port) { - return !uart_tx_stopped(port) && - uart_circ_chars_pending(&port->state->xmit); + if (uart_tx_stopped(port)) + return 0; + + if (uart_circ_chars_pending(&port->state->xmit)) + return -EBUSY; + + return 0; } static int serial_port_runtime_resume(struct device *dev) @@ -46,8 +51,33 @@ static int serial_port_runtime_resume(struct device *dev) return 0; } +static int serial_port_runtime_suspend(struct device *dev) +{ + struct serial_port_device *port_dev = to_serial_base_port_device(dev); + struct uart_port *port; + unsigned long flags; + int ret; + + port = port_dev->port; + + if (port->flags & UPF_DEAD) + return 0; + + uart_port_lock_irqsave(port, &flags); + ret = __serial_port_busy(port); + if (ret) + port->ops->start_tx(port); + uart_port_unlock_irqrestore(port, flags); + + if (ret) + pm_runtime_mark_last_busy(dev); + + return ret; +} + static DEFINE_RUNTIME_DEV_PM_OPS(serial_port_pm, - NULL, serial_port_runtime_resume, NULL); + serial_port_runtime_suspend, + serial_port_runtime_resume, NULL); static int serial_port_probe(struct device *dev) { -- 2.24.0