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=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 29415C433DF for ; Tue, 13 Oct 2020 00:40: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 C272D21655 for ; Tue, 13 Oct 2020 00:40: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="OHvvfGAU"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=lechnology.com header.i=@lechnology.com header.b="LCWAFnRQ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C272D21655 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lechnology.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: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/dhNJOrPmxNxk4UjOXYph9JXpMYRzShqbAYOmeTPTSk=; b=OHvvfGAUCrrOQh3ZNBDbUK85x +h4gywbNB872xqvDjiauC9YgAgbcxFtAyQGHx6n1zDoXNY8iUXzq32gADiTwD9IFHk2AdRHQnEPDD 4f7AiVRwkha1iOJM0777mgFl2zYU1TQvMBmFUmLLOrSKMr8oKGJ/czUNY1lxbPS5JSBDpmXwkD83L DrgxRGcGyjO3SI7DuC6AuCJAG13RftqE9n7bZUSpam+DWe4bHkkF1E5AbAt95X6k8uTHcT1bfERbl NuBWcWxWVw/zdVD34EKoV7D8aqONTr2kLcTyGg+Ca7pW4ak96BQwQJFqvpu6YzbuHogpYW5FdKsK6 nK3KqSSBw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kS8Km-0000QH-5I; Tue, 13 Oct 2020 00:38:32 +0000 Received: from vern.gendns.com ([98.142.107.122]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kS8Hc-0006wG-Uu for linux-arm-kernel@lists.infradead.org; Tue, 13 Oct 2020 00:35:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lechnology.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=i3DN6BtJb3Jcv8rh81sTBY6UT+tAKn+rVAVT3o7iIs0=; b=LCWAFnRQ9KOZLwI3SDaZMqncKF f/DMPsIh8viZE5VxEU395L0jKfZ8dHRv62q3AUsfR32nPKPduHKBTAcODM2InG2K5L9el+tpax9lu RvXe2CekmCNzDQHRTFFJMNKSPaf4ROoDVJWaiGbGvnPxPnmCMpRLLGogchn7I6YAMjMssrq+eRPnh pUetcBTuhuR+6qCd1PI3sePSJ2uQYE8990YSxuSwWmq6uhcJriMzwMTZVCj3ybIcvJGvsjwZ3nE+j ENd2JhPRPtymm+u+khNB97+5AQe1/KRpoi59MZmIZJ9ksLZz80kd8T/J1WfaRNPWz3zqoX6/eTzow ebDqpVoQ==; Received: from [2600:1700:4830:165f::19e] (port=56668) by vern.gendns.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kS8HZ-0000vN-Pn; Mon, 12 Oct 2020 20:35:13 -0400 Subject: Re: [PATCH v5 0/5] Introduce the Counter character device interface To: William Breathitt Gray , jic23@kernel.org References: From: David Lechner Message-ID: Date: Mon, 12 Oct 2020 19:35:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vern.gendns.com X-AntiAbuse: Original Domain - lists.infradead.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lechnology.com X-Get-Message-Sender-Via: vern.gendns.com: authenticated_id: davidmain+lechnology.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: vern.gendns.com: davidmain@lechnology.com X-Source: X-Source-Args: X-Source-Dir: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201012_203517_130623_8054FE20 X-CRM114-Status: GOOD ( 19.14 ) 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, mcoquelin.stm32@gmail.com, syednwaris@gmail.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 9/26/20 9:18 PM, William Breathitt Gray wrote: > The following are some questions I have about this patchset: > > 1. Should standard Counter component data types be defined as u8 or u32? > > 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 the > Counter subsystem code as u8 data types. > > 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. > > 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? 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. So I am in favor of using strongly typed enums with u32 as the "generic" enum member type. > > 2. Should I have reserved members in the userspace structures? > > 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? > 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)? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel