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 2148AC41513 for ; Thu, 17 Aug 2023 15:52:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353345AbjHQPvu (ORCPT ); Thu, 17 Aug 2023 11:51:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47760 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353374AbjHQPve (ORCPT ); Thu, 17 Aug 2023 11:51:34 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4365830E1; Thu, 17 Aug 2023 08:51:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692287490; x=1723823490; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=mSEcYZALTQJIZt/i/ZDOECf+xJ+2HGAure6MfLyotKg=; b=a1BJZaeHVEaABBmouCSaoLT06Zt8qB7wRcrUPHG+qvSTRGsfkizO/x1G Tb9X8easCaBZgxp7K8YfT6BIpUlYD/gygj0Cd+YRFo0UGjM0VtOavri2P L9Ok8BQqYrDaUmDaNIxEgWBZA06teHu/9x5uyEhQ68sZlmaz3LZ/+1SJR mAVCGaAvg8jrN6P0SHGszo5RXs++72R6zNKPeHtHEwhyP/p41Wim7cirP 9GjB3QopbB/fx8e8QC2Es9H0pPLBJOClbTV6Ly4R2VRUA4Nn8SIpLO9Ji rDuNlzF7icwFLGIy6yb1s/udr6GR328FaAdWduLooCjuIM6nvm17CryV9 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10805"; a="436767852" X-IronPort-AV: E=Sophos;i="6.01,180,1684825200"; d="scan'208";a="436767852" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Aug 2023 08:51:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.01,202,1684825200"; d="scan'208";a="878280802" Received: from smile.fi.intel.com ([10.237.72.54]) by fmsmga001.fm.intel.com with ESMTP; 17 Aug 2023 08:51:21 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1qWfHH-000gnh-1N; Thu, 17 Aug 2023 18:51:15 +0300 Date: Thu, 17 Aug 2023 18:51:15 +0300 From: Andy Shevchenko To: Yann Sionneau Cc: Jarkko Nikula , Mika Westerberg , linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org, Yann Sionneau , Jonathan Borne Subject: Re: [PATCH 2/2] i2c: designware: abort the transfer if receiving byte count of 0 Message-ID: References: <20230811124624.12792-1-yann@sionneau.net> <20230811124624.12792-2-yann@sionneau.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 17, 2023 at 04:42:05PM +0200, Yann Sionneau wrote: > Le 11/08/2023 à 16:01, Andy Shevchenko a écrit : > > On Fri, Aug 11, 2023 at 02:46:24PM +0200, Yann Sionneau wrote: ... > > > + if ((tmp <= I2C_SMBUS_BLOCK_MAX) && (tmp != 0)) > > if (tmp && tmp <= I2C_SMBUS_BLOCK_MAX) > > I find the tmp != 0 "more obvious", I am more used to "just tmp" when it's a > pointer or a boolean, but maybe it's just me! > > I'll fix that in the V2 :) IIRC it's unsigned, so you may use if (tmp > 0 && tmp <= I2C_SMBUS_BLOCK_MAX) which will be more explicit. > > > + len = i2c_dw_recv_len(dev, tmp); > > > + else > > > + i2c_dw_abort(dev); -- With Best Regards, Andy Shevchenko