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=-4.0 required=3.0 tests=BAYES_00,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 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 1225FC433E0 for ; Sun, 9 Aug 2020 17:53:45 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 CFB86206B5 for ; Sun, 9 Aug 2020 17:53:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FUL8xYRt"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="S3Iu1VC3" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CFB86206B5 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+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=merlin.20170209; h=Sender: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-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=NRXTnynTGkN2vQpfyVa9VpMnKqM2EXenht3Mt38tuOY=; b=FUL8xYRtCOuWqGv8nzk24iNzx p+2kvDGO00DrulNbDgDwswflTxZutQP7Nvtkok7cYM6rRSkoTFNqSS4Uq2wp/9lrIGIDdgdSrwvMC j6eWU1svjmh7EMIGxRlouMvtzQwSRDlVeUAk49SoP4vvpvAS7gOF7iKmt3crxcVN+CBark/k13NnC B2Ke/auXHZ3dTb9NlKqbkWbY/HO0gpry4DietQTaxoY/Fn4a+FV4AKZnFIq79S2EkSFEPQz6whKul GvC/E6drXZjbR2CKJQC8zTFiGYdu14HNWk2NPKRpzXmMvJDob/GJ+kBzKRM321YLRLR3Q5XypgqlG EGa+b+uhQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1k4pUA-0007yx-Pu; Sun, 09 Aug 2020 17:51:54 +0000 Received: from mail-qv1-xf42.google.com ([2607:f8b0:4864:20::f42]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1k4pU7-0007yN-Ov for linux-arm-kernel@lists.infradead.org; Sun, 09 Aug 2020 17:51:52 +0000 Received: by mail-qv1-xf42.google.com with SMTP id s15so3204170qvv.7 for ; Sun, 09 Aug 2020 10:51:50 -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; bh=n0x8YNxsCm7bGHeqbF8zvvR+sEvGuDkwyk/DAgXQhHw=; b=S3Iu1VC36rllT2s/b3IGvShcgQCYwpTombmTvT1JjcO53Se++BrGPfwLnk2xaZHEF9 DxK+kzM6G3uurL1qyVeBfPOcgCIGYORyMsExe0q8yvod6CSnZ/71K9Rvupf2a/KmqMhF RRzFBT0+FCutZXj9u5OeN1fYhxoAm56KD7n5MZssC1kSSMWq4mEMrrOIkQp1dxZ3PJIB OpMB8TtMAHOXKlBcb/zL6xNtjRLq6Ic+zjKgLYayJCfHHdtF6CNam+3owtyNvqVH1k30 GRG6Tz5HILGt1L8kx1TSRiBn9/5ZHwXpiSXbLJkvTOobQBq7R0qvY6mmyc/2VSBQ1XUS f7gQ== 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; bh=n0x8YNxsCm7bGHeqbF8zvvR+sEvGuDkwyk/DAgXQhHw=; b=FBDLkLkAS/ov0idEG6ULNBD7R+gJEuiHcxmxbg4SdsV4Alx/GijsP3buUm+jij677N dCgwo/xJKri8o11rkbn/jjUXWIczh+K528d3OcNG07bDX0obkbeNVG2ZuaqgYaofhlqI G6Y7Lsnx5dSd5AanjwmaPjyRDGpv0gR7AgPv9FJeTRcaqNLqisAfOIoQUqYwtl7VcgZ3 Gd4BSZn4oM+CLT7+W7SrDvMVDxqtInxA9y8rPDq4unvG4j8BrdDA10vsLH8M5mftLM9Y DHV0TlFcMyHKRB7SOK8P58XKEpkW1jBFl9XKYFG0RK/e5SYfZijK8awfL++VTDo/7s3J YMvQ== X-Gm-Message-State: AOAM533WypLh+codLxCxYr+QpuPJZ/NXAr7GNCgMGAzp03zHNwEWI6hV ndzOwhYSXOiZZ5Cu3g2pxpY= X-Google-Smtp-Source: ABdhPJz12sgXjE+X2nALn9osOEpYrHt9vHeEldiICmpuV68vmmG56WGukiYmWeKacikankoCPBRBtw== X-Received: by 2002:a0c:d64b:: with SMTP id e11mr18066172qvj.169.1596995508936; Sun, 09 Aug 2020 10:51:48 -0700 (PDT) Received: from shinobu (072-189-064-225.res.spectrum.com. [72.189.64.225]) by smtp.gmail.com with ESMTPSA id i18sm13211332qtv.39.2020.08.09.10.51.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2020 10:51:48 -0700 (PDT) Date: Sun, 9 Aug 2020 13:51:45 -0400 From: William Breathitt Gray To: Jonathan Cameron Subject: Re: [PATCH v4 0/5] Introduce the Counter character device interface Message-ID: <20200809175145.GB6542@shinobu> References: <20200809144800.6b067dea@archlinux> MIME-Version: 1.0 In-Reply-To: <20200809144800.6b067dea@archlinux> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200809_135151_959135_D97FD093 X-CRM114-Status: GOOD ( 35.25 ) 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, david@lechnology.com, linux-iio@vger.kernel.org, patrick.havelange@essensium.com, alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org, mcoquelin.stm32@gmail.com, fabrice.gasnier@st.com, syednwaris@gmail.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, alexandre.torgue@st.com Content-Type: multipart/mixed; boundary="===============3362004937900314264==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3362004937900314264== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0ntfKIWw70PvrIHh" Content-Disposition: inline --0ntfKIWw70PvrIHh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 09, 2020 at 02:48:00PM +0100, Jonathan Cameron wrote: > On Tue, 21 Jul 2020 15:35:46 -0400 > William Breathitt Gray wrote: > > The following are some questions I have about this patchset: > >=20 > > 1. Should I support multiple file descriptors for the character device > > in this introduction patchset? > >=20 > > I intend to add support for multiple file descriptors to the Counter > > character device, but I restricted this patchset to a single file > > descriptor to simplify the code logic for the sake of review. If > > there is enough interest, I can add support for multiple file > > descriptors in the next revision; I anticipate that this should be > > simple to implement through the allocation of a kfifo for each file > > descriptor during the open callback. >=20 > What is the use case? I can conjecture one easily enough, but I'm not > sure how real it actually is. We've been around this question a few > times in IIO :) >=20 > Certainly makes sense to design an interface that would allow you to > add this support later if needed though. I don't have any particular use case in mind, but I figured it would be useful. For example, a counter device can have multiple channels with their own events, but any particular channel might be counting the signals of an independent device unrelated to the other channels; in this scenario, two independent user applications might need access to the same counter device. Of course, supporting multiple file descriptors is something that can be added later so perhaps it's best for us to wait until the need arises with a real-life use case. > >=20 > > 2. Should struct counter_event have a union for different value types, > > or just a value u8 array? > >=20 > > Currently I expose the event data value via a union containing the > > various possible Counter data types (value_u8 and value_u64). It is > > up to the user to select the right union member for the data they > > received. Would it make sense to return this data in a u8 array > > instead, with the expectation that the user will cast to the > > necessary data type? >=20 > Be careful on alignment if you do that. We would need to ensure that the > buffer is suitable aligned for a cast to work as expected. That's a fair point. It's probably safer to continue with a union which also has the benefit of making the possible returned types clearer to see in the code. > >=20 > > 3. How should errors be returned for Counter data reads performed by > > Counter events? > >=20 > > Counter events are configured with a list of Counter data read > > operations to perform for the user. Any one of those data reads can > > return an error code, but not necessarily all of them. Currently, the > > code exits early when an error code is returned. Should the code > > instead continue on, saving the error code to the struct > > counter_event for userspace to handle? >=20 > I'd argue that errors are expected to be rare, so it isn't a problem > to just fault out hard on the first one. All right, that should help keep the error logic simple too then. William Breathitt Gray --0ntfKIWw70PvrIHh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAl8wN6YACgkQhvpINdm7 VJJS2A//eaJ/jtLitKdyaRHiFbB4//bIf3sPQQxG2eJSu3eztaFphLlkMxdDijrY OiBq5wsBkHYvcpy/z2A+XqY/PFzCpMrr/tAyuxiEeKB95WjzTUZl59CbUDOqqtwz 8wx1DcymzHfvwun1AQDfXPyMXD/Np0zdQTaY2vmjyllC5otFSfW2VfFh/RIzxQ2A FCtP9ogxam3Pl1GZ20e76C8f+tH8M25xP9Aj3h8R7XV2NiR6xE/WuhOlsmfAHyue cvYBfyS8YnTvZaDu1L88kqgEoXqJXqTXKTfxRYLRgEQD0DN/i7IndPgApUoya93O kBiGMexlfBeGOMaMgs29ZoFUflyg6ZjxcgrlCGt7jGHP8cmTex6TDw3f/BSGloPq ED5rh5rPnYzWy0mqenPgZU2V6VCZeApcGwhakCpSYFVdM4Lp4yiktdFTpzC9LkXY jeQvOXAespYNJH1llge4DfLwctqclMZVJg0flDDCUCQA75sy6vrPE73Nb+T3XChu TEu+P8gRFJbxi9Rg/l/7p+P30s4e2a1YKJfWdYStcHSougEHJq+9x8zUaejWAMwo YB8+NaDRnhUi6DVgTLwrib6uvwOyGj94P2qn8Y1RhkqUzQh0vSlG0z/gyss298H8 WCSZNFOLbS9pTLd77PpNxf7HkBCkg+/M14ZmjimDQMZwRMP0yGA= =+ft6 -----END PGP SIGNATURE----- --0ntfKIWw70PvrIHh-- --===============3362004937900314264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============3362004937900314264==--