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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 4C308C3815B for ; Sat, 11 Apr 2020 23:31:59 +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 2300C20936 for ; Sat, 11 Apr 2020 23:31:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nV8zPN2W" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2300C20936 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bootlin.com 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:In-Reply-To:MIME-Version:References: 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=xFX3cr18pUwTgOoySKM8cHUifxeo/YTWZjj/71Nzll0=; b=nV8zPN2WgHYCbu t72WMhBhHoLcqxAOhnU+mOsiUhjW+EX1gCejQu2wWjNCdGqrNPI6o1QPGjg6RvD4CXsS7dTs+iaKQ gWF2C5LV9R84hFul84nxPadSr9DkS6kEHmBebdADO0h005p3k0eCEcRPAjWODxdQ19SuaDJPvImCS xpaiv0RQtkMIvRZ8yOgaA4bU/cV2zDY+5fHCbS7RFB/blG44Uy0kj9BBWfFDJXnFfSrgj/16yusGs ThAMPeTDgvalo3bN0wBygZ1JOCz0HN4r+ou/+Qk6AGAPa4gIZzS7yzUxC2kbVIZnM/R5+DuW/BtmJ Vc2Vo8s8uqaAJ3OSJ2Kg==; 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 1jNPbP-00050M-NW; Sat, 11 Apr 2020 23:31:55 +0000 Received: from relay7-d.mail.gandi.net ([217.70.183.200]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jNPbM-0004yc-4j for linux-arm-kernel@lists.infradead.org; Sat, 11 Apr 2020 23:31:54 +0000 X-Originating-IP: 86.202.105.35 Received: from localhost (lfbn-lyo-1-9-35.w86-202.abo.wanadoo.fr [86.202.105.35]) (Authenticated sender: alexandre.belloni@bootlin.com) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id C998520004; Sat, 11 Apr 2020 23:31:45 +0000 (UTC) Date: Sun, 12 Apr 2020 01:31:45 +0200 From: Alexandre Belloni To: William Breathitt Gray Subject: Re: [PATCH 0/3] Introduce a counter inkernel API Message-ID: <20200411233145.GC3628@piout.net> References: <20200406155806.1295169-1-kamel.bouhara@bootlin.com> <20200411172259.GB95806@icarus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200411172259.GB95806@icarus> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200411_163152_313832_3528B5A0 X-CRM114-Status: GOOD ( 17.51 ) 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: Mark Rutland , Kamel Bouhara , devicetree@vger.kernel.org, linux-iio@vger.kernel.org, Dmitry Torokhov , linux-kernel@vger.kernel.org, Ludovic Desroches , Rob Herring , Thomas Petazzoni , linux-input@vger.kernel.org, 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 Hi, On 11/04/2020 13:22:59-0400, William Breathitt Gray wrote: > I'm not inherently opposed to adding an in-kernel API for the Counter > subsystem, but I'm not sure yet if it's necessary for this particular > situation. > > Is the purpose of this driver to allow users to poll on the rotary > encoder position value? If so, perhaps instead of an in-kernel API, the > polling functionality should be added as part of the Counter subsystem; > I can see this being a useful feature for many counter devices, and > it'll keep the code contained to a single subsystem. > > By the way, I'm going to be submitting a major update to the Counter > subsystem code in the next couple weeks that isolates the sysfs code > from the rest of the subsystem -- it'll likely affect the interface and > code here -- so I'll probably wait to decide for certain until that > patch lands; I anticipate it making things easier for you here after > it's merged. > > For now, I want to get a better high-level understanding about how users > would interact with this driver to use the device (input_setup_polling > is a new call for me). That should help me understand whether an > in-kernel API is the best choice here. > Well, the goal is not really polling the counters but mainly exposing the correct userspace interface for the rotary encoders that are connected to quadrature decoders. The input driver is using polling because this reduces the complexity of the patches but the ultimate goal is to also have interrupts working. I'm pretty sure the in-kernel interface can also have other usages like for example iio triggers. I could envision having to read an ADC after x turns of a motor to check for the torque. I also think that having the sysfs code separate would help as it could be considered as one of the in-kernel interface user. BTW, do you have plans to add a character device interface? -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel