Message ID | 20230914183831.587273-1-john.ogness@linutronix.de |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:172:b0:3f2:4152:657d with SMTP id h50csp549444vqi; Thu, 14 Sep 2023 11:40:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFaw/C5nHC3cKgZJslw/+EVIRK5lVw1YA1sB0sNKoI2ZyhtOcVNa6Td26iQM1vlGQWnvrV3 X-Received: by 2002:a05:6a21:788a:b0:159:d4f5:d59 with SMTP id bf10-20020a056a21788a00b00159d4f50d59mr3254069pzc.12.1694716849075; Thu, 14 Sep 2023 11:40:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694716849; cv=none; d=google.com; s=arc-20160816; b=JB96sjmfkgq2LDKSD28rXpzpSgwIc/YeH2hize/WRvahS1sYbaqkJGlLHzM3m+edSw Xw8s03GkMU5FkXXpxIUI7J/92mxo7MDvz5hewBz5L0L7JxdaswaaYroswPGGFfYhL9M7 E8ljGEsIC8sXUC1ftrq5ZAGIPS2ug+/QDIXkJlEduzHlWf2VCeph0/V89AdJOLLInRvj RRqFZb0TyKffrLc6fA/a9VC56iZemaya2dSnLFu0PxRq/huqrUzQxDH4M/hJFRIyyuZg i20oHoCBbXAepATB4pouWMw5KIi8oAESSP8AjR3+0lI2aotET+iA4IBptdUaKu3xYwYB BIMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:dkim-signature:dkim-signature:from; bh=aQcu0Tj+ffJBWZVQ9fNZPj8/IhtyreTS7DJJKIPF900=; fh=XGcUGZFq91PndIxB/X5tkBsXmlDmdTqA4KDzRqQvHYg=; b=A7DReS8lD8TW44li9frR+PRn0m+1mzRPso967iZl3uN40gNosIv2vitoHsMNxtmk10 gsIBPfUR8RLT4tjA+owUm36PW2/pFfwV2PjF26jjs4b/aheAfClKW7fMOQnbW2kTtfEL 8heXAaBqVqZzvJDC/1dut/wbprf1PiNVuWWx0J47+l6aEDO77GDrf+WrZBkzVCKd1CCN mMm4O78Ta7vvq5inXp5PMwzpPx9dF9shXPeXwsuIbwILOzNEQ2QdAn63x7XDsoQFzmSK 6oUMvlkD3VhYH5AqOsDKFBb7ARaBL9TJMUf6Yg42shakHJy4vcI59ElyUqwCE0D/l0Q3 68Dw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Z8UeMKj4; dkim=neutral (no key) header.i=@linutronix.de header.b="6i/Rykkl"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from lipwig.vger.email (lipwig.vger.email. [2620:137:e000::3:3]) by mx.google.com with ESMTPS id k24-20020a63ff18000000b005697ebac19esi1523122pgi.776.2023.09.14.11.40.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 11:40:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) client-ip=2620:137:e000::3:3; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=Z8UeMKj4; dkim=neutral (no key) header.i=@linutronix.de header.b="6i/Rykkl"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:3 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by lipwig.vger.email (Postfix) with ESMTP id 998D982AC787; Thu, 14 Sep 2023 11:39:07 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at lipwig.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241683AbjINSiz (ORCPT <rfc822;pwkd43@gmail.com> + 33 others); Thu, 14 Sep 2023 14:38:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231243AbjINSiq (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 14 Sep 2023 14:38:46 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DD4911FD7; Thu, 14 Sep 2023 11:38:41 -0700 (PDT) From: John Ogness <john.ogness@linutronix.de> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1694716719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=aQcu0Tj+ffJBWZVQ9fNZPj8/IhtyreTS7DJJKIPF900=; b=Z8UeMKj4Fav9MLhk6d+JmpTi5nJHEpVJNO1ur5Ad3vBiVWCnoe9Eog0Qg33XlH6id3FWbz S8l2Lt2jSbU2XHwf8xi9UIitF4+b8K7paGx1bjjYr5t2rdTDVV0Fim6UAKFi2CtuZ1mb3L E0TJN4HYA+tWtKTLOiVDx3F+jVsGlfsYYAnFZvFt3iKUUrP7SkGJJcZ1UIkJ/UqIQ0831V SMEuLB8ZIcl+FG04i7hT9/QWq5F02SyOTdFIc9j7ps1+LHHwMSHMPuADoGutw3ZHkUAICp RXxdloN+Gh4cSEl07/GwEgsU+m8aqlGccQ2NbBYv7A5wSEzPoJaqC36jkiHDjg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1694716719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=aQcu0Tj+ffJBWZVQ9fNZPj8/IhtyreTS7DJJKIPF900=; b=6i/Rykkl4Rl5SBtIHP9RIQNQNOB8Crkkj2AcFISLN8Dmxq51odZMyUMI6Usmo7xHPgkuGu 8OGeRMSrDoYZsqCg== To: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Jiri Slaby <jirislaby@kernel.org>, linux-serial@vger.kernel.org, Petr Mladek <pmladek@suse.com>, Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org, Tobias Klauser <tklauser@distanz.ch>, Thierry Reding <treding@nvidia.com>, Joel Stanley <joel@jms.id.au>, Andrew Jeffery <andrew@aj.id.au>, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, Al Cooper <alcooperx@gmail.com>, Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com>, Tony Lindgren <tony@atomide.com>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, =?utf-8?q?Ilpo_J=C3=A4?= =?utf-8?q?rvinen?= <ilpo.jarvinen@linux.intel.com>, Florian Fainelli <f.fainelli@gmail.com>, Andrew Davis <afd@ti.com>, Matthew Howell <matthew.howell@sealevel.com>, =?utf-8?q?Uwe_Kleine-K=C3=B6n?= =?utf-8?q?ig?= <u.kleine-koenig@pengutronix.de>, Johan Hovold <johan@kernel.org>, Matthias Brugger <matthias.bgg@gmail.com>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Chen-Yu Tsai <wenst@chromium.org>, linux-mediatek@lists.infradead.org, Lukas Wunner <lukas@wunner.de>, Matthias Schiffer <matthias.schiffer@ew.tq-group.com>, Arnd Bergmann <arnd@arndb.de>, Kumaravel Thiagarajan <kumaravel.thiagarajan@microchip.com>, Tharun Kumar P <tharunkumar.pasumarthi@microchip.com>, Russell King <linux@armlinux.org.uk>, "Maciej W. Rozycki" <macro@orcam.me.uk>, Hongyu Xie <xiehongyu1@kylinos.cn>, Jiamei Xie <jiamei.xie@arm.com>, Rob Herring <robh@kernel.org>, delisun <delisun@pateo.com.cn>, Lino Sanfilippo <l.sanfilippo@kunbus.com>, Yangtao Li <frank.li@vivo.com>, Vineet Gupta <vgupta@kernel.org>, linux-snps-arc@lists.infradead.org, Richard Genoud <richard.genoud@gmail.com>, Nicolas Ferre <nicolas.ferre@microchip.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Claudiu Beznea <claudiu.beznea@tuxon.dev>, Arend van Spriel <arend.vanspriel@broadcom.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, Baruch Siach <baruch@tkos.co.il>, Sherry Sun <sherry.sun@nxp.com>, Shenwei Wang <shenwei.wang@nxp.com>, Shawn Guo <shawnguo@kernel.org>, Sascha Hauer <s.hauer@pengutronix.de>, Pengutronix Kernel Team <kernel@pengutronix.de>, Fabio Estevam <festevam@gmail.com>, NXP Linux Team <linux-imx@nxp.com>, Sergey Organov <sorganov@gmail.com>, Tom Rix <trix@redhat.com>, Marek Vasut <marex@denx.de>, Karol Gugala <kgugala@antmicro.com>, Mateusz Holenko <mholenko@antmicro.com>, Gabriel Somlo <gsomlo@gmail.com>, Vladimir Zapolskiy <vz@mleia.com>, Jacky Huang <ychuang3@nuvoton.com>, Shan-Chun Hung <schung@nuvoton.com>, Neil Armstrong <neil.armstrong@linaro.org>, Kevin Hilman <khilman@baylibre.com>, Jerome Brunet <jbrunet@baylibre.com>, Martin Blumenstingl <martin.blumenstingl@googlemail.com>, Dmitry Rokosov <ddrokosov@sberdevices.ru>, Lucas Tanure <tanure@linux.com>, linux-amlogic@lists.infradead.org, Taichi Sugaya <sugaya.taichi@socionext.com>, Takao Orito <orito.takao@socionext.com>, Liviu Dudau <liviu.dudau@arm.com>, Sudeep Holla <sudeep.holla@arm.com>, Lorenzo Pieralisi <lpieralisi@kernel.org>, Andy Gross <agross@kernel.org>, Bjorn Andersson <andersson@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, linux-arm-msm@vger.kernel.org, =?utf-8?q?Pali_Roh=C3=A1r?= <pali@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, =?utf-8?q?Andreas_F=C3=A4rber?= <afaerber@suse.de>, Manivannan Sadhasivam <mani@kernel.org>, linux-actions@lists.infradead.org, Xiongfeng Wang <wangxiongfeng2@huawei.com>, Yuan Can <yuancan@huawei.com>, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, linuxppc-dev@lists.ozlabs.org, linux-unisoc@lists.infradead.org, Kevin Cernekee <cernekee@gmail.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Alim Akhtar <alim.akhtar@samsung.com>, linux-samsung-soc@vger.kernel.org, Lukas Bulwahn <lukas.bulwahn@gmail.com>, Lech Perczak <lech.perczak@camlingroup.com>, Hugo Villeneuve <hvilleneuve@dimonoff.com>, Andy Shevchenko <andy.shevchenko@gmail.com>, Isaac True <isaac.true@canonical.com>, Laxman Dewangan <ldewangan@nvidia.com>, Thierry Reding <thierry.reding@gmail.com>, Jonathan Hunter <jonathanh@nvidia.com>, linux-tegra@vger.kernel.org, Biju Das <biju.das.jz@bp.renesas.com>, Geert Uytterhoeven <geert+renesas@glider.be>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Nick Hu <nick.hu@sifive.com>, Ruan Jinjie <ruanjinjie@huawei.com>, Samuel Holland <samuel.holland@sifive.com>, linux-riscv@lists.infradead.org, Orson Zhai <orsonzhai@gmail.com>, Baolin Wang <baolin.wang@linux.alibaba.com>, Chunyan Zhang <zhang.lyra@gmail.com>, Patrice Chotard <patrice.chotard@foss.st.com>, Maxime Coquelin <mcoquelin.stm32@gmail.com>, Alexandre Torgue <alexandre.torgue@foss.st.com>, Valentin Caron <valentin.caron@foss.st.com>, Sebastian Andrzej Siewior <bigeasy@linutronix.de>, linux-stm32@st-md-mailman.stormreply.com, "David S. Miller" <davem@davemloft.net>, sparclinux@vger.kernel.org, Hammer Hsieh <hammerh0314@gmail.com>, Peter Korsgaard <jacmet@sunsite.dk>, Timur Tabi <timur@kernel.org>, Mukesh Ojha <quic_mojha@quicinc.com>, =?utf-8?q?Jonathan_Neusch=C3=A4fer?= <j.neuschaefer@gmx.net>, Michal Simek <michal.simek@amd.com> Subject: [PATCH tty v1 00/74] serial: wrappers for uart port lock Date: Thu, 14 Sep 2023 20:43:17 +0206 Message-Id: <20230914183831.587273-1-john.ogness@linutronix.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (lipwig.vger.email [0.0.0.0]); Thu, 14 Sep 2023 11:39:07 -0700 (PDT) X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INVALID_DATE_TZ_ABSURD, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lipwig.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1777039414495180103 X-GMAIL-MSGID: 1777039414495180103 |
Series |
serial: wrappers for uart port lock
|
|
Message
John Ogness
Sept. 14, 2023, 6:37 p.m. UTC
When a serial port is used for kernel console output, then all modifications to the UART registers which are done from other contexts, e.g. getty, termios, are interference points for the kernel console. So far this has been ignored and the printk output is based on the principle of hope. The rework of the console infrastructure which aims to support threaded and atomic consoles, requires to mark sections which modify the UART registers as unsafe. This allows the atomic write function to make informed decisions and eventually to restore operational state. It also allows to prevent the regular UART code from modifying UART registers while printk output is in progress. All modifications of UART registers are guarded by the UART port lock, which provides an obvious synchronization point with the console infrastructure. Provide and use wrapper functions for spin_[un]lock*(port->lock) invocations so that the console mechanics can be applied later on at a single place and does not require to copy the same logic all over the drivers. Patch 1 adds the wrapper functions. Patches 2-74 switch all uart port locking call sites to use the new wrappers. These patches were automatically generated using coccinelle. The 2 used coccinelle scripts are included below and executed as follows: $ spatch --sp-file uartlock-1.cocci $FILE $ spatch --sp-file uartlock-2.cocci --recursive-includes $FILE This series brings no functional change. Patches 2-74 contain identical commit message bodies. Feel free to fold them into a single commit if that seems more reasonable. Thomas Gleixner (74): serial: core: Provide port lock wrappers serial: core: Use lock wrappers serial: 21285: Use port lock wrappers serial: 8250_aspeed_vuart: Use port lock wrappers serial: 8250_bcm7271: Use port lock wrappers serial: 8250: Use port lock wrappers serial: 8250_dma: Use port lock wrappers serial: 8250_dw: Use port lock wrappers serial: 8250_exar: Use port lock wrappers serial: 8250_fsl: Use port lock wrappers serial: 8250_mtk: Use port lock wrappers serial: 8250_omap: Use port lock wrappers serial: 8250_pci1xxxx: Use port lock wrappers serial: altera_jtaguart: Use port lock wrappers serial: altera_uart: Use port lock wrappers serial: amba-pl010: Use port lock wrappers serial: amba-pl011: Use port lock wrappers serial: apb: Use port lock wrappers serial: ar933x: Use port lock wrappers serial: arc_uart: Use port lock wrappers serial: atmel: Use port lock wrappers serial: bcm63xx-uart: Use port lock wrappers serial: cpm_uart: Use port lock wrappers serial: digicolor: Use port lock wrappers serial: dz: Use port lock wrappers serial: linflexuart: Use port lock wrappers serial: fsl_lpuart: Use port lock wrappers serial: icom: Use port lock wrappers serial: imx: Use port lock wrappers serial: ip22zilog: Use port lock wrappers serial: jsm: Use port lock wrappers serial: liteuart: Use port lock wrappers serial: lpc32xx_hs: Use port lock wrappers serial: ma35d1: Use port lock wrappers serial: mcf: Use port lock wrappers serial: men_z135_uart: Use port lock wrappers serial: meson: Use port lock wrappers serial: milbeaut_usio: Use port lock wrappers serial: mpc52xx: Use port lock wrappers serial: mps2-uart: Use port lock wrappers serial: msm: Use port lock wrappers serial: mvebu-uart: Use port lock wrappers serial: omap: Use port lock wrappers serial: owl: Use port lock wrappers serial: pch: Use port lock wrappers serial: pic32: Use port lock wrappers serial: pmac_zilog: Use port lock wrappers serial: pxa: Use port lock wrappers serial: qcom-geni: Use port lock wrappers serial: rda: Use port lock wrappers serial: rp2: Use port lock wrappers serial: sa1100: Use port lock wrappers serial: samsung_tty: Use port lock wrappers serial: sb1250-duart: Use port lock wrappers serial: sc16is7xx: Use port lock wrappers serial: tegra: Use port lock wrappers serial: core: Use port lock wrappers serial: mctrl_gpio: Use port lock wrappers serial: txx9: Use port lock wrappers serial: sh-sci: Use port lock wrappers serial: sifive: Use port lock wrappers serial: sprd: Use port lock wrappers serial: st-asc: Use port lock wrappers serial: stm32: Use port lock wrappers serial: sunhv: Use port lock wrappers serial: sunplus-uart: Use port lock wrappers serial: sunsab: Use port lock wrappers serial: sunsu: Use port lock wrappers serial: sunzilog: Use port lock wrappers serial: timbuart: Use port lock wrappers serial: uartlite: Use port lock wrappers serial: ucc_uart: Use port lock wrappers serial: vt8500: Use port lock wrappers serial: xilinx_uartps: Use port lock wrappers drivers/tty/serial/21285.c | 8 +- drivers/tty/serial/8250/8250_aspeed_vuart.c | 6 +- drivers/tty/serial/8250/8250_bcm7271.c | 28 +++--- drivers/tty/serial/8250/8250_core.c | 12 +-- drivers/tty/serial/8250/8250_dma.c | 8 +- drivers/tty/serial/8250/8250_dw.c | 8 +- drivers/tty/serial/8250/8250_exar.c | 4 +- drivers/tty/serial/8250/8250_fsl.c | 6 +- drivers/tty/serial/8250/8250_mtk.c | 8 +- drivers/tty/serial/8250/8250_omap.c | 52 +++++----- drivers/tty/serial/8250/8250_pci1xxxx.c | 8 +- drivers/tty/serial/8250/8250_port.c | 100 ++++++++++---------- drivers/tty/serial/altera_jtaguart.c | 28 +++--- drivers/tty/serial/altera_uart.c | 20 ++-- drivers/tty/serial/amba-pl010.c | 20 ++-- drivers/tty/serial/amba-pl011.c | 72 +++++++------- drivers/tty/serial/apbuart.c | 8 +- drivers/tty/serial/ar933x_uart.c | 26 ++--- drivers/tty/serial/arc_uart.c | 16 ++-- drivers/tty/serial/atmel_serial.c | 24 ++--- drivers/tty/serial/bcm63xx_uart.c | 22 ++--- drivers/tty/serial/cpm_uart.c | 8 +- drivers/tty/serial/digicolor-usart.c | 18 ++-- drivers/tty/serial/dz.c | 32 +++---- drivers/tty/serial/fsl_linflexuart.c | 26 ++--- drivers/tty/serial/fsl_lpuart.c | 88 ++++++++--------- drivers/tty/serial/icom.c | 26 ++--- drivers/tty/serial/imx.c | 84 ++++++++-------- drivers/tty/serial/ip22zilog.c | 36 +++---- drivers/tty/serial/jsm/jsm_neo.c | 4 +- drivers/tty/serial/jsm/jsm_tty.c | 16 ++-- drivers/tty/serial/liteuart.c | 20 ++-- drivers/tty/serial/lpc32xx_hs.c | 26 ++--- drivers/tty/serial/ma35d1_serial.c | 22 ++--- drivers/tty/serial/mcf.c | 20 ++-- drivers/tty/serial/men_z135_uart.c | 8 +- drivers/tty/serial/meson_uart.c | 30 +++--- drivers/tty/serial/milbeaut_usio.c | 16 ++-- drivers/tty/serial/mpc52xx_uart.c | 12 +-- drivers/tty/serial/mps2-uart.c | 16 ++-- drivers/tty/serial/msm_serial.c | 38 ++++---- drivers/tty/serial/mvebu-uart.c | 18 ++-- drivers/tty/serial/omap-serial.c | 38 ++++---- drivers/tty/serial/owl-uart.c | 26 ++--- drivers/tty/serial/pch_uart.c | 10 +- drivers/tty/serial/pic32_uart.c | 20 ++-- drivers/tty/serial/pmac_zilog.c | 52 +++++----- drivers/tty/serial/pxa.c | 30 +++--- drivers/tty/serial/qcom_geni_serial.c | 8 +- drivers/tty/serial/rda-uart.c | 34 +++---- drivers/tty/serial/rp2.c | 20 ++-- drivers/tty/serial/sa1100.c | 20 ++-- drivers/tty/serial/samsung_tty.c | 50 +++++----- drivers/tty/serial/sb1250-duart.c | 12 +-- drivers/tty/serial/sc16is7xx.c | 40 ++++---- drivers/tty/serial/serial-tegra.c | 32 +++---- drivers/tty/serial/serial_core.c | 88 ++++++++--------- drivers/tty/serial/serial_mctrl_gpio.c | 4 +- drivers/tty/serial/serial_port.c | 4 +- drivers/tty/serial/serial_txx9.c | 26 ++--- drivers/tty/serial/sh-sci.c | 68 ++++++------- drivers/tty/serial/sifive.c | 16 ++-- drivers/tty/serial/sprd_serial.c | 30 +++--- drivers/tty/serial/st-asc.c | 18 ++-- drivers/tty/serial/stm32-usart.c | 38 ++++---- drivers/tty/serial/sunhv.c | 28 +++--- drivers/tty/serial/sunplus-uart.c | 26 ++--- drivers/tty/serial/sunsab.c | 34 +++---- drivers/tty/serial/sunsu.c | 46 ++++----- drivers/tty/serial/sunzilog.c | 42 ++++---- drivers/tty/serial/timbuart.c | 8 +- drivers/tty/serial/uartlite.c | 18 ++-- drivers/tty/serial/ucc_uart.c | 4 +- drivers/tty/serial/vt8500_serial.c | 8 +- drivers/tty/serial/xilinx_uartps.c | 56 +++++------ include/linux/serial_core.h | 91 ++++++++++++++++-- 76 files changed, 1086 insertions(+), 1007 deletions(-) base-commit: 0bb80ecc33a8fb5a682236443c1e740d5c917d1d
Comments
On Thu, 14 Sep 2023, John Ogness wrote: > Patches 2-74 switch all uart port locking call sites to use the new > wrappers. These patches were automatically generated using coccinelle. Hmm, no need to do this for drivers/tty/serial/zs.c? Maciej
On Thu, Sep 14, 2023 at 08:44:06PM +0206, John Ogness wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > When a serial port is used for kernel console output, then all > modifications to the UART registers which are done from other contexts, > e.g. getty, termios, are interference points for the kernel console. > > So far this has been ignored and the printk output is based on the > principle of hope. The rework of the console infrastructure which aims to > support threaded and atomic consoles, requires to mark sections which > modify the UART registers as unsafe. This allows the atomic write function > to make informed decisions and eventually to restore operational state. It > also allows to prevent the regular UART code from modifying UART registers > while printk output is in progress. > > All modifications of UART registers are guarded by the UART port lock, > which provides an obvious synchronization point with the console > infrastructure. > > To avoid adding this functionality to all UART drivers, wrap the > spin_[un]lock*() invocations for uart_port::lock into helper functions > which just contain the spin_[un]lock*() invocations for now. In a > subsequent step these helpers will gain the console synchronization > mechanisms. > > Converted with coccinelle. No functional change. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com> > --- > drivers/tty/serial/qcom_geni_serial.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/tty/serial/qcom_geni_serial.c b/drivers/tty/serial/qcom_geni_serial.c > index b8aa4c1293ba..7e78f97e8f43 100644 > --- a/drivers/tty/serial/qcom_geni_serial.c > +++ b/drivers/tty/serial/qcom_geni_serial.c > @@ -482,9 +482,9 @@ static void qcom_geni_serial_console_write(struct console *co, const char *s, > > uport = &port->uport; > if (oops_in_progress) > - locked = spin_trylock_irqsave(&uport->lock, flags); > + locked = uart_port_trylock_irqsave(uport, &flags); > else > - spin_lock_irqsave(&uport->lock, flags); > + uart_port_lock_irqsave(uport, &flags); > > geni_status = readl(uport->membase + SE_GENI_STATUS); > > @@ -520,7 +520,7 @@ static void qcom_geni_serial_console_write(struct console *co, const char *s, > qcom_geni_serial_setup_tx(uport, port->tx_remaining); > > if (locked) > - spin_unlock_irqrestore(&uport->lock, flags); > + uart_port_unlock_irqrestore(uport, flags); > } > > static void handle_rx_console(struct uart_port *uport, u32 bytes, bool drop) > @@ -970,7 +970,7 @@ static irqreturn_t qcom_geni_serial_isr(int isr, void *dev) > if (uport->suspended) > return IRQ_NONE; > > - spin_lock(&uport->lock); > + uart_port_lock(uport); > Nice, now this no longer look unbalanced with the unlock in uart_port_unlock_irqrestore(). Regards, Bjorn > m_irq_status = readl(uport->membase + SE_GENI_M_IRQ_STATUS); > s_irq_status = readl(uport->membase + SE_GENI_S_IRQ_STATUS); > -- > 2.39.2 >
On Thu, 14 Sep 2023, John Ogness wrote: > When a serial port is used for kernel console output, then all > modifications to the UART registers which are done from other contexts, > e.g. getty, termios, are interference points for the kernel console. > > So far this has been ignored and the printk output is based on the > principle of hope. The rework of the console infrastructure which aims to > support threaded and atomic consoles, requires to mark sections which > modify the UART registers as unsafe. This allows the atomic write function > to make informed decisions and eventually to restore operational state. It > also allows to prevent the regular UART code from modifying UART registers > while printk output is in progress. Hi John, Would this also be useful to enable printing to console while under port's lock (by postponing the output until the lock is released)? E.g., 8250_dw.c has had this commented out since the dawn on time: /* * FIXME: this deadlocks if port->lock is already held * dev_err(p->dev, "Couldn't set LCR to %d\n", value); */
On Thu, 14 Sep 2023, John Ogness wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > When a serial port is used for kernel console output, then all > modifications to the UART registers which are done from other contexts, > e.g. getty, termios, are interference points for the kernel console. > > So far this has been ignored and the printk output is based on the > principle of hope. The rework of the console infrastructure which aims to > support threaded and atomic consoles, requires to mark sections which > modify the UART registers as unsafe. This allows the atomic write function > to make informed decisions and eventually to restore operational state. It > also allows to prevent the regular UART code from modifying UART registers > while printk output is in progress. > > All modifications of UART registers are guarded by the UART port lock, > which provides an obvious synchronization point with the console > infrastructure. > > Provide wrapper functions for spin_[un]lock*(port->lock) invocations so > that the console mechanics can be applied later on at a single place and > does not require to copy the same logic all over the drivers. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > --- > include/linux/serial_core.h | 79 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > index bb6f073bc159..f1d5c0d1568c 100644 > --- a/include/linux/serial_core.h > +++ b/include/linux/serial_core.h > @@ -588,6 +588,85 @@ struct uart_port { > void *private_data; /* generic platform data pointer */ > }; > > +/** > + * uart_port_lock - Lock the UART port > + * @up: Pointer to UART port structure > + */ > +static inline void uart_port_lock(struct uart_port *up) > +{ > + spin_lock(&up->lock); > +} > + > +/** > + * uart_port_lock_irq - Lock the UART port and disable interrupts > + * @up: Pointer to UART port structure > + */ > +static inline void uart_port_lock_irq(struct uart_port *up) > +{ > + spin_lock_irq(&up->lock); > +} > + > +/** > + * uart_port_lock_irqsave - Lock the UART port, save and disable interrupts > + * @up: Pointer to UART port structure > + * @flags: Pointer to interrupt flags storage > + */ > +static inline void uart_port_lock_irqsave(struct uart_port *up, unsigned long *flags) > +{ > + spin_lock_irqsave(&up->lock, *flags); > +} > + > +/** > + * uart_port_trylock - Try to lock the UART port > + * @up: Pointer to UART port structure > + * > + * Returns: True if lock was acquired, false otherwise > + */ > +static inline bool uart_port_trylock(struct uart_port *up) > +{ > + return spin_trylock(&up->lock); > +} > + > +/** > + * uart_port_trylock_irqsave - Try to lock the UART port, save and disable interrupts > + * @up: Pointer to UART port structure > + * @flags: Pointer to interrupt flags storage > + * > + * Returns: True if lock was acquired, false otherwise > + */ > +static inline bool uart_port_trylock_irqsave(struct uart_port *up, unsigned long *flags) > +{ > + return spin_trylock_irqsave(&up->lock, *flags); > +} > + > +/** > + * uart_port_unlock - Unlock the UART port > + * @up: Pointer to UART port structure > + */ > +static inline void uart_port_unlock(struct uart_port *up) > +{ > + spin_unlock(&up->lock); > +} > + > +/** > + * uart_port_unlock_irq - Unlock the UART port and re-enable interrupts > + * @up: Pointer to UART port structure > + */ > +static inline void uart_port_unlock_irq(struct uart_port *up) > +{ > + spin_unlock_irq(&up->lock); > +} > + > +/** > + * uart_port_lock_irqrestore - Unlock the UART port, restore interrupts > + * @up: Pointer to UART port structure > + * @flags: The saved interrupt flags for restore > + */ > +static inline void uart_port_unlock_irqrestore(struct uart_port *up, unsigned long flags) > +{ > + spin_unlock_irqrestore(&up->lock, flags); > +} > + > static inline int serial_port_in(struct uart_port *up, int offset) > { > return up->serial_in(up, offset); > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On Thu, 14 Sep 2023, John Ogness wrote: > From: Thomas Gleixner <tglx@linutronix.de> > > When a serial port is used for kernel console output, then all > modifications to the UART registers which are done from other contexts, > e.g. getty, termios, are interference points for the kernel console. > > So far this has been ignored and the printk output is based on the > principle of hope. The rework of the console infrastructure which aims to > support threaded and atomic consoles, requires to mark sections which > modify the UART registers as unsafe. This allows the atomic write function > to make informed decisions and eventually to restore operational state. It > also allows to prevent the regular UART code from modifying UART registers > while printk output is in progress. > > All modifications of UART registers are guarded by the UART port lock, > which provides an obvious synchronization point with the console > infrastructure. > > To avoid adding this functionality to all UART drivers, wrap the > spin_[un]lock*() invocations for uart_port::lock into helper functions > which just contain the spin_[un]lock*() invocations for now. In a > subsequent step these helpers will gain the console synchronization > mechanisms. > > Converted with coccinelle. No functional change. > > Signed-off-by: Thomas Gleixner <tglx@linutronix.de> > --- > include/linux/serial_core.h | 12 ++++++------ > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > index f1d5c0d1568c..3091c62ec37b 100644 > --- a/include/linux/serial_core.h > +++ b/include/linux/serial_core.h > @@ -1035,14 +1035,14 @@ static inline void uart_unlock_and_check_sysrq(struct uart_port *port) > u8 sysrq_ch; > > if (!port->has_sysrq) { > - spin_unlock(&port->lock); > + uart_port_unlock(port); > return; > } > > sysrq_ch = port->sysrq_ch; > port->sysrq_ch = 0; > > - spin_unlock(&port->lock); > + uart_port_unlock(port); > > if (sysrq_ch) > handle_sysrq(sysrq_ch); > @@ -1054,14 +1054,14 @@ static inline void uart_unlock_and_check_sysrq_irqrestore(struct uart_port *port > u8 sysrq_ch; > > if (!port->has_sysrq) { > - spin_unlock_irqrestore(&port->lock, flags); > + uart_port_unlock_irqrestore(port, flags); > return; > } > > sysrq_ch = port->sysrq_ch; > port->sysrq_ch = 0; > > - spin_unlock_irqrestore(&port->lock, flags); > + uart_port_unlock_irqrestore(port, flags); > > if (sysrq_ch) > handle_sysrq(sysrq_ch); > @@ -1077,12 +1077,12 @@ static inline int uart_prepare_sysrq_char(struct uart_port *port, u8 ch) > } > static inline void uart_unlock_and_check_sysrq(struct uart_port *port) > { > - spin_unlock(&port->lock); > + uart_port_unlock(port); > } > static inline void uart_unlock_and_check_sysrq_irqrestore(struct uart_port *port, > unsigned long flags) > { > - spin_unlock_irqrestore(&port->lock, flags); > + uart_port_unlock_irqrestore(port, flags); > } > #endif /* CONFIG_MAGIC_SYSRQ_SERIAL */ > > Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
On Thu, Sep 14 2023 at 20:01, Maciej W. Rozycki wrote: > On Thu, 14 Sep 2023, John Ogness wrote: > >> Patches 2-74 switch all uart port locking call sites to use the new >> wrappers. These patches were automatically generated using coccinelle. > > Hmm, no need to do this for drivers/tty/serial/zs.c? zs.c does not use port lock at all. It has like a couple of other drivers a local homebrewn spinlock. Thanks, tglx
On Fri, 15 Sep 2023, Thomas Gleixner wrote: > >> Patches 2-74 switch all uart port locking call sites to use the new > >> wrappers. These patches were automatically generated using coccinelle. > > > > Hmm, no need to do this for drivers/tty/serial/zs.c? > > zs.c does not use port lock at all. It has like a couple of other > drivers a local homebrewn spinlock. Ah, right, that's because there are registers shared between two ports within one SCC, so the spinlock has to be shared as well. This also indicates that dz.c is wrong and shouldn't be using a per-port spinlock as the DZ has a shared register set between all the four ports (it's a serial line multiplexer rather than a set discrete ports; up to 8 lines are architecturally supported, though we don't have support in Linux for systems having those), e.g. there's only one 16-bit receiver buffer register for all the four ports, supplying the 8-bit character received along with the receive status and the number of the line this data arrived on, and similarly there's only one transmit data register, which supplies data to the next enabled line whose transmit buffer needs servicing, and the chip routes the data itself. Therefore the driver ought to use a shared spinlock too. I guess it wasn't noticed so far because DZ devices aren't that common (and my usual test machine is currently broken too, pending an SRAM chip replacement, hopefully in the next few weeks) and then hardly ever more than one serial line has been used at a time with these devices. It looks like the first issue for me to look into once the machine has been fixed. Maybe dz.c shouldn't be touched by this series then? (Though obviously both drivers will have to be eventually adapted for the ultimate console rework.) Thanks for your input, as it turns out it has had an unexpected outcome. Maciej
On 2023-09-15, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote: > Maybe dz.c shouldn't be touched by this series then? Correct. This series is only wrapping the uart port lock, which dz.c is not using. > Though obviously both drivers will have to be eventually adapted for > the ultimate console rework. Correct. Thanks for clarifying how the hardware works. John
On 2023-09-15, Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote: > Would this also be useful to enable printing to console while under > port's lock (by postponing the output until the lock is released)? > > E.g., 8250_dw.c has had this commented out since the dawn on time: > /* > * FIXME: this deadlocks if port->lock is already held > * dev_err(p->dev, "Couldn't set LCR to %d\n", value); > */ Yes, this will fix such issues. However, only for consoles that are converted to the new NBCON console type. Good news, the 8250 driver will be the flagship driver that is converted as part of the rework. So this particular issue will be solved then. I will try to remember this so that I can remove the FIXME in the series. Thanks for mentioning it. John
On 2023-09-14, John Ogness <john.ogness@linutronix.de> wrote: > Provide and use wrapper functions for spin_[un]lock*(port->lock) > invocations so that the console mechanics can be applied later on at a > single place and does not require to copy the same logic all over the > drivers. For the full 74-patch series: Signed-off-by: John Ogness <john.ogness@linutronix.de> Sorry that my SoB was missing from the initial posting. John Ogness
On Mon, Sep 18, 2023 at 10:29:30AM +0206, John Ogness wrote: > On 2023-09-14, John Ogness <john.ogness@linutronix.de> wrote: > > Provide and use wrapper functions for spin_[un]lock*(port->lock) > > invocations so that the console mechanics can be applied later on at a > > single place and does not require to copy the same logic all over the > > drivers. > > For the full 74-patch series: > > Signed-off-by: John Ogness <john.ogness@linutronix.de> > > Sorry that my SoB was missing from the initial posting. Thanks for this, I'll rebuild my tree with this added. greg k-h