From patchwork Thu May 10 17:08:23 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dave Martin X-Patchwork-Id: 135417 Delivered-To: patch@linaro.org Received: by 10.46.151.6 with SMTP id r6csp1263382lji; Thu, 10 May 2018 10:08:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqAdC2blx2xuTA/bnH/n15LA036lZJj5DQljW+RYBQ2dL1xvbhOC6+gx+yc55QyAn7D5Pdy X-Received: by 2002:a17:902:aa04:: with SMTP id be4-v6mr2145880plb.20.1525972110671; Thu, 10 May 2018 10:08:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525972110; cv=none; d=google.com; s=arc-20160816; b=x3IOYZtewOBNewsslIJ2SabMO7dSfLniU6TAjwKg7xUItZmnP99F6FCCX3C77YHtLA 6dJnKh2sctIQ4VwfKq8aRpL0bDib+/oOT5Ibbj1da2OWATzc5UQQhlaBuEZOaUf7kGAs LhlR7R+3kKw5/2Ehe+Kkq/khUGcHJTTsnKknnazoVwDiovD+Rj5/X15DcxiJGmTSiQWI 51S1Gu7/Y98WQsPhR1ib8rNAW388W7PD9gT0OWzqYUJa9/3iFU9CTXk4QjQXc5TNaYFV rz9rKgl46KKdabw5hOLvoV2aZ/ESM40ZzzwvW2aZ9za7e5RXq3m4E1wCaGH33CuzjT0N 81XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=dF/nYFc3cvU50VbzoQtcL3SelImyyQLfoJHxEk7BkyI=; b=x5SfsWFkt3MgMb+0JRvRsDDDegVXOulKm+ak4Ltguq+HfnbB1c9qgusrsdVcrXhyp/ lUDhfYHhEgMj/UgKXXM7lHCRRdzHX4wAQdmkjQwVJknIM/UUCCHnXhRO9qByZnheEMPf gbXsNtuMiKyTO5ZpyPlKErfJCXWj2UBD2QGNzu82mfMXEBhPC3gb8oeEwP4VVa08t2nX vsCE5A72/OzB2nnxs8L1a6/2hGXwQ5eVsotVyUDfAcVEIi0Z8x3YODelKqEE9lHFJwYD EjaNn7WXCj1GWiA9dmzVsuHR0q38GPz7U7OLR0rZH+Waf7vGtBOJepFb20OTs78VCz/c b22Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-serial-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-serial-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n4-v6si1258518pfa.66.2018.05.10.10.08.30; Thu, 10 May 2018 10:08:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-serial-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-serial-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-serial-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966402AbeEJRIa (ORCPT + 2 others); Thu, 10 May 2018 13:08:30 -0400 Received: from foss.arm.com ([217.140.101.70]:59016 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966398AbeEJRI3 (ORCPT ); Thu, 10 May 2018 13:08:29 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 0916F1435; Thu, 10 May 2018 10:08:29 -0700 (PDT) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 80A2E3F73E; Thu, 10 May 2018 10:08:27 -0700 (PDT) From: Dave Martin To: linux-arm-kernel@lists.infradead.org Cc: linux-serial@vger.kernel.org, Russell King , Linus Walleij , Peter Maydell , Wei Xu , Andrew Jones , Ciro Santilli , Greg KH Subject: [PATCH v2] tty: pl011: Avoid spuriously stuck-off interrupts Date: Thu, 10 May 2018 18:08:23 +0100 Message-Id: <1525972103-26691-1-git-send-email-Dave.Martin@arm.com> X-Mailer: git-send-email 2.1.4 Sender: linux-serial-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org Commit 9b96fbacda34 ("serial: PL011: clear pending interrupts") clears the RX and receive timeout interrupts on pl011 startup, to avoid a screaming-interrupt scenario that can occur when the firmware or bootloader leaves these interrupts asserted. This has been noted as an issue when running Linux on qemu [1]. Unfortunately, the above fix seems to lead to potential misbehaviour if the RX FIFO interrupt is asserted _non_ spuriously on driver startup, if the RX FIFO is also already full to the trigger level. Clearing the RX FIFO interrupt does not change the FIFO fill level. In this scenario, because the interrupt is now clear and because the FIFO is already full to the trigger level, no new assertion of the RX FIFO interrupt can occur unless the FIFO is drained back below the trigger level. This never occurs because the pl011 driver is waiting for an RX FIFO interrupt to tell it that there is something to read, and does not read the FIFO at all until that interrupt occurs. Thus, simply clearing "spurious" interrupts on startup may be misguided, since there is no way to be sure that the interrupts are truly spurious, and things can go wrong if they are not. This patch instead clears the interrupt condition by draining the RX FIFO during UART startup, after clearing any potentially spurious interrupt. This should ensure that an interrupt will definitely be asserted if the RX FIFO subsequently becomes sufficiently full. The drain is done at the point of enabling interrupts only. This means that it will occur any time the UART is newly opened through the tty layer. It will not apply to polled-mode use of the UART by kgdboc: since that scenario cannot use interrupts by design, this should not matter. kgdboc will interact badly with "normal" use of the UART in any case: this patch makes no attempt to paper over such issues. This patch does not attempt to address the case where the RX FIFO fills faster than it can be drained: that is a pathological hardware design problem that is beyond the scope of the driver to work around. As a failsafe, the number of poll iterations for draining the FIFO is limited to twice the FIFO size. This will ensure that the kernel at least boots even if it is impossible to drain the FIFO for some reason. [1] [Qemu-devel] [Qemu-arm] [PATCH] pl011: do not put into fifo before enabled the interruption https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg06446.html Reported-by: Wei Xu Cc: Russell King Cc: Linus Walleij Cc: Peter Maydell Fixes: 9b96fbacda34 ("serial: PL011: clear pending interrupts") Signed-off-by: Dave Martin --- Changes since v1 [1] * Deleted Andrew Jones' Reviewed/Tested-bys due to the following change. If you can please retest that the updated patch fixes your issue that would be appreciated. Suggested by Russell King: * Only drain 2 * FIFO size, to avoid going into an infinite spin if something does wrong. If the FIFO still couldn't be drained sufficiently then pl011 RX won't work properly, but the kernel will at least boot. [1] [PATCH] tty: pl011: Avoid spuriously stuck-off interrupts http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/574362.html --- drivers/tty/serial/amba-pl011.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Tested-by: Wei Xu diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c index 4b40a5b..ebd33c0 100644 --- a/drivers/tty/serial/amba-pl011.c +++ b/drivers/tty/serial/amba-pl011.c @@ -1727,10 +1727,26 @@ static int pl011_allocate_irq(struct uart_amba_port *uap) */ static void pl011_enable_interrupts(struct uart_amba_port *uap) { + unsigned int i; + spin_lock_irq(&uap->port.lock); /* Clear out any spuriously appearing RX interrupts */ pl011_write(UART011_RTIS | UART011_RXIS, uap, REG_ICR); + + /* + * RXIS is asserted only when the RX FIFO transitions from below + * to above the trigger threshold. If the RX FIFO is already + * full to the threshold this can't happen and RXIS will now be + * stuck off. Drain the RX FIFO explicitly to fix this: + */ + for (i = 0; i < uap->fifosize * 2; ++i) { + if (pl011_read(uap, REG_FR) & UART01x_FR_RXFE) + break; + + pl011_read(uap, REG_DR); + } + uap->im = UART011_RTIM; if (!pl011_dma_rx_running(uap)) uap->im |= UART011_RXIM;