* Re: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms
From: Laurentiu Tudor @ 2017-04-04 13:28 UTC (permalink / raw)
To: Michael Ellerman, Horia Geantă, Herbert Xu, Scott Wood,
Roy Pledge
Cc: Claudiu Manoil, Cristian Stoica, Dan Douglass,
linux-arm-kernel@lists.infradead.org, Vakul Garg,
linuxppc-dev@lists.ozlabs.org, David S. Miller,
Alexandru Porosanu, linux-crypto@vger.kernel.org
In-Reply-To: <87vaqkvk6c.fsf@concordia.ellerman.id.au>
Hi Michael,
Just a couple of basic things to check:
- was the dtb updated to the newest?
- is the qman node present? This should be easily visible in
/proc/device-tree/soc@ffe000000/qman@318000.
---
Best Regards, Laurentiu
On 04/04/2017 08:03 AM, Michael Ellerman wrote:
> Horia Geantă <horia.geanta@nxp.com> writes:
>
>> Add support to submit ablkcipher and authenc algorithms
>> via the QI backend:
>> -ablkcipher:
>> cbc({aes,des,des3_ede})
>> ctr(aes), rfc3686(ctr(aes))
>> xts(aes)
>> -authenc:
>> authenc(hmac(md5),cbc({aes,des,des3_ede}))
>> authenc(hmac(sha*),cbc({aes,des,des3_ede}))
>>
>> caam/qi being a new driver, let's wait some time to settle down without
>> interfering with existing caam/jr driver.
>> Accordingly, for now all caam/qi algorithms (caamalg_qi module) are
>> marked to be of lower priority than caam/jr ones (caamalg module).
>>
>> Signed-off-by: Vakul Garg <vakul.garg@nxp.com>
>> Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com>
>> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
>> ---
>> drivers/crypto/caam/Kconfig | 20 +-
>> drivers/crypto/caam/Makefile | 1 +
>> drivers/crypto/caam/caamalg.c | 9 +-
>> drivers/crypto/caam/caamalg_desc.c | 77 +-
>> drivers/crypto/caam/caamalg_desc.h | 15 +-
>> drivers/crypto/caam/caamalg_qi.c | 2387 ++++++++++++++++++++++++++++++++++++
>> drivers/crypto/caam/sg_sw_qm.h | 108 ++
>> 7 files changed, 2601 insertions(+), 16 deletions(-)
>> create mode 100644 drivers/crypto/caam/caamalg_qi.c
>> create mode 100644 drivers/crypto/caam/sg_sw_qm.h
>
>
> This appears to be blowing up my Freescale (NXP) P5020DS board:
>
> Unable to handle kernel paging request for data at address 0x00000020
> Faulting instruction address: 0xc0000000004393e4
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=24
> CoreNet Generic
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc3-compiler_gcc-4.6.3-00046-gb189817cf789 #5
> task: c0000000f70c0000 task.stack: c0000000f70c8000
> NIP: c0000000004393e4 LR: c0000000004aeba0 CTR: c0000000004fa7d8
> REGS: c0000000f70cb160 TRAP: 0300 Not tainted (4.11.0-rc3-compiler_gcc-4.6.3-00046-gb189817cf789)
> MSR: 0000000080029000 <CE,EE,ME>
> CR: 24adbe48 XER: 20000000
> DEAR: 0000000000000020 ESR: 0000000000000000 SOFTE: 1
> GPR00: c0000000006feba0 c0000000f70cb3e0 c000000000e60000 0000000000000000
> GPR04: 0000000000000001 0000000000000000 c000000000e0b290 0000000000000003
> GPR08: 0000000000000004 c000000000ea5280 0000000000000004 0000000000000004
> GPR12: 0000000088adbe22 c00000003fff5000 c000000000ba3518 8000080088090fa8
> GPR16: 0000000000001000 c000000000ba3500 c0000000f72c68d8 0000000000000004
> GPR20: c000000000ea5280 c000000000ba34e8 0000000000000020 0000000000000004
> GPR24: c000000000eab7c0 0000000000000000 c0000000f7fc8818 c000000000eb0000
> GPR28: c0000000f786cc00 c000000000eab780 fffffffff786cc00 c000000000eab7c0
> NIP [c0000000004393e4] .gen_pool_alloc+0x0/0xc
> LR [c0000000004aeba0] .qman_alloc_cgrid_range+0x24/0x54
> Call Trace:
> [c0000000f70cb3e0] [c000000000504054] .platform_device_register_full+0x12c/0x150 (unreliable)
> [c0000000f70cb460] [c0000000006feba0] .caam_qi_init+0x158/0x63c
> [c0000000f70cb5f0] [c0000000006fc64c] .caam_probe+0x8b8/0x1830
> [c0000000f70cb740] [c000000000503288] .platform_drv_probe+0x60/0xac
> [c0000000f70cb7c0] [c000000000501194] .driver_probe_device+0x248/0x344
> [c0000000f70cb870] [c0000000005013b4] .__driver_attach+0x124/0x128
> [c0000000f70cb900] [c0000000004fed90] .bus_for_each_dev+0x80/0xcc
> [c0000000f70cb9a0] [c000000000500858] .driver_attach+0x24/0x38
> [c0000000f70cba10] [c00000000050043c] .bus_add_driver+0x14c/0x29c
> [c0000000f70cbab0] [c000000000501d64] .driver_register+0x8c/0x154
> [c0000000f70cbb30] [c000000000503000] .__platform_driver_register+0x48/0x5c
> [c0000000f70cbba0] [c000000000c7f798] .caam_driver_init+0x1c/0x30
> [c0000000f70cbc10] [c000000000001904] .do_one_initcall+0x60/0x1a8
> [c0000000f70cbcf0] [c000000000c35f30] .kernel_init_freeable+0x248/0x334
> [c0000000f70cbdb0] [c0000000000020fc] .kernel_init+0x1c/0xf20
> [c0000000f70cbe30] [c0000000000009bc] .ret_from_kernel_thread+0x58/0x9c
> Instruction dump:
> eb61ffd8 eb81ffe0 eba1ffe8 ebc1fff0 ebe1fff8 4e800020 38600000 4bffffb0
> 7ce53b78 4bffff0c 7f67db78 4bffff24 <e8a30020> e8c30028 4bfffd30 fbe1fff8
> ---[ end trace 9f61087068991b02 ]---
>
>
> home:linux-next(4)(I)> git bisect log
> ...
> git bisect bad b189817cf7894e03fd3700acd923221d3007259e
> # first bad commit: [b189817cf7894e03fd3700acd923221d3007259e] crypto: caam/qi - add ablkcipher and authenc algorithms
>
>
> The oops is saying gen_pool_alloc() was called with a NULL pointer, so
> it seems qm_cgralloc is NULL:
>
> static int qman_alloc_range(struct gen_pool *p, u32 *result, u32 cnt)
> {
> unsigned long addr;
>
> addr = gen_pool_alloc(p, cnt);
> ...
>
> int qman_alloc_cgrid_range(u32 *result, u32 count)
> {
> return qman_alloc_range(qm_cgralloc, result, count);
> }
>
>
> I didn't pull the thread any further than that.
>
> cheers
>
^ permalink raw reply
* Re: [PATCH] padata: avoid race in reordering
From: Greg KH @ 2017-04-04 18:26 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: stable, Steffen Klassert, Linux Crypto Mailing List, LKML,
Herbert Xu
In-Reply-To: <CAHmME9radQrAeyWmwapLGg1RYD0wVz3ysAT_p19KD0fi4q=anQ@mail.gmail.com>
On Tue, Apr 04, 2017 at 01:53:15PM +0200, Jason A. Donenfeld wrote:
> Herbert applied this to his tree. It's probably a good stable
> candidate, since it's a two line change to fix a race condition.
>
> On Fri, Mar 24, 2017 at 3:16 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> >> Under extremely heavy uses of padata, crashes occur, and with list
> >> debugging turned on, this happens instead:
> >>
> >> [87487.298728] WARNING: CPU: 1 PID: 882 at lib/list_debug.c:33
> >> __list_add+0xae/0x130
> >> [87487.301868] list_add corruption. prev->next should be next
> >> (ffffb17abfc043d0), but was ffff8dba70872c80. (prev=ffff8dba70872b00).
> >> [87487.339011] [<ffffffff9a53d075>] dump_stack+0x68/0xa3
> >> [87487.342198] [<ffffffff99e119a1>] ? console_unlock+0x281/0x6d0
> >> [87487.345364] [<ffffffff99d6b91f>] __warn+0xff/0x140
> >> [87487.348513] [<ffffffff99d6b9aa>] warn_slowpath_fmt+0x4a/0x50
> >> [87487.351659] [<ffffffff9a58b5de>] __list_add+0xae/0x130
> >> [87487.354772] [<ffffffff9add5094>] ? _raw_spin_lock+0x64/0x70
> >> [87487.357915] [<ffffffff99eefd66>] padata_reorder+0x1e6/0x420
> >> [87487.361084] [<ffffffff99ef0055>] padata_do_serial+0xa5/0x120
> >>
> >> padata_reorder calls list_add_tail with the list to which its adding
> >> locked, which seems correct:
> >>
> >> spin_lock(&squeue->serial.lock);
> >> list_add_tail(&padata->list, &squeue->serial.list);
> >> spin_unlock(&squeue->serial.lock);
> >>
> >> This therefore leaves only place where such inconsistency could occur:
> >> if padata->list is added at the same time on two different threads.
> >> This pdata pointer comes from the function call to
> >> padata_get_next(pd), which has in it the following block:
> >>
> >> next_queue = per_cpu_ptr(pd->pqueue, cpu);
> >> padata = NULL;
> >> reorder = &next_queue->reorder;
> >> if (!list_empty(&reorder->list)) {
> >> padata = list_entry(reorder->list.next,
> >> struct padata_priv, list);
> >> spin_lock(&reorder->lock);
> >> list_del_init(&padata->list);
> >> atomic_dec(&pd->reorder_objects);
> >> spin_unlock(&reorder->lock);
> >>
> >> pd->processed++;
> >>
> >> goto out;
> >> }
> >> out:
> >> return padata;
> >>
> >> I strongly suspect that the problem here is that two threads can race
> >> on reorder list. Even though the deletion is locked, call to
> >> list_entry is not locked, which means it's feasible that two threads
> >> pick up the same padata object and subsequently call list_add_tail on
> >> them at the same time. The fix is thus be hoist that lock outside of
> >> that block.
> >>
> >> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> >
> > Patch applied. Thanks.
Any clue as to what the git commit id is?
thanks,
greg k-h
^ permalink raw reply
* [PATCH v1] hw_random: Fix timeriomem_rng for sub-jiffie update periods
From: Rick Altherr @ 2017-04-04 21:43 UTC (permalink / raw)
To: alex; +Cc: openbmc, Herbert Xu, Matt Mackall, linux-crypto, linux-kernel
Some hardware RNGs provide a single register for obtaining random data.
Instead of signaling when new data is available, the reader must wait a
fixed amount of time between reads for new data to be generated.
timeriomem_rng implements this scheme with the period specified in
platform data or device tree. While the period is specified in
microseconds, the implementation used a standard timer which has a
minimum delay of 1 jiffie and caused a significant bottleneck for
devices that can update at 1us. By switching to an hrtimer, 1us periods
now only delay at most 2us per read.
Migrated to new hw_random API while I in this driver.
Signed-off-by: Rick Altherr <raltherr@google.com>
---
drivers/char/hw_random/timeriomem-rng.c | 153 ++++++++++++++++----------------
1 file changed, 75 insertions(+), 78 deletions(-)
diff --git a/drivers/char/hw_random/timeriomem-rng.c b/drivers/char/hw_random/timeriomem-rng.c
index cf37db263ecd..7482de2ca71c 100644
--- a/drivers/char/hw_random/timeriomem-rng.c
+++ b/drivers/char/hw_random/timeriomem-rng.c
@@ -20,90 +20,99 @@
* TODO: add support for reading sizes other than 32bits and masking
*/
-#include <linux/module.h>
-#include <linux/kernel.h>
-#include <linux/platform_device.h>
-#include <linux/of.h>
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/hrtimer.h>
#include <linux/hw_random.h>
#include <linux/io.h>
+#include <linux/ktime.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/time.h>
#include <linux/timeriomem-rng.h>
-#include <linux/jiffies.h>
-#include <linux/sched.h>
-#include <linux/timer.h>
-#include <linux/completion.h>
-struct timeriomem_rng_private_data {
+struct timeriomem_rng_private {
void __iomem *io_base;
- unsigned int expires;
- unsigned int period;
+ ktime_t period;
unsigned int present:1;
- struct timer_list timer;
+ struct hrtimer timer;
struct completion completion;
- struct hwrng timeriomem_rng_ops;
+ struct hwrng rng_ops;
};
-#define to_rng_priv(rng) \
- ((struct timeriomem_rng_private_data *)rng->priv)
-
-/*
- * have data return 1, however return 0 if we have nothing
- */
-static int timeriomem_rng_data_present(struct hwrng *rng, int wait)
+static int timeriomem_rng_read(struct hwrng *hwrng, void *data,
+ size_t max, bool wait)
{
- struct timeriomem_rng_private_data *priv = to_rng_priv(rng);
-
- if (!wait || priv->present)
- return priv->present;
+ struct timeriomem_rng_private *priv =
+ container_of(hwrng, struct timeriomem_rng_private, rng_ops);
+ int retval = 0;
+ int period_us = ktime_to_us(priv->period);
+
+ /*
+ * There may not have been enough time for new data to be generated
+ * since the last request. If the caller doesn't want to wait, let them
+ * bail out. Otherwise, wait for the completion. If the new data has
+ * already been generated, the completion should already be available.
+ */
+ if (!wait && !priv->present)
+ return 0;
wait_for_completion(&priv->completion);
- return 1;
-}
-
-static int timeriomem_rng_data_read(struct hwrng *rng, u32 *data)
-{
- struct timeriomem_rng_private_data *priv = to_rng_priv(rng);
- unsigned long cur;
- s32 delay;
-
- *data = readl(priv->io_base);
-
- cur = jiffies;
-
- delay = cur - priv->expires;
- delay = priv->period - (delay % priv->period);
-
- priv->expires = cur + delay;
+ do {
+ /*
+ * After the first read, all additional reads will need to wait
+ * for the RNG to generate new data. Since the period can have
+ * a wide range of values (1us to 1s have been observed), allow
+ * for 1% tolerance in the sleep time rather than a fixed value.
+ */
+ if (retval > 0)
+ usleep_range(period_us,
+ period_us + min(1, period_us / 100));
+
+ *(u32 *)data = readl(priv->io_base);
+ retval += sizeof(u32);
+ data += sizeof(u32);
+ max -= sizeof(u32);
+ } while (wait && max > sizeof(u32));
+
+ /*
+ * Block any new callers until the RNG has had time to generate new
+ * data.
+ */
priv->present = 0;
-
reinit_completion(&priv->completion);
- mod_timer(&priv->timer, priv->expires);
+ hrtimer_forward_now(&priv->timer, priv->period);
+ hrtimer_restart(&priv->timer);
- return 4;
+ return retval;
}
-static void timeriomem_rng_trigger(unsigned long data)
+static enum hrtimer_restart timeriomem_rng_trigger(struct hrtimer *timer)
{
- struct timeriomem_rng_private_data *priv
- = (struct timeriomem_rng_private_data *)data;
+ struct timeriomem_rng_private *priv
+ = container_of(timer, struct timeriomem_rng_private, timer);
priv->present = 1;
complete(&priv->completion);
+
+ return HRTIMER_NORESTART;
}
static int timeriomem_rng_probe(struct platform_device *pdev)
{
struct timeriomem_rng_data *pdata = pdev->dev.platform_data;
- struct timeriomem_rng_private_data *priv;
+ struct timeriomem_rng_private *priv;
struct resource *res;
int err = 0;
int period;
if (!pdev->dev.of_node && !pdata) {
- dev_err(&pdev->dev, "timeriomem_rng_data is missing\n");
+ dev_err(&pdev->dev, "timeriomem_rng_private is missing\n");
return -EINVAL;
}
@@ -119,7 +128,7 @@ static int timeriomem_rng_probe(struct platform_device *pdev)
/* Allocate memory for the device structure (and zero it) */
priv = devm_kzalloc(&pdev->dev,
- sizeof(struct timeriomem_rng_private_data), GFP_KERNEL);
+ sizeof(struct timeriomem_rng_private), GFP_KERNEL);
if (!priv)
return -ENOMEM;
@@ -139,54 +148,42 @@ static int timeriomem_rng_probe(struct platform_device *pdev)
period = pdata->period;
}
- priv->period = usecs_to_jiffies(period);
- if (priv->period < 1) {
- dev_err(&pdev->dev, "period is less than one jiffy\n");
- return -EINVAL;
- }
-
- priv->expires = jiffies;
- priv->present = 1;
-
+ priv->period = ns_to_ktime(period * NSEC_PER_USEC);
init_completion(&priv->completion);
- complete(&priv->completion);
+ hrtimer_init(&priv->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+ priv->timer.function = timeriomem_rng_trigger;
- setup_timer(&priv->timer, timeriomem_rng_trigger, (unsigned long)priv);
-
- priv->timeriomem_rng_ops.name = dev_name(&pdev->dev);
- priv->timeriomem_rng_ops.data_present = timeriomem_rng_data_present;
- priv->timeriomem_rng_ops.data_read = timeriomem_rng_data_read;
- priv->timeriomem_rng_ops.priv = (unsigned long)priv;
+ priv->rng_ops.name = dev_name(&pdev->dev);
+ priv->rng_ops.read = timeriomem_rng_read;
+ priv->rng_ops.priv = (unsigned long)priv;
priv->io_base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(priv->io_base)) {
- err = PTR_ERR(priv->io_base);
- goto out_timer;
+ return PTR_ERR(priv->io_base);
}
- err = hwrng_register(&priv->timeriomem_rng_ops);
+ /* Assume random data is already available. */
+ priv->present = 1;
+ complete(&priv->completion);
+
+ err = hwrng_register(&priv->rng_ops);
if (err) {
dev_err(&pdev->dev, "problem registering\n");
- goto out_timer;
+ return err;
}
dev_info(&pdev->dev, "32bits from 0x%p @ %dus\n",
priv->io_base, period);
return 0;
-
-out_timer:
- del_timer_sync(&priv->timer);
- return err;
}
static int timeriomem_rng_remove(struct platform_device *pdev)
{
- struct timeriomem_rng_private_data *priv = platform_get_drvdata(pdev);
-
- hwrng_unregister(&priv->timeriomem_rng_ops);
+ struct timeriomem_rng_private *priv = platform_get_drvdata(pdev);
- del_timer_sync(&priv->timer);
+ hwrng_unregister(&priv->rng_ops);
+ hrtimer_cancel(&priv->timer);
return 0;
}
--
2.12.2.715.g7642488e1d-goog
^ permalink raw reply related
* Re: [PATCH 1/5] crypto/nx: Rename nx842_powernv_function as icswx function
From: Haren Myneni @ 2017-04-05 3:32 UTC (permalink / raw)
To: Michael Ellerman
Cc: herbert, ddstreet, linuxppc-dev, linux-crypto, benh, mikey, suka,
hbabu
In-Reply-To: <87inmkv348.fsf@concordia.ellerman.id.au>
On 04/04/2017 04:11 AM, Michael Ellerman wrote:
> Haren Myneni <haren@linux.vnet.ibm.com> writes:
>
>> [PATCH 1/5] crypto/nx: Rename nx842_powernv_function as icswx function
>>
>> nx842_powernv_function is points to nx842_icswx_function and
>> will be point to VAS function which will be added later for
>> P9 NX support.
>
> I know it's nit-picking but can you give it a better name while you're
> there.
>
> I was thinking it should be called "send" or something, but it actually
> synchronously sends and waits for a request.
>
> So perhaps just nx842_exec(), for "execute a request", and then you can
> have nx842_exec_icswx() and nx842_exec_vas().
>
> cheers
>
Michael,
Thanks for review,
nx842_powernv_function() was used before, So just renamed similar to this name. But I will make changes in the next version.
Haren
^ permalink raw reply
* Re: [PATCH v5 0/4] gf128mul refactoring
From: Eric Biggers @ 2017-04-05 4:13 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: Herbert Xu, David S. Miller, linux-crypto, Eric Biggers,
Jeffrey Walton, Milan Broz
In-Reply-To: <20170402191916.9309-1-omosnacek@gmail.com>
Hi Ondrej,
On Sun, Apr 02, 2017 at 09:19:12PM +0200, Ondrej Mosnacek wrote:
> This patchset contains the following gf128mul-related changes:
> 1. The gf128mul_x_* functions are moved to gf128mul.h for performance reasons.
> 2. The gf128mul_x_ble function is fixed to use the correct block type.
> 3. The le128_gf128mul_x_ble function from glue_helper.h is removed and its
> usages replaced with gf128mul_x_ble calls.
> 4. The now obsolete dependency of CRYPTO_XTS on CRYPTO_GF128MUL is removed.
>
> v4 -> v5: added the other three patches
> v3 -> v4: a faster version of gf128mul_x_lle
> v2 -> v3: constant-time implementation
> v1 -> v2: move all _x_ functions to the header, not just gf128mul_x_ble
>
> Ondrej Mosnacek (4):
> crypto: gf128mul - define gf128mul_x_* in gf128mul.h
> crypto: gf128mul - switch gf128mul_x_ble to le128
> crypto: glue_helper - remove the le128_gf128mul_x_ble function
> crypto: xts - drop gf128mul dependency
These all look good to me, and you can add
Reviewed-by: Eric Biggers <ebiggers@google.com>
to the patches.
I think the change to le128 is an improvement, but what I've actually wanted to
do is have the GF(2^128) elements strongly typed, with ble128, bbe128, and
lle128 types, so that the types would reflect both the bit order and the byte
order. But that's harder to do and I ran into some issues when I tried it last.
- Eric
^ permalink raw reply
* 57014 linux-crypto
From: smallgroups @ 2017-04-05 5:13 UTC (permalink / raw)
To: linux-crypto
[-- Attachment #1: 10.zip --]
[-- Type: application/zip, Size: 3824 bytes --]
^ permalink raw reply
* [PATCH] crypto: caam - fix RNG deinstantiation error checking
From: Horia Geantă @ 2017-04-05 8:41 UTC (permalink / raw)
To: Herbert Xu
Cc: David S. Miller, linux-crypto, Dan Douglass, Alexandru Porosanu
RNG instantiation was previously fixed by
commit 62743a4145bb9 ("crypto: caam - fix RNG init descriptor ret. code checking")
while deinstantiation was not addressed.
Since the descriptors used are similar, in the sense that they both end
with a JUMP HALT command, checking for errors should be similar too,
i.e. status code 7000_0000h should be considered successful.
Cc: <stable@vger.kernel.org> # 3.13+
Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
---
drivers/crypto/caam/ctrl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index b3a94d5eff26..b7a36af5008d 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -285,7 +285,8 @@ static int deinstantiate_rng(struct device *ctrldev, int state_handle_mask)
/* Try to run it through DECO0 */
ret = run_descriptor_deco0(ctrldev, desc, &status);
- if (ret || status) {
+ if (ret ||
+ (status && status != JRSTA_SSRC_JUMP_HALT_CC)) {
dev_err(ctrldev,
"Failed to deinstantiate RNG4 SH%d\n",
sh_idx);
--
2.12.0.264.gd6db3f216544
^ permalink raw reply related
* Re: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms
From: Michael Ellerman @ 2017-04-05 10:06 UTC (permalink / raw)
To: Laurentiu Tudor, Horia Geantă, Herbert Xu, Scott Wood,
Roy Pledge
Cc: Claudiu Manoil, Cristian Stoica, Dan Douglass,
linux-arm-kernel@lists.infradead.org, Vakul Garg,
linuxppc-dev@lists.ozlabs.org, David S. Miller,
Alexandru Porosanu, linux-crypto@vger.kernel.org
In-Reply-To: <58E39F90.6050408@nxp.com>
Laurentiu Tudor <laurentiu.tudor@nxp.com> writes:
> Hi Michael,
>
> Just a couple of basic things to check:
> - was the dtb updated to the newest?
Possibly not, it's an automated build/boot, I'll have to check what it
does with the dtb.
> - is the qman node present? This should be easily visible in
> /proc/device-tree/soc@ffe000000/qman@318000.
No it's not there.
That's running linux-next with:
CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI=n
Does that mean I didn't update the device tree?
cheers
^ permalink raw reply
* Re: [PATCH] padata: avoid race in reordering
From: Herbert Xu @ 2017-04-05 10:29 UTC (permalink / raw)
To: Greg KH
Cc: Jason A. Donenfeld, stable, Steffen Klassert,
Linux Crypto Mailing List, LKML
In-Reply-To: <20170404182612.GA3419@kroah.com>
On Tue, Apr 04, 2017 at 08:26:12PM +0200, Greg KH wrote:
> Any clue as to what the git commit id is?
It's
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?h=linus&id=de5540d088fe97ad583cc7d396586437b32149a5
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: [7/7] crypto: caam/qi - add ablkcipher and authenc algorithms
From: Laurentiu Tudor @ 2017-04-05 11:49 UTC (permalink / raw)
To: Michael Ellerman, Horia Geantă, Herbert Xu, Scott Wood,
Roy Pledge
Cc: Dan Douglass, Cristian Stoica, Claudiu Manoil, Alexandru Porosanu,
Vakul Garg, linuxppc-dev@lists.ozlabs.org, David S. Miller,
linux-arm-kernel@lists.infradead.org,
linux-crypto@vger.kernel.org
In-Reply-To: <87lgrftbgl.fsf@concordia.ellerman.id.au>
On 04/05/2017 01:06 PM, Michael Ellerman wrote:
> Laurentiu Tudor <laurentiu.tudor@nxp.com> writes:
>
>> Hi Michael,
>>
>> Just a couple of basic things to check:
>> - was the dtb updated to the newest?
>
> Possibly not, it's an automated build/boot, I'll have to check what it
> does with the dtb.
>
>> - is the qman node present? This should be easily visible in
>> /proc/device-tree/soc@ffe000000/qman@318000.
>
> No it's not there.
>
> That's running linux-next with:
>
> CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI=n
>
>
> Does that mean I didn't update the device tree?
>
I think so. Also, I just checked that the node is actually there by
compiling p5020ds.dts and then decompiling the dtb.
---
Best Regards, Laurentiu
^ permalink raw reply
* Re: [PATCH] crypto: AF_ALG: handle 0 lengths in af_alg_make_sg
From: Herbert Xu @ 2017-04-05 12:50 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <2164576.cSnkze5bYl@positron.chronox.de>
On Sat, Apr 01, 2017 at 07:46:39PM +0200, Stephan Müller wrote:
> Am Samstag, 1. April 2017, 17:04:28 CEST schrieb Stephan Müller:
>
> Hi Herbert,
>
> > Hi Herbert,
> >
> > If you concur with the patch, I think it should go to 4.11 as well as
> > to stable.
>
> After checking this issue again, I see that it is not triggerable in the
> current code as the different af_alg users make sure that this function is not
> called with 0.
>
> I only triggered this issue during experimenting with the algif_skcipher and
> algif_aead revamp as requested by you. During those experiments, I invoked
> af_alg_make_sg with a len = 0.
>
> Thus, this patch is not applicable for stable and 4.11.
>
> Yet, I would suggest to consider this patch as a safeguard for any potential
> programming errors.
So this is only possible with patches that have not been applied
yet? In that case please fold this into whichever patch series
that needs it.
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 v1] hw_random: Fix timeriomem_rng for sub-jiffie update periods
From: Herbert Xu @ 2017-04-05 12:57 UTC (permalink / raw)
To: Rick Altherr; +Cc: alex, openbmc, Matt Mackall, linux-crypto, linux-kernel
In-Reply-To: <20170404214307.7748-1-raltherr@google.com>
On Tue, Apr 04, 2017 at 02:43:07PM -0700, Rick Altherr wrote:
> Some hardware RNGs provide a single register for obtaining random data.
> Instead of signaling when new data is available, the reader must wait a
> fixed amount of time between reads for new data to be generated.
> timeriomem_rng implements this scheme with the period specified in
> platform data or device tree. While the period is specified in
> microseconds, the implementation used a standard timer which has a
> minimum delay of 1 jiffie and caused a significant bottleneck for
> devices that can update at 1us. By switching to an hrtimer, 1us periods
> now only delay at most 2us per read.
>
> Migrated to new hw_random API while I in this driver.
>
> Signed-off-by: Rick Altherr <raltherr@google.com>
Thanks Rick. Could you split this into two patches? One doing
the API conversion and the other one doing the substantive change
to the entropy gathering?
That way if there is a problem it'll be easier to track down.
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: ccp - Remove redundant cpu-to-le32 macros
From: Herbert Xu @ 2017-04-05 14:09 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <20170328135828.13086.97535.stgit@taos>
On Tue, Mar 28, 2017 at 08:58:28AM -0500, Gary R Hook wrote:
> Endianness is dealt with when the command descriptor is
> copied into the command queue. Remove any occurrences of
> cpu_to_le32() found elsewhere.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.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/nx: Update MAINTAINERS entry for 842 compression
From: Herbert Xu @ 2017-04-05 14:10 UTC (permalink / raw)
To: Haren Myneni; +Cc: ddstreet, linux-crypto, linux-kernel
In-Reply-To: <1491067540.29552.39.camel@hbabu-laptop>
On Sat, Apr 01, 2017 at 10:25:40AM -0700, Haren Myneni wrote:
> [PATCH] crypto/nx: Update MAINTAINERS entry for 842 compression
>
> Signed-off-by: Haren Myneni <haren@us.ibm.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 V2] crypto: ccp - Rearrange structure members to minimize size
From: Herbert Xu @ 2017-04-05 14:10 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, arnd, davem
In-Reply-To: <20170328155725.9578.85077.stgit@taos>
On Tue, Mar 28, 2017 at 10:57:26AM -0500, Gary R Hook wrote:
> The AES GCM function (in ccp-ops) requires a fair amount of
> stack space, which elicits a complaint when KASAN is enabled.
> Rearranging and packing a few structures eliminates the
> warning.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.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 v5 0/4] gf128mul refactoring
From: Herbert Xu @ 2017-04-05 14:11 UTC (permalink / raw)
To: Ondrej Mosnacek
Cc: David S. Miller, linux-crypto, Eric Biggers, Jeffrey Walton,
Milan Broz
In-Reply-To: <20170402191916.9309-1-omosnacek@gmail.com>
On Sun, Apr 02, 2017 at 09:19:12PM +0200, Ondrej Mosnacek wrote:
> This patchset contains the following gf128mul-related changes:
> 1. The gf128mul_x_* functions are moved to gf128mul.h for performance reasons.
> 2. The gf128mul_x_ble function is fixed to use the correct block type.
> 3. The le128_gf128mul_x_ble function from glue_helper.h is removed and its
> usages replaced with gf128mul_x_ble calls.
> 4. The now obsolete dependency of CRYPTO_XTS on CRYPTO_GF128MUL is removed.
>
> v4 -> v5: added the other three patches
> v3 -> v4: a faster version of gf128mul_x_lle
> v2 -> v3: constant-time implementation
> v1 -> v2: move all _x_ functions to the header, not just gf128mul_x_ble
All 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: caam - fix invalid dereference in caam_rsa_init_tfm()
From: Herbert Xu @ 2017-04-05 14:08 UTC (permalink / raw)
To: Horia Geantă; +Cc: David S. Miller, linux-crypto, Dan Douglass
In-Reply-To: <20170403153007.30455-1-horia.geanta@nxp.com>
On Mon, Apr 03, 2017 at 06:30:07PM +0300, Horia Geantă wrote:
> In case caam_jr_alloc() fails, ctx->dev carries the error code,
> thus accessing it with dev_err() is incorrect.
>
> Cc: <stable@vger.kernel.org> # 4.8+
> Fixes: 8c419778ab57e ("crypto: caam - add support for RSA algorithm")
> Signed-off-by: Horia Geantă <horia.geanta@nxp.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: caam - fix JR platform device subsequent (re)creations
From: Herbert Xu @ 2017-04-05 14:08 UTC (permalink / raw)
To: Horia Geantă
Cc: Rob Herring, Russell King, David S. Miller, linux-crypto,
Dan Douglass, Ruchika Gupta
In-Reply-To: <20170403151204.27488-1-horia.geanta@nxp.com>
On Mon, Apr 03, 2017 at 06:12:04PM +0300, Horia Geantă wrote:
> The way Job Ring platform devices are created and released does not
> allow for multiple create-release cycles.
>
> JR0 Platform device creation error
> JR0 Platform device creation error
> caam 2100000.caam: no queues configured, terminating
> caam: probe of 2100000.caam failed with error -12
>
> The reason is that platform devices are created for each job ring:
>
> for_each_available_child_of_node(nprop, np)
> if (of_device_is_compatible(np, "fsl,sec-v4.0-job-ring") ||
> of_device_is_compatible(np, "fsl,sec4.0-job-ring")) {
> ctrlpriv->jrpdev[ring] =
> of_platform_device_create(np, NULL, dev);
>
> which sets OF_POPULATED on the device node, but then it cleans these up:
>
> /* Remove platform devices for JobRs */
> for (ring = 0; ring < ctrlpriv->total_jobrs; ring++) {
> if (ctrlpriv->jrpdev[ring])
> of_device_unregister(ctrlpriv->jrpdev[ring]);
> }
>
> which leaves OF_POPULATED set.
>
> Use of_platform_populate / of_platform_depopulate instead.
> This allows for a bit of driver clean-up, jrpdev is no longer needed.
>
> Logic changes a bit too:
> -exit in case of_platform_populate fails, since currently even QI backend
> depends on JR; true, we no longer support the case when "some" of the JR
> DT nodes are incorrect
> -when cleaning up, caam_remove() would also depopulate RTIC in case
> it would have been populated somewhere else - not the case for now
>
> Fixes: 313ea293e9c4d ("crypto: caam - Add Platform driver for Job Ring")
> Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
> Suggested-by: Rob Herring <robh+dt@kernel.org>
> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
> ---
> Not sending this directly to -stable, since it does not apply cleanly.
Patch applied. I forced it to apply on the crypto tree, then merged
it forward to cryptodev. Please check the end result and let me know
if it's wrong.
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: caam - fix RNG deinstantiation error checking
From: Herbert Xu @ 2017-04-05 14:09 UTC (permalink / raw)
To: Horia Geantă
Cc: David S. Miller, linux-crypto, Dan Douglass, Alexandru Porosanu
In-Reply-To: <20170405084103.19053-1-horia.geanta@nxp.com>
On Wed, Apr 05, 2017 at 11:41:03AM +0300, Horia Geantă wrote:
> RNG instantiation was previously fixed by
> commit 62743a4145bb9 ("crypto: caam - fix RNG init descriptor ret. code checking")
> while deinstantiation was not addressed.
>
> Since the descriptors used are similar, in the sense that they both end
> with a JUMP HALT command, checking for errors should be similar too,
> i.e. status code 7000_0000h should be considered successful.
>
> Cc: <stable@vger.kernel.org> # 3.13+
> Fixes: 1005bccd7a4a6 ("crypto: caam - enable instantiation of all RNG4 state handles")
> Signed-off-by: Horia Geantă <horia.geanta@nxp.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 v2 0/5] STM32 CRC crypto driver
From: Herbert Xu @ 2017-04-05 14:09 UTC (permalink / raw)
To: Fabien Dessenne
Cc: David S . Miller, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-crypto, devicetree,
linux-arm-kernel, Benjamin Gaignard
In-Reply-To: <1490109211-4869-1-git-send-email-fabien.dessenne@st.com>
On Tue, Mar 21, 2017 at 04:13:26PM +0100, Fabien Dessenne wrote:
> This set of patches adds a new crypto driver for STMicroelectronics stm32f746.
> The drivers uses the crypto API and provides with an HW-enabled CRC32 algorithm.
> It was developed and tested (tcrypt / testmgr) on evaluation board stm32746g.
>
> v2 changes:
> - remove useless check of crc / crc->clk
> - enable crypto in stm32 defconfig
> - typo fix in dt-bindings
All 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: AF_ALG: handle 0 lengths in af_alg_make_sg
From: Stephan Müller @ 2017-04-05 15:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20170405125012.GA26558@gondor.apana.org.au>
Am Mittwoch, 5. April 2017, 14:50:12 CEST schrieb Herbert Xu:
Hi Herbert,
> So this is only possible with patches that have not been applied
> yet?
Correct.
> In that case please fold this into whichever patch series
> that needs it.
Ok, let us defer it.
Ciao
Stephan
^ permalink raw reply
* [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT
From: Matthias Kaehlcke @ 2017-04-05 16:56 UTC (permalink / raw)
To: Ard Biesheuvel, Greg Hackmann, Herbert Xu, David S . Miller,
Catalin Marinas, Will Deacon
Cc: Grant Grundler, linux-kernel, Michael Davidson, Matthias Kaehlcke,
linux-crypto, linux-arm-kernel
From: Greg Hackmann <ghackmann@google.com>
The current definition of ASM_EXPORT doesn't work properly with clang,
according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on
gcc specific behavior. Change the constraint from an intermediate to an
output expression which works with both gcc and clang.
From: Greg Hackmann <ghackmann@google.com>
Commit-message-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
arch/arm64/crypto/sha1-ce-glue.c | 2 +-
arch/arm64/crypto/sha2-ce-glue.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha1-ce-glue.c b/arch/arm64/crypto/sha1-ce-glue.c
index aefda9868627..c71e94ba0e43 100644
--- a/arch/arm64/crypto/sha1-ce-glue.c
+++ b/arch/arm64/crypto/sha1-ce-glue.c
@@ -18,7 +18,7 @@
#include <linux/module.h>
#define ASM_EXPORT(sym, val) \
- asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
+ asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
diff --git a/arch/arm64/crypto/sha2-ce-glue.c b/arch/arm64/crypto/sha2-ce-glue.c
index 7cd587564a41..381b5fb2dcb2 100644
--- a/arch/arm64/crypto/sha2-ce-glue.c
+++ b/arch/arm64/crypto/sha2-ce-glue.c
@@ -18,7 +18,7 @@
#include <linux/module.h>
#define ASM_EXPORT(sym, val) \
- asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
+ asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto Extensions");
MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
--
2.12.2.715.g7642488e1d-goog
^ permalink raw reply related
* Re: [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT
From: Ard Biesheuvel @ 2017-04-05 17:08 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Herbert Xu, Grant Grundler, Catalin Marinas, Will Deacon,
linux-kernel@vger.kernel.org, Greg Hackmann, Michael Davidson,
linux-crypto@vger.kernel.org, David S . Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170405165603.87264-1-mka@chromium.org>
Hoi Matthias!
On 5 April 2017 at 17:56, Matthias Kaehlcke <mka@chromium.org> wrote:
> From: Greg Hackmann <ghackmann@google.com>
>
> The current definition of ASM_EXPORT doesn't work properly with clang,
> according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on
> gcc specific behavior. Change the constraint from an intermediate to an
> output expression which works with both gcc and clang.
>
> From: Greg Hackmann <ghackmann@google.com>
> Commit-message-by: Matthias Kaehlcke <mka@chromium.org>
> Signed-off-by: Greg Hackmann <ghackmann@google.com>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> arch/arm64/crypto/sha1-ce-glue.c | 2 +-
> arch/arm64/crypto/sha2-ce-glue.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/crypto/sha1-ce-glue.c b/arch/arm64/crypto/sha1-ce-glue.c
> index aefda9868627..c71e94ba0e43 100644
> --- a/arch/arm64/crypto/sha1-ce-glue.c
> +++ b/arch/arm64/crypto/sha1-ce-glue.c
> @@ -18,7 +18,7 @@
> #include <linux/module.h>
>
> #define ASM_EXPORT(sym, val) \
> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> + asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
>
> MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
> MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
> diff --git a/arch/arm64/crypto/sha2-ce-glue.c b/arch/arm64/crypto/sha2-ce-glue.c
> index 7cd587564a41..381b5fb2dcb2 100644
> --- a/arch/arm64/crypto/sha2-ce-glue.c
> +++ b/arch/arm64/crypto/sha2-ce-glue.c
> @@ -18,7 +18,7 @@
> #include <linux/module.h>
>
> #define ASM_EXPORT(sym, val) \
> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
> + asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
>
> MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto Extensions");
> MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
I am fine with this change, although I would really like to add a
better reference to the commit log. It is *very* difficult to find any
documentation regarding non-trivial uses of inline asm constraints,
and if %c0 is the correct syntax, surely we can quote something better
than a LLVM bugzilla entry? Also, where does the distinction between
'intermediate' vs 'output' expression come from?
^ permalink raw reply
* Re: [PATCH] crypto: caam - fix JR platform device subsequent (re)creations
From: Horia Geantă @ 2017-04-05 17:09 UTC (permalink / raw)
To: Herbert Xu
Cc: Rob Herring, Russell King, David S. Miller,
linux-crypto@vger.kernel.org, Dan Douglass, Ruchika Gupta
In-Reply-To: <20170405140834.GA27150@gondor.apana.org.au>
On 4/5/2017 5:14 PM, Herbert Xu wrote:
> On Mon, Apr 03, 2017 at 06:12:04PM +0300, Horia Geantă wrote:
>> The way Job Ring platform devices are created and released does not
>> allow for multiple create-release cycles.
>>
>> JR0 Platform device creation error
>> JR0 Platform device creation error
>> caam 2100000.caam: no queues configured, terminating
>> caam: probe of 2100000.caam failed with error -12
>>
>> The reason is that platform devices are created for each job ring:
>>
>> for_each_available_child_of_node(nprop, np)
>> if (of_device_is_compatible(np, "fsl,sec-v4.0-job-ring") ||
>> of_device_is_compatible(np, "fsl,sec4.0-job-ring")) {
>> ctrlpriv->jrpdev[ring] =
>> of_platform_device_create(np, NULL, dev);
>>
>> which sets OF_POPULATED on the device node, but then it cleans these up:
>>
>> /* Remove platform devices for JobRs */
>> for (ring = 0; ring < ctrlpriv->total_jobrs; ring++) {
>> if (ctrlpriv->jrpdev[ring])
>> of_device_unregister(ctrlpriv->jrpdev[ring]);
>> }
>>
>> which leaves OF_POPULATED set.
>>
>> Use of_platform_populate / of_platform_depopulate instead.
>> This allows for a bit of driver clean-up, jrpdev is no longer needed.
>>
>> Logic changes a bit too:
>> -exit in case of_platform_populate fails, since currently even QI backend
>> depends on JR; true, we no longer support the case when "some" of the JR
>> DT nodes are incorrect
>> -when cleaning up, caam_remove() would also depopulate RTIC in case
>> it would have been populated somewhere else - not the case for now
>>
>> Fixes: 313ea293e9c4d ("crypto: caam - Add Platform driver for Job Ring")
>> Reported-by: Russell King <rmk+kernel@armlinux.org.uk>
>> Suggested-by: Rob Herring <robh+dt@kernel.org>
>> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
>> ---
>> Not sending this directly to -stable, since it does not apply cleanly.
>
> Patch applied. I forced it to apply on the crypto tree, then merged
> it forward to cryptodev. Please check the end result and let me know
> if it's wrong.
>
Looks fine.
Thanks,
Horia
^ permalink raw reply
* Re: [PATCH] crypto: arm64/sha: use %c constraint code in ASM_EXPORT
From: Robin Murphy @ 2017-04-05 17:21 UTC (permalink / raw)
To: Ard Biesheuvel, Matthias Kaehlcke
Cc: Herbert Xu, Grant Grundler, Catalin Marinas, Will Deacon,
linux-kernel@vger.kernel.org, Greg Hackmann, Michael Davidson,
linux-crypto@vger.kernel.org, David S . Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu-7tX6THETVA+M0UrC6rJ4id2AsHi2XfhDEmxCJ_tdwKw@mail.gmail.com>
On 05/04/17 18:08, Ard Biesheuvel wrote:
> Hoi Matthias!
>
> On 5 April 2017 at 17:56, Matthias Kaehlcke <mka@chromium.org> wrote:
>> From: Greg Hackmann <ghackmann@google.com>
>>
>> The current definition of ASM_EXPORT doesn't work properly with clang,
>> according to https://bugs.llvm.org//show_bug.cgi?id=27250#c3 it relies on
>> gcc specific behavior. Change the constraint from an intermediate to an
>> output expression which works with both gcc and clang.
>>
>> From: Greg Hackmann <ghackmann@google.com>
>> Commit-message-by: Matthias Kaehlcke <mka@chromium.org>
>> Signed-off-by: Greg Hackmann <ghackmann@google.com>
>> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
>> ---
>> arch/arm64/crypto/sha1-ce-glue.c | 2 +-
>> arch/arm64/crypto/sha2-ce-glue.c | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/crypto/sha1-ce-glue.c b/arch/arm64/crypto/sha1-ce-glue.c
>> index aefda9868627..c71e94ba0e43 100644
>> --- a/arch/arm64/crypto/sha1-ce-glue.c
>> +++ b/arch/arm64/crypto/sha1-ce-glue.c
>> @@ -18,7 +18,7 @@
>> #include <linux/module.h>
>>
>> #define ASM_EXPORT(sym, val) \
>> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
>> + asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
>>
>> MODULE_DESCRIPTION("SHA1 secure hash using ARMv8 Crypto Extensions");
>> MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
>> diff --git a/arch/arm64/crypto/sha2-ce-glue.c b/arch/arm64/crypto/sha2-ce-glue.c
>> index 7cd587564a41..381b5fb2dcb2 100644
>> --- a/arch/arm64/crypto/sha2-ce-glue.c
>> +++ b/arch/arm64/crypto/sha2-ce-glue.c
>> @@ -18,7 +18,7 @@
>> #include <linux/module.h>
>>
>> #define ASM_EXPORT(sym, val) \
>> - asm(".globl " #sym "; .set " #sym ", %0" :: "I"(val));
>> + asm(".globl " #sym "; .set " #sym ", %c0" :: "I"(val));
>>
>> MODULE_DESCRIPTION("SHA-224/SHA-256 secure hash using ARMv8 Crypto Extensions");
>> MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
>
> I am fine with this change, although I would really like to add a
> better reference to the commit log. It is *very* difficult to find any
> documentation regarding non-trivial uses of inline asm constraints,
> and if %c0 is the correct syntax, surely we can quote something better
> than a LLVM bugzilla entry? Also, where does the distinction between
> 'intermediate' vs 'output' expression come from?
FWIW, GCC docs do say (under the helpfully-obvious "x86 operand
modifiers" section[1]):
c Require a constant operand and print the constant
expression with no punctuation.
Which more or less makes sense in this this context too. As an aside,
though, since this is emitting a general integer argument to an
assembler directive, and not an operand to an ADD instruction, how come
we're using "I" and not "i" as the constraint in the first place?
Robin.
[1]:https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#x86-Operand-Modifiers
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ 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