From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66EB61D9A70; Tue, 15 Jul 2025 10:42:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752576161; cv=none; b=kGz0VWTQBOwzlyAhHwR52Z4hiYd+FQ6xUaCSfxJ09ccUlseVEZMYpmpAP85bVzzLECTWJrBsvaDdxQwuCx05vzLy+lOV/DVHotMXOqXo0qnhatny6etrdtezjtWiP5sfNXI9QYSqstupEV/g5QPsvP856GxAUM0bZ0BW/Fz9/M8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752576161; c=relaxed/simple; bh=qPvGaKZPuwIuu9H/djUeWBfbuZULyNCjjRuj3wYvkwM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aT/kXdk8HNhmWqJ/r3ly/T/cVlNvy73VgiRV2R6xitVotfDddSaDkSUSeVihuVzrJSrAw2ROJe5qBFEOzyMqlHopUB2TjM4UbF6LT8tzorVeJi7CLtctMDmcUlJbvtlCI93SCI3ZeJ/c+DLDv5NNfIuS7xhLjre9tmziEcXqnx8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=C9icJ8Xc; arc=none smtp.client-ip=198.175.65.15 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="C9icJ8Xc" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752576159; x=1784112159; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=qPvGaKZPuwIuu9H/djUeWBfbuZULyNCjjRuj3wYvkwM=; b=C9icJ8XczebumfsqrngmAleLfW1ZPtclpPsu0HGYcLEgAQTJV2HS8w9H 3YyPql/esGM7U1p9PIb2MtBdh9gYcayfY0noNwuVCLW9RdoddNcgjEGkq 58aZovJ7wlyuophlKupXKGDGuzZob9dMA2e6g4Y6aAVdfsrH+EgJdW3l9 T5NtCcN0R9UPPu09/lmQe04Xf6fIflpJjCVbOPXh0036Zdk8r7JX0Rfga tXkRD9aBOh4wMEo1fsf0qvBXc4mqcdCUrpKEZ62lrsbFHadQICd5Jz4R+ eQ2zg4dcsQgDSPCLhqR11E9FhggpUDHSzIB/UeIb+PfYIiO0nZKdEElmc g==; X-CSE-ConnectionGUID: c3yobWWxQlysfDzBE7vytw== X-CSE-MsgGUID: QV1srw1nRvevSOhcO4z9cA== X-IronPort-AV: E=McAfee;i="6800,10657,11491"; a="58445765" X-IronPort-AV: E=Sophos;i="6.16,313,1744095600"; d="scan'208";a="58445765" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2025 03:42:38 -0700 X-CSE-ConnectionGUID: dmjPbJpiSbiGp3SPSf7lKw== X-CSE-MsgGUID: /JEWBtDaS7uWpRZYqR/N6Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,313,1744095600"; d="scan'208";a="157730369" Received: from smile.fi.intel.com ([10.237.72.52]) by fmviesa008.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jul 2025 03:42:35 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.98.2) (envelope-from ) id 1ubd7I-0000000Fckz-48BA; Tue, 15 Jul 2025 13:42:32 +0300 Date: Tue, 15 Jul 2025 13:42:32 +0300 From: Andy Shevchenko To: Remi Buisson Cc: Jonathan Cameron , David Lechner , Nuno =?iso-8859-1?Q?S=E1?= , Andy Shevchenko , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "linux-kernel@vger.kernel.org" , "linux-iio@vger.kernel.org" , "devicetree@vger.kernel.org" Subject: Re: [PATCH v2 2/8] iio: imu: inv_icm45600: add new inv_icm45600 driver Message-ID: References: <20250710-add_newport_driver-v2-0-bf76d8142ef2@tdk.com> <20250710-add_newport_driver-v2-2-bf76d8142ef2@tdk.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs, Bertel Jungin Aukio 5, 02600 Espoo On Tue, Jul 15, 2025 at 09:11:47AM +0000, Remi Buisson wrote: > >From: Andy Shevchenko > >Sent: Friday, July 11, 2025 1:56 PM > >On Fri, Jul 11, 2025 at 11:32:48AM +0000, Remi Buisson wrote: > >> >From: Andy Shevchenko andriy.shevchenko@intel.com > >> >Sent: Thursday, July 10, 2025 11:30 AM > >> >On Thu, Jul 10, 2025 at 08:57:57AM +0000, Remi Buisson via B4 Relay wrote: ... > >> >> +#define INV_ICM45600_SENSOR_CONF_INIT {-1, -1, -1, -1} > >> > > >> >Unused. > >> This is used in later patch of the serie. > >> I will move this definition to the patch using it. > > > >Yes, unused in this code. You should compile the series incrementally, > >so each patch will get a compilation test. This is called compile-time > >bisectability. Also run the system each time to confirm no regressions > >(this is called run-time bisectability). > Yes I did that for each patch, everything build successfully. > In that case, nothing is broken due to this early definition of the macro. > But I'll definitely move it to later patch for clarity. Yeah, the problem is that the (unused) definitions are not warned even when `make W=1`. And I guess I understand why. We have tons of unused definitions in the drivers that usually substitute (on whatever reasons) the actual documentation. It's hard to catch for the definitions like this without reading the code. ... > >> It's probably safer to keep the delay even in case of failure to make sure > >> the device is ready before next operation. > > > >I am not sure about it. Why? This has to be well justified as it's quite > >unusual pattern. > Ok I understand, the hardware needs that delay if the access was actually > done on the bus (to not jeopardize next access). If a regmap error means > that no real access occured then the delay is avoidable. Perhaps you need to have this delay embedded in the IO accessors? Also do read _and_ write need this or only one of them? -- With Best Regards, Andy Shevchenko