From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-183.mta0.migadu.com (out-183.mta0.migadu.com [91.218.175.183]) (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 527B62165E2 for ; Mon, 28 Jul 2025 22:44:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.183 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753742681; cv=none; b=BSKETHpqYiiXJYASExykQLtnTOXLMAK/19rQtmn5cRTl2vp0HCb7WVMvgpsSbb5AktbprvJUGkpu+4xplxO7yrxcPthC5D59UnhVQPe8JecoFC+6KkJ4XC/xlmEkcwpPi3IrsQswge5UU7thEQVA8R7d97A+NAHcJnDvvOoDUzA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1753742681; c=relaxed/simple; bh=Ky/PMGLyUDQZC9gL7CyrG5pqZrnrhZeqsFDICY7TrN4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=r++oQnDIaZpN0znJKXP7bmfBzk5C8d+N3Dm0C8qVgU1BmwLCh+6uFTzRLSchajUJf6WcpQpC6ZH8BrZ7XoQWYf3dinx6h2V8WpJdadMDjIEW7zQvJS4PKQLzoeu+DTcmO2p+UvvTMmnmkjJpSwIh72a75T62BnK9KEk6/c6AujI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=fzGslW6k; arc=none smtp.client-ip=91.218.175.183 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="fzGslW6k" Message-ID: <0ccf7735-6a2c-473a-ab67-ae0c5ff9a335@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1753742675; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k5/0co1W+cu2shaBxXBw2d5dMLF1j3owv/slrDbSyAk=; b=fzGslW6kZZkYeu4/WJy+c5tm8uXUHreJ17xnA4jnLRtASHmQk+lzNA/LsSevM76wH9Qxii 0OL0tyBHi9z04+P2gJ1q0SkKib7Eb2zdOFnQGgoV0u/zf7gkLeW21YjueCgdiSz56o0dTs btnPKWyjyrT6QbnX1FYvmoAG8/Ug1eo= Date: Mon, 28 Jul 2025 18:44:30 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 3/7] iio: Add in-kernel API for events To: Jonathan Cameron Cc: =?UTF-8?Q?Nuno_S=C3=A1?= , Jean Delvare , Guenter Roeck , linux-iio@vger.kernel.org, linux-hwmon@vger.kernel.org, Andy Shevchenko , =?UTF-8?Q?Nuno_S=C3=A1?= , linux-kernel@vger.kernel.org, David Lechner References: <20250715012023.2050178-1-sean.anderson@linux.dev> <20250715012023.2050178-4-sean.anderson@linux.dev> <9b187e7f-a116-4aea-a9a6-b9222562868d@linux.dev> <20250727172126.35d0a477@jic23-huawei> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Sean Anderson In-Reply-To: <20250727172126.35d0a477@jic23-huawei> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 7/27/25 12:21, Jonathan Cameron wrote: > On Tue, 15 Jul 2025 12:52:19 -0400 > Sean Anderson wrote: > >> On 7/15/25 07:09, Nuno Sá wrote: >> > On Mon, 2025-07-14 at 21:20 -0400, Sean Anderson wrote: >> >> Add an API to notify consumers about events. Events still need to be >> >> enabled using the iio_read_event/iio_write_event functions. Of course, >> >> userspace can also manipulate the enabled events. I don't think this is >> >> too much of an issue, since userspace can also manipulate the event >> >> thresholds. But enabling events may cause existing programs to be >> >> surprised when they get something unexpected. Maybe we should set the >> >> interface as busy when there are any in-kernel listeners? >> >> >> > >> > Sensible question. I'm not that familiar with events but I suspect is not >> > trivial (if doable) to do a similar approach as with buffers? With buffers, an >> > inkernal consumer get's it's own buffer object (that goes into a list of active >> > buffers in the iio device) with all channels enabled and then we demux the >> > appropriate channels for each consumer. >> >> For in-kernel consumers I think it's reasonable to expect them to handle >> events they didn't explicitly enable. I'm not sure about userspace >> consumers. > > This already happens because we don't have a demux equivalent (what we do > for buffered data flow) so if a device only has a single enable bit that covers > multiple events (annoyingly common for accelerometers for example) then > userspace will get events it didn't ask for. We 'could' fix that, > but it's never really been worth the effort. > > Events tend to be low data rate so an occasionally extra is rather different > to having to have much larger data buffers to handle a range of channels you > never asked for. > > Lets be careful to document this behaviour as 'may enable extra events' > as then if we decide later to do demux type stuff we won't be breaking ABI. > No one will mind getting fewer spurious events due to a core improvement. Where would this get documented? >> >> > Independent of the above, we can argue that having both inkernel and userspace >> > changing thresholds is ok (I mean, there's nothing stopping two userspace apps >> > doing that) but we should likely be careful with enabling/disabling. If multiple >> > consumers enable the same event, one of them disabling it should not disable it >> > for all the consumers, right? >> >> Right now the HWMON consumer never permanently disable events to avoid this >> issue. It does toggle the enable to determine if an alarm should stay >> enabled: >> ________ >> condition __/ \________ >> _____ ____ ___ >> enable \__/ \__/ >> >> event | | >> __ ____ >> alarm __/ \__/ \_____ >> >> read 1 1 0 >> >> I suppose this could also be done by comparing the raw threshold to the >> channel. > > I wonder if we should add the option to do a 'get_exclusive' or similar > to block the IIO user interfaces if something critical is using the device. > > If we were for instance to use this to block the IOCTL to get the events > fd then any built in driver etc will almost certainly load before anyone > can call the ioctl so it will fairly cleanly block things. This is how it currently works for userspace. Only one process can create the event fd, and everyone else gets -EBUSY. Of course, it would be pretty surprising to have an IIO device where some channels were used by userspace and others were used by hwmon and then have your daemon stop working after you update your kernel because now the hwmon driver takes exclusive event access. I originally had kernel users read from the kfifo just like userspace, but I was concerned about the above scenario. --Sean