Re: [PATCH 07/12] hwrng: bcm2835-rng: Manage an optional clock

> The clk API outside of DT doesn't have knowledge of when it's "complete" > to be able to determine whether the clock is not present or temporarily > missing. I've already NAK'd this suggestion. Hi Russell O.K, yes, makes sense. We do have of_clk_get_by_name() and of_clk_get(). Would optional

Re: [PATCH 07/12] hwrng: bcm2835-rng: Manage an optional clock

Hi Florian > > >> +/* Clock is optional on most platforms */ > > >> +priv->clk = devm_clk_get(dev, NULL); > > >> +if (IS_ERR(priv->clk)) > > >> +priv->clk = NULL; > > > > > > at least in case of EPROBE_DEFERED this isn't the expected behavior. > > > Maybe

Re: [PATCH 06/10] drivers:ethernet: return -ENOMEM on allocation failure.

On Wed, Sep 13, 2017 at 01:02:15PM +0530, Allen Pais wrote: > Signed-off-by: Allen Pais > --- > drivers/net/ethernet/sun/cassini.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/sun/cassini.c >

Re: [PATCH 05/10] drivers:net: return -ENOMEM on allocation failure.

s it goes: Reviewed-by: Andrew Lunn <and...@lunn.ch> Andrew

Re: crypto: marvell/CESA: Issues with non cache-line aligned buffers

A few other things I notice when looking at this code: /* Not all platforms can gate the clock, so it is not an error if the clock does not exists. */ cp-clk = clk_get(pdev-dev, NULL); if (!IS_ERR(cp-clk)) clk_prepare_enable(cp-clk);

Re: [PATCH v3 14/16] ARM: marvell/dt: enable crypto on armada-xp-gp

On Tue, May 26, 2015 at 11:22:45AM +0200, Imre Kaloz wrote: On Tue, 26 May 2015 10:59:36 +0200, Boris Brezillon boris.brezil...@free-electrons.com wrote: snip As the crypto engine really depend on the SoC itself and not of the board, what about updating the dts of the other board using

Re: [PATCH 0/2] crypto: add new driver for Marvell CESA

On Thu, Apr 09, 2015 at 04:58:41PM +0200, Boris Brezillon wrote: Hello, This is an attempt to replace the mv_cesa driver by a new one to address some limitations of the existing driver. From a performance and CPU load point of view the most important limitation is the lack of DMA support,

Re: [PATCH 1/2] crypto: mv_cesa: remove unnecessary platform_set_drvdata()

/crypto/mv_cesa.c +++ b/drivers/crypto/mv_cesa.c @@ -1146,7 +1146,6 @@ err_unmap_reg: err: kfree(cp); cpg = NULL; - platform_set_drvdata(pdev, NULL); return ret; } Acked-by: Andrew Lunn and...@lunn.ch -- To unsubscribe from this list: send the line unsubscribe linux

[PATCH] Crypto: CESA: Add support for DT based instantiation.

Based on work by Michael Waller and Jason Cooper. Added support for getting the interrupt number and address of SRAM from DT. Signed-off-by: Andrew Lunn and...@lunn.ch --- .../devicetree/bindings/crypto/mv_cesa.txt | 20 arch/arm/boot/dts/kirkwood.dtsi

Re: [PATCH 0/2] Fixes for MV_CESA with IDMA or TDMA

Hi Cloudy I've not been following this thread too closely.. Do you have any patches you want included into mainline? Thanks Andrew -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH 0/2] Fixes for MV_CESA with IDMA or TDMA

On Mon, Jul 16, 2012 at 03:52:16PM +0200, Phil Sutter wrote: Hey Andrew, On Mon, Jul 16, 2012 at 11:32:25AM +0200, Andrew Lunn wrote: I've not been following this thread too closely.. Do you have any patches you want included into mainline? No need to fix anything mainline O.K. I

Re: [PATCH 0/2] Fixes for MV_CESA with IDMA or TDMA

I think the problem is not in mv_cesa but in flush_kernel_dcache_page(). I have proposed a fix here: http://www.spinics.net/lists/arm-kernel/msg176913.html There was a little bit of discussion on the patch, but it has not been picked up yet. Hi Simon This is core code, not an area i