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.2 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 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 1289FC4740A for ; Sat, 5 Oct 2019 17:20:20 +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 D3A10222C0 for ; Sat, 5 Oct 2019 17:20:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="u5zwn0eB"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hInKtJ1w" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D3A10222C0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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=EdWOsT3xJ4iwcYY04bv5M8IT2/bqxkiJU20Wa2MaF58=; b=u5zwn0eBby19gt s/F55tZhnDKLYXAZdM4TjmadKstN9tkXEXLqdOGXPH8QIqfl7NMn9znU+45Bsfz14smUTSKyc6csr AGztEA0SN9+xPM/qZX84GUzCnfnsJtRe7EwIJEbR22J2ljLAz+mOiOTnq78ag/p4QQ1kamNjv/xPi lLN6UwbRAUAvFNxHt4B9Uc2wz59c1C3HPhv5r+gJ/IgHS4QR+lG0M+xPVU7GEAjKuDhlRM+RM7sTh vboudAkr3cfDhQfDOfWmY8O4VmncOp/Gm71LVm7LR6FxHSLrs4JhJ1XCiCxvxvQQiS4MA35SjyuQy +LAduybwlUnwtXDYPU2w==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iGnj0-0004VH-Hy; Sat, 05 Oct 2019 17:20:10 +0000 Received: from mail-yw1-xc42.google.com ([2607:f8b0:4864:20::c42]) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iGniu-0003Sz-W0 for linux-arm-kernel@lists.infradead.org; Sat, 05 Oct 2019 17:20:06 +0000 Received: by mail-yw1-xc42.google.com with SMTP id e205so3528941ywc.7 for ; Sat, 05 Oct 2019 10:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MGAToH7gf0cf1NNYqYOLRrO0bNygR1ZINN+gs4KcfjI=; b=hInKtJ1wQDIAaaHqSxMc1KyxX4ngqQzK06TYsc/fewv9OUTewxjNvhoAA22E2/loFi wasFDBlq9zqGi2r4tcMli2676VkrYeWc1VXonj2huB9BN3/KO62U593XrF3cCPk9zh6/ Ro3i0ArBfq+DiD4Hjv4cx+SzU6bYwnUpYuNYZyv3BwS51hHP+2oNYpbFzTziWvHPq8uA rxkpkdoCpCasIyeZOFSod3u9r/N1cd2scssUF3wZUa98SWne/8/bY2otB/XZ9Pu6S6ie GdABnngINi8bA5qSz0P8R+JqRAjS6T41wKr3An9fF/dYeSQaFX8z5Jmv3S99rwN62CoH a1gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=MGAToH7gf0cf1NNYqYOLRrO0bNygR1ZINN+gs4KcfjI=; b=D6+Lk8JISYB2vgOBsgGsnKagqiyhQKz4+z0arX1Y2AnGIhxHJLFZerjIdGkWWedI4n DMb0kxFaSeky0x0tmlXi+ao5MCmGDogf9i8krJi8oogLf2lGgonSl0gT6AbZlFmJ5UbL mPcK6q3b/vuzypptcOgIg+dq2VT+/xWcJ7pGjRhH93nmA+hYGM6DeiHLWw9wGCTvZNdk 23UQR/izjwI793Zn/5pqedz6jqwhdZgCuCdezUZz5dKCkcsrC6mXAfNOxQ3Pqb2ZCxgG K+lzx65nr9negmfFjpNaByVa40lOAL2z3EYPUWm0WDVWV24b32fW55ZrlXoUbsboSm5P LbRA== X-Gm-Message-State: APjAAAVQP1szM5+95518RJ6WOQQ9UXSmpZ+HMltcFZ2BZ8FQNFa2Ykr4 gOUxM+k8yghrzuQN9AVg+1bu/+4o X-Google-Smtp-Source: APXvYqwwjA05OEJO+32btwCbv0PRqgBlNIanc9PkgxO2kfSjusl2VL25zMbuvWbNGxLNX46za0Mg4Q== X-Received: by 2002:a81:3601:: with SMTP id d1mr15208844ywa.103.1570295998277; Sat, 05 Oct 2019 10:19:58 -0700 (PDT) Received: from icarus (072-189-084-142.res.spectrum.com. [72.189.84.142]) by smtp.gmail.com with ESMTPSA id y205sm2445684ywc.6.2019.10.05.10.19.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Oct 2019 10:19:57 -0700 (PDT) Date: Sat, 5 Oct 2019 13:19:38 -0400 From: William Breathitt Gray To: Jonathan Cameron Subject: Re: [PATCH v3 0/2] Simplify count_read/count_write/signal_read Message-ID: <20191005171938.GA7199@icarus> References: <20191005153255.4290ce81@archlinux> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20191005153255.4290ce81@archlinux> User-Agent: Mutt/1.12.1 (2019-06-15) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20191005_102005_050247_C08019F2 X-CRM114-Status: GOOD ( 28.21 ) 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: benjamin.gaignard@linaro.org, alexandre.torgue@st.com, Felipe Balbi , linux-iio@vger.kernel.org, patrick.havelange@essensium.com, linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com, fabrice.gasnier@st.com, Fabien Lahoudere , linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, David Lechner 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 Sat, Oct 05, 2019 at 03:33:08PM +0100, Jonathan Cameron wrote: > Hi William, > > This all makes sense to me. Do you want to wait for some more reviews > or should I pick them up now through IIO? We are really early in > the cycle so plenty of time, unless there are new drivers coming you > want to use these from the start. > > Thanks, > > Jonathan Getting this in sooner would be better since that will save Fabien from having to introduce the COUNTER_COUNT_TALLY type in the cros_ec patch submission. The only concern left now is that the TI eQEP driver needs to be updated as well for these changes, but it's not in the IIO testing branch yet. Do you want to merge this patchset first, or wait until TI eQEP makes it into the testing branch? Alternatively, I can merge the cros_ec patchset and Intel QEP patchset into my personal repository when they are ready, then later submit a git pull request to you with these changes if you prefer that route. William Breathitt Gray > On Wed, 18 Sep 2019 23:22:44 +0900 > William Breathitt Gray wrote: > > > Changes in v3: > > - Squash code changes to single patch to avoid compilation error > > > > The changes in this patchset will not affect the userspace interface. > > Rather, these changes are intended to simplify the kernelspace Counter > > callbacks for counter device driver authors. > > > > The following main changes are proposed: > > > > * Retire the opaque counter_count_read_value/counter_count_write_value > > structures and simply represent count data as an unsigned integer. > > > > * Retire the opaque counter_signal_read_value structure and represent > > Signal data as a counter_signal_value enum. > > > > These changes should reduce some complexity and code in the use and > > implementation of the count_read, count_write, and signal_read > > callbacks. > > > > The opaque structures for Count data and Signal data were introduced > > originally in anticipation of supporting various representations of > > counter data (e.g. arbitrary-precision tallies, floating-point spherical > > coordinate positions, etc). However, with the counter device drivers > > that have appeared, it's become apparent that utilizing opaque > > structures in kernelspace is not the best approach to take. > > > > I believe it is best to let userspace applications decide how to > > interpret the count data they receive. There are a couple of reasons why > > it would be good to do so: > > > > * Users use their devices in unexpected ways. > > > > For example, a quadrature encoder counter device is typically used to > > keep track of the position of a motor, but a user could set the device > > in a pulse-direction mode and instead use it to count sporadic rising > > edges from an arbitrary signal line unrelated to positioning. Users > > should have the freedom to decide what their data represents. > > > > * Most counter devices represent data as unsigned integers anyway. > > > > For example, whether the device is a tally counter or position > > counter, the count data is represented to the user as an unsigned > > integer value. So specifying that one device is representing tallies > > while the other specifies positions does not provide much utility from > > an interface perspective. > > > > For these reasons, the count_read and count_write callbacks have been > > redefined to pass count data directly as unsigned long instead of passed > > via opaque structures: > > > > count_read(struct counter_device *counter, > > struct counter_count *count, unsigned long *val); > > count_write(struct counter_device *counter, > > struct counter_count *count, unsigned long val); > > > > Similarly, the signal_read is redefined to pass Signal data directly as > > a counter_signal_value enum instead of via an opaque structure: > > > > signal_read(struct counter_device *counter, > > struct counter_signal *signal, > > enum counter_signal_value *val); > > > > The counter_signal_value enum is simply the counter_signal_level enum > > redefined to remove the references to the Signal data "level" data type. > > > > William Breathitt Gray (2): > > counter: Simplify the count_read and count_write callbacks > > docs: driver-api: generic-counter: Update Count and Signal data types > > > > Documentation/driver-api/generic-counter.rst | 22 ++-- > > drivers/counter/104-quad-8.c | 33 ++---- > > drivers/counter/counter.c | 101 +++---------------- > > drivers/counter/ftm-quaddec.c | 14 +-- > > drivers/counter/stm32-lptimer-cnt.c | 5 +- > > drivers/counter/stm32-timer-cnt.c | 17 +--- > > include/linux/counter.h | 74 ++------------ > > 7 files changed, 53 insertions(+), 213 deletions(-) > > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel