From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E341AC28CBC for ; Sun, 3 May 2020 14:52:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B844120787 for ; Sun, 3 May 2020 14:52:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ip4rxDKq"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BwzIx5JN" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B844120787 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=dRNHshMrz1BcZlSeJM+F68IUrMiEWkearuylnWGbfdU=; b=ip4rxDKqB3lxs7 YXXlJJJEwug14YBdZ+y0SAIkDDIRj9DNz/hssbxfx2n6KSM1E3oOG3Tsw1Sn9SXlQrdtOvekRT2rH OkIWBLttB9frJB2qbB2mTG2PY048YmTnk5ZnLOANv+hE0lJKk7yzPk/TeQLSMpotKhk55WJsFMZtg 2JURtkKSf9rXgzV7uQwv8fyuCHVVArap9VMcqj0wkANe9XcGAme8UuxR5S2EAuOlRROm+YEgW4FdL uX/nnFBrmfhEsGc4SB7FCI/p4F+QPvsVJW7uXjKqzjRXYXO+GCEcL+V3gnyatQGXDvfJnXQDZLaTj AZbO+TRGKfiEf2jyLnAA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVFzC-0004L2-9R; Sun, 03 May 2020 14:52:54 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVFz9-0004KG-Cg for linux-arm-kernel@lists.infradead.org; Sun, 03 May 2020 14:52:52 +0000 Received: from archlinux (cpc149474-cmbg20-2-0-cust94.5-4.cable.virginm.net [82.4.196.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 918FD206F0; Sun, 3 May 2020 14:52:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588517571; bh=xXDUieDuCzRqcEpqQa4OH8QkYBoUMGQ7uE6Ln2swCE8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BwzIx5JNlgm+xPpdHNmK6Ug/5+tkTXai709h5BlOsaYVzJ70JQUz02hooslHlBOpm cvowAwVs5jIu5veh1ttXQnvWEGfN4Feo4hghFrLb49giSYHDa16woOeomwk/qq32g5 L/RSkXW+YBlKnRkpnbcJgJIo7mU7ZHX4hiwzt2Zo= Date: Sun, 3 May 2020 15:52:45 +0100 From: Jonathan Cameron To: David Lechner Subject: Re: [PATCH 0/4] Introduce the Counter character device interface Message-ID: <20200503155245.08916211@archlinux> In-Reply-To: References: X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200503_075251_450890_00E86B34 X-CRM114-Status: GOOD ( 17.74 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kamel.bouhara@bootlin.com, gwendal@chromium.org, alexandre.torgue@st.com, felipe.balbi@linux.intel.com, linux-iio@vger.kernel.org, syednwaris@gmail.com, William Breathitt Gray , linux-kernel@vger.kernel.org, alexandre.belloni@bootlin.com, mcoquelin.stm32@gmail.com, patrick.havelange@essensium.com, fabrice.gasnier@st.com, fabien.lahoudere@collabora.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 29 Apr 2020 15:21:05 -0500 David Lechner wrote: > On 4/29/20 1:11 PM, William Breathitt Gray wrote: > > Over the past couple years we have noticed some shortcomings with the > > Counter sysfs interface. Although useful in the majority of situations, > > there are certain use-cases where interacting through sysfs attributes > > can become cumbersome and inefficient. A desire to support more advanced > > functionality such as timestamps, multi-axis positioning tables, and > > other such latency-sensitive applications, has motivated a reevaluation > > of the Counter subsystem. I believe a character device interface will be > > helpful for this more niche area of counter device use. > > Nice to see some progress being made. :-) > > > > > Interaction with Counter character devices occurs via ioctl commands. > > This allows userspace applications to access and set counter data using > > native C datatypes rather than working through string translations. > > For most aspects of the counter subsystem, this is not an issue since > configuring a counter is not a time-sensitive operation. Instead of > ioctls, I was expecting to just be able to read the character device > and receive counter events or poll to wait for events similar to how > the input subsystem works or how buffers work in the iio subsystem. > > I'm afraid I don't really see much use in having ioctls that do > exactly what sysfs already does. And my intuition tells me that the > extra work needed to maintain it will probably cost more than any > benefit gained. (Maybe other have a different experience that leads > to a different conclusion?) I agree with David here. The ioctls are currently doing what could have been done nicely with a userspace library. Moving away from the string based internal interface is a good move to my mind, because it ensures consistency in they sysfs interface and provides for in kernel users when they make sense. The step of then using that to simplify providing an IOCTL interface to do the same things doesn't seem particularly useful. So what do we gain? Jonathan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel