From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f46.google.com (mail-oa1-f46.google.com [209.85.160.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEA3D256C9E for ; Sun, 18 Jan 2026 20:10:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768767037; cv=none; b=ewrl9CZaRi3UVRila5lI6khcCJb5YcDNzOmn44dXJeEa84f15Vqog4g1bskg52YNV2knJTPqLBQdG+9QEFa2C0lJ/NJJrFcCL2vzVmhCJpNDumizWJL5m3e0JctzmoqCIkkAnCj7EATG+UF2t6s4vdKYmDCXd34XkrDsV8mKEqM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768767037; c=relaxed/simple; bh=Idr/9lC0h+Y/MDT98JBhmBK5C5uie9ywPiZzL0QSgfc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dTTwI926wsHCx+vDLG7GmfeC2PVtV9qri635xdfzD0QkkCz+m9+/bxgd4D8bygluVJ+TDtE7wpr46ShDM5shtG2ykyBM82rf3JEhJBF5vReYr689Tgk04aPlPmnp+Qt+aUirPLHSXkY1UrqxPMI3HozJtpsZ6AM3fhYqSdJJRAk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=frVbBmHu; arc=none smtp.client-ip=209.85.160.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="frVbBmHu" Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-40439fb8584so2259933fac.0 for ; Sun, 18 Jan 2026 12:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1768767034; x=1769371834; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=trA58ecVKWrbKL/kcv6gytfma/FjnpD4gUB9nlw8H64=; b=frVbBmHuYEiiT0itRGUty9yv4YigztA0aCQj6l5cdhaXJl9ak5AOykHoPpmkvTAPil AtnFF7cWH0QZOCsAq0RFUIFrKnqmp6yPw6t95xvjRjsLOyVb0kKj49daLyMWs4Fqk/st nqoqo4wi2qFw7KwhrGWmFnE399xQSZYoDCFCGFCOEXyB5QDIS82aLI0/etOxW4EfzwFj UfxP9Lzu0B0Gjopp4ars4d4ya57qceTZ6U/ppXy6xi6YTrv3CfbHYMUpTSFNaESumOA0 /BJnLvYCeYY4J2eqxz0sW68RQfBL4dy+/Sj/Rz+097zEoEKh8zj0Ur/gVMyDZ86qsdn5 5EUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768767034; x=1769371834; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=trA58ecVKWrbKL/kcv6gytfma/FjnpD4gUB9nlw8H64=; b=neBm9LXDisTPwLa64F8I2cn8ZJLUxsOpLUBLxsb1lgQ9ctHejkgqYRHg/hCpdX4gy9 E0e+IbEq3OzaPEMj1NtduqBRGY5SlWS6tJy5wps7JxxiCjfm6QwsMfLWRqkuAllZ3Il9 NQUSisAix0ynOJJon6CsGMn4AAMv5QU00OH1Rz9ZJTuiGSytnuvoOguvctm93uL/TdAk 758mrFQ4jUfpmI2urZNYrlFNaH+y5I3cHX2AmRmBFoP6MVamOPUOv7WK+pYy3NZSx2Zp NafZtKdS5l01RKPHL2YVhPY5kaos2+u6qm3OotKn9sqUvuQhN0rdmT5jdJuGibYt5Q0E SK7Q== X-Forwarded-Encrypted: i=1; AJvYcCVtT7QlID1MzuBOLOOmV1p5vyi2s1tXlPJHxUWAsM+TTMin0DNzY/GwMcTx+t+zDAzYBdQblyqyqY3EuEY=@vger.kernel.org X-Gm-Message-State: AOJu0YwcD5+gpFcrmDMq+pV7ItOrMNGOSGNusYveXdf002IUJixoqQQy bWpNP2uogl5FdKUs0hHSw2fHmNJbklM57mS+2Bk0SKua9JPMdK3i2Wby8T5bnQXiOCA= X-Gm-Gg: AY/fxX5aV484AmHDGrR7HT+qQnpJSOgkhhpg7XEWoRPNbQtfomrtaOw/CfrGfWxOQZ+ LoJbZflFNoco/Zl6xh6omlZ3OJdGj3sY2t46w9sAepaH/7S70AlNHNkFDaYPlnpXAPDwyoGZwaq lxMYGHKmBzzO+VBSTR8fpSNzYe5g1xK3Uo5piQZ2+bYYZzGLlBqhFyDSV/N4Um7Vt/mi0vGLWk5 Euzui2kKFenWUhfM6aNBAVRT+AYg9XpwJ2ZsxgKx7MfMT1d5ChfGYEnJnhU705D+oMBHrxpoqJ6 PhCfVOIgei45KyJWOgvW6/KZQkTaI9JSctX4CaexVv9vsNI4pLedTJovjJPD6LvvSYR9TRx8Bvc 3L5QBrNy2c0kQrlr+Yp5BxUkwRD8EP3VtCzKRUUJnOera/FklfafWAImm4kABgI8Mpy94WdwW5c t5Ag7jNFwYOp31agNpjd8o5y7L0/HHYQRJg4Xzpie4vrMY6pwPGZJpN/TSgv66 X-Received: by 2002:a05:6820:612:b0:65b:865e:36f2 with SMTP id 006d021491bc7-66117fca883mr3557535eaf.4.1768767033769; Sun, 18 Jan 2026 12:10:33 -0800 (PST) Received: from ?IPV6:2600:8803:e7e4:500:d542:af69:64b6:f7df? ([2600:8803:e7e4:500:d542:af69:64b6:f7df]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-661186ca7aasm4022210eaf.2.2026.01.18.12.10.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Jan 2026 12:10:32 -0800 (PST) Message-ID: <5835e21b-0b27-41f5-8c92-762cac327b40@baylibre.com> Date: Sun, 18 Jan 2026 14:10:30 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v1 7/9] iio: Expand IIO event interface for real-world unit handling To: Marcelo Schmitt , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org Cc: jic23@kernel.org, Jonathan.Cameron@huawei.com, nuno.sa@analog.com, andy@kernel.org References: <6d9baa8d553d03a41fbd97bca0377a7a4779a93e.1768759292.git.marcelo.schmitt1@gmail.com> Content-Language: en-US From: David Lechner In-Reply-To: <6d9baa8d553d03a41fbd97bca0377a7a4779a93e.1768759292.git.marcelo.schmitt1@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/18/26 12:21 PM, Marcelo Schmitt wrote: > The IIO event ABI documentation distinguishes between interfaces that > handle values in device-specific units (_raw) and event interfaces that > handle values in real-world units (e.g. meters, Joules, lux, etc). > However, the IIO event code infrastructure had never really implemented the > bits to distinguish between those two types of interfaces and had always > presumed events to handle raw device values. > > For most current use cases, assuming events to handle values in device raw > units is reasonable because it often matches the type of the associated IIO > channel. There are a few cases where drivers provide events along side > channels with both _raw and _input interfaces, though. Also, when > real-world values can be mapped back to device configurations, it enables > drivers to provide event interfaces that are arguably easier to use. > > Expand the IIO events support, enabling IIO drivers to provide event > interfaces that handle values in real-world units. > ... > @@ -399,15 +410,23 @@ static int iio_device_add_event(struct iio_dev *indio_dev, > for_each_set_bit(i, mask, sizeof(*mask)*8) { > if (i >= ARRAY_SIZE(iio_ev_info_text)) > return -EINVAL; > - if (dir != IIO_EV_DIR_NONE) > - postfix = kasprintf(GFP_KERNEL, "%s_%s_%s", > - iio_ev_type_text[type], > - iio_ev_dir_text[dir], > - iio_ev_info_text[i]); > - else > + if (dir != IIO_EV_DIR_NONE) { > + if (i == IIO_EV_INFO_ENABLE) > + postfix = kasprintf(GFP_KERNEL, "%s_%s_%s", > + iio_ev_type_text[type], > + iio_ev_dir_text[dir], > + iio_ev_info_text[i]); > + else > + postfix = kasprintf(GFP_KERNEL, "%s_%s_%s_%s", > + iio_ev_unit_text[unit], > + iio_ev_type_text[type], > + iio_ev_dir_text[dir], > + iio_ev_info_text[i]); > + } else { I think that the units only make sense on IIO_EV_INFO_VALUE and IIO_EV_INFO_HYSTERESIS. Everything else has it's own unit, not just IIO_EV_INFO_ENABLE. > postfix = kasprintf(GFP_KERNEL, "%s_%s", > iio_ev_type_text[type], > iio_ev_info_text[i]); > + } > if (postfix == NULL) > return -ENOMEM; >