From patchwork Fri Sep 16 10:08:51 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Romain Perier X-Patchwork-Id: 9335377 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 66C996077F for ; Fri, 16 Sep 2016 10:12:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 57B3A29F1C for ; Fri, 16 Sep 2016 10:12:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 4C2D429F0D; Fri, 16 Sep 2016 10:12:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DE88D29F0D for ; Fri, 16 Sep 2016 10:12:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757456AbcIPKML (ORCPT ); Fri, 16 Sep 2016 06:12:11 -0400 Received: from down.free-electrons.com ([37.187.137.238]:60847 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752117AbcIPKMJ (ORCPT ); Fri, 16 Sep 2016 06:12:09 -0400 Received: by mail.free-electrons.com (Postfix, from userid 110) id 284AA3DD; Fri, 16 Sep 2016 12:12:07 +0200 (CEST) Received: from latitudeE7470 (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.free-electrons.com (Postfix) with ESMTPSA id F0E8A1C2D; Fri, 16 Sep 2016 12:11:56 +0200 (CEST) From: Romain Perier To: dsaxena@plexity.net, mpm@selenic.com, Herbert Xu Cc: Gregory Clement , Thomas Petazzoni , Romain Perier , Nadav Haklai , Omri Itach , Shadi Ammouri , Yahuda Yitschak , Hanna Hawa , Neta Zur Hershkovits , Igal Liberman , Marcin Wojtas , linux-crypto@vger.kernel.org Subject: [PATCH v3 3/8] hwrng: omap - Switch to non-obsolete read API implementation Date: Fri, 16 Sep 2016 12:08:51 +0200 Message-Id: <20160916100856.31727-4-romain.perier@free-electrons.com> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20160916100856.31727-1-romain.perier@free-electrons.com> References: <20160916100856.31727-1-romain.perier@free-electrons.com> Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The ".data_present" and ".data_read" operations are marked as OBSOLETE in the hwrng API. We have to use the ".read" operation instead. It makes the driver simpler and moves the busy loop, that waits until enough data is generated, to the read function. We simplify this step by only checking the status of the engine, if there is data, we copy the data to the output buffer and the amout of copied data is returned to the caller, otherwise zero is returned. The hwrng core will re-call the read operation as many times as required until enough data has been copied. Signed-off-by: Romain Perier --- Changes in v3: - Re-add code for busy loop that waits until enough data is generated. When no data is available, the busy loop is tried several time until the function returns to the hw_random core and then schedule_timeout_interruptible(1) is called. in v2, schedule_timeout_interruptible(1) was called each time data was not available, which added more latency. drivers/char/hw_random/omap-rng.c | 41 ++++++++++++++++----------------------- 1 file changed, 17 insertions(+), 24 deletions(-) diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c index 01d4be2..b3f6047 100644 --- a/drivers/char/hw_random/omap-rng.c +++ b/drivers/char/hw_random/omap-rng.c @@ -140,41 +140,35 @@ static inline void omap_rng_write(struct omap_rng_dev *priv, u16 reg, __raw_writel(val, priv->base + priv->pdata->regs[reg]); } -static int omap_rng_data_present(struct hwrng *rng, int wait) + +static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max, + bool wait) { struct omap_rng_dev *priv; - int data, i; + int i, present; priv = (struct omap_rng_dev *)rng->priv; + if (max < priv->pdata->data_size) + return 0; + for (i = 0; i < 20; i++) { - data = priv->pdata->data_present(priv); - if (data || !wait) + present = priv->pdata->data_present(priv); + if (present || !wait) break; - /* RNG produces data fast enough (2+ MBit/sec, even - * during "rngtest" loads, that these delays don't - * seem to trigger. We *could* use the RNG IRQ, but - * that'd be higher overhead ... so why bother? - */ + udelay(10); } - return data; -} - -static int omap_rng_data_read(struct hwrng *rng, u32 *data) -{ - struct omap_rng_dev *priv; - u32 data_size, i; - - priv = (struct omap_rng_dev *)rng->priv; - data_size = priv->pdata->data_size; + if (!present) + return 0; - for (i = 0; i < data_size / sizeof(u32); i++) - data[i] = omap_rng_read(priv, RNG_OUTPUT_L_REG + i); + memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_L_REG], + priv->pdata->data_size); if (priv->pdata->regs[RNG_INTACK_REG]) omap_rng_write(priv, RNG_INTACK_REG, RNG_REG_INTACK_RDY_MASK); - return data_size; + + return priv->pdata->data_size; } static int omap_rng_init(struct hwrng *rng) @@ -195,8 +189,7 @@ static void omap_rng_cleanup(struct hwrng *rng) static struct hwrng omap_rng_ops = { .name = "omap", - .data_present = omap_rng_data_present, - .data_read = omap_rng_data_read, + .read = omap_rng_do_read, .init = omap_rng_init, .cleanup = omap_rng_cleanup, };