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, URIBL_BLOCKED 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 2A2CCC388F7 for ; Sun, 25 Oct 2020 13:20:39 +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 CAAD321D41 for ; Sun, 25 Oct 2020 13:20:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JochFnQS"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="LlUxpVS1" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CAAD321D41 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=bWt6W4bs3546EnEO4driFF9pPubfCEi2j8imSsIjpqo=; b=JochFnQSzhJ9HAve7j+OpxD6J D0C8Lnzz5gH/qwHyCifewGLUCu5rgMnG7u9so5ugdYh5ff3SIWRs/62UfWcP2k3ym7/ZE+Z9swJEZ GKw3N5UkpeRM9SXZvClFK0yE1hed53KPtKV76T7dJzRKEezpQ7xo4eocS72RgVftgpDF265H5Eri4 BnXoiv4tZQq1rKvRoL/p4TzYyIjyz/mgyEfz2nmdZNb6xLjAVjcQzTZdiYem1GTYaKq7S4NPYi/pI FycfePuXQytyEEm5YJ8ZKvkinA+rAJDSutDkyA4xtOX9wy+Beo5BN85JtU047S7LRyUz4yE8SKbLT 5TXk8S0hw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kWfug-0007SY-Gq; Sun, 25 Oct 2020 13:18:22 +0000 Received: from mail-qk1-x742.google.com ([2607:f8b0:4864:20::742]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kWfua-0007Rs-IV for linux-arm-kernel@lists.infradead.org; Sun, 25 Oct 2020 13:18:20 +0000 Received: by mail-qk1-x742.google.com with SMTP id z6so5960300qkz.4 for ; Sun, 25 Oct 2020 06:18:14 -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=MO3IwgFsTuuAQb69apcANcklu+gz2Tub8fis0XXwpSs=; b=LlUxpVS1OaD+CeUBXrHMQWS+9BXnKIfgj5wmrUKZT5pL+Y/rDiYUzqZN7mkbI83bDM pO12lEGNkAYK2ITrMnQPoJUxojGxCJM9uXUJjfOPGP3olHT8+ZfFhq4g9m1UO6WUqhRq skojFLE08/yUGaP9dAdnYgCVWLYuZe8/nOtl/fyM4ycl4dwkXroiB3VWnYfaZ2iO8QzM 3zKdF4u3wMKG1JSAVnQRznN46F0cTTIU78q4NsUxbgBNYIaZ015R50+Vf1xQpeD+xbZB NnRqiHY8uCsBhaUymXn8u9VZZFwOpOsA+luVzJ6FQcKxSsfbG9R4CjzuB/kjYLN3l4L0 fL7A== 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=MO3IwgFsTuuAQb69apcANcklu+gz2Tub8fis0XXwpSs=; b=VHXlSz1s6Z8R65kHYp+lSLUZlUlJPhpx6CK2NMIhlG4mqkd2KVadTV5yiVp096+SRB 1Nj3n8WPVy0MQSQe/XkHUOnbOIb1rLJUWIoa1cA63BsN9NmgBDDbkwFxoXv/qDxJQYq1 lpaI7Vzy1H3+fl/oL9WNI6ii5vz54JOPu8YY4+AP4+VUXV35FlfVomJHULrH4fvT4/bK B6W0P/UINMJfcigpijX1ydznR8upSCy7SMOC3lDX2NdyjUtuZtPYa9wtlAWQz2uVhcbN oVu14ySvPkSIE0Vfc0tDZ9jQnFyejUg2mdMNBflELq08oRgFgksrNZc6s/Xj7FswfPns 6OIg== X-Gm-Message-State: AOAM530TO9PjcuxknNTEtBqyM5XBDqLwgXPJmhzuHQStWh9gh7siIv0Y tUxJO9YstbTGzt5NG2nOw0w= X-Google-Smtp-Source: ABdhPJyXtkIjzFGKZ/fvA7asDRtn9qRjAGXlMjQJcK/CHKeVOyeYYuoPCcNoY09Y9eflMTPcCm3SuA== X-Received: by 2002:a37:a407:: with SMTP id n7mr11745316qke.248.1603631893378; Sun, 25 Oct 2020 06:18:13 -0700 (PDT) Received: from shinobu (072-189-064-225.res.spectrum.com. [72.189.64.225]) by smtp.gmail.com with ESMTPSA id 19sm4563158qki.33.2020.10.25.06.18.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Oct 2020 06:18:12 -0700 (PDT) Date: Sun, 25 Oct 2020 09:18:09 -0400 From: William Breathitt Gray To: David Lechner Subject: Re: [PATCH v5 3/5] counter: Add character device interface Message-ID: <20201025131809.GB3458@shinobu> References: <00be1fccc672c5207f3b04fe4cc09c29e22641f4.1601170670.git.vilhelm.gray@gmail.com> <20201018165822.GE231549@shinobu> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201025_091817_692022_51391C86 X-CRM114-Status: GOOD ( 23.40 ) 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="===============0803905181402547765==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============0803905181402547765== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wzJLGUyc3ArbnUjN" Content-Disposition: inline --wzJLGUyc3ArbnUjN Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 20, 2020 at 11:06:42AM -0500, David Lechner wrote: > On 10/18/20 11:58 AM, William Breathitt Gray wrote: > > On Wed, Oct 14, 2020 at 05:40:44PM -0500, David Lechner wrote: > >> On 9/26/20 9:18 PM, William Breathitt Gray wrote: > >>> +static ssize_t counter_chrdev_read(struct file *filp, char __user *b= uf, > >>> + size_t len, loff_t *f_ps) > >>> +{ > >>> + struct counter_device *const counter =3D filp->private_data; > >>> + int err; > >>> + unsigned long flags; > >>> + unsigned int copied; > >>> + > >>> + if (len < sizeof(struct counter_event)) > >>> + return -EINVAL; > >>> + > >>> + do { > >>> + if (kfifo_is_empty(&counter->events)) { > >>> + if (filp->f_flags & O_NONBLOCK) > >>> + return -EAGAIN; > >>> + > >>> + err =3D wait_event_interruptible(counter->events_wait, > >>> + !kfifo_is_empty(&counter->events)); > >>> + if (err) > >>> + return err; > >>> + } > >>> + > >>> + raw_spin_lock_irqsave(&counter->events_lock, flags); > >>> + err =3D kfifo_to_user(&counter->events, buf, len, &copied); > >>> + raw_spin_unlock_irqrestore(&counter->events_lock, flags); > >>> + if (err) > >>> + return err; > >>> + } while (!copied); > >>> + > >>> + return copied; > >>> +} > >> > >> All other uses of kfifo_to_user() I saw use a mutex instead of spin > >> lock. I don't see a reason for disabling interrupts here. > >=20 > > The Counter character device interface is special in this case because > > counter->events could be accessed from an interrupt context. This is > > possible if counter_push_event() is called for an interrupt (as is the > > case for the 104_quad_8 driver). In this case, we can't use mutex > > because we can't sleep in an interrupt context, so our only option is to > > use spin lock. > >=20 >=20 >=20 > The way I understand it, locking is only needed for concurrent readers > and locking between reader and writer is not needed. You're right, it does say in the kfifo.h comments that with only one concurrent reader and one current write, we don't need extra locking to use these macros. Because we only have one kfifo_to_user() operating on counter->events, does that mean we don't need locking at all here for the counter_chrdev_read() function? William Breathitt Gray --wzJLGUyc3ArbnUjN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEk5I4PDJ2w1cDf/bghvpINdm7VJIFAl+VexEACgkQhvpINdm7 VJICoBAAw8HLhwVk1o7CRK0hVoeMc0fdPh59yHCvT33kbxnA92J0zxnjH+MuGVAJ kOWu3CLQ1s0+qhTGMmSfGUUCODAsN9+2IE+it0LnW1cbHw0xw7MBK0vaIkyAKNG4 T3eWQCUYGEwDFWRqSvSCIUBJlAEQPVKcgyntEdgPASaWheL4Do/iGg6QvV3KRVb2 gnzdcQO5sgN+2YVVlhoB3KoeJRVTgskq+S/9b7tw3yDxtyxMCX8huiKXsm0jHMiZ fX8pxf0ni/ht/RLcpTjX7r0n34aL8HU3Owfqkq8DGsYiQ5Jc8AdJ6OAI2hgPifpZ NzwyeFfxAtohot+GZa5RsXewEK8M0kHxnO2MyaxUTrVNZ623p6aWm3h3gNiwpuFg 2V+mDCSTPN5y0q0Bg0k6n3c7cGWnItY9/UJnNJiUg8zinEzWfM5jwcM6LAOVj5pS EEdlzXu6IFR+T16m7N2bdR1EcAyB95OFkFL0IX9oOLcXYRmWRHQIBiFoEJXitNYQ X7ZXuKQmQpNoFP6kR4oRkvT/SQlt/jXJMw745PJKOgnQnOpV0dGYt8CMZnjI350k WJzvTVmWLSq3xzuXzB7egNqDUzl3u3GZiYBU7PkzTRAmxM3ZcCcKbntbMwOshYZz NKIcZpApO1tXWlSfm3A81N+heHtPlKFgxjHqxsQPbRaWzm1h5MU= =jRkJ -----END PGP SIGNATURE----- --wzJLGUyc3ArbnUjN-- --===============0803905181402547765== 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 --===============0803905181402547765==--