Received: by 2002:ab2:6816:0:b0:1f9:5764:f03e with SMTP id t22csp2077824lqo; Sun, 19 May 2024 12:13:03 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCUZGBBxN6PE2n/6luN0wAxG2r/yXwwovD/4OlaZEp21c+FUJttnov3CIPcC3p34UOH9DKO72LzB8Dfv/QFHHz7NW+oRaQXi7oTo2IapIg== X-Google-Smtp-Source: AGHT+IFi2CjjxZ7xjvbAapZXPMj9xgEe5q23jkQFRbzTqTR3fVdkYIgyZHdjZvzhtrQTfvGQUxWh X-Received: by 2002:a17:906:2dd5:b0:a59:c728:5430 with SMTP id a640c23a62f3a-a5a2d677dc0mr1671794566b.76.1716145983215; Sun, 19 May 2024 12:13:03 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716145983; cv=pass; d=google.com; s=arc-20160816; b=RRoksvXz+G0o+uITer6In8j+HQhMS+sbh/YFVYl2RDepXuTVBnGOQOp3eiX84IZmj3 V3/MemSPMy9a2zhD4XPmtnTiw/0ASgDeDfOucqM1rHAHzJiOm+yUt4/hfhMJCNIXs9Ig crCe9kCrHAttKRgq4hdfkWCzp9CzY655CCPefCzP48lOtc/DIjmdAiVurIwqbFILx46H zzxTKbnUzBVr3ud4CoL3Kk+EYLiOhdlyvu3EPXC+5sje8hrRKpgG+dWyfIDFP1OTDXqz 9Thv2z+uN3RqX42hyDycgOZb7S8ZlhgoBpbGXy3eorobcVBxQuRAVsoWc91cC29j/4g0 taZw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :subject:cc:to:from:date:dkim-signature; bh=NVmh92iA/+REglKrWzzom8VS1vC71+r3uNICaeATHao=; fh=PeXr6QPNG2+Sw4i+fHdT/xT9k+zjK2to6GtabHVpFWk=; b=A1L0AbDFmU4yozdPib35jAh/O5x3G6SJUtEq7TcCKiLD6Zt3uK9pF0cDqwpiTHxSG/ RQB2+dHBq7A9Zx5pJxA7DaOpOb8BPPYrPCp7AnwbdnhWu3CXgil2P9A5AnvpZPVAxdAK ZKwG5um3jmq1ZybvnURD64rymgUM8NyJSOchXKDNy10jf4GwqlTNJCXqdFzgnBd3GoBG BoBz/JP7bM3PHmCsJBbUx/giStoc4vRUADJgLheDfgSbKnjyX/chmUxe6FK9uu1XKQ66 Huoz6FoVHbX2nDaJoUO4TT+5A+yLFloa30c9i8enUR4bQ9GA8hId31xgB2Y7HwrjqxHY 6pPw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=QkIXLoeT; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-183218-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-183218-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id a640c23a62f3a-a5a17ba39a2si186112866b.518.2024.05.19.12.13.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 19 May 2024 12:13:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-183218-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=QkIXLoeT; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-183218-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-183218-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 785DF1F212EE for ; Sun, 19 May 2024 19:13:02 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3861F6E61E; Sun, 19 May 2024 19:12:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QkIXLoeT" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 4AB4DD2EE; Sun, 19 May 2024 19:12:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716145973; cv=none; b=hYhpnVMN+6WzVFfP2YECwFLPV50OJqieVOSKDDlMHFU6lJIAEO5UgFcD/paPUDJTZgOvT43rQsJcVxJjZxIBhZx5V5xZRmechyeHsrBmpV9gOvFY59JkJiwKDpaocX51fYW+dgwvs+Cr9zAaUO5P141NYBYyEvyz8vVwNqo8m2M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716145973; c=relaxed/simple; bh=P34NKSklVsYLnu3eDNayZ3uJz6ljvNnmtRy3oFcgwyw=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=F038/uB3dN2n0zRr960whFNG3eZfqfAmlDXpX8CwP9ZqpFEuQqIx8ARlAjqWYfAxiRdS/Kxs0rp4ExMge0Hpp3D93vH52Rw/ZB2clRGHtjfai+gB+90/gDJbMOYUtt4MrGkZNL8cSW3qC7xieWrJojlCSj45MZPnpDCrnSWNnt8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QkIXLoeT; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B6E8C32782; Sun, 19 May 2024 19:12:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716145972; bh=P34NKSklVsYLnu3eDNayZ3uJz6ljvNnmtRy3oFcgwyw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=QkIXLoeTUfoSAms6MbwgvyWS0dQL0rvRFGlvOApvtFtZG+pTHH1oPRQaqfvQKH07p EJY5Gr9QTDarsZgkSg9dg212dGBI0qlLOdV+9ZqHSyWToN+RQrczUInd/rQRD49aUC nP7C4bxIGQweo1OgY2MG637Ih9Kr0TYAOId1gRYSmt2Fl+h+djPu7gle8OY16jRoiL kKC/pCQWAGkE9BVVQAEK/ucRJktnOwwcqgOGIAcdeqO3j/A2rESmrECOHrpu/1J3iM ehlJmlI44aaKxAeEJ6RfvXsOZkz9z7EqxaRHoI4k3lzwZz1UoFX8OMHVP8paTL+fGC 4PtRx6HbC/isg== Date: Sun, 19 May 2024 20:12:41 +0100 From: Jonathan Cameron To: David Lechner Cc: Michael Hennerich , Nuno =?UTF-8?B?U8Oh?= , Julien Stephan , Esteban Blanc , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 3/4] iio: add support for multiple scan types per channel Message-ID: <20240519201241.7c60abac@jic23-huawei> In-Reply-To: <20240507-iio-add-support-for-multiple-scan-types-v1-3-95ac33ee51e9@baylibre.com> References: <20240507-iio-add-support-for-multiple-scan-types-v1-0-95ac33ee51e9@baylibre.com> <20240507-iio-add-support-for-multiple-scan-types-v1-3-95ac33ee51e9@baylibre.com> X-Mailer: Claws Mail 4.2.0 (GTK 3.24.42; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Tue, 7 May 2024 14:02:07 -0500 David Lechner wrote: > This adds new fields to the iio_channel structure to support multiple > scan types per channel. This is useful for devices that support multiple > resolution modes or other modes that require different data formats of > the raw data. > > To make use of this, drivers can still use the old scan_type field for > the "default" scan type and use the new scan_type_ext field for any > additional scan types. Comment inline says that you should commit scan_type if scan_type_ext is provided. That makes sense to me rather that a default no one reads. The example that follows in patch 4 uses both the scan_type and the scan_type_ext which is even more confusing. > And they must implement the new callback > get_current_scan_type() to return the current scan type based on the > current state of the device. > > The buffer code is the only code in the IIO core code that is using the > scan_type field. This patch updates the buffer code to use the new > iio_channel_validate_scan_type() function to ensure it is returning the > correct scan type for the current state of the device when reading the > sysfs attributes. The buffer validation code is also update to validate > any additional scan types that are set in the scan_type_ext field. Part > of that code is refactored to a new function to avoid duplication. > > Signed-off-by: David Lechner > --- > diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h > index 19de573a944a..66f0b4c68f53 100644 > --- a/include/linux/iio/iio.h > +++ b/include/linux/iio/iio.h > @@ -205,6 +205,9 @@ struct iio_scan_type { > * @scan_index: Monotonic index to give ordering in scans when read > * from a buffer. > * @scan_type: struct describing the scan type > + * @ext_scan_type: Used in rare cases where there is more than one scan > + * format for a channel. When this is used, omit scan_type. Here is the disagreement with the patch description. > + * @num_ext_scan_type: Number of elements in ext_scan_type. > * @info_mask_separate: What information is to be exported that is specific to > * this channel. > * @info_mask_separate_available: What availability information is to be > @@ -256,6 +259,8 @@ struct iio_chan_spec { > unsigned long address; > int scan_index; > struct iio_scan_type scan_type; > + const struct iio_scan_type *ext_scan_type; > + unsigned int num_ext_scan_type; Let's make it explicit that you can't do both. union { struct iio_scan_type scan_type; struct { const struct iio_scan_type *ext_scan_type; unsigned int num_ext_scan_type; }; }; should work for that I think. However this is I think only used for validation. If that's the case do we care about values not in use? Can we move the validation to be runtime if the get_current_scan_type() callback is used. > long info_mask_separate; > long info_mask_separate_available; > long info_mask_shared_by_type; > @@ -435,6 +440,9 @@ struct iio_trigger; /* forward declaration */ > * for better event identification. > * @validate_trigger: function to validate the trigger when the > * current trigger gets changed. > + * @get_current_scan_type: must be implemented by drivers that use ext_scan_type > + * in the channel spec to return the currently active scan > + * type based on the current state of the device. > * @update_scan_mode: function to configure device and scan buffer when > * channels have changed > * @debugfs_reg_access: function to read or write register value of device > @@ -519,6 +527,9 @@ struct iio_info { > > int (*validate_trigger)(struct iio_dev *indio_dev, > struct iio_trigger *trig); > + const struct iio_scan_type *(*get_current_scan_type)( > + const struct iio_dev *indio_dev, > + const struct iio_chan_spec *chan); > int (*update_scan_mode)(struct iio_dev *indio_dev, > const unsigned long *scan_mask); > int (*debugfs_reg_access)(struct iio_dev *indio_dev, > @@ -804,6 +815,28 @@ static inline bool iio_read_acpi_mount_matrix(struct device *dev, > } > #endif > > +/** > + * iio_get_current_scan_type - Get the current scan type for a channel > + * @indio_dev: the IIO device to get the scan type for > + * @chan: the channel to get the scan type for > + * > + * Most devices only have one scan type per channel and can just access it > + * directly without calling this function. Core IIO code and drivers that > + * implement ext_scan_type in the channel spec should use this function to > + * get the current scan type for a channel. > + * > + * Returns: the current scan type for the channel > + */ > +static inline const struct iio_scan_type *iio_get_current_scan_type( > + const struct iio_dev *indio_dev, > + const struct iio_chan_spec *chan) > +{ > + if (indio_dev->info->get_current_scan_type) > + return indio_dev->info->get_current_scan_type(indio_dev, chan); > + > + return &chan->scan_type; > +} > + > ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals); > > int iio_str_to_fixpoint(const char *str, int fract_mult, int *integer, >