Re: [RESEND PATCH 0/2] hw_random: Add Amlogic Meson SoCs Random Generator driver

Neil Armstrong <narmstr...@baylibre.com> writes: > NOTE: This is a resent of the DT Bindings and DTSI patches based on the > Amlogic DT 64bit > GIT pull request from Kevin Hilman at [1]. > > Changes since v2 at > http://lkml.kernel.org/r/1465546915-24229-1-git-send-email

Re: [PATCH v2 0/3] hw_random: Add Amlogic Meson SoCs Random Generator driver

Hi Herbert, Herbert Xu writes: > On Fri, Jun 10, 2016 at 10:21:52AM +0200, Neil Armstrong wrote: >> Add support for the Amlogic Meson SoCs Hardware Random generator as a >> hw_random char driver. >> The generator is a single 32bit wide register. >> Also adds the

Re: [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS

since > the reported uevent MODALIAS to user-space will always be the OF one. > > Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com> Acked-by: Kevin Hilman <khil...@baylibre.com> > --- > > drivers/char/hw_random/meson-rng.c | 1 - > 1 file changed

Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0

Herbert Xu <herb...@gondor.apana.org.au> writes: > On Thu, Mar 16, 2017 at 11:24:31AM -0700, Kevin Hilman wrote: >> Hi Herbert, >> >> Herbert Xu <herb...@gondor.apana.org.au> writes: >> >> > On Wed, Feb 22, 2017 at 07:55:24AM +0100, Heiner Kal

Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0

Hi Herbert, Herbert Xu writes: > On Wed, Feb 22, 2017 at 07:55:24AM +0100, Heiner Kallweit wrote: >> Expose clock CLKID_RNG0 which is needed for the HW random number generator. >> >> Signed-off-by: Heiner Kallweit > > All patches applied.

Re: [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0

Herbert Xu <herb...@gondor.apana.org.au> writes: > On Thu, Mar 16, 2017 at 11:24:31AM -0700, Kevin Hilman wrote: >> Hi Herbert, >> >> Herbert Xu <herb...@gondor.apana.org.au> writes: >> >> > On Wed, Feb 22, 2017 at 07:55:24AM +0100, Heiner Kal

Re: [PATCH v2 5/7] crypto: omap-sham: Convert to use pm_runtime API

Hi Mark, Mark A. Greer mgr...@animalcreek.com writes: From: Mark A. Greer mgr...@animalcreek.com Convert the omap-sham crypto driver to use the pm_runtime API instead of the clk API. CC: Kevin Hilman khil...@deeprootsystems.com CC: Paul Walmsley p...@pwsan.com CC: Dmitry Kasatkin

Re: [PATCH] OMAP: AES: Don't idle/start AES device between Encrypt operations

Joel A Fernandes joelag...@ti.com writes: Calling runtime PM API for every block causes serious perf hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The

Re: [PATCH] OMAP: AES: Don't idle/start AES device between Encrypt operations

Hi Joel, Fernandes, Joel A joelag...@ti.com writes: Hi Kevin, Thanks for your review. -Original Message- From: Kevin Hilman [mailto:khil...@linaro.org] Sent: Monday, May 13, 2013 11:36 AM To: Fernandes, Joel A Cc: linux-crypto@vger.kernel.org; linux-o...@vger.kernel.org; Mark

Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations

: 4857 aes-128-cbc's in 0.03s While at it, also drop enter and exit pr_debugs, in related code. tracers can be used for that. Tested on a Beaglebone (AM335x SoC) board. Signed-off-by: Joel A Fernandes joelag...@ti.com Acked-by: Kevin Hilman khil...@linaro.org Thanks for the updated changelog

Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations

Joel A Fernandes joelag...@ti.com writes: Calling runtime PM API for every block causes serious perf hit to crypto operations that are done on a long buffer. As crypto is performed on a page boundary, encrypting large buffers can cause a series of crypto operations divided by page. The