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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B4BCC0015E for ; Tue, 11 Jul 2023 11:01:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230182AbjGKLBh (ORCPT ); Tue, 11 Jul 2023 07:01:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229921AbjGKLBf (ORCPT ); Tue, 11 Jul 2023 07:01:35 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 81ADDE51; Tue, 11 Jul 2023 04:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689073294; x=1720609294; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=g5docwgn1sedQFCIUNy5vO+RB2jnG5735hob/X5gUzk=; b=UAHxZlT74CdhVAFszHf8/YP/qnudI48ytjXycAzmc5G/W/3vkawJt93q O67ArP6c840w44lX2ZEAKAr30tUJSdH+8QyH9DQ4a4FZimsW5DKPBftPO CjV6Qv88HHwPu10D2kVHPOlGHnzcBAKejOUaBeGARL0uNvQ9F+j4NZgWj 7RQ9wV751zxO9F9mTVNI2MM19GTxWuXJsWY/c4b+sEWHsWCildiHim/QJ pDlgGTvzxCq6GrXeXq7dH8gTKA8ngDR3aBmSx4O80yjOmzqe6GcX9+VJ/ A2k79fsZjqKZbmdeacQPDRxlsgcZW/cLTEjyOJPLiFJ+YIQ7pY26zk0Xo w==; X-IronPort-AV: E=McAfee;i="6600,9927,10767"; a="368087964" X-IronPort-AV: E=Sophos;i="6.01,196,1684825200"; d="scan'208";a="368087964" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Jul 2023 04:01:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10767"; a="715143826" X-IronPort-AV: E=Sophos;i="6.01,196,1684825200"; d="scan'208";a="715143826" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP; 11 Jul 2023 04:01:17 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qJB7J-001p8E-30; Tue, 11 Jul 2023 14:01:13 +0300 Date: Tue, 11 Jul 2023 14:01:13 +0300 From: Andy Shevchenko To: Mark Brown Cc: Cristian Ciocaltea , Yang Yingliang , Amit Kumar Mahapatra via Alsa-devel , Neil Armstrong , Tharun Kumar P , Vijaya Krishna Nivarthi , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , 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, 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 , AngeloGioacchino Del Regno , 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 Subject: Re: [PATCH v2 04/15] spi: Replace open coded spi_controller_xfer_timeout() Message-ID: References: <20230710154932.68377-1-andriy.shevchenko@linux.intel.com> <20230710154932.68377-5-andriy.shevchenko@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org On Mon, Jul 10, 2023 at 06:30:32PM +0100, Mark Brown wrote: > On Mon, Jul 10, 2023 at 06:49:21PM +0300, Andy Shevchenko wrote: > > > Since the new spi_controller_xfer_timeout() helper appeared, > > we may replace open coded variant in spi_transfer_wait(). > > > + * Assume speed to be 100 kHz if it's not defined at the time of invocation. > > + * > > You didn't mention this bit in the changelog, and I'm not 100% convinced > it was the best idea in the first place. It's going to result in some > very big timeouts if it goes off, and we really should be doing > validation much earlier in the process. Okay, let's drop this change. > > + u32 speed_hz = xfer->speed_hz ?: 100000; > > Not only the ternery operator, but the version without the second > argument for extra clarity! Elvis can be interpreted as "A _or_ B (if A is false/0)". Some pieces related to SPI use Elvis already IIRC. -- With Best Regards, Andy Shevchenko