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.6 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 97619C43387 for ; Mon, 7 Jan 2019 13:20:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6461B21736 for ; Mon, 7 Jan 2019 13:20:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546867201; bh=545UHZUd4Kpwd2q1bcRmZMAmQ41FTTTgbAdJvngpewc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=mM4M4/GjqZywti+nxQuStT50/SrBsj8DHrlLEbxiS3pmxK46r9ViaOjZfWviurE2b qgEYPKzbEzZM/JhEq3BbgCl5tFh4+AbXJiAGyxeU7Au3zNcyAEdq62LeGg11BXQzLl Q2B9ag/E7MkVapZKkyw9M7z+75Wvisu02pSPCFEs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727810AbfAGMzp (ORCPT ); Mon, 7 Jan 2019 07:55:45 -0500 Received: from mail.kernel.org ([198.145.29.99]:43938 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727532AbfAGMzm (ORCPT ); Mon, 7 Jan 2019 07:55:42 -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 0002E20665; Mon, 7 Jan 2019 12:55:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1546865742; bh=545UHZUd4Kpwd2q1bcRmZMAmQ41FTTTgbAdJvngpewc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r264z7pa3D2BaBOCg0QoGfMu04YHm1l8W62cMO51J0ES90BkVFt6qwBF8EwS+GDjV TCol9FECCseRpSYrPRoBsJrypdB+jNyoWW4MM36g2FXBoL3t9as8AuCo5hmlbKLbqv 1qzlDWkQ82xUtYrgnA+t44juVZeeAthm5NGrVe9E= 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.19 117/170] spi: bcm2835: Avoid finishing transfer prematurely in IRQ mode Date: Mon, 7 Jan 2019 13:32:24 +0100 Message-Id: <20190107104506.758086070@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190107104452.953560660@linuxfoundation.org> References: <20190107104452.953560660@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.19-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 */