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=unavailable 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 249BBC43387 for ; Fri, 11 Jan 2019 14:21:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EB5C621783 for ; Fri, 11 Jan 2019 14:21:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1547216484; bh=Bt5f0lJYEwi4Z7PFsaQxjJmeAVqqKZpPP0oZ+SUZ740=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=DHZixrJtfFYqbvm3QR7ldlm5CTJWKw6eMw9oW51nU0qb1lIMBeCWo3Sbq23apk2LM n6uewc3MLMAlFeJTNwxHgJLVHcdZP7pssGd32CiyD2OERHHCY8eG8dj3prlquDAqrD D7vKkTyqXOaPZh7vHcdtyJU4TNY7AXVAinDPu1oI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730004AbfAKOVS (ORCPT ); Fri, 11 Jan 2019 09:21:18 -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: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@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 */