From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CACEBC43444 for ; Fri, 11 Jan 2019 14:21:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9A3902183F for ; Fri, 11 Jan 2019 14:21:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547216480; bh=Bt5f0lJYEwi4Z7PFsaQxjJmeAVqqKZpPP0oZ+SUZ740=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Qwl9oSZO2iE9ZvaSbPEnkXbRmbK9ECmOAQIkxYefyK7KowfWzpDK/K5EF4FVf4cJb yhl8OUxf+OO8rUtozn5PVek8U7pqz4r8gpehzmgfswwhmWtsY3p1CR4rU43zgrEhMq OY5Jko3ryCXsgHWAom61Z9TaHlF6DH0okF4pY4P0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732503AbfAKOVU (ORCPT ); Fri, 11 Jan 2019 09:21:20 -0500 Received: from mail.kernel.org ([198.145.29.99]:37384 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388019AbfAKOT7 (ORCPT ); Fri, 11 Jan 2019 09:19:59 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 21C212184A; Fri, 11 Jan 2019 14:19:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547216398; bh=Bt5f0lJYEwi4Z7PFsaQxjJmeAVqqKZpPP0oZ+SUZ740=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rZzC10NDKph1i9wLYZuIdZ/LgrGMF+J5Td3MwN+vmWE8FebKJTrn+vf1CQJLbrLJM NKCvWmNJRcuzmOytg0aKaoqItfdhsl+lZkiZfOL+RfegKLL7JNMKsgQc88Ic+Ci/Tj rfiTMCXUb251OFVqdQinZAmvVM9LomjhrcnT74ao= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lukas Wunner , Mathias Duckeck , Frank Pavlic , Martin Sperl , =?UTF-8?q?Noralf=20Tr=C3=B8nnes?= , Mark Brown Subject: [PATCH 4.4 48/88] spi: bcm2835: Avoid finishing transfer prematurely in IRQ mode Date: Fri, 11 Jan 2019 15:08:17 +0100 Message-Id: <20190111131053.213760317@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190111131045.137499039@linuxfoundation.org> References: <20190111131045.137499039@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lukas Wunner commit 56c1723426d3cfd4723bfbfce531d7b38bae6266 upstream. The IRQ handler bcm2835_spi_interrupt() first reads as much as possible from the RX FIFO, then writes as much as possible to the TX FIFO. Afterwards it decides whether the transfer is finished by checking if the TX FIFO is empty. If very few bytes were written to the TX FIFO, they may already have been transmitted by the time the FIFO's emptiness is checked. As a result, the transfer will be declared finished and the chip will be reset without reading the corresponding received bytes from the RX FIFO. The odds of this happening increase with a high clock frequency (such that the TX FIFO drains quickly) and either passing "threadirqs" on the command line or enabling CONFIG_PREEMPT_RT_BASE (such that the IRQ handler may be preempted between filling the TX FIFO and checking its emptiness). Fix by instead checking whether rx_len has reached zero, which means that the transfer has been received in full. This is also more efficient as it avoids one bus read access per interrupt. Note that bcm2835_spi_transfer_one_poll() likewise uses rx_len to determine whether the transfer has finished. Signed-off-by: Lukas Wunner Fixes: e34ff011c70e ("spi: bcm2835: move to the transfer_one driver model") Cc: stable@vger.kernel.org # v4.1+ Cc: Mathias Duckeck Cc: Frank Pavlic Cc: Martin Sperl Cc: Noralf Trønnes Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman --- drivers/spi/spi-bcm2835.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/spi/spi-bcm2835.c +++ b/drivers/spi/spi-bcm2835.c @@ -155,8 +155,7 @@ static irqreturn_t bcm2835_spi_interrupt /* Write as many bytes as possible to FIFO */ bcm2835_wr_fifo(bs); - /* based on flags decide if we can finish the transfer */ - if (bcm2835_rd(bs, BCM2835_SPI_CS) & BCM2835_SPI_CS_DONE) { + if (!bs->rx_len) { /* Transfer complete - reset SPI HW */ bcm2835_spi_reset_hw(master); /* wake up the framework */