Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp36499144rwd; Tue, 11 Jul 2023 01:38:09 -0700 (PDT) X-Google-Smtp-Source: APBJJlEZ1jb7jScOWqKT/lIKs41lU5ZZh/Mov/0q8jCzSQGuKWeLCbjklQEb9Pc69agHuhzfCv1v X-Received: by 2002:a17:907:d15:b0:992:103c:43fa with SMTP id gn21-20020a1709070d1500b00992103c43famr23633004ejc.30.1689064689393; Tue, 11 Jul 2023 01:38:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689064689; cv=none; d=google.com; s=arc-20160816; b=VdxqVFCqHJV/iVd8tTuu8NzecNxdrU9IC8JtaFA6vQeJ8owYhk2LNXLKpeL70Plpuh nunniY+XVas8r2fxAs+NlINsLBoUuyRekgDcKoesZALOjWxiRn3Mv/NqcV86jLxTIfWv wM8amoxzuvFUf6ed2s9CRMLlGe2JTtL4HlYSFeRu8dUd8yTNefI/waxi0G7zUdynuEAd 4psiTl6CDwSsQB2M81oYHZ7vG41h2dnvhrxREKM4zktVyuibJx2Qt0dI1H6DGlYAk+3u JuRrd9GXPDUDWR9x/hotL/msxVLsjzYWoreal3xpAl2Z4Tppm+1j5gERUU1BeBZRiTwc wIrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=e0ITNM84h8mOwKhA1IlZoP3DKih9eIhFfww2ByRdPXk=; fh=k2xC0hVIVVmpseit9+5Q+yo+YyBs94PaxxbVkxO8w6w=; b=m4dDywHyE/H8gMdFnu1gVyhy+IVOiO5WZTikchWXZ//0HqUBxCzwTRJ1SqNJlQ/KRm n7B7gyjsXxnDhCPzC5lmeJhn3NHklB1tjKLclP7n/BQyOy87eUIFpBs113BLrr12HpPu vvNouH16Fe+N2wAMT5ArhMG6In50UEXbVKM5lTK6zawTE1tkvGkeh5IOscyG7h5mY6u4 z7Ywyq2BtR//canh4iZpIGhiIVkwfciK2rbnaibga+D4zcQ2PhU8fd7G2jDN8YS0pP1O 7Mshkufm7tcNfvZcUqRRJ+02qUCNa2uhl/7m3i7dnwAsntpy2FMd7QPQKx2+aAoUwtDl sCKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=XSCTbFXk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b13-20020a1709065e4d00b00977e4a1fe32si1514758eju.539.2023.07.11.01.37.45; Tue, 11 Jul 2023 01:38:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=XSCTbFXk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230311AbjGKI27 (ORCPT + 99 others); Tue, 11 Jul 2023 04:28:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48062 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230292AbjGKI26 (ORCPT ); Tue, 11 Jul 2023 04:28:58 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 80336E77; Tue, 11 Jul 2023 01:28:27 -0700 (PDT) Received: from [192.168.1.100] (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 2532E660700A; Tue, 11 Jul 2023 09:28:16 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1689064098; bh=spdNLway67POM3vmFaXNGhDhQmXxhVIedWvVLp0PkEI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=XSCTbFXk9e6Ms6w3dUD0gTaJbCLMJPnp6Us3KW28VZQ9hoaNYRdeO51FSibZH/fzR JKiOts4MP0vpXd7Sm62WRMiy18wm8cew197TIrGkrMstBRkn8EotGVMfdYCXfIPJSe daxKC2B2n9x1az4GZ5GnR8rcX8dTYTsyY730jAhseXuJoFP2RlZZLPbPOwRRmcg2DA AuU+HmpPB29i7vONs5CAXPnuO8/39XXDXiNgdv1iHqfSMOywBsFHXC35USEsn3iVGM sm/VWNEaupu1VVdE1Na6ph1PWVqdQwL0sL6NNEZHb+h9luZhHTnlJNLnVZ7IUaGKbA HdIZq6knmkqdQ== Message-ID: <83c4b75a-06d7-9fca-ffa0-f2e6a6ae7aed@collabora.com> Date: Tue, 11 Jul 2023 10:28:13 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v2 04/15] spi: Replace open coded spi_controller_xfer_timeout() Content-Language: en-US To: Andy Shevchenko , Mark Brown , Cristian Ciocaltea , Yang Yingliang , Amit Kumar Mahapatra via Alsa-devel , Neil Armstrong , Tharun Kumar P , Vijaya Krishna Nivarthi , =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-amlogic@lists.infradead.org, linux-mediatek@lists.infradead.org, linux-arm-msm@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-riscv@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, linux-trace-kernel@vger.kernel.org, netdev@vger.kernel.org Cc: Sanjay R Mehta , Radu Pirea , Nicolas Ferre , Alexandre Belloni , Claudiu Beznea , Tudor Ambarus , Serge Semin , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , Matthias Brugger , Andy Gross , Bjorn Andersson , Konrad Dybcio , Heiko Stuebner , Palmer Dabbelt , Paul Walmsley , Orson Zhai , Baolin Wang , Chunyan Zhang , Alain Volmat , Maxime Coquelin , Alexandre Torgue , Max Filippov , Steven Rostedt , Masami Hiramatsu , Richard Cochran References: <20230710154932.68377-1-andriy.shevchenko@linux.intel.com> <20230710154932.68377-5-andriy.shevchenko@linux.intel.com> From: AngeloGioacchino Del Regno In-Reply-To: <20230710154932.68377-5-andriy.shevchenko@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Il 10/07/23 17:49, Andy Shevchenko ha scritto: > Since the new spi_controller_xfer_timeout() helper appeared, > we may replace open coded variant in spi_transfer_wait(). > > Signed-off-by: Andy Shevchenko > --- > drivers/spi/spi.c | 25 ++----------------------- > include/linux/spi/spi.h | 6 +++++- > 2 files changed, 7 insertions(+), 24 deletions(-) > > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c > index 125dea8fae00..c99ee4164f11 100644 > --- a/drivers/spi/spi.c > +++ b/drivers/spi/spi.c > @@ -1342,8 +1342,7 @@ static int spi_transfer_wait(struct spi_controller *ctlr, > { > struct spi_statistics __percpu *statm = ctlr->pcpu_statistics; > struct spi_statistics __percpu *stats = msg->spi->pcpu_statistics; > - u32 speed_hz = xfer->speed_hz; > - unsigned long long ms; > + unsigned long ms; > > if (spi_controller_is_slave(ctlr)) { > if (wait_for_completion_interruptible(&ctlr->xfer_completion)) { > @@ -1351,29 +1350,9 @@ static int spi_transfer_wait(struct spi_controller *ctlr, > return -EINTR; > } > } else { > - if (!speed_hz) > - speed_hz = 100000; > - > - /* > - * For each byte we wait for 8 cycles of the SPI clock. > - * Since speed is defined in Hz and we want milliseconds, > - * use respective multiplier, but before the division, > - * otherwise we may get 0 for short transfers. > - */ > - ms = 8LL * MSEC_PER_SEC * xfer->len; > - do_div(ms, speed_hz); > - > - /* > - * Increase it twice and add 200 ms tolerance, use > - * predefined maximum in case of overflow. > - */ > - ms += ms + 200; > - if (ms > UINT_MAX) > - ms = UINT_MAX; > - > + ms = spi_controller_xfer_timeout(ctlr, xfer); I agree on using helpers, but the logic is slightly changing here: yes it is unlikely (and also probably useless) to get ms == UINT_MAX, but the helper is limiting the maximum timeout value to 500mS, which may not work for some slow controllers/devices. This should get validated on more than a few platforms, and I'm not sure that this kind of validation would be "fast" to get... so, probably the best thing to do here is to add a warning in case the timeout exceeds 500mS, print the actual value, keep it like this for a kernel version or two and check reports: that would allow to understand what a safe maximum timeout value could be. Aside from that, I wouldn't drop those nice comments explaining how/why the timeout is calculated: I know how, but not everyone knows in advance. Regards, Angelo > ms = wait_for_completion_timeout(&ctlr->xfer_completion, > msecs_to_jiffies(ms)); > - > if (ms == 0) { > SPI_STATISTICS_INCREMENT_FIELD(statm, timedout); > SPI_STATISTICS_INCREMENT_FIELD(stats, timedout); > diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h > index 32c94eae8926..0ce1cb18a076 100644 > --- a/include/linux/spi/spi.h > +++ b/include/linux/spi/spi.h > @@ -1270,12 +1270,16 @@ static inline bool spi_is_bpw_supported(struct spi_device *spi, u32 bpw) > * that it would take on a single data line and take twice this amount of time > * with a minimum of 500ms to avoid false positives on loaded systems. > * > + * Assume speed to be 100 kHz if it's not defined at the time of invocation. > + * > * Returns: Transfer timeout value in milliseconds. > */ > static inline unsigned int spi_controller_xfer_timeout(struct spi_controller *ctlr, > struct spi_transfer *xfer) > { > - return max(xfer->len * 8 * 2 / (xfer->speed_hz / 1000), 500U); > + u32 speed_hz = xfer->speed_hz ?: 100000; > + > + return max(xfer->len * 8 * 2 / (speed_hz / 1000), 500U); > } > > /*---------------------------------------------------------------------------*/