From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) (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 498CD314D0B for ; Wed, 25 Feb 2026 21:27:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772054883; cv=none; b=gVbDZA/apDwTCajZm3J3kOxDxncrlgQOp/JpjBbXB5hzHuB4CYX1dDOBO4jphWa+O69Cr/Ve9KbkhNud3KBBPklbVu3kQVLX5JyC7BicuxefcOMgNLxX0KLBrPwemCQ3C5HnHEugZ8Cjmo51jE2XwsOC4m6CRDPFnhIuYn812bY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772054883; c=relaxed/simple; bh=qjrk/gpVIC1qKApvcZQJkb+2O/ErBj+6Q50wrK706PE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=XwT26LoiKu7+VsO4BqZn9GOupJEnRRPWQJcI1CFBvrWx44Szh91SlHMrh9MLlWx6qam5OW8wLlMIPf0PjuAECJu7Vonrf9pQosO1seJUKlPjSLgJf8Qu6IHqrSVSNrtJt0dAijmcfBI+gyISx2rN9Zb4sJS0ni21mKqJ5aA0fpA= 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=zVFNrM6/; arc=none smtp.client-ip=209.85.167.174 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="zVFNrM6/" Received: by mail-oi1-f174.google.com with SMTP id 5614622812f47-4648448e387so136510b6e.1 for ; Wed, 25 Feb 2026 13:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1772054878; x=1772659678; 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=ppp+Wy9oVLyAcv92KWS/Xhqb10P6rmyhJHh80S79F44=; b=zVFNrM6/dL4RVlHdZshlXZedPF+Sqou81/Sq7A0ZCjiDZ7tfVk1EgwHCfOsrTxzeSH FpwwIwQ8zWvqPpAxNspF25xgKP5TDUyD1pJM3fD3gY3IDOuKjwXBkjH5l0fZ1zUUeZHm c5HRx6mgh2hZwornmLh3CjK4NibTfZ/VDFth8CSCG5PwGyxt3ZJQ4V1qh341VFL3LizR qG2H4yi21KcKfjCY7MF6S2OGLUWXEikGFrcW4Qwc6nlTwbmkaCs39YSyIq4wK6ymu7i2 mXx2lM9bsF7BTIHyp7IaApmqtoAD0VhGrLQQBPc5IXWyCUeZ+j+pmr0rfmUFn37jkc8C GE9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772054878; x=1772659678; 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=ppp+Wy9oVLyAcv92KWS/Xhqb10P6rmyhJHh80S79F44=; b=VLgiC+zRu0SDEcLUSFFpUpbq+7xWDl6zEwyOkk7EdqNKlps9zsbrIhi0gf7tzeB051 xf3GVcFJpBh04OWRp/1FXjxKsUAPacKVp5aiKNUhse3RLzU6c3rwB/lBgNcPX6E1u/Az Fb8mJabbRmvr3OkLWQu2VZCm2CwBu3W8hR9GSk6vqeS9dNv0nmdSQlxZFOJMf1t+y6nF XCweGjl63u0PLfD5LnhLqILhd/+rK6uyipaiLuZh+DSzC5LEg8wP4tgnYVJdGa8/AWGL EENbGPC4XilY/iAK881aWpsRFrTPFd81gZmfyUd4iuUKLGPoMRQoJq/G5pVK3IjA5XoV N88Q== X-Forwarded-Encrypted: i=1; AJvYcCXcObbwREW74SWuieMY3A/M8UEYwr+9YWAap3kV9Eex/wsqDW7v9sqi+hd+VBg5BlGuwMg0g43Le1Ia8lI=@vger.kernel.org X-Gm-Message-State: AOJu0YzN/gaca8VfVgcqUaipgutksJldURus+h7B+xq9sPlmvpIzadlG hTxEN3EklnsDlekoRKsUp3iOsjKdsBUXSAsGzjoPlxHxHeoIsmt8FUDHahr28vMExNY= X-Gm-Gg: ATEYQzwuI40teM8pVFzNJmpYkiFTaUm/1CuZl7/8n49WTaavHuH/bU4Cy9ys6WTYrMi ijTPoKwLnVAbd+h6m+FX2wL3LvEI9Es9Gow36HsDumsoLkFF4IKbTLn9vomquv2hAIxIzCLvAJU AkciUN0p+7G97agDL3v4jhkc9kqbzbCDt1d5epozyck94kRSQy8t/9EHSZLZrcLDwWOTYJhv1EP /OFY/1FNiwdavZOnZS4lWWGG5TFMAIwb8IW0lnjbh0/HnCO2eZtOEzJ9kD4uLAJZQWH7DvrKgDN jbPRc0zVaQpP086GZNUu86mJ94ipjalY42yxxfZWW5KS6Gj+cQJ1e0675d3A4Vt1gUHFUSUyKOa ThJnL10Kp2FfqbNvIW/DDlbdm0Bvkdp/+ZywjxyUHzw4HV4bSNORHsvnY0s1ilzYTazT96gIYcy T+h11pecJYxBXDGfQo8KDuDXw5ADtL0pT2ZvnNBK0ILw4WMJ8We3uum8pq1WLIXljeUvjMBP0= X-Received: by 2002:a05:6808:6508:b0:45e:a52c:e4cd with SMTP id 5614622812f47-4649eef644amr1321892b6e.27.1772054878045; Wed, 25 Feb 2026 13:27:58 -0800 (PST) Received: from ?IPV6:2600:8803:e7e4:500:146:def2:caeb:cb1f? ([2600:8803:e7e4:500:146:def2:caeb:cb1f]) by smtp.gmail.com with ESMTPSA id 5614622812f47-4644a17aa52sm9783451b6e.10.2026.02.25.13.27.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Feb 2026 13:27:57 -0800 (PST) Message-ID: Date: Wed, 25 Feb 2026 15:27:55 -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: [PATCH v6 6/7] iio: ABI: Add custom data type To: Andy Shevchenko , Francesco Lavra Cc: Jonathan Cameron , =?UTF-8?Q?Nuno_S=C3=A1?= , Andy Shevchenko , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260225100421.2366864-1-flavra@baylibre.com> <20260225101806.2368391-1-flavra@baylibre.com> Content-Language: en-US From: David Lechner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2/25/26 5:43 AM, Andy Shevchenko wrote: > On Wed, Feb 25, 2026 at 11:18:06AM +0100, Francesco Lavra wrote: >> This type is used when the data received from or sent to a device cannot be >> identified with a standard type and must be processed by custom userspace. >> Any driver using the custom type must provide a driver-specific document >> that explains what the data represents and how it is to be interpreted by >> userspace. > > This rises the same Q as for other firmware-hidden algos, et cetera: How > can we prevent the kernel from being just a simple proxy between HW and > the userspace? What would be the point of having the "driver" in the kernel > space? > I tend to agree that this opens the door for misuse or an excuse to not make the effort to develop something more generally useful on future drivers. For this patch series, could we still use IIO_ROT and introduce a new IIO_MOD_PARTIAL_QUATERNION that is defined according to the description in the documentation patch in this series? This may be the only driver that ever uses it, but it is still clearly defined. Or perhaps we could even say that if a IIO_MOD_QUATERNION has .repeat = 3 instead of .repeat = 4, then it should be interpreted this way?