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 90900C6FD1D for ; Mon, 20 Mar 2023 17:07:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232340AbjCTRHn (ORCPT ); Mon, 20 Mar 2023 13:07:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42518 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233325AbjCTRHE (ORCPT ); Mon, 20 Mar 2023 13:07:04 -0400 Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8F6A3928D; Mon, 20 Mar 2023 10:02:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1679331726; x=1710867726; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=yiv2o1xgkJKIW97HgBc4IdaI8YCn/dj8kY/wB9X9Iqw=; b=Wzx5++aH7Sfu/31SGEBmAZY/7z9aMh2EUuOj5178xMF88s+57JYom0kS YMNlB5DiowT0WP4DOHOMbeycLdUIBQaVdJiJ+lM7hMPYtXMP9+eCbkCPk 9Fx64VCHKt9j6cWK4F3PR6lN5O+TRRcbVepF/TJ5h41IMCP74xBYb4MqP UtTmvD1HbRxPOAdPid1UBn/HEv7qh5qU/SXzkufykDqr5h167ICnpIw3y pmroXHWMUNbM0fJMYhg54M8MFrxII2ry++XrErXDK/QkYPfcBuG7G08Z9 g69hz5gie+dH2vmJL6rCX2Y/VLDI5RXccMBUxZzOHYNJ31iebcAOUzbZc w==; X-IronPort-AV: E=McAfee;i="6600,9927,10655"; a="319116923" X-IronPort-AV: E=Sophos;i="5.98,276,1673942400"; d="scan'208";a="319116923" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Mar 2023 09:54:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10655"; a="770264230" X-IronPort-AV: E=Sophos;i="5.98,276,1673942400"; d="scan'208";a="770264230" Received: from smile.fi.intel.com ([10.237.72.54]) by FMSMGA003.fm.intel.com with ESMTP; 20 Mar 2023 09:54:18 -0700 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1peIm0-006Lus-16; Mon, 20 Mar 2023 18:54:16 +0200 Date: Mon, 20 Mar 2023 18:54:16 +0200 From: Andy Shevchenko To: William Breathitt Gray Cc: linux-iio@vger.kernel.org, Johannes Berg , Jonathan Cameron , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/4] counter: 104-quad-8: Utilize helper functions to handle PR, FLAG and PSC Message-ID: References: <71496f9295e68388ce07f3051bf5882177be83c5.1679149543.git.william.gray@linaro.org> 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-kernel@vger.kernel.org On Mon, Mar 20, 2023 at 11:53:36AM -0400, William Breathitt Gray wrote: > On Mon, Mar 20, 2023 at 05:36:17PM +0200, Andy Shevchenko wrote: ... > After reading through the implementation for these functions I realized > they are actually doing something different than what's happening here. > The 104-QUAD-8 device exposes the 24-bit register by consecutive 8-bit > I/O operations on the same address; however, the iomap_copy and regmap > bulk functions operate on different addresses. Ah, than we have ioreadXX_rep()/iowriteXX_rep() for that. > I'm not sure if there really is a way to make the 104-QUAD-8 operation > more generic for other drivers because it configures the current byte > pointer through a separate register from the data register (all of this > feel rather device specific), so I suspect keeping this function local > to 104-quad-8 is best for now. -- With Best Regards, Andy Shevchenko