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=-3.5 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 487D1C433DF for ; Sun, 18 Oct 2020 14:16:05 +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 CB34721655 for ; Sun, 18 Oct 2020 14:16:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Rd5Scl26"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="sLqkvqoY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB34721655 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=e4PnhGwsN8q1DQ0ELQTvdmlLts+tueFAJulrTEkonCQ=; b=Rd5Scl26lHFbEZEm/ZSw7dxMD phHhIPIgBgKN4ru5eirsU+mpw2C/7Szw7HaV/LI0OvqAcTqivMPZQ2eGWhZ7FyDs7evbsPmuThFVp jEslBeSmn74noYUdPgo84bDKhyAcB34izPSaP/wQ65nbOpmx2IxgbBYVbl6UulKr2bj+cAkfWXEza ktIaWuaeeYi6aHHBKuxroIgJKJ3j9G6w4i4tNg2Zs2ddAHQzMlIhtdevQ9ERcP/S8xM7NwV9/xmYS 9/b1mor/nk9x1m/A3bFSs43TOF9VrhI9E7FJ/lMiec69SRqxp67vXXZ3m6Z9jEZ8mjYh42ZGiOpro G9al0GkgQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kU9SH-0005ai-3F; Sun, 18 Oct 2020 14:14:37 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kU9SE-0005aF-Mk for linux-arm-kernel@lists.infradead.org; Sun, 18 Oct 2020 14:14:35 +0000 Received: by mail-qt1-x842.google.com with SMTP id e6so4602272qtw.10 for ; Sun, 18 Oct 2020 07:14:32 -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=wQD8dvtVrq4V8MJl2t269P6nRY45qGQQwokAStwOkWk=; b=sLqkvqoYyL7bDoORzLgwtKjYTyFm2yH2VYX0ISHtpB70KxnqQaVk5WrYtFap5xmV3b zY2daPhUl7UyatttwIktfRPPwTwoHd9gmGawqyu2i2QuBbHMxpQ3ZBVOEF7FmMCkHyT6 cdbagoqTqHTMKBxZO+s4jlaaavO63RA+5bbQEDVof6h93xRejTA8+O6c/gdGZpTkkoqi IU2LgK8+EhXpIgY98TCxaCpsCPY2KguBD2ab6lV6FXPk+BOgO2eIZDYgBzbEITGw7oa1 SfnkVcR98W7rsML9bQ8Dkyfrpe4ZWn8bSKDlTNT+M6rUs7bZ2aiGIFhlhv99F8Oh+Ovo tZAA== 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=wQD8dvtVrq4V8MJl2t269P6nRY45qGQQwokAStwOkWk=; b=J6N+jxEJj6S2wXwtf4AAzoQFPI+mVO4wWrXY8BramaqSCVMiRcqrpy6kVkXnskr2T2 uf9B5BvsPN4eYEG9exm4YDbrC8VrI1VLuMJ8qNdTo0uVmPk9ILJIT3hnq/eVHxtcqJYh r8rgLT4ACiOPSmC0feC56o1w7OAtAZhHj5PvtEq6HMlL2Pc3M9h/sV/175c8VOOwfHM2 Tqhfccqa1xuode7joQq3xV7pSuQgIHk7czOxGCGW6TsiBuRA3qVpYn61fLmvH/RTkk3b SVfVFVzEIayfQJmjnpGv4SKRMJ0bKKHsRasftpdsr+GMya2bFBojHn/sBm/z+aG9D9Hq KkXQ== X-Gm-Message-State: AOAM5314FrkEEikhfSuoeyaHREdizjct8qB606Jv72AozBEC0FEA2Wpt LoB89PqCF6uIWq7YNVaQOFU= X-Google-Smtp-Source: ABdhPJz8AqYMLj6JncUpgAzSEh01P1bIeDSVxq6zjSr5BxjFbB42zFfwuvL7QL1MnzhJ1uMLrHtPSQ== X-Received: by 2002:ac8:1a30:: with SMTP id v45mr11101920qtj.345.1603030471220; Sun, 18 Oct 2020 07:14:31 -0700 (PDT) Received: from shinobu (072-189-064-225.res.spectrum.com. [72.189.64.225]) by smtp.gmail.com with ESMTPSA id g15sm1566143qki.107.2020.10.18.07.14.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 18 Oct 2020 07:14:30 -0700 (PDT) Date: Sun, 18 Oct 2020 10:14:01 -0400 From: William Breathitt Gray To: David Lechner Subject: Re: [PATCH v5 0/5] Introduce the Counter character device interface Message-ID: <20201018141401.GA231549@shinobu> References: MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201018_101434_766958_A315A1CD X-CRM114-Status: GOOD ( 28.94 ) 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, linux-iio@vger.kernel.org, patrick.havelange@essensium.com, alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, mcoquelin.stm32@gmail.com, syednwaris@gmail.com, linux-stm32@st-md-mailman.stormreply.com, jic23@kernel.org Content-Type: multipart/mixed; boundary="===============2602381001525610962==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============2602381001525610962== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 12, 2020 at 07:35:11PM -0500, David Lechner wrote: > On 9/26/20 9:18 PM, William Breathitt Gray wrote: > > The following are some questions I have about this patchset: > >=20 > > 1. Should standard Counter component data types be defined as u8 or u32? > >=20 > > Many standard Counter component types such COUNTER_COMP_SIGNAL_LEVEL > > have standard values defined (e.g. COUNTER_SIGNAL_LEVEL_LOW and > > COUNTER_SIGNAL_LEVEL_HIGH). These values are currently handled by t= he > > Counter subsystem code as u8 data types. > >=20 > > If u32 is used for these values instead, C enum structures could be > > used by driver authors to implicit cast these values via the driver > > callback parameters; userspace would still use u32 with no issue. > >=20 > > In theory this can work because GCC will treat enums are having a > > 32-bit size; but I worry about the possibility of build targets that > > have -fshort-enums enabled, resulting in enums having a size less > > than 32 bits. Would this be a problem? >=20 > We shouldn't have to worry about userspace programs using -fshort-enums > since that would break all kernel interfaces that use enums, not just > these - so no one should be using that compiler flag. >=20 > So I am in favor of using strongly typed enums with u32 as the > "generic" enum member type. That reasoning pacifies my worries. I'll test out strongly typed enums in the next revision of this patchset. > >=20 > > 2. Should I have reserved members in the userspace structures? > >=20 > > The structures in include/uapi/linux/counter.h are available to > > userspace applications. Should I reserve space in these structures > > for future additions and usage? Will endianess and packing be a > > concern here? > >=20 > Since there doesn't seem to be a large number of counter devices > this probably isn't critical. Are there any aspects of counter > devices in general that couldn't be described with the proposed > structures? For example, could there be components more than two > levels deep (i.e. it would need id, parent id and grandparent id > to describe fully)? I can't think of any devices that would require more depth, so we probably don't need any additional members added to the userspace structures. The current structure should be flexible enough for future expansion, and any additional functionality we come across can be handled by implementing new extension types as we have for the sysfs attributes. William Breathitt Gray --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAl+MTZ8ACgkQhvpINdm7 VJK9LBAAge9m8K8GflWtmFR6Fs3MjZ4VRmuFs6SXmkK0zYWPpaw0vy5Is6poej9f p2hXz0EBxEVSdD+/hMmnyrz3VeLrRrSKN4iekMxGpScZoiyjeh0wy9J0kcv01zTd jYR8Jm4lCJShMW20HFHUZXR3gUGTzXXB6jot2jDk+UMAkISYK7msNt4nmb6WsaU0 4QGpNZE0uznJN1PZ8pzv4NZ7LzZpf/HDDU6XgCIT9lWrQIbVXiOXG9aeXA0nL8cJ WmBwtSZ5KQJo9Ijjo1Rn6zhNUoKMzF1wvGNEHvpvJDZ8n9x4ljyVh9FsEMUV9MC4 jWgJMA2+7vRbrheBqAuLTB2rC46xZuSr3cS7mu9sY+DO+LSNVafLWU8vjzzK5tfX ahPxfm7Bz/lX8zhddNPWL1t7aNFMCJJdLAmRIlHewf9mdoE0n35ifyvOpgAACtIn qFgr0TkpZdwq7TG3FCNqXRE80cw0YWZUIXeZr0MFoETzHPs50VvFDBQB/xKU1/wo qdV2OZAn5bdfbk/DMqg9S61+H3KbujUgQZ+k+ANB4UMKYdo3QyNgBNUpFQgUqlp2 rqFuAZTNVG1VY2mJcA+8QJe4eQkn3oEGzgvK29ruiysk6nk/GjEhtJ8qJ+NLqw7q HpTWR26ANLXz6Iy7izaSHM3jLiAp675Ej6bDzkZRf74d+RoKf5Y= =oiqw -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- --===============2602381001525610962== 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 --===============2602381001525610962==--