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=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 E98FEC433E0 for ; Thu, 21 Jan 2021 08:12:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A44152396D for ; Thu, 21 Jan 2021 08:12:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725933AbhAUILy (ORCPT ); Thu, 21 Jan 2021 03:11:54 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727697AbhAUIEC (ORCPT ); Thu, 21 Jan 2021 03:04:02 -0500 Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3AD4DC061575; Thu, 21 Jan 2021 00:03:22 -0800 (PST) Received: by mail-pj1-x1032.google.com with SMTP id lw17so4458106pjb.0; Thu, 21 Jan 2021 00:03:22 -0800 (PST) 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=bh13r2wHvQbcitjyvM1dQ9PJDj0Nb/62/ozD/OJPFnA=; b=Bdu4BJfoYHZa4/6zPvES1e1NpE5Sa3X+5Fe7dt+Cx3g86HHp9Gl6FzC0GqiQmO2jIz QT2kbaKRn6fWOyy2VBpXKwUjYjyMwjjhHTKaX1lZwTIOaUFxIGUFWy6T28M9sbHOrCpJ vabrkikQoTJ7+VD/zKbIp5BtPCQdVqaMPrkAS9mIgKv2YWM/7G8I32FxdNTVggnu3F5s mfQuGiFJuXftIMTD6V6NhkPTRjWAcEGm+3kg3FzW3mRHCH8GN9ebpdiUJ3cA+oR+0XSJ ixiTF9Z8Bj9Xgkpxp5kEINNzqFU3ox19YrltS/4om9cAx2XiBPhyklOqEJAFuDtPhoJk YBtA== 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=bh13r2wHvQbcitjyvM1dQ9PJDj0Nb/62/ozD/OJPFnA=; b=nL6Uxqv8KRYXjC5Uxyc9OxkmiZ+ArOcKp3t+7Kpg5/JnF4tyjaSi7FWErMMoHGkorc /xXjvTgjHa2UCm5vMLL62TJ9DP79sf7tsSSJsAQ+g+L4PT6llY788yy/h/FgqBPgFuVr b0idtaKqXbW77LzJ2x96amZNwdBflE/pfYScTBVuqXHqYM/hN1FCT7Gqn1ckG29mzXS2 7XdSLVYebEA7s5Z0q6dxvE0tm44O2yDH7yDNniAE8LQiK3Y0w7kLDreoTCB30oOGeyIc ybJgdoFrWXzmpKr0YdqVG2E66M5EXyY1v+G0X/GzJh1zs8xdHwTqJ5/vVoZejDScsKDh WDqw== X-Gm-Message-State: AOAM531KJRLa+J6I04n/s+WY9UJ4WsKIiqtHEsl3QutH59SJ1KQneu0Q uC+5U1SXc+LZ0tbHACShCrw= X-Google-Smtp-Source: ABdhPJzsjty/5oIGiORbLq3cGorBJfWIykd6mkaKqPfqopL6VBY51ktcbHb+u9QCiIF9PohiE7B5KA== X-Received: by 2002:a17:90b:17c7:: with SMTP id me7mr10338364pjb.205.1611216201618; Thu, 21 Jan 2021 00:03:21 -0800 (PST) Received: from shinobu (113x33x126x33.ap113.ftth.ucom.ne.jp. [113.33.126.33]) by smtp.gmail.com with ESMTPSA id t8sm4676775pjm.45.2021.01.21.00.03.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jan 2021 00:03:20 -0800 (PST) Date: Thu, 21 Jan 2021 17:03:11 +0900 From: William Breathitt Gray To: Oleksij Rempel Cc: jic23@kernel.org, kamel.bouhara@bootlin.com, gwendal@chromium.org, a.fatoum@pengutronix.de, david@lechnology.com, linux-iio@vger.kernel.org, patrick.havelange@essensium.com, alexandre.belloni@bootlin.com, mcoquelin.stm32@gmail.com, linux-kernel@vger.kernel.org, Dan Carpenter , kernel@pengutronix.de, fabrice.gasnier@st.com, syednwaris@gmail.com, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, alexandre.torgue@st.com, David Jander Subject: Re: [PATCH v6 3/5] counter: Add character device interface Message-ID: References: <20210119092022.GA14502@pengutronix.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7JoiEQsXQ7A8iDp7" Content-Disposition: inline In-Reply-To: <20210119092022.GA14502@pengutronix.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --7JoiEQsXQ7A8iDp7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 19, 2021 at 10:20:22AM +0100, Oleksij Rempel wrote: > On Sun, Nov 22, 2020 at 03:29:54PM -0500, William Breathitt Gray wrote: > > This patch introduces a character device interface for the Counter > > subsystem. Device data is exposed through standard character device read > > operations. Device data is gathered when a Counter event is pushed by > > the respective Counter device driver. Configuration is handled via ioctl > > operations on the respective Counter character device node. > >=20 > > Cc: David Lechner > > Cc: Gwendal Grignou > > Cc: Dan Carpenter > > Signed-off-by: William Breathitt Gray > > --- >=20 > Hello William, >=20 > the series looks quite interesting, we have some thoughts... see below: >=20 > [...] > > +/** > > + * counter_push_event - queue event for userspace reading > > + * @counter: pointer to Counter structure > > + * @event: triggered event > > + * @channel: event channel > > + * > > + * Note: If no one is watching for the respective event, it is silently > > + * discarded. > > + * > > + * RETURNS: > > + * 0 on success, negative error number on failure. > > + */ > > +int counter_push_event(struct counter_device *const counter, const u8 = event, > > + const u8 channel) > > +{ > > + struct counter_event ev =3D {0}; > > + unsigned int copied =3D 0; > > + unsigned long flags; > > + struct counter_event_node *event_node; > > + struct counter_comp_node *comp_node; > > + int err =3D 0; > > + > > + ev.timestamp =3D ktime_get_ns(); > > + ev.watch.event =3D event; > > + ev.watch.channel =3D channel; > > + > > + raw_spin_lock_irqsave(&counter->events_lock, flags); > > + > > + /* Search for event in the list */ > > + list_for_each_entry(event_node, &counter->events_list, l) > > + if (event_node->event =3D=3D event && > > + event_node->channel =3D=3D channel) > > + break; > > + > > + /* If event is not in the list */ > > + if (&event_node->l =3D=3D &counter->events_list) > > + goto exit_early; > > + > > + /* Read and queue relevant comp for userspace */ > > + list_for_each_entry(comp_node, &event_node->comp_list, l) { > > + err =3D counter_get_data(counter, comp_node, &ev.value); > > + if (err) > > + goto exit_early; > > + > > + ev.watch.component =3D comp_node->component; > > + > > + copied +=3D kfifo_put(&counter->events, ev); >=20 > We want to calculate the frequency of some IRQ pulses in user space and > counter values with time stamps really fits well here. As the pulses are > from a physical system (rotating wheel), they will only change at a > certain rate. We want to have the possibility to read from the counter > device less often, we intentionally want to skip (meaning miss) > events. >=20 > When reading we're interested in the newest events. The kfifo implements > a "tail" drop FIFO, which means new values are added at the end, and if > the FIFO is full, they are dropped. We need a "head" drop FIFO which > discards the oldest events, keeping only the recent ones. >=20 > As far as we know, kfifo doesn't offer a head drop mode, but I think > this can be added. I'm not sure if kfifo has this kind of mode, but it seems like something that should be there if it is not already -- I imagine this kind of operation mode would be pretty common. Perhaps someone knows how to achieve this and will share here. >=20 > [...] >=20 > > struct counter_device { > > const char *name; > > @@ -270,12 +270,20 @@ struct counter_device { > > =20 > > int id; > > struct device dev; > > + struct cdev chrdev; > > + raw_spinlock_t events_lock; > > + struct list_head events_list; > > + struct list_head next_events_list; > > + DECLARE_KFIFO(events, struct counter_event, 64); >=20 > Do you plan to make the size of the FIFO configurable? >=20 > regards, > Oleksij & Marc I suppose it wouldn't be a problem to make this a configurable setting; I think I can implement this via kfifo_alloc() and kfifo_free(). How would users control this -- maybe using a sysfs attribute? William Breathitt Gray --7JoiEQsXQ7A8iDp7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAmAJNTMACgkQhvpINdm7 VJIpoBAAn3DpItFgzN5v2hJbI28XhzwT7nzB7h8JHE3jm6IQ9i4QmOhWY0lE7ZQT 334CjFwj2/BrXrQiC4v1l4tVIUjbcGQyk+watPXOIqSG1jPaqR3cwqAGb8ekPJcn /EJg8+ytI4idmiX76ilGlG59O+3Imm5lhlRX6xEqYTNeFDUUGwcD9nMFsRzSZPA4 SDVqe6Jvke0oCYiW8a3HIqki+bdyBauMF10EbAd51ZECrIVK2IHukAIQ6bea2tVN 41Uwr4yIoUnUonwPvrK4h2U+CZVHMty+Z6AxamFj8D1Ltm/hEOZunrElYfOKS9Rw XdVvSElGkhyrNdwFfr+p4hpsEX7ingZkpZrdxZQeXbgF8AVO+FzuAaFXJIPMlzjw mYL2HT2ClAPJNuF7IRi/sQWAYcrcNpRl9/JPfzfSz+6GpEME/xGv7c5aYKN+K+NL gMrLLT92TGmxmR8z5P9aPL9kULTq7ZqMi+C2OK0c6ufdzX5jPpDYKe+fBv56EDDr Sfbcd57tHK3HqILXx2cNvBLGP87Xt+FLFktXZXYyuNIA5zmhiIuovs7zkqDIwjJC pjgF5MQAWQa2Z26gboCp3opTZYaTHEfoDG1tMqZg0I8WatAxJ3HglbgwZLJ8Er3P 0t18drOAHEhuafYYiASZ1JQcuX9NNz7tA+wBLbhJm6QGsUcYK3Y= =841n -----END PGP SIGNATURE----- --7JoiEQsXQ7A8iDp7-- 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=-10.7 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 EBA88C433DB for ; Thu, 21 Jan 2021 08:05:20 +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 937A5238E2 for ; Thu, 21 Jan 2021 08:05:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 937A5238E2 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=6gP3t0JxPvdbyhFOBO5EgJfBII4YNXldgIbXMmjvBIY=; b=P/OHkepDO2Cv3Hd8SqnNaUkcN Zcu5n3UMSwvYHHjsbvHnmLaHJJBDLSnFE+KWiHw1U7nfTuU6c930eSjhxd3HDeP8sTAVcnG9z3Gum HiT/FsHM1W6kCGuro/JToqd0zPAbmIUuSCgy6QAbnBORCraxcHApqkTBjW6Fu5uU2hj+8aM5Yehsn k0C3SeV9EH89UvouW1Cz9epQpDi/M0M/LPOG8BL74teFsARfyb3STCYXkQeBg4n5/qkEKyPguXk54 9hC4Fc4MML/YGEwLu2RTWTUxvvFDWT0HEWOvo0OrSMBlfH+1hsepoCz4cxVQNDuVo/YBNXvEqxRrN KMFUnuzBQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2UwD-0000Zu-9z; Thu, 21 Jan 2021 08:03:29 +0000 Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2UwA-0000Ys-GO for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 08:03:27 +0000 Received: by mail-pj1-x102c.google.com with SMTP id kx7so1129206pjb.2 for ; Thu, 21 Jan 2021 00:03:23 -0800 (PST) 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=bh13r2wHvQbcitjyvM1dQ9PJDj0Nb/62/ozD/OJPFnA=; b=Bdu4BJfoYHZa4/6zPvES1e1NpE5Sa3X+5Fe7dt+Cx3g86HHp9Gl6FzC0GqiQmO2jIz QT2kbaKRn6fWOyy2VBpXKwUjYjyMwjjhHTKaX1lZwTIOaUFxIGUFWy6T28M9sbHOrCpJ vabrkikQoTJ7+VD/zKbIp5BtPCQdVqaMPrkAS9mIgKv2YWM/7G8I32FxdNTVggnu3F5s mfQuGiFJuXftIMTD6V6NhkPTRjWAcEGm+3kg3FzW3mRHCH8GN9ebpdiUJ3cA+oR+0XSJ ixiTF9Z8Bj9Xgkpxp5kEINNzqFU3ox19YrltS/4om9cAx2XiBPhyklOqEJAFuDtPhoJk YBtA== 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=bh13r2wHvQbcitjyvM1dQ9PJDj0Nb/62/ozD/OJPFnA=; b=no/5mZYjAvBcusZEUorxN3QtgY3T9NEHcLKMaEYIl7Y7IyvtVMDqmafbWdW4Jy19J0 EfhK6Vh4LfUDN9DlZXU4UGtrMK8GOYb6Xenu+JtUc/5Fmc40fteHPcfnqslk9f1knci6 Bazdyqswii7GVh58V9TQ2Bi51Edir49uSy6UnRqe5blfOkY+Irn0JHT+qYjGlGeyxrQy SfPF536OBVw8VSbxbQf2ynrnr++lPfbWCbuUQZ+kp5g+zcKHNH2NQ1fA/RrH9C5os2Kg mZ160ww/wDP79i0LKHlnpOPp7Ikyv2XqPdO1RMszG+xq5ztFQiVoDHbt+d4N/ADhTTUa e0mQ== X-Gm-Message-State: AOAM531LDWuUbZKDyStri4CpX7O4Drgf1RvSkZMmd6MkZL3Eupco/Acl ZhBR4chjTa7r+jM4fsBpnMw= X-Google-Smtp-Source: ABdhPJzsjty/5oIGiORbLq3cGorBJfWIykd6mkaKqPfqopL6VBY51ktcbHb+u9QCiIF9PohiE7B5KA== X-Received: by 2002:a17:90b:17c7:: with SMTP id me7mr10338364pjb.205.1611216201618; Thu, 21 Jan 2021 00:03:21 -0800 (PST) Received: from shinobu (113x33x126x33.ap113.ftth.ucom.ne.jp. [113.33.126.33]) by smtp.gmail.com with ESMTPSA id t8sm4676775pjm.45.2021.01.21.00.03.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Jan 2021 00:03:20 -0800 (PST) Date: Thu, 21 Jan 2021 17:03:11 +0900 From: William Breathitt Gray To: Oleksij Rempel Subject: Re: [PATCH v6 3/5] counter: Add character device interface Message-ID: References: <20210119092022.GA14502@pengutronix.de> MIME-Version: 1.0 In-Reply-To: <20210119092022.GA14502@pengutronix.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_030326_583158_5978485F X-CRM114-Status: GOOD ( 33.07 ) 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: linux-arm-kernel@lists.infradead.org, kamel.bouhara@bootlin.com, gwendal@chromium.org, a.fatoum@pengutronix.de, david@lechnology.com, linux-iio@vger.kernel.org, patrick.havelange@essensium.com, linux-stm32@st-md-mailman.stormreply.com, alexandre.belloni@bootlin.com, linux-kernel@vger.kernel.org, Dan Carpenter , mcoquelin.stm32@gmail.com, David Jander , fabrice.gasnier@st.com, syednwaris@gmail.com, kernel@pengutronix.de, jic23@kernel.org, alexandre.torgue@st.com Content-Type: multipart/mixed; boundary="===============3370802927681431843==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============3370802927681431843== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7JoiEQsXQ7A8iDp7" Content-Disposition: inline --7JoiEQsXQ7A8iDp7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 19, 2021 at 10:20:22AM +0100, Oleksij Rempel wrote: > On Sun, Nov 22, 2020 at 03:29:54PM -0500, William Breathitt Gray wrote: > > This patch introduces a character device interface for the Counter > > subsystem. Device data is exposed through standard character device read > > operations. Device data is gathered when a Counter event is pushed by > > the respective Counter device driver. Configuration is handled via ioctl > > operations on the respective Counter character device node. > >=20 > > Cc: David Lechner > > Cc: Gwendal Grignou > > Cc: Dan Carpenter > > Signed-off-by: William Breathitt Gray > > --- >=20 > Hello William, >=20 > the series looks quite interesting, we have some thoughts... see below: >=20 > [...] > > +/** > > + * counter_push_event - queue event for userspace reading > > + * @counter: pointer to Counter structure > > + * @event: triggered event > > + * @channel: event channel > > + * > > + * Note: If no one is watching for the respective event, it is silently > > + * discarded. > > + * > > + * RETURNS: > > + * 0 on success, negative error number on failure. > > + */ > > +int counter_push_event(struct counter_device *const counter, const u8 = event, > > + const u8 channel) > > +{ > > + struct counter_event ev =3D {0}; > > + unsigned int copied =3D 0; > > + unsigned long flags; > > + struct counter_event_node *event_node; > > + struct counter_comp_node *comp_node; > > + int err =3D 0; > > + > > + ev.timestamp =3D ktime_get_ns(); > > + ev.watch.event =3D event; > > + ev.watch.channel =3D channel; > > + > > + raw_spin_lock_irqsave(&counter->events_lock, flags); > > + > > + /* Search for event in the list */ > > + list_for_each_entry(event_node, &counter->events_list, l) > > + if (event_node->event =3D=3D event && > > + event_node->channel =3D=3D channel) > > + break; > > + > > + /* If event is not in the list */ > > + if (&event_node->l =3D=3D &counter->events_list) > > + goto exit_early; > > + > > + /* Read and queue relevant comp for userspace */ > > + list_for_each_entry(comp_node, &event_node->comp_list, l) { > > + err =3D counter_get_data(counter, comp_node, &ev.value); > > + if (err) > > + goto exit_early; > > + > > + ev.watch.component =3D comp_node->component; > > + > > + copied +=3D kfifo_put(&counter->events, ev); >=20 > We want to calculate the frequency of some IRQ pulses in user space and > counter values with time stamps really fits well here. As the pulses are > from a physical system (rotating wheel), they will only change at a > certain rate. We want to have the possibility to read from the counter > device less often, we intentionally want to skip (meaning miss) > events. >=20 > When reading we're interested in the newest events. The kfifo implements > a "tail" drop FIFO, which means new values are added at the end, and if > the FIFO is full, they are dropped. We need a "head" drop FIFO which > discards the oldest events, keeping only the recent ones. >=20 > As far as we know, kfifo doesn't offer a head drop mode, but I think > this can be added. I'm not sure if kfifo has this kind of mode, but it seems like something that should be there if it is not already -- I imagine this kind of operation mode would be pretty common. Perhaps someone knows how to achieve this and will share here. >=20 > [...] >=20 > > struct counter_device { > > const char *name; > > @@ -270,12 +270,20 @@ struct counter_device { > > =20 > > int id; > > struct device dev; > > + struct cdev chrdev; > > + raw_spinlock_t events_lock; > > + struct list_head events_list; > > + struct list_head next_events_list; > > + DECLARE_KFIFO(events, struct counter_event, 64); >=20 > Do you plan to make the size of the FIFO configurable? >=20 > regards, > Oleksij & Marc I suppose it wouldn't be a problem to make this a configurable setting; I think I can implement this via kfifo_alloc() and kfifo_free(). How would users control this -- maybe using a sysfs attribute? William Breathitt Gray --7JoiEQsXQ7A8iDp7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAmAJNTMACgkQhvpINdm7 VJIpoBAAn3DpItFgzN5v2hJbI28XhzwT7nzB7h8JHE3jm6IQ9i4QmOhWY0lE7ZQT 334CjFwj2/BrXrQiC4v1l4tVIUjbcGQyk+watPXOIqSG1jPaqR3cwqAGb8ekPJcn /EJg8+ytI4idmiX76ilGlG59O+3Imm5lhlRX6xEqYTNeFDUUGwcD9nMFsRzSZPA4 SDVqe6Jvke0oCYiW8a3HIqki+bdyBauMF10EbAd51ZECrIVK2IHukAIQ6bea2tVN 41Uwr4yIoUnUonwPvrK4h2U+CZVHMty+Z6AxamFj8D1Ltm/hEOZunrElYfOKS9Rw XdVvSElGkhyrNdwFfr+p4hpsEX7ingZkpZrdxZQeXbgF8AVO+FzuAaFXJIPMlzjw mYL2HT2ClAPJNuF7IRi/sQWAYcrcNpRl9/JPfzfSz+6GpEME/xGv7c5aYKN+K+NL gMrLLT92TGmxmR8z5P9aPL9kULTq7ZqMi+C2OK0c6ufdzX5jPpDYKe+fBv56EDDr Sfbcd57tHK3HqILXx2cNvBLGP87Xt+FLFktXZXYyuNIA5zmhiIuovs7zkqDIwjJC pjgF5MQAWQa2Z26gboCp3opTZYaTHEfoDG1tMqZg0I8WatAxJ3HglbgwZLJ8Er3P 0t18drOAHEhuafYYiASZ1JQcuX9NNz7tA+wBLbhJm6QGsUcYK3Y= =841n -----END PGP SIGNATURE----- --7JoiEQsXQ7A8iDp7-- --===============3370802927681431843== 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 --===============3370802927681431843==--