From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=34.202.193.197 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793605672; b=NkHVhTdNyh5xUyy35xgk21IZFRlaqfRzJxyb8ulMN9gPbsRypKilmOHTgK9X3+NohiGK TmeN4qkVZNfvnjNZCpWRRQ0OCnRfrO5aYjNg0nsnSzaU1A2aXHkBnGxYiqvIZXP/d9KMO V+cv6gic+GXu6BY/vyau647ylmPI9prUOnWxktQE1GqFpVVWfbZlmHYm6ASttJcJzQJ1Z yCJLGfVx08GNcQk3S4+IITKD0aXbGviX8Qo5YMmo1T+HL2JCmvReDWFWOi2lM9bZqJwwG ihuGvaU6dq55PNTDtlneB9PJxRWhmKQnhZBI/Tk2CB+ODfAig8TT2Wd4/6f21yAxipA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793605672; h=DMARC-Filter:DKIM-Signature:DKIM-Signature:Feedback-ID: X-Pm-Original-To:Received:From:To:Cc:Subject:Date:Message-ID:X-Mailer: MIME-Version:Content-Transfer-Encoding:X-MIME-Autoconverted: Content-Type; bh=ME2Cqg6qSz8PRLsZdr3Tn5bcHvcBRTnMAvRs195fxiM=; b=kK3OgpdfUb2EJI+S25lZQiazQzMauY/HwDPXeMiBKheuS7b9BDrtMlBRnXPNE6caJbZA nhHVevKPOeo0m3dnkHRweVEZ9tROQSLfu/+y3jn2PvTC4Qixl2jfgs7j6ziso4X1UkPoo GZjs5nRQ6CYnGaipM6ZR7X/2EaDrOJAQv0W6YeFcW52OMluGCR82v93xboFKqRqK6LdKR 1KNkCzTENtcZAjBGgYzgw0ut9LfcWzs7T4brFcOzzNj8lQpK90VtNMkbOgmbaDkf2FfuM SkPvFyk07Ki+KTYDPtCqJC9MO1G9N7CIp47eYZETePdqw0zvt+g/1SAvlcmBnUmf1/Q== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=arkamondal.net; spf=pass smtp.mailfrom=arkamondal.net; dkim=pass header.d=arkamondal.net header.i=@arkamondal.net header.a=rsa-sha256 header.s=purelymail2 header.b=gra4POX3; dkim=pass header.d=purelymail.com header.i=@purelymail.com header.a=rsa-sha256 header.s=purelymail2 header.b="QW/uBBom"; arc=none smtp.remote-ip=34.202.193.197 Received: from sendmail.purelymail.com (sendmail.purelymail.com [34.202.193.197]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FCC1606A324 for ; Mon, 2 Nov 2026 07:47:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 4FCC1606A324 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=arkamondal.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arkamondal.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=arkamondal.net header.i=@arkamondal.net header.a=rsa-sha256 header.s=purelymail2 header.b=gra4POX3; dkim=pass (2048-bit key, unprotected) header.d=purelymail.com header.i=@purelymail.com header.a=rsa-sha256 header.s=purelymail2 header.b=QW/uBBom DKIM-Signature: a=rsa-sha256; b=gra4POX39YwbZTA5PZhGKUncV6Zp994OHHzlTtuq45sKg6HkduIGhUyxz/wJIFk23rr9yv8rsuuV1MainkCa7n+qWOc7xNrLHgLLAjxueJ5PbdUrSAHxMdJDbww2uQf78w71fWqJHm1IYQixPl8ZMKzkdWIboyGUh9/+n36d9KUp0Nt6FZ7BVeOtJEn78xNCWImHWI0M39PqpppIBjOrUG07amnRy9WV9+RwaAbimzbklSitTMMCFweCL1oMajvjX1CpKlNsn2htE7Dbo1gcbOEPpELeDY6ypdYgsahmNM6dx8816BOQtaDkcm956u/pXlxGrTVcOlI5wmpwmVH3dA==; s=purelymail2; d=arkamondal.net; v=1; bh=kSHKm1nWBcQgSB/3l+sue+BQAl6lbrZWZ2hKP4X1zXQ=; h=Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=QW/uBBommH6pVDn2ig+V4wLwAlHffUQKH/gpld2lttq/X1R8NgF/zt84zlVhLWutE5vZH8t1XLu3srRUlDjcE28+xHf6Mh6KW+SonLWhfpeXssmT+yu02WVw30eOr2wr9bjUIIvB0qKCgBx5xjrCXt+BCDehcS6ZbHyZ+n4lbiK4lzmFXPfJXoteSWWPFMvk1tFB393nwKH/1cRfCCRplLlL8XpiCJHxZsZF1EbA/VqYAlkvy2TvR9v86OIcR70jtTv1UObn8n/o4k+tM3tP79dj1LYZqYwY1hIngTUtNE41J2T45HUNbxWZ+l+LN5oXkDVMPbQrkWMcnYQGvhLucw==; s=purelymail2; d=purelymail.com; v=1; bh=kSHKm1nWBcQgSB/3l+sue+BQAl6lbrZWZ2hKP4X1zXQ=; h=Feedback-ID:Received:From:To:Subject:Date; Feedback-ID: 1246644:48769:null:purelymail X-Pm-Original-To: linux-kernel@vger.kernel.org Authentication-Results: purelymail.com; auth=pass Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id 1445244709; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Mon, 02 Nov 2026 07:47:18 +0000 (UTC) From: Arka Mondal To: Jonathan Cameron , Linus Walleij Cc: David Lechner , =?UTF-8?q?Nuno=20S=C3=A1?= , Andy Shevchenko , Peter Meerwald , Matt Ranostay , Robert Eshleman , Leonard Crestez , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org, Arka Mondal Subject: [PATCH 0/6] iio: Give the *_available attributes the names the core generates Date: Mon, 2 Nov 2026 16:46:54 +0900 Message-ID: <20261102074700.63075-1-arka@arkamondal.net> X-Mailer: git-send-email 2.56.0 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by Purelymail Content-Type: text/plain; charset=UTF-8 An _available file takes its name from the attribute whose values it lists. The core builds both names with __iio_chan_prefix_emit(), called for the available attribute with the same shared_by argument, so the prefix follows from where the value sits: in_ plus any index or modifier for info_mask_separate, in_ for info_mask_shared_by_type, and nothing at all for info_mask_shared_by_all. The iio-channel-prefix KUnit suite covers each of those cases. Six drivers build their lists by hand with IIO_CONST_ATTR instead, and ten of the eleven names they use have no prefix even though none of those values is shared across all channels. Each of the ten is a device level attribute paired with no channel, so its list is reachable only under a name that does not describe it. Documentation/ABI/testing/sysfs-bus-iio keeps bare names for the shared-across-all case, sampling_frequency_available and oversampling_ratio_available, and gives the prefixed form everywhere else: in_accel_scale_available, in_illuminance_scale_available, in_intensity_hardwaregain_available. Anything that looks for a list beside the attribute it belongs to finds no such file. These patches hand all eleven lists to read_avail() and delete the custom attribute groups. The same was done for hts221 in commit 003e99cf33e3 ("iio: humidity: hts221: report available values via re= ad_avail()") where "the incorrectly named in_humidity_oversampling_ratio_available attribute is replaced by the standard in_humidityrelative_oversampling_ratio_available name", so the shape is not new. The names change as follows. isl29125 scale_available -> in_intensity_scale_available apds9960 proximity_scale_available -> in_proximity_scale_available apds9960 intensity_scale_available -> in_intensity_scale_available apds9960 integration_time_available -> in_intensity_integration_time_available max44009 illuminance_integration_time_available -> in_illuminance_integration_time_available max44000 illuminance_scale_available -> in_illuminance_scale_available max44000 illuminance_integration_time_available -> in_illuminance_integration_time_available hdc100x temp_integration_time_available -> in_temp_integration_time_available hdc100x humidityrelative_integration_time_available -> in_humidityrelative_integration_time_available hdc100x out_current_heater_raw_available -> unchanged, this one was already right mpu3050 anglevel_scale_available -> in_anglvel_scale_available Of the eleven lists, four print exactly the text they printed before and six gain trailing decimals, because the core prints each value to the full precision of its IIO_VAL_* type where the old strings were written out by hand. apds9960's integration time, for one, becomes 0.028000 0.100000 0.200000 0.700000. The numbers are the same. The eleventh is mpu3050, whose four values really do change. They were computed against 2^16 while mpu3050_read_raw() divides by U16_MAX, so the list never agreed with the channel: it offered 0.000122070 where in_anglvel_scale reports 0.000122072, and likewise for the other three. Patch 6 builds the list from the same IIO_DEGREE_TO_RAD() terms the read path uses, so the two cannot diverge again. On who runs these parts: mpu3050 appears in eight in-tree device tree files, covering Tegra 2 and 3 tablets, the APQ8060 Dragonboard and two Ux500 phones, and hdc1080 in two, one of them an IBM BMC. apds9960, max44000 and hdc100x also carry ACPI ids, so they turn up on x86 machines with no device tree at all. isl29125 and max44009 have no in-tree user that I could find. Compile tested only; I have none of this hardware. Patch 2 draws one checkpatch spelling warning on a word inside its Fixes: subject. That typo is in the 2015 commit being cited and has to stay, or the tag stops matching the subject it names. I am happy to rebase on togreg or testing if that is easier for you. Arka Mondal (6): iio: light: isl29125: Report the scale list via read_avail() iio: light: apds9960: Report the available lists via read_avail() iio: light: max44009: Report the integration time via read_avail() iio: light: max44000: Report the available lists via read_avail() iio: humidity: hdc100x: Report the available lists via read_avail() iio: gyro: mpu3050: Fix the scale list and report it via read_avail() drivers/iio/gyro/mpu3050-core.c | 40 ++++++++++++--------- drivers/iio/humidity/hdc100x.c | 61 ++++++++++++++++++++++++--------- drivers/iio/light/apds9960.c | 56 ++++++++++++++++++++++-------- drivers/iio/light/isl29125.c | 29 +++++++++++----- drivers/iio/light/max44000.c | 60 +++++++++++++++++++------------- drivers/iio/light/max44009.c | 48 ++++++++++++++------------ 6 files changed, 193 insertions(+), 101 deletions(-) base-commit: d135ab453a7400a34930bdda1ef4bdc8acfac80e --=20 2.56.0