* Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
From: Herbert Xu @ 2013-05-28 7:42 UTC (permalink / raw)
To: Joel A Fernandes; +Cc: linux-crypto, linux-omap, khilman, Mark A. Greer
In-Reply-To: <1368500867-7737-1-git-send-email-joelagnel@ti.com>
On Tue, May 14, 2013 at 03:07:47AM +0000, Joel A Fernandes wrote:
> 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 runtime PM API
> is also called those many times.
>
> We call runtime_pm_get_sync only at beginning on the session (cra_init)
> and runtime_pm_put at the end. This result in upto a 50% speedup as below.
> This doesn't make the driver to keep the system awake as runtime get/put
> is only called during a crypto session which completes usually quickly.
>
> Before:
> root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
> Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
> Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
> Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
> Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
> Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
>
> After:
> root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
> Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
> Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
> Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
> Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
> Doing aes-128-cbc for 3s on 8192 size blocks: 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 <joelagnel@ti.com>
I like your patch but it doesn't apply against the current cryptodev
tree.
Please rebase and repost.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] crypto: hifn_795x - fix to pass correct device identity to free_irq()
From: Wei Yongjun @ 2013-05-28 9:10 UTC (permalink / raw)
To: herbert; +Cc: yongjun_wei, linux-crypto
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
free_irq() expects the same device identity that was passed
to request_irq(), otherwise the IRQ is not freed.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/crypto/hifn_795x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index ebf130e..12fea3e 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -2676,7 +2676,7 @@ err_out_stop_device:
hifn_reset_dma(dev, 1);
hifn_stop_device(dev);
err_out_free_irq:
- free_irq(dev->irq, dev->name);
+ free_irq(dev->irq, dev);
tasklet_kill(&dev->tasklet);
err_out_free_desc:
pci_free_consistent(pdev, sizeof(struct hifn_dma),
@@ -2711,7 +2711,7 @@ static void hifn_remove(struct pci_dev *pdev)
hifn_reset_dma(dev, 1);
hifn_stop_device(dev);
- free_irq(dev->irq, dev->name);
+ free_irq(dev->irq, dev);
tasklet_kill(&dev->tasklet);
hifn_flush(dev);
^ permalink raw reply related
* Re: [PATCH 1/8] crypto: caam - fix SEQ IN PTR command when RTO or PRE bit is set
From: Herbert Xu @ 2013-05-28 9:50 UTC (permalink / raw)
To: Andrei Varvara; +Cc: linux-crypto, Kim.Phillips, AFLEMING, vakul
In-Reply-To: <1368455877-1759-1-git-send-email-andrei.varvara@freescale.com>
On Mon, May 13, 2013 at 02:37:57PM +0000, Andrei Varvara wrote:
> SEQ IN PTR command does not require pointer if RTO or PRE bit is set
> Updated desc_constr.h accordingly.
>
> Signed-off-by: Andrei Varvara <andrei.varvara@freescale.com>
> Reviewed-by: Phillips Kim-R1AAHA <Kim.Phillips@freescale.com>
> Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
All applied to cryptodev. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 1/1] crypto: Added support for Freescale's DCP co-processor
From: Herbert Xu @ 2013-05-28 9:51 UTC (permalink / raw)
To: Tobias Rauter; +Cc: David S. Miller, linux-crypto, Tobias Rauter
In-Reply-To: <1368993578-23661-1-git-send-email-tobias.rauter@gmail.com>
On Sun, May 19, 2013 at 09:59:38PM +0200, Tobias Rauter wrote:
> This patch enables the DCP crypto functionality on imx28.
> Currently, only aes-128-cbc is supported.
> Moreover, the dcpboot misc-device, which is used by Freescale's
> SDK tools and uses a non-software-readable OTP-key, is added.
>
> Changes of v2:
> - ring buffer for hardware-descriptors
> - use of ablkcipher walk
> - OTP key encryption/decryption via misc-device
> (compatible to Freescale-SDK)
> - overall cleanup
>
> The DCP is also capable of sha1/sha256 but I won't be able to add
> that anytime soon.
> Tested with built-in runtime-self-test, tcrypt and openssl via
> cryptodev 1.6 on imx28-evk and a custom built imx28-board.
>
>
> Signed-off-by: Tobias Rauter <tobias.rauter@gmail.com>
Patch applied. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: sha512_generic - set cra_driver_name
From: Herbert Xu @ 2013-05-28 9:52 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-crypto, David S. Miller
In-Reply-To: <20130521141010.16154.53640.stgit@localhost6.localdomain6>
On Tue, May 21, 2013 at 05:10:10PM +0300, Jussi Kivilinna wrote:
> 'sha512_generic' should set driver name now that there is alternative sha512
> provider (sha512_ssse3).
>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Patch applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 1/2] crypto: sha512_ssse3 - add sha384 support
From: Herbert Xu @ 2013-05-28 9:53 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-crypto, Tim Chen, David S. Miller
In-Reply-To: <20130521141044.16352.75962.stgit@localhost6.localdomain6>
On Tue, May 21, 2013 at 05:10:44PM +0300, Jussi Kivilinna wrote:
> Add sha384 implementation to sha512_ssse3 module.
>
> This also fixes sha512_ssse3 module autoloading issue when 'sha384' is used
> before 'sha512'. Previously in such case, just sha512_generic was loaded and
> not sha512_ssse3 (since it did not provide sha384). Now if 'sha512' was used
> after 'sha384' usage, sha512_ssse3 would remain unloaded. For example, this
> happens with tcrypt testing module since it tests 'sha384' before 'sha512'.
>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Signed-off-by: Jussi Kivilinna <jussi.kivilinna@iki.fi>
Both patches applied. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ux50: Cocci spatch "resource_size.spatch"
From: Herbert Xu @ 2013-05-28 9:53 UTC (permalink / raw)
To: Thomas Meyer; +Cc: davem, linux-crypto, linux-kernel
In-Reply-To: <1369251520.3865.321.camel@localhost.localdomain>
On Wed, May 22, 2013 at 09:38:40PM +0200, Thomas Meyer wrote:
>
> Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Patch applied.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Felipe Balbi @ 2013-05-28 16:27 UTC (permalink / raw)
To: Linus Walleij
Cc: Lee Jones, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Felipe Balbi,
linux-usb@vger.kernel.org, linux-crypto@vger.kernel.org,
David S. Miller, Herbert Xu, Vinod Koul, Arnd Bergmann,
Linus WALLEIJ, Srinidhi KASAGAR
In-Reply-To: <CACRpkdYjjDp+7hzGtAchyy3+5Vxc8jK5THGCETkAO_V9Hj9Ssw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]
Hi,
On Wed, May 15, 2013 at 07:18:01PM +0200, Linus Walleij wrote:
> On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
>
> > For all ux500 based platforms the maximum number of end-points are used.
> > Move this knowledge into the driver so we can relinquish the burden from
> > platform data. This also removes quite a bit of complexity from the driver
> > and will aid us when we come to enable the driver for Device Tree.
> >
> > Cc: Felipe Balbi <balbi@ti.com>
> > Cc: linux-usb@vger.kernel.org
> > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > Acked-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> I guess this stuff is dependent on the stuff Fabio has recently sent to
> Felipe for the ux500 musb DMA so these musb patches should
> primarily go through his tree.
>
> It seems like the later changes to the platform code
> (arch/arm/mach-ux500) may be sufficiently orthogonal
> so it can be done out-of-order?
>
> I can't merge any of this without Felipes ACKs in any
> case.
Do you want to take this yourself ? I haven't fully read the series yet,
but seems like this depends on the rest of the series. If you want to
take it, let me know I can ack the patches as soon as I'm done
reviewing.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Lee Jones @ 2013-05-28 16:48 UTC (permalink / raw)
To: Felipe Balbi
Cc: Linus Walleij, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-crypto@vger.kernel.org, David S. Miller, Herbert Xu,
Vinod Koul, Arnd Bergmann, Linus WALLEIJ, Srinidhi KASAGAR
In-Reply-To: <20130528162715.GB28253@arwen.pp.htv.fi>
Hi Felipe
> > > For all ux500 based platforms the maximum number of end-points are used.
> > > Move this knowledge into the driver so we can relinquish the burden from
> > > platform data. This also removes quite a bit of complexity from the driver
> > > and will aid us when we come to enable the driver for Device Tree.
> > >
> > > Cc: Felipe Balbi <balbi@ti.com>
> > > Cc: linux-usb@vger.kernel.org
> > > Acked-by: Linus Walleij <linus.walleij@linaro.org>
> > > Acked-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >
> > I guess this stuff is dependent on the stuff Fabio has recently sent to
> > Felipe for the ux500 musb DMA so these musb patches should
> > primarily go through his tree.
> >
> > It seems like the later changes to the platform code
> > (arch/arm/mach-ux500) may be sufficiently orthogonal
> > so it can be done out-of-order?
> >
> > I can't merge any of this without Felipes ACKs in any
> > case.
>
> Do you want to take this yourself ? I haven't fully read the series yet,
> but seems like this depends on the rest of the series. If you want to
> take it, let me know I can ack the patches as soon as I'm done
> reviewing.
Yes that would be ideal, if you wouldn't mind.
Kind regards,
Lee
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
From: Joel A Fernandes @ 2013-05-29 0:02 UTC (permalink / raw)
To: linux-crypto, linux-omap; +Cc: Herbert Xu, Joel A Fernandes
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 runtime PM API
is also called those many times.
We call runtime_pm_get_sync only at beginning on the session (cra_init)
and runtime_pm_put at the end. This result in upto a 50% speedup as below.
This doesn't make the driver to keep the system awake as runtime get/put
is only called during a crypto session which completes usually quickly.
Before:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
After:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
Doing aes-128-cbc for 3s on 8192 size blocks: 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.
v3 changes:
Refreshed patch on kernel v3.10-rc3
Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
---
drivers/crypto/omap-aes.c | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ee15b0f..06524a0 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -203,13 +203,6 @@ static void omap_aes_write_n(struct omap_aes_dev *dd, u32 offset,
static int omap_aes_hw_init(struct omap_aes_dev *dd)
{
- /*
- * clocks are enabled when request starts and disabled when finished.
- * It may be long delays between requests.
- * Device might go to off mode to save power.
- */
- pm_runtime_get_sync(dd->dev);
-
if (!(dd->flags & FLAGS_INIT)) {
dd->flags |= FLAGS_INIT;
dd->err = 0;
@@ -636,7 +629,6 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err)
pr_debug("err: %d\n", err);
- pm_runtime_put(dd->dev);
dd->flags &= ~FLAGS_BUSY;
req->base.complete(&req->base, err);
@@ -837,8 +829,16 @@ static int omap_aes_ctr_decrypt(struct ablkcipher_request *req)
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
- pr_debug("enter\n");
+ struct omap_aes_dev *dd = NULL;
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(&list_lock);
+ list_for_each_entry(dd, &dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(&list_lock);
+
+ pm_runtime_get_sync(dd->dev);
tfm->crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
return 0;
@@ -846,7 +846,16 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
- pr_debug("enter\n");
+ struct omap_aes_dev *dd = NULL;
+
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(&list_lock);
+ list_for_each_entry(dd, &dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(&list_lock);
+
+ pm_runtime_put_sync(dd->dev);
}
/* ********************** ALGS ************************************ */
--
1.7.4.1
^ permalink raw reply related
* [PATCH 1/4] crypto: dcp: Remove redundant platform_set_drvdata()
From: Sachin Kamat @ 2013-05-29 11:39 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, tobias.rauter, sachin.kamat
Commit 0998d06310 (device-core: Ensure drvdata = NULL when no
driver is bound) removes the need to set driver data field to
NULL.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Tobias Rauter <tobias.rauter@gmail.com>
---
This series compile tested against linux-next (20130529).
---
drivers/crypto/dcp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index eea194c..83eaefc 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -876,7 +876,6 @@ static int dcp_remove(struct platform_device *pdev)
struct dcp_dev *dev;
int j;
dev = platform_get_drvdata(pdev);
- platform_set_drvdata(pdev, NULL);
dma_free_coherent(&pdev->dev,
DCP_MAX_PKG * sizeof(struct dcp_hw_packet),
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/4] crypto: dcp: Use devm_* APIs
From: Sachin Kamat @ 2013-05-29 11:39 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, tobias.rauter, sachin.kamat
In-Reply-To: <1369827552-28373-1-git-send-email-sachin.kamat@linaro.org>
devm_* APIs are device managed and make cleanup and exit
code simpler.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Tobias Rauter <tobias.rauter@gmail.com>
---
drivers/crypto/dcp.c | 32 ++++++++++----------------------
1 file changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index 83eaefc..9e91c2c 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -723,12 +723,10 @@ static int dcp_probe(struct platform_device *pdev)
struct resource *r;
int i, ret, j;
- dev = kzalloc(sizeof(*dev), GFP_KERNEL);
- if (dev == NULL) {
- dev_err(&pdev->dev, "Failed to allocate structure\n");
- ret = -ENOMEM;
- goto err;
- }
+ dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
+ if (!dev)
+ return -ENOMEM;
+
global_dev = dev;
dev->dev = &pdev->dev;
@@ -737,11 +735,10 @@ static int dcp_probe(struct platform_device *pdev)
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!r) {
dev_err(&pdev->dev, "failed to get IORESOURCE_MEM\n");
- ret = -ENXIO;
- goto err_dev;
+ return -ENXIO;
}
- dev->dcp_regs_base = ioremap(r->start, resource_size(r));
-
+ dev->dcp_regs_base = devm_ioremap(&pdev->dev, r->start,
+ resource_size(r));
dcp_set(dev, DCP_CTRL_SFRST, DCP_REG_CTRL);
udelay(10);
@@ -762,15 +759,13 @@ static int dcp_probe(struct platform_device *pdev)
r = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!r) {
dev_err(&pdev->dev, "can't get IRQ resource (0)\n");
- ret = -EIO;
- goto err_unmap_mem;
+ return -EIO;
}
dev->dcp_vmi_irq = r->start;
ret = request_irq(dev->dcp_vmi_irq, dcp_vmi_irq, 0, "dcp", dev);
if (ret != 0) {
dev_err(&pdev->dev, "can't request_irq (0)\n");
- ret = -EIO;
- goto err_unmap_mem;
+ return -EIO;
}
r = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
@@ -863,11 +858,7 @@ err_free_irq1:
free_irq(dev->dcp_irq, dev);
err_free_irq0:
free_irq(dev->dcp_vmi_irq, dev);
-err_unmap_mem:
- iounmap((void *) dev->dcp_regs_base);
-err_dev:
- kfree(dev);
-err:
+
return ret;
}
@@ -890,14 +881,11 @@ static int dcp_remove(struct platform_device *pdev)
tasklet_kill(&dev->done_task);
tasklet_kill(&dev->queue_task);
- iounmap((void *) dev->dcp_regs_base);
-
for (j = 0; j < ARRAY_SIZE(algs); j++)
crypto_unregister_alg(&algs[j]);
misc_deregister(&dev->dcp_bootstream_misc);
- kfree(dev);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/4] crypto: dcp: Use NULL instead of 0
From: Sachin Kamat @ 2013-05-29 11:39 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, tobias.rauter, sachin.kamat
In-Reply-To: <1369827552-28373-1-git-send-email-sachin.kamat@linaro.org>
Use NULL instead of 0 for pointer variables.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/crypto/dcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index 9e91c2c..49dd560 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -408,7 +408,7 @@ static void dcp_done_task(unsigned long data)
ablkcipher_walk_complete(&dev->ctx->walk);
dev->ctx->req->base.complete(&dev->ctx->req->base,
dev->ctx->stat);
- dev->ctx->req = 0;
+ dev->ctx->req = NULL;
/* in case there are other requests in the queue */
tasklet_schedule(&dev->queue_task);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/4] crypto: dcp: Staticize local symbols
From: Sachin Kamat @ 2013-05-29 11:39 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, tobias.rauter, sachin.kamat
In-Reply-To: <1369827552-28373-1-git-send-email-sachin.kamat@linaro.org>
These symbols are referenced only in this file and hence
should be static.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/crypto/dcp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
index 49dd560..a8a7dd4 100644
--- a/drivers/crypto/dcp.c
+++ b/drivers/crypto/dcp.c
@@ -195,7 +195,7 @@ struct dcp_hw_packet {
uint32_t stat;
};
-struct dcp_dev *global_dev;
+static struct dcp_dev *global_dev;
static inline u32 dcp_chan_reg(u32 reg, int chan)
{
@@ -227,14 +227,14 @@ static inline unsigned int dcp_read(struct dcp_dev *dev, u32 reg)
return readl(dev->dcp_regs_base + reg);
}
-void dcp_dma_unmap(struct dcp_dev *dev, struct dcp_hw_packet *pkt)
+static void dcp_dma_unmap(struct dcp_dev *dev, struct dcp_hw_packet *pkt)
{
dma_unmap_page(dev->dev, pkt->src, pkt->size, DMA_TO_DEVICE);
dma_unmap_page(dev->dev, pkt->dst, pkt->size, DMA_FROM_DEVICE);
dev_dbg(dev->dev, "unmap packet %x", (unsigned int) pkt);
}
-int dcp_dma_map(struct dcp_dev *dev,
+static int dcp_dma_map(struct dcp_dev *dev,
struct ablkcipher_walk *walk, struct dcp_hw_packet *pkt)
{
dev_dbg(dev->dev, "map packet %x", (unsigned int) pkt);
@@ -413,7 +413,7 @@ static void dcp_done_task(unsigned long data)
tasklet_schedule(&dev->queue_task);
}
-void dcp_watchdog(unsigned long data)
+static void dcp_watchdog(unsigned long data)
{
struct dcp_dev *dev = (struct dcp_dev *)data;
dev->ctx->stat |= dcp_read(dev,
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Linus Walleij @ 2013-05-29 11:57 UTC (permalink / raw)
To: Felipe Balbi
Cc: Lee Jones,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Herbert Xu, Vinod Koul, Arnd Bergmann,
Linus WALLEIJ, Srinidhi KASAGAR
In-Reply-To: <20130528162715.GB28253-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
On Tue, May 28, 2013 at 6:27 PM, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org> wrote:
> On Wed, May 15, 2013 at 07:18:01PM +0200, Linus Walleij wrote:
>> I can't merge any of this without Felipes ACKs in any
>> case.
>
> Do you want to take this yourself ? I haven't fully read the series yet,
> but seems like this depends on the rest of the series. If you want to
> take it, let me know I can ack the patches as soon as I'm done
> reviewing.
Yes please. They are dependent on a stash of patches that that
has recently landed in the ARM SoC tree, so currently they need
to follow those through the same tree, which is where I funnel
all the ux500 stuff.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
From: Kevin Hilman @ 2013-05-29 16:39 UTC (permalink / raw)
To: Joel A Fernandes; +Cc: linux-crypto, linux-omap, Herbert Xu
In-Reply-To: <1369785775-3737-1-git-send-email-joelagnel@ti.com>
Joel A Fernandes <joelagnel@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 runtime PM API
> is also called those many times.
>
> We call runtime_pm_get_sync only at beginning on the session (cra_init)
> and runtime_pm_put at the end. This result in upto a 50% speedup as below.
> This doesn't make the driver to keep the system awake as runtime get/put
> is only called during a crypto session which completes usually quickly.
>
> Before:
> root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
> Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
> Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
> Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
> Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
> Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
>
> After:
> root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
> Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
> Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
> Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
> Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
> Doing aes-128-cbc for 3s on 8192 size blocks: 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.
>
> v3 changes:
> Refreshed patch on kernel v3.10-rc3
>
> Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
This patch had at least 2 acks (myself and Mark Greer) which you should
include when reposting.
Also, changelog says v3 but subject says v2.
Kevin
^ permalink raw reply
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Felipe Balbi @ 2013-05-29 17:57 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel, linux-kernel, balbi, linux-usb, linux-crypto,
davem, herbert, vinod.koul, arnd, linus.walleij, srinidhi.kasagar
In-Reply-To: <1368611522-9984-21-git-send-email-lee.jones@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote:
> For all ux500 based platforms the maximum number of end-points are used.
> Move this knowledge into the driver so we can relinquish the burden from
> platform data. This also removes quite a bit of complexity from the driver
> and will aid us when we come to enable the driver for Device Tree.
>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: linux-usb@vger.kernel.org
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
for drivers/usb/musb
Acked-by: Felipe Balbi <balbi@ti.com>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH v3] OMAP: AES: Don't idle/start AES device between Encrypt operations
From: Joel A Fernandes @ 2013-05-29 18:59 UTC (permalink / raw)
To: linux-crypto, linux-omap; +Cc: Mark A. Greer, Kevin Hilman, Joel A Fernandes
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 runtime PM API
is also called those many times.
We call runtime_pm_get_sync only at beginning on the session (cra_init)
and runtime_pm_put at the end. This result in upto a 50% speedup as below.
This doesn't make the driver to keep the system awake as runtime get/put
is only called during a crypto session which completes usually quickly.
Before:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
After:
root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
Doing aes-128-cbc for 3s on 8192 size blocks: 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.
v2 changes:
Refreshed patch on kernel v3.10-rc3
v3 changes:
Included Acks in commit message
Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Acked-by: Mark A. Greer <mgreer@animalcreek.com>
---
drivers/crypto/omap-aes.c | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index ee15b0f..06524a0 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -203,13 +203,6 @@ static void omap_aes_write_n(struct omap_aes_dev *dd, u32 offset,
static int omap_aes_hw_init(struct omap_aes_dev *dd)
{
- /*
- * clocks are enabled when request starts and disabled when finished.
- * It may be long delays between requests.
- * Device might go to off mode to save power.
- */
- pm_runtime_get_sync(dd->dev);
-
if (!(dd->flags & FLAGS_INIT)) {
dd->flags |= FLAGS_INIT;
dd->err = 0;
@@ -636,7 +629,6 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err)
pr_debug("err: %d\n", err);
- pm_runtime_put(dd->dev);
dd->flags &= ~FLAGS_BUSY;
req->base.complete(&req->base, err);
@@ -837,8 +829,16 @@ static int omap_aes_ctr_decrypt(struct ablkcipher_request *req)
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
- pr_debug("enter\n");
+ struct omap_aes_dev *dd = NULL;
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(&list_lock);
+ list_for_each_entry(dd, &dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(&list_lock);
+
+ pm_runtime_get_sync(dd->dev);
tfm->crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
return 0;
@@ -846,7 +846,16 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
- pr_debug("enter\n");
+ struct omap_aes_dev *dd = NULL;
+
+ /* Find AES device, currently picks the first device */
+ spin_lock_bh(&list_lock);
+ list_for_each_entry(dd, &dev_list, list) {
+ break;
+ }
+ spin_unlock_bh(&list_lock);
+
+ pm_runtime_put_sync(dd->dev);
}
/* ********************** ALGS ************************************ */
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v3] OMAP: AES: Don't idle/start AES device between Encrypt operations
From: Santosh Shilimkar @ 2013-05-29 19:05 UTC (permalink / raw)
To: Joel A Fernandes; +Cc: linux-crypto, linux-omap, Mark A. Greer, Kevin Hilman
In-Reply-To: <1369853986-3970-1-git-send-email-joelagnel@ti.com>
On Wednesday 29 May 2013 02:59 PM, Joel A Fernandes wrote:
> 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 runtime PM API
> is also called those many times.
>
> We call runtime_pm_get_sync only at beginning on the session (cra_init)
> and runtime_pm_put at the end. This result in upto a 50% speedup as below.
> This doesn't make the driver to keep the system awake as runtime get/put
> is only called during a crypto session which completes usually quickly.
>
Nice !!
> Before:
> root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
> Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
> Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
> Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
> Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
> Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
>
> After:
> root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
> Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
> Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
> Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
> Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
> Doing aes-128-cbc for 3s on 8192 size blocks: 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.
>
> v2 changes:
> Refreshed patch on kernel v3.10-rc3
> v3 changes:
> Included Acks in commit message
>
> Signed-off-by: Joel A Fernandes <joelagnel@ti.com>
> Acked-by: Kevin Hilman <khilman@linaro.org>
> Acked-by: Mark A. Greer <mgreer@animalcreek.com>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
^ permalink raw reply
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Linus Walleij @ 2013-05-30 7:44 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Felipe Balbi,
linux-usb@vger.kernel.org, linux-crypto@vger.kernel.org,
David S. Miller, Herbert Xu, Vinod Koul, Arnd Bergmann,
Linus WALLEIJ, Srinidhi KASAGAR
In-Reply-To: <1368611522-9984-21-git-send-email-lee.jones@linaro.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
> For all ux500 based platforms the maximum number of end-points are used.
> Move this knowledge into the driver so we can relinquish the burden from
> platform data. This also removes quite a bit of complexity from the driver
> and will aid us when we come to enable the driver for Device Tree.
>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: linux-usb@vger.kernel.org
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Patch applied to my dma40 branch with Felipe's ACK.
Thanks!
Linus Walleij
^ permalink raw reply
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Linus Walleij @ 2013-05-30 7:48 UTC (permalink / raw)
To: Felipe Balbi
Cc: Lee Jones, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-crypto@vger.kernel.org, David S. Miller, Herbert Xu,
Vinod Koul, Arnd Bergmann, Linus WALLEIJ, Srinidhi KASAGAR
In-Reply-To: <20130529175741.GG21290@arwen.pp.htv.fi>
On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi <balbi@ti.com> wrote:
> On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote:
>> For all ux500 based platforms the maximum number of end-points are used.
>> Move this knowledge into the driver so we can relinquish the burden from
>> platform data. This also removes quite a bit of complexity from the driver
>> and will aid us when we come to enable the driver for Device Tree.
>>
>> Cc: Felipe Balbi <balbi@ti.com>
>> Cc: linux-usb@vger.kernel.org
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> Acked-by: Fabio Baltieri <fabio.baltieri@linaro.org>
>> Signed-off-by: Lee Jones <lee.jones@linaro.org>
>
> for drivers/usb/musb
>
> Acked-by: Felipe Balbi <balbi@ti.com>
Is that only for this patch 20/39 or also 21, 22 & 23?
Poke us if we should re-send them...
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Lee Jones @ 2013-05-30 8:12 UTC (permalink / raw)
To: Linus Walleij
Cc: Felipe Balbi, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-crypto@vger.kernel.org, David S. Miller, Herbert Xu,
Vinod Koul, Arnd Bergmann, Linus WALLEIJ, Srinidhi KASAGAR
In-Reply-To: <CACRpkda3d9_XvqRmy0nbWyri2xC3Qst2U2Sv=UDxV4w-UxK_JQ@mail.gmail.com>
On Thu, 30 May 2013, Linus Walleij wrote:
> On Wed, May 29, 2013 at 7:57 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Wed, May 15, 2013 at 10:51:43AM +0100, Lee Jones wrote:
> >> For all ux500 based platforms the maximum number of end-points are used.
> >> Move this knowledge into the driver so we can relinquish the burden from
> >> platform data. This also removes quite a bit of complexity from the driver
> >> and will aid us when we come to enable the driver for Device Tree.
> >>
> >> Cc: Felipe Balbi <balbi@ti.com>
> >> Cc: linux-usb@vger.kernel.org
> >> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >> Acked-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> >> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >
> > for drivers/usb/musb
> >
> > Acked-by: Felipe Balbi <balbi@ti.com>
>
> Is that only for this patch 20/39 or also 21, 22 & 23?
>
> Poke us if we should re-send them...
I read this as all patches in the series "for drivers/usb/musb".
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 21/39] usb: musb: ux500: move the MUSB HDRC configuration into the driver
From: Linus Walleij @ 2013-05-30 8:30 UTC (permalink / raw)
To: Lee Jones
Cc: Herbert Xu, Arnd Bergmann, Srinidhi KASAGAR, Vinod Koul,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
Felipe Balbi, linux-crypto@vger.kernel.org, David S. Miller,
linux-arm-kernel@lists.infradead.org, Linus WALLEIJ
In-Reply-To: <1368611522-9984-22-git-send-email-lee.jones@linaro.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
> The MUSB HDRC configuration never changes between each of the ux500
> supported platforms, so there's little point passing it though platform
> data. If we set it in the driver instead, we can make good use of it
> when booting with either ATAGs or Device Tree.
>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: linux-usb@vger.kernel.org
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Tentatively applied with Felipe's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 22/39] usb: musb: ux500: take the dma_mask from coherent_dma_mask
From: Linus Walleij @ 2013-05-30 8:32 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Felipe Balbi,
linux-usb@vger.kernel.org, linux-crypto@vger.kernel.org,
David S. Miller, Herbert Xu, Vinod Koul, Arnd Bergmann,
Linus WALLEIJ, Srinidhi KASAGAR
In-Reply-To: <1368611522-9984-23-git-send-email-lee.jones@linaro.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
> The dma_mask will always be the same as the coherent_dma_mask, so let's
> cut down on the platform_data burden and set it as such in the driver.
> This also saves us from supporting it separately when we come to enable
> this driver for Device Tree.
>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: linux-usb@vger.kernel.org
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Acked-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Tentatively applied with Felipe's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 23/39] usb: musb: ux500: harden checks for platform data
From: Linus Walleij @ 2013-05-30 8:34 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Felipe Balbi, linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David S. Miller, Herbert Xu, Vinod Koul, Arnd Bergmann,
Linus WALLEIJ, Srinidhi KASAGAR
In-Reply-To: <1368611522-9984-24-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> In its current state, the ux500-musb driver uses platform data pointers
> blindly with no prior checking. If no platform data pointer is passed
> this will Oops the kernel. In this patch we ensure platform data and
> board data are present prior to using them.
>
> Cc: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
> Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Acked-by: Fabio Baltieri <fabio.baltieri-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Tentatively applied with Felipe's ACK.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox