Received: by 10.223.185.116 with SMTP id b49csp1131436wrg; Wed, 14 Feb 2018 12:06:53 -0800 (PST) X-Google-Smtp-Source: AH8x2265MYNsBI61OloeSEQUz44AkKsh8SiFQwTuAJZPBPOalf4auvVqdhzqDryR31GLnNxrgni4 X-Received: by 2002:a17:902:3124:: with SMTP id w33-v6mr180567plb.356.1518638812825; Wed, 14 Feb 2018 12:06:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518638812; cv=none; d=google.com; s=arc-20160816; b=mr346JUITCDxf987N05JbGuBnakE9Bb+GocDMWtlNLEFKAD9f3jWAHH7DYFwHc1Eww XEcAHUbHRTN5leLfUWaSDN4jS/YiN6swBb3fFTb5Pgpv2lOdVl6zcHjLA6IFRS+upye5 meQibLPGWVBEzxnmi7/8SiKshRv2Ymuda/rdds+mssCeeIHverXdciQ8zCOGGXuWEFiF hjuk7vLCoUhOtgbp6sdmHuzxMuOVIu1YrM8nGfnMy+Z+LYw53FqESb9nuMeJw9Rdsbrz dABpPWL1btyCAJnoRbmoIPugirHlKjZHIUeo55T07KW0RUbRHPvYC8soJ8OH5FuzqO9X dIrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:message-id:in-reply-to:subject:cc:to :from:dkim-signature:arc-authentication-results; bh=kmXTpg9Xf+mRFMY2+Y5+mnuTk7SxBb7zJgyXN6fMt8Q=; b=plc/gxX297hVFUWWKsFn10Xkf8332afJzq+dG98LF3JLgLQagxbQAjNOXs/Ds8sq/4 7KFrP2U3Jhx1e06nQ5sIJYXjdZpZGEMlJ4pS7E1Z0lyEsz6fC7DbizHpYSLyuBnlq0Yj zBR5zp54oxfXh/NDMAuIGVEVIW9sSTIim3MtXe3NZ4ezgjpxgH0XT22ivoaMSgADp8Mq IgJi7y1OLWl74jtHWeJo1RhhJ5iI4gDul4CYslsz7Ohqmo8JpX0OcVR1t39GyVtDERRU df+JQm9yMCcaqHTT2xi5eIZJwQvWIomLm6NKAt9A2XgsgV09jaLTXZMHnzIaCC9/sYfs h40g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=QqaF6DYq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 k8-v6si52665plt.293.2018.02.14.12.06.38; Wed, 14 Feb 2018 12:06:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=QqaF6DYq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1032571AbeBNQ3D (ORCPT + 99 others); Wed, 14 Feb 2018 11:29:03 -0500 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:54734 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032392AbeBNQ3B (ORCPT ); Wed, 14 Feb 2018 11:29:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=Date:Message-Id:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References: List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner: List-Archive; bh=kmXTpg9Xf+mRFMY2+Y5+mnuTk7SxBb7zJgyXN6fMt8Q=; b=QqaF6DYqVLgE Yu7VwhVrRJG6my4pKg5ioqPjrK/m/Zls5XgFCA1O10sk+61TeqWnYqfl1jHZwLKLf5pyRWb4DQPup gZ0zCmNbREPZgGdS+0soa1fe79jcaZ8fkzTHjwuUGAG9nXGt+OUely0PqvfXhS0/NZ6BSpo+kURHW 4guyg=; Received: from debutante.sirena.org.uk ([2001:470:1f1d:6b5::3] helo=debutante) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1elzvG-0005qn-8i; Wed, 14 Feb 2018 16:28:42 +0000 Received: from broonie by debutante with local (Exim 4.90_1) (envelope-from ) id 1elzvF-0005oU-Pj; Wed, 14 Feb 2018 16:28:41 +0000 From: Mark Brown To: Trent Piepho Cc: Mark Brown , linux-spi@vger.kernel.org, linux-rpi-kernel@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Gustavo A . R . Silva" , Mark Brown , Eric Anholt , Stefan Wahren , Florian Fainelli , Ray Jui , linux-spi@vger.kernel.org Subject: Applied "spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc" to the spi tree In-Reply-To: <20180212193814.17644-1-tpiepho@impinj.com> Message-Id: Date: Wed, 14 Feb 2018 16:28:41 +0000 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The patch spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark From d704afffe65c8fab424963c1ba4ec4364c2d6a82 Mon Sep 17 00:00:00 2001 From: Trent Piepho Date: Mon, 12 Feb 2018 11:38:14 -0800 Subject: [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We want to check for xfers that are over 30 microseconds. Rather than find how many µs a xfer will take, instead find how many bytes can be transferred in 30 µs. The latter must be less than 32 bits (since our clock speed is limited to 32 bits), while the former involves 64 bit quantities and more arithmetic operations. Signed-off-by: Trent Piepho Signed-off-by: Mark Brown --- drivers/spi/spi-bcm2835aux.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c index 7428091d3f5b..1431cb98fe40 100644 --- a/drivers/spi/spi-bcm2835aux.c +++ b/drivers/spi/spi-bcm2835aux.c @@ -321,7 +321,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, struct bcm2835aux_spi *bs = spi_master_get_devdata(master); unsigned long spi_hz, clk_hz, speed; unsigned long spi_used_hz; - unsigned long long xfer_time_us; /* calculate the registers to handle * @@ -358,20 +357,21 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, bs->rx_len = tfr->len; bs->pending = 0; - /* calculate the estimated time in us the transfer runs - * note that there are are 2 idle clocks after each - * chunk getting transferred - in our case the chunk size - * is 3 bytes, so we approximate this by 9 bits/byte + /* Calculate the estimated time in us the transfer runs. Note that + * there are are 2 idle clocks cycles after each chunk getting + * transferred - in our case the chunk size is 3 bytes, so we + * approximate this by 9 cycles/byte. This is used to find the number + * of Hz per byte per polling limit. E.g., we can transfer 1 byte in + * 30 µs per 300,000 Hz of bus clock. */ - xfer_time_us = tfr->len * 9 * 1000000; - do_div(xfer_time_us, spi_used_hz); - +#define HZ_PER_BYTE ((9 * 1000000) / BCM2835_AUX_SPI_POLLING_LIMIT_US) /* run in polling mode for short transfers */ - if (xfer_time_us < BCM2835_AUX_SPI_POLLING_LIMIT_US) + if (tfr->len < spi_used_hz / HZ_PER_BYTE) return bcm2835aux_spi_transfer_one_poll(master, spi, tfr); /* run in interrupt mode for all others */ return bcm2835aux_spi_transfer_one_irq(master, spi, tfr); +#undef HZ_PER_BYTE } static int bcm2835aux_spi_prepare_message(struct spi_master *master, -- 2.16.1