* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Herbert Xu @ 2013-05-21 13:46 UTC (permalink / raw)
To: Tim Chen
Cc: Geert Uytterhoeven, Xiong Zhou, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <1369076985.27102.319.camel@schen9-DESK>
On Mon, May 20, 2013 at 12:09:45PM -0700, Tim Chen wrote:
> On Mon, 2013-05-20 at 19:47 +0800, Herbert Xu wrote:
>
> >
> > Nope this is still broken. We need to move the actual crct10dif
> > code into crypto/. I'll fix up the patch in the tree.
> >
> > Also I'm going to get rid of crc_t10dif_update_lib function. If you
> > still want to maintain the ordering you should do so using the
> > *_init constructs.
> >
>
> Herbert,
>
> I used the following constructs in the pclmulqdq version of t10dif
> to get the module loaded.
>
> static const struct x86_cpu_id crct10dif_cpu_id[] = {
> X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ),
> {}
> };
> MODULE_DEVICE_TABLE(x86cpu, crct10dif_cpu_id);
>
> However, the default generic algorithm is used
> in the library function. The options CRC_T10DIF, CRYPTO_CRCT10DIF
> and CRYPTO_CRCT10DIF_PCLMUL are selected as modules (which
> is most likely usage scenario in distribution) on my
> test machine. The library module and generic crypto module was loaded
> before the pclmulqdq t10dif module during boot. How should
> things be changed to get this crypto module loaded earlier before the
> library? Should we add another init call level between fs and device
> init calls for loading the available crypto algorithms?
> The crc_t10dif_update_lib was originally used to side step this issue.
OK, the way it's meant to work is that the all versions generic
or otherwise do not call themselves by the name of the algorithm.
Instead every implementation links itself to the algorithm via
a module alias. That way the first user will cause modprobe
to load all available versions and then rank them by priority.
However, now that I've looked at it it appears that crc32c and
crct10dif have not done this properly. I'll fix that up.
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][RFC] CPU Jitter random number generator (resent)
From: Stephan Mueller @ 2013-05-21 6:44 UTC (permalink / raw)
To: linux-crypto, linux-kernel
Hi,
[1] patch at http://www.chronox.de/jent/jitterentropy-20130516.tar.bz2
A new version of the CPU Jitter random number generator is released at
http://www.chronox.de/ . The heart of the RNG is about 30 lines of easy
to read code. The readme in the main directory explains the different
code files. A changelog can be found on the web site.
In a previous attempt (http://lkml.org/lkml/2013/2/8/476), the first
iteration received comments for the lack of tests, documentation and
entropy assessment. All these concerns have been addressed. The
documentation of the CPU Jitter random number generator
(http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html and PDF at
http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.pdf -- the graphs and
pictures are better in PDF) offers a full analysis of:
- the root cause of entropy
- a design of the RNG
- statistical tests and analyses
- entropy assessment and explanation of the flow of entropy
The document also explains the core concept to have a fully
decentralized entropy collector for every caller in need of entropy.
Also, this RNG is well suitable for virtualized environments.
Measurements on OpenVZ and KVM environments have been conducted as
documented. As the Linux kernel is starved of entropy in virtualized as
well as server environments, new sources of entropy are vital.
The appendix of the documentation contains example use cases by
providing link code to the Linux kernel crypto API, libgcrypt and
OpenSSL. Links to other cryptographic libraries should be straight
forward to implement. These implementations follow the concept of
decentralized entropy collection.
The man page provided with the source code explains the use of the API
of the CPU Jitter random number generator.
The test cases used to compile the documentation are available at the
web site as well.
Note: for the kernel crypto API, please read the provided Kconfig file
for the switches and which of them are recommended in regular
operation. These switches must currently be set manually in the
Makefile.
Ciao
Stephan
Signed-off-by: Stephan Mueller <smueller@chronox.de>
^ permalink raw reply
* Re: Oops on 3.10-rc1 related to ssh256_ssse3
From: Jussi Kivilinna @ 2013-05-20 20:15 UTC (permalink / raw)
To: Julian Wollrath, linux-crypto@vger.kernel.org
In-Reply-To: <20130516154135.17e03aca@ilfaris>
[-- Attachment #1: Type: text/plain, Size: 10127 bytes --]
On 16.05.2013 16:41, Julian Wollrath wrote:
> Hello,
>
> I have an encrypted disc (dm-crypt, type LUKS1, ssh256 as hash
> algorithm). I have an Intel Core i5 M450 that supports ssse3. Find
> below the output from netconsole with the oops. The last warning
> appeared when I restart the pc using the magic sysrq key combination
> REISUB. I have the same problem with a different laptop with an AMD
> E-450 APU.
Appears to be stack corruption caused by sha256_transform_ssse3. Does attached patch help?
-Jussi
>
> If you need further information, feel free to ask.
>
>
> Best regards,
> Julian Wollrath
>
> [ 3.647071] device-mapper: uevent: version 1.0.3
> [ 3.647245] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-devel@redhat.com
> [ 11.619603] sha256_ssse3: Using SSSE3 optimized SHA-256 implementation
> [ 12.131483] BUG: unable to handle kernel paging request at ffff8800bb593000
> [ 12.131848] IP: [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
> [ 12.132032] PGD 1a32067 PUD 1a35067 PMD 1a36067 PTE 0
> [ 12.132427] Oops: 0000 [#1] SMP
> [ 12.132670] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169 mii usbcore usb_common thermal thermal_sys
> [ 12.135396] CPU: 3 PID: 276 Comm: cryptomgr_test Not tainted 3.10.0-rc1+ #2
> [ 12.135559] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010
> [ 12.135720] task: ffff880037572090 ti: ffff8800b66b6000 task.ti: ffff8800b66b6000
> [ 12.135836] RIP: 0010:[<ffffffffa016b083>] [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
> [ 12.136032] RSP: 0018:ffff8800b66b7af0 EFLAGS: 00010287
> [ 12.136130] RAX: 00000000a186fc15 RBX: 00000000704bb939 RCX: 00000000d1b791ec
> [ 12.136232] RDX: 000000001fd2088a RSI: ffff880037a97ee8 RDI: ffff8800bb592fc8
> [ 12.136334] RBP: ffffffffa016f000 R08: 0000000052a5c3c8 R09: 000000005db427ef
> [ 12.136439] R10: 00000000b80a833e R11: 0000000029c53567 R12: ffff8800b66b7b08
> [ 12.136543] R13: 000000003158a213 R14: 00000000c7fc368e R15: 0000000001008012
> [ 12.136647] FS: 0000000000000000(0000) GS:ffff8800bb180000(0000) knlGS:0000000000000000
> [ 12.136763] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 12.136863] CR2: ffff8800bb593000 CR3: 000000000180b000 CR4: 00000000000007e0
> [ 12.136964] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 12.137066] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 12.137167] Stack:
> [ 12.137257] ffff880108c634c8 ffff8800bb592f88 6033fb357b8c96fd c5e119eaebeb38a3
> [ 12.137668] ffff880037a97f08 ffff8800b66b7b80 0000000000000008 0000000000000008
> [ 12.138077] ffff880037a97ed0 ffffffffa016dc4e ffff880001496ae5 ffff880037a97ee0
> [ 12.138484] Call Trace:
> [ 12.138580] [<ffffffffa016dc4e>] ? __sha256_ssse3_update+0x5e/0xe0 [sha256_ssse3]
> [ 12.138701] [<ffffffffa016df15>] ? sha256_ssse3_final+0x145/0x1ec [sha256_ssse3]
> [ 12.138825] [<ffffffff81214362>] ? shash_ahash_finup+0x32/0x80
> [ 12.138931] [<ffffffff81217523>] ? test_hash+0x383/0x6b0
> [ 12.139034] [<ffffffff8120c8a0>] ? crypto_mod_get+0x10/0x30
> [ 12.139141] [<ffffffff811186d6>] ? __kmalloc+0x1c6/0x1f0
> [ 12.139243] [<ffffffff8120cdfc>] ? __crypto_alg_lookup+0xac/0xf0
> [ 12.139344] [<ffffffff8120ca48>] ? crypto_create_tfm+0x48/0xd0
> [ 12.139445] [<ffffffff812146cd>] ? crypto_init_shash_ops_async+0x2d/0xd0
> [ 12.139548] [<ffffffff81217893>] ? alg_test_hash+0x43/0xa0
> [ 12.139650] [<ffffffff81215b9b>] ? alg_test+0x9b/0x230
> [ 12.139753] [<ffffffff81421351>] ? __schedule+0x271/0x650
> [ 12.139856] [<ffffffff81214940>] ? cryptomgr_probe+0xb0/0xb0
> [ 12.139954] [<ffffffff81214978>] ? cryptomgr_test+0x38/0x40
> [ 12.140058] [<ffffffff8105c53f>] ? kthread+0xaf/0xc0
> [ 12.140219] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
> [ 12.140382] [<ffffffff814237ac>] ? ret_from_fork+0x7c/0xb0
> [ 12.140482] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
> [ 12.140585] Code: c4 40 00 00 48 8d 2d 9d 3f 00 00 f3 0f 6f 27 66 41 0f 38 00 e4 f3 0f 6f 6f 10 66 41 0f 38 00 ec f3 0f 6f 77 20 66 41 0f 38 00 f4 <f3> 0f 6f 7f 30 66 41 0f 38 00 fc 48 89 7c 24 08 48 c7 c7 03 00
> [ 12.145708] RIP [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
> [ 12.145885] RSP <ffff8800b66b7af0>
> [ 12.145979] CR2: ffff8800bb593000
> [ 12.146075] ---[ end trace 0382cf30f3465fd1 ]---
> [ 12.146173] note: cryptomgr_test[276] exited with preempt_count 1
> [ 12.146347] BUG: scheduling while atomic: cryptomgr_test/276/0x10000001
> [ 12.146485] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169 mii usbcore usb_common thermal thermal_sys
> [ 12.150126] CPU: 3 PID: 276 Comm: cryptomgr_test Tainted: G D 3.10.0-rc1+ #2
> [ 12.150282] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010
> [ 12.150428] ffffffff8141eaf7 ffffffff8141bca7 ffffffff8142167a 0000000000000035
> [ 12.151034] 0000000000000046 ffff8800b66b7fd8 ffff8800b66b7fd8 ffff8800b66b7fd8
> [ 12.151610] ffff880037572090 ffff8800b66b6000 ffff8800375725d0 0000000000000046
> [ 12.152215] Call Trace:
> [ 12.152352] [<ffffffff8141eaf7>] ? dump_stack+0xc/0x15
> [ 12.152496] [<ffffffff8141bca7>] ? __schedule_bug+0x3f/0x4c
> [ 12.152637] [<ffffffff8142167a>] ? __schedule+0x59a/0x650
> [ 12.152764] [<ffffffff81067ccd>] ? __cond_resched+0x1d/0x30
> [ 12.152898] [<ffffffff814217a6>] ? _cond_resched+0x26/0x30
> [ 12.153033] [<ffffffff81420405>] ? mutex_lock+0x15/0x40
> [ 12.153169] [<ffffffff810cfba0>] ? perf_event_exit_task+0x20/0x1e0
> [ 12.153277] [<ffffffff8103e24f>] ? do_exit+0x29f/0xa10
> [ 12.153414] [<ffffffff81005ca6>] ? oops_end+0x96/0xe0
> [ 12.153550] [<ffffffff8141afd9>] ? no_context+0x24c/0x275
> [ 12.153692] [<ffffffff8102d51e>] ? __do_page_fault+0x2ee/0x480
> [ 12.153834] [<ffffffff810db066>] ? __alloc_pages_nodemask+0x106/0x8f0
> [ 12.153962] [<ffffffff81423332>] ? page_fault+0x22/0x30
> [ 12.154102] [<ffffffffa016b083>] ? loop0+0x27/0x44 [sha256_ssse3]
> [ 12.154232] [<ffffffffa016dc4e>] ? __sha256_ssse3_update+0x5e/0xe0 [sha256_ssse3]
> [ 12.154380] [<ffffffffa016df15>] ? sha256_ssse3_final+0x145/0x1ec [sha256_ssse3]
> [ 12.154532] [<ffffffff81214362>] ? shash_ahash_finup+0x32/0x80
> [ 12.154660] [<ffffffff81217523>] ? test_hash+0x383/0x6b0
> [ 12.154800] [<ffffffff8120c8a0>] ? crypto_mod_get+0x10/0x30
> [ 12.154940] [<ffffffff811186d6>] ? __kmalloc+0x1c6/0x1f0
> [ 12.155042] [<ffffffff8120cdfc>] ? __crypto_alg_lookup+0xac/0xf0
> [ 12.155183] [<ffffffff8120ca48>] ? crypto_create_tfm+0x48/0xd0
> [ 12.155327] [<ffffffff812146cd>] ? crypto_init_shash_ops_async+0x2d/0xd0
> [ 12.155466] [<ffffffff81217893>] ? alg_test_hash+0x43/0xa0
> [ 12.155609] [<ffffffff81215b9b>] ? alg_test+0x9b/0x230
> [ 12.155746] [<ffffffff81421351>] ? __schedule+0x271/0x650
> [ 12.155886] [<ffffffff81214940>] ? cryptomgr_probe+0xb0/0xb0
> [ 12.156018] [<ffffffff81214978>] ? cryptomgr_test+0x38/0x40
> [ 12.156150] [<ffffffff8105c53f>] ? kthread+0xaf/0xc0
> [ 12.156275] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
> [ 12.156408] [<ffffffff814237ac>] ? ret_from_fork+0x7c/0xb0
> [ 12.156542] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
> [ 16.822251] SysRq : Keyboard mode set to system default
> [ 18.165412] SysRq : Terminate All Tasks
> [ 18.165722] ------------[ cut here ]------------
> [ 18.165825] WARNING: at crypto/algapi.c:329 crypto_wait_for_test+0x55/0x70()
> [ 18.165846] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169 mii usbcore usb_common thermal thermal_sys
> [ 18.165847] CPU: 3 PID: 273 Comm: modprobe Tainted: G D W 3.10.0-rc1+ #2
> [ 18.165849] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010
> [ 18.165851] ffffffff8141eaf7 ffffffff810390fa ffff8800b669b400 ffff8800b669b400
> [ 18.165853] ffffffffa016f660 ffffffffa016f6b0 0000000000000001 ffffffff8120e4d5
> [ 18.165854] 0000000000000000 ffffffff8120e634 ffffffffa0046000 0000000000000000
> [ 18.165855] Call Trace:
> [ 18.165858] [<ffffffff8141eaf7>] ? dump_stack+0xc/0x15
> [ 18.165861] [<ffffffff810390fa>] ? warn_slowpath_common+0x6a/0xa0
> [ 18.165863] [<ffffffff8120e4d5>] ? crypto_wait_for_test+0x55/0x70
> [ 18.165864] [<ffffffff8120e634>] ? crypto_register_alg+0x64/0x80
> [ 18.165867] [<ffffffffa0046000>] ? 0xffffffffa0045fff
> [ 18.165868] [<ffffffff810002fa>] ? do_one_initcall+0x10a/0x160
> [ 18.165873] [<ffffffff81090a57>] ? load_module+0x1b37/0x2450
> [ 18.165875] [<ffffffff8108ca90>] ? unset_module_init_ro_nx+0x80/0x80
> [ 18.165877] [<ffffffff81091430>] ? SyS_init_module+0xc0/0xf0
> [ 18.165879] [<ffffffff81423852>] ? system_call_fastpath+0x16/0x1b
> [ 18.165880] ---[ end trace 0382cf30f3465fd2 ]---
> [ 18.166140] bio: create slab <bio-1> at 1
> [ 20.123114] SysRq : Kill All Tasks
> [ 20.882858] SysRq : Emergency Sync
> [ 20.883148] Emergency Sync complete
> [ 22.531845] SysRq : Emergency Remount R/O
> [ 22.532141] Emergency Remount complete
> [ 23.386434] SysRq : Resetting
> [ 23.386663] ACPI MEMORY or I/O RESET_REG.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: 23-sha256-ssse3-fix-stack-corruption.patch --]
[-- Type: text/x-patch, Size: 1308 bytes --]
crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations
From: Jussi Kivilinna <jussi.kivilinna@iki.fi>
The _XFER stack element size was set too small, 8 bytes, when it needs to be
16 bytes. As _XFER is the last stack element used by these implementations,
the 16 byte stores with 'movdqa' corrupt the stack where the value of register
%r12 is temporarily stored. As implementations align stack to 16 bytes, this
corruption did not happen every time.
Patch corrects this issue.
---
arch/x86/crypto/sha256-avx-asm.S | 2 +-
arch/x86/crypto/sha256-ssse3-asm.S | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/crypto/sha256-avx-asm.S b/arch/x86/crypto/sha256-avx-asm.S
index 56610c4..642f156 100644
--- a/arch/x86/crypto/sha256-avx-asm.S
+++ b/arch/x86/crypto/sha256-avx-asm.S
@@ -118,7 +118,7 @@ y2 = %r15d
_INP_END_SIZE = 8
_INP_SIZE = 8
-_XFER_SIZE = 8
+_XFER_SIZE = 16
_XMM_SAVE_SIZE = 0
_INP_END = 0
diff --git a/arch/x86/crypto/sha256-ssse3-asm.S b/arch/x86/crypto/sha256-ssse3-asm.S
index 98d3c39..f833b74 100644
--- a/arch/x86/crypto/sha256-ssse3-asm.S
+++ b/arch/x86/crypto/sha256-ssse3-asm.S
@@ -111,7 +111,7 @@ y2 = %r15d
_INP_END_SIZE = 8
_INP_SIZE = 8
-_XFER_SIZE = 8
+_XFER_SIZE = 16
_XMM_SAVE_SIZE = 0
_INP_END = 0
^ permalink raw reply related
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Tim Chen @ 2013-05-20 19:09 UTC (permalink / raw)
To: Herbert Xu
Cc: Geert Uytterhoeven, Xiong Zhou, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <20130520114707.GA1187@gondor.apana.org.au>
On Mon, 2013-05-20 at 19:47 +0800, Herbert Xu wrote:
>
> Nope this is still broken. We need to move the actual crct10dif
> code into crypto/. I'll fix up the patch in the tree.
>
> Also I'm going to get rid of crc_t10dif_update_lib function. If you
> still want to maintain the ordering you should do so using the
> *_init constructs.
>
Herbert,
I used the following constructs in the pclmulqdq version of t10dif
to get the module loaded.
static const struct x86_cpu_id crct10dif_cpu_id[] = {
X86_FEATURE_MATCH(X86_FEATURE_PCLMULQDQ),
{}
};
MODULE_DEVICE_TABLE(x86cpu, crct10dif_cpu_id);
However, the default generic algorithm is used
in the library function. The options CRC_T10DIF, CRYPTO_CRCT10DIF
and CRYPTO_CRCT10DIF_PCLMUL are selected as modules (which
is most likely usage scenario in distribution) on my
test machine. The library module and generic crypto module was loaded
before the pclmulqdq t10dif module during boot. How should
things be changed to get this crypto module loaded earlier before the
library? Should we add another init call level between fs and device
init calls for loading the available crypto algorithms?
The crc_t10dif_update_lib was originally used to side step this issue.
BTW, latest crypto-dev need the following modification if we get
rid of crc_t10dif_update_lib.
Thanks.
Tim
diff --git a/arch/x86/crypto/crct10dif-pclmul_glue.c
b/arch/x86/crypto/crct10dif-pclmul_glue.c
index 3c0abd3..d838b7f 100644
--- a/arch/x86/crypto/crct10dif-pclmul_glue.c
+++ b/arch/x86/crypto/crct10dif-pclmul_glue.c
@@ -136,8 +136,6 @@ static int __init crct10dif_intel_mod_init(void)
return -ENODEV;
ret = crypto_register_shash(&alg);
- if (!ret)
- crc_t10dif_update_lib();
return ret;
}
^ permalink raw reply related
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Linus Walleij @ 2013-05-20 12:19 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-21-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:
> 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-l0cyMroinI0@public.gmane.org>
> Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@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>
I have now gone over and collected ACKs etc for the patches up until here.
Now you need Felipe's consent to proceed with the MUSB changes
through my tree.
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 19/39] ARM: ux500: Register Cyrp and Hash platform drivers on Snowball
From: Linus Walleij @ 2013-05-20 12:17 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-20-git-send-email-lee.jones@linaro.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
> These drivers are now operational and even use the latest common clk
> and DMA APIs. There's no reason why we shouldn't start them up now.
>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Patch applied now that the deps are in place.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 18/39] crypto: ux500/[cryp|hash] - Show successful start-up in the bootlog
From: Linus Walleij @ 2013-05-20 12:15 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, Andreas Westin
In-Reply-To: <1368611522-9984-19-git-send-email-lee.jones@linaro.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
> The Cryp driver is currently silent and the Hash driver prints the
> name of its probe function unnecessarily. Let's just put a nice
> descriptive one-liner there instead.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andreas Westin <andreas.westin@stericsson.com>
> Cc: linux-crypto@vger.kernel.org
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Patch applied with Herbert's ACK.
Thanks,
Linus Walleij
^ permalink raw reply
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Herbert Xu @ 2013-05-20 12:14 UTC (permalink / raw)
To: Tim Chen
Cc: Geert Uytterhoeven, Xiong Zhou, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <20130520114707.GA1187@gondor.apana.org.au>
On Mon, May 20, 2013 at 07:47:07PM +0800, Herbert Xu wrote:
> On Thu, May 16, 2013 at 11:03:32AM -0700, Tim Chen wrote:
> >
> > Need to also add select CRYPTO for CRC_T10DIF. Updated fix below:
> >
> >
> > Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
> > ---
> > diff --git a/crypto/Kconfig b/crypto/Kconfig
> > index d1ca631..015df24 100644
> > --- a/crypto/Kconfig
> > +++ b/crypto/Kconfig
> > @@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
> > config CRYPTO_CRCT10DIF
> > tristate "CRCT10DIF algorithm"
> > select CRYPTO_HASH
> > + depends on CRC_T10DIF
> > help
> > CRC T10 Data Integrity Field computation is being cast as
> > a crypto transform. This allows for faster crc t10 diff
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index 0cee056..6407793 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -63,7 +63,8 @@ config CRC16
> >
> > config CRC_T10DIF
> > tristate "CRC calculation for the T10 Data Integrity Field"
> > - select CRYPTO_CRCT10DIF
> > + select CRYPTO
> > + select CRYPTO_HASH
> > help
> > This option is only needed if a module that's not in the
> > kernel tree needs to calculate CRC checks for use with the
>
> Nope this is still broken. We need to move the actual crct10dif
> code into crypto/. I'll fix up the patch in the tree.
>
> Also I'm going to get rid of crc_t10dif_update_lib function. If you
> still want to maintain the ordering you should do so using the
> *_init constructs.
Here is the updated patch in question:
commit 2d31e518a42828df7877bca23a958627d60408bc
Author: Tim Chen <tim.c.chen@linux.intel.com>
Date: Wed May 1 12:52:48 2013 -0700
crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework
When CRC T10 DIF is calculated using the crypto transform framework, we
wrap the crc_t10dif function call to utilize it. This allows us to
take advantage of any accelerated CRC T10 DIF transform that is
plugged into the crypto framework.
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 622d8a4..ceb3611 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -376,6 +376,14 @@ config CRYPTO_CRC32_PCLMUL
which will enable any routine to use the CRC-32-IEEE 802.3 checksum
and gain better performance as compared with the table implementation.
+config CRYPTO_CRCT10DIF
+ tristate "CRCT10DIF algorithm"
+ select CRYPTO_HASH
+ help
+ CRC T10 Data Integrity Field computation is being cast as
+ a crypto transform. This allows for faster crc t10 diff
+ transforms to be used if they are available.
+
config CRYPTO_GHASH
tristate "GHASH digest algorithm"
select CRYPTO_GF128MUL
diff --git a/crypto/Makefile b/crypto/Makefile
index a8e9b0f..62af87d 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_CRYPTO_ZLIB) += zlib.o
obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += michael_mic.o
obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o
obj-$(CONFIG_CRYPTO_CRC32) += crc32.o
+obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif.o
obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o authencesn.o
obj-$(CONFIG_CRYPTO_LZO) += lzo.o
obj-$(CONFIG_CRYPTO_842) += 842.o
diff --git a/crypto/crct10dif.c b/crypto/crct10dif.c
new file mode 100644
index 0000000..92aca96
--- /dev/null
+++ b/crypto/crct10dif.c
@@ -0,0 +1,178 @@
+/*
+ * Cryptographic API.
+ *
+ * T10 Data Integrity Field CRC16 Crypto Transform
+ *
+ * Copyright (c) 2007 Oracle Corporation. All rights reserved.
+ * Written by Martin K. Petersen <martin.petersen@oracle.com>
+ * Copyright (C) 2013 Intel Corporation
+ * Author: Tim Chen <tim.c.chen@linux.intel.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+#include <linux/types.h>
+#include <linux/module.h>
+#include <linux/crc-t10dif.h>
+#include <crypto/internal/hash.h>
+#include <linux/init.h>
+#include <linux/string.h>
+#include <linux/kernel.h>
+
+struct chksum_desc_ctx {
+ __u16 crc;
+};
+
+/* Table generated using the following polynomium:
+ * x^16 + x^15 + x^11 + x^9 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
+ * gt: 0x8bb7
+ */
+static const __u16 t10_dif_crc_table[256] = {
+ 0x0000, 0x8BB7, 0x9CD9, 0x176E, 0xB205, 0x39B2, 0x2EDC, 0xA56B,
+ 0xEFBD, 0x640A, 0x7364, 0xF8D3, 0x5DB8, 0xD60F, 0xC161, 0x4AD6,
+ 0x54CD, 0xDF7A, 0xC814, 0x43A3, 0xE6C8, 0x6D7F, 0x7A11, 0xF1A6,
+ 0xBB70, 0x30C7, 0x27A9, 0xAC1E, 0x0975, 0x82C2, 0x95AC, 0x1E1B,
+ 0xA99A, 0x222D, 0x3543, 0xBEF4, 0x1B9F, 0x9028, 0x8746, 0x0CF1,
+ 0x4627, 0xCD90, 0xDAFE, 0x5149, 0xF422, 0x7F95, 0x68FB, 0xE34C,
+ 0xFD57, 0x76E0, 0x618E, 0xEA39, 0x4F52, 0xC4E5, 0xD38B, 0x583C,
+ 0x12EA, 0x995D, 0x8E33, 0x0584, 0xA0EF, 0x2B58, 0x3C36, 0xB781,
+ 0xD883, 0x5334, 0x445A, 0xCFED, 0x6A86, 0xE131, 0xF65F, 0x7DE8,
+ 0x373E, 0xBC89, 0xABE7, 0x2050, 0x853B, 0x0E8C, 0x19E2, 0x9255,
+ 0x8C4E, 0x07F9, 0x1097, 0x9B20, 0x3E4B, 0xB5FC, 0xA292, 0x2925,
+ 0x63F3, 0xE844, 0xFF2A, 0x749D, 0xD1F6, 0x5A41, 0x4D2F, 0xC698,
+ 0x7119, 0xFAAE, 0xEDC0, 0x6677, 0xC31C, 0x48AB, 0x5FC5, 0xD472,
+ 0x9EA4, 0x1513, 0x027D, 0x89CA, 0x2CA1, 0xA716, 0xB078, 0x3BCF,
+ 0x25D4, 0xAE63, 0xB90D, 0x32BA, 0x97D1, 0x1C66, 0x0B08, 0x80BF,
+ 0xCA69, 0x41DE, 0x56B0, 0xDD07, 0x786C, 0xF3DB, 0xE4B5, 0x6F02,
+ 0x3AB1, 0xB106, 0xA668, 0x2DDF, 0x88B4, 0x0303, 0x146D, 0x9FDA,
+ 0xD50C, 0x5EBB, 0x49D5, 0xC262, 0x6709, 0xECBE, 0xFBD0, 0x7067,
+ 0x6E7C, 0xE5CB, 0xF2A5, 0x7912, 0xDC79, 0x57CE, 0x40A0, 0xCB17,
+ 0x81C1, 0x0A76, 0x1D18, 0x96AF, 0x33C4, 0xB873, 0xAF1D, 0x24AA,
+ 0x932B, 0x189C, 0x0FF2, 0x8445, 0x212E, 0xAA99, 0xBDF7, 0x3640,
+ 0x7C96, 0xF721, 0xE04F, 0x6BF8, 0xCE93, 0x4524, 0x524A, 0xD9FD,
+ 0xC7E6, 0x4C51, 0x5B3F, 0xD088, 0x75E3, 0xFE54, 0xE93A, 0x628D,
+ 0x285B, 0xA3EC, 0xB482, 0x3F35, 0x9A5E, 0x11E9, 0x0687, 0x8D30,
+ 0xE232, 0x6985, 0x7EEB, 0xF55C, 0x5037, 0xDB80, 0xCCEE, 0x4759,
+ 0x0D8F, 0x8638, 0x9156, 0x1AE1, 0xBF8A, 0x343D, 0x2353, 0xA8E4,
+ 0xB6FF, 0x3D48, 0x2A26, 0xA191, 0x04FA, 0x8F4D, 0x9823, 0x1394,
+ 0x5942, 0xD2F5, 0xC59B, 0x4E2C, 0xEB47, 0x60F0, 0x779E, 0xFC29,
+ 0x4BA8, 0xC01F, 0xD771, 0x5CC6, 0xF9AD, 0x721A, 0x6574, 0xEEC3,
+ 0xA415, 0x2FA2, 0x38CC, 0xB37B, 0x1610, 0x9DA7, 0x8AC9, 0x017E,
+ 0x1F65, 0x94D2, 0x83BC, 0x080B, 0xAD60, 0x26D7, 0x31B9, 0xBA0E,
+ 0xF0D8, 0x7B6F, 0x6C01, 0xE7B6, 0x42DD, 0xC96A, 0xDE04, 0x55B3
+};
+
+__u16 crc_t10dif_generic(__u16 crc, const unsigned char *buffer, size_t len)
+{
+ unsigned int i;
+
+ for (i = 0 ; i < len ; i++)
+ crc = (crc << 8) ^ t10_dif_crc_table[((crc >> 8) ^ buffer[i]) & 0xff];
+
+ return crc;
+}
+EXPORT_SYMBOL(crc_t10dif_generic);
+
+/*
+ * Steps through buffer one byte at at time, calculates reflected
+ * crc using table.
+ */
+
+static int chksum_init(struct shash_desc *desc)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ ctx->crc = 0;
+
+ return 0;
+}
+
+static int chksum_update(struct shash_desc *desc, const u8 *data,
+ unsigned int length)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ ctx->crc = crc_t10dif_generic(ctx->crc, data, length);
+ return 0;
+}
+
+static int chksum_final(struct shash_desc *desc, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ *(__u16 *)out = ctx->crc;
+ return 0;
+}
+
+static int __chksum_finup(__u16 *crcp, const u8 *data, unsigned int len,
+ u8 *out)
+{
+ *(__u16 *)out = crc_t10dif_generic(*crcp, data, len);
+ return 0;
+}
+
+static int chksum_finup(struct shash_desc *desc, const u8 *data,
+ unsigned int len, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ return __chksum_finup(&ctx->crc, data, len, out);
+}
+
+static int chksum_digest(struct shash_desc *desc, const u8 *data,
+ unsigned int length, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ return __chksum_finup(&ctx->crc, data, length, out);
+}
+
+static struct shash_alg alg = {
+ .digestsize = CRC_T10DIF_DIGEST_SIZE,
+ .init = chksum_init,
+ .update = chksum_update,
+ .final = chksum_final,
+ .finup = chksum_finup,
+ .digest = chksum_digest,
+ .descsize = sizeof(struct chksum_desc_ctx),
+ .base = {
+ .cra_name = "crct10dif",
+ .cra_driver_name = "crct10dif-generic",
+ .cra_priority = 100,
+ .cra_blocksize = CRC_T10DIF_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static int __init crct10dif_mod_init(void)
+{
+ int ret;
+
+ ret = crypto_register_shash(&alg);
+ return ret;
+}
+
+static void __exit crct10dif_mod_fini(void)
+{
+ crypto_unregister_shash(&alg);
+}
+
+module_init(crct10dif_mod_init);
+module_exit(crct10dif_mod_fini);
+
+MODULE_AUTHOR("Tim Chen <tim.c.chen@linux.intel.com>");
+MODULE_DESCRIPTION("T10 DIF CRC calculation.");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/crc-t10dif.h b/include/linux/crc-t10dif.h
index a9c96d8..b3cb71f 100644
--- a/include/linux/crc-t10dif.h
+++ b/include/linux/crc-t10dif.h
@@ -3,6 +3,10 @@
#include <linux/types.h>
+#define CRC_T10DIF_DIGEST_SIZE 2
+#define CRC_T10DIF_BLOCK_SIZE 1
+
+__u16 crc_t10dif_generic(__u16 crc, const unsigned char *buffer, size_t len);
__u16 crc_t10dif(unsigned char const *, size_t);
#endif
diff --git a/lib/Kconfig b/lib/Kconfig
index fe01d41..339d5a4 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -63,6 +63,8 @@ config CRC16
config CRC_T10DIF
tristate "CRC calculation for the T10 Data Integrity Field"
+ select CRYPTO
+ select CRYPTO_CRCT10DIF
help
This option is only needed if a module that's not in the
kernel tree needs to calculate CRC checks for use with the
diff --git a/lib/crc-t10dif.c b/lib/crc-t10dif.c
index fbbd66e..0cb6463 100644
--- a/lib/crc-t10dif.c
+++ b/lib/crc-t10dif.c
@@ -11,57 +11,46 @@
#include <linux/types.h>
#include <linux/module.h>
#include <linux/crc-t10dif.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <crypto/hash.h>
-/* Table generated using the following polynomium:
- * x^16 + x^15 + x^11 + x^9 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
- * gt: 0x8bb7
- */
-static const __u16 t10_dif_crc_table[256] = {
- 0x0000, 0x8BB7, 0x9CD9, 0x176E, 0xB205, 0x39B2, 0x2EDC, 0xA56B,
- 0xEFBD, 0x640A, 0x7364, 0xF8D3, 0x5DB8, 0xD60F, 0xC161, 0x4AD6,
- 0x54CD, 0xDF7A, 0xC814, 0x43A3, 0xE6C8, 0x6D7F, 0x7A11, 0xF1A6,
- 0xBB70, 0x30C7, 0x27A9, 0xAC1E, 0x0975, 0x82C2, 0x95AC, 0x1E1B,
- 0xA99A, 0x222D, 0x3543, 0xBEF4, 0x1B9F, 0x9028, 0x8746, 0x0CF1,
- 0x4627, 0xCD90, 0xDAFE, 0x5149, 0xF422, 0x7F95, 0x68FB, 0xE34C,
- 0xFD57, 0x76E0, 0x618E, 0xEA39, 0x4F52, 0xC4E5, 0xD38B, 0x583C,
- 0x12EA, 0x995D, 0x8E33, 0x0584, 0xA0EF, 0x2B58, 0x3C36, 0xB781,
- 0xD883, 0x5334, 0x445A, 0xCFED, 0x6A86, 0xE131, 0xF65F, 0x7DE8,
- 0x373E, 0xBC89, 0xABE7, 0x2050, 0x853B, 0x0E8C, 0x19E2, 0x9255,
- 0x8C4E, 0x07F9, 0x1097, 0x9B20, 0x3E4B, 0xB5FC, 0xA292, 0x2925,
- 0x63F3, 0xE844, 0xFF2A, 0x749D, 0xD1F6, 0x5A41, 0x4D2F, 0xC698,
- 0x7119, 0xFAAE, 0xEDC0, 0x6677, 0xC31C, 0x48AB, 0x5FC5, 0xD472,
- 0x9EA4, 0x1513, 0x027D, 0x89CA, 0x2CA1, 0xA716, 0xB078, 0x3BCF,
- 0x25D4, 0xAE63, 0xB90D, 0x32BA, 0x97D1, 0x1C66, 0x0B08, 0x80BF,
- 0xCA69, 0x41DE, 0x56B0, 0xDD07, 0x786C, 0xF3DB, 0xE4B5, 0x6F02,
- 0x3AB1, 0xB106, 0xA668, 0x2DDF, 0x88B4, 0x0303, 0x146D, 0x9FDA,
- 0xD50C, 0x5EBB, 0x49D5, 0xC262, 0x6709, 0xECBE, 0xFBD0, 0x7067,
- 0x6E7C, 0xE5CB, 0xF2A5, 0x7912, 0xDC79, 0x57CE, 0x40A0, 0xCB17,
- 0x81C1, 0x0A76, 0x1D18, 0x96AF, 0x33C4, 0xB873, 0xAF1D, 0x24AA,
- 0x932B, 0x189C, 0x0FF2, 0x8445, 0x212E, 0xAA99, 0xBDF7, 0x3640,
- 0x7C96, 0xF721, 0xE04F, 0x6BF8, 0xCE93, 0x4524, 0x524A, 0xD9FD,
- 0xC7E6, 0x4C51, 0x5B3F, 0xD088, 0x75E3, 0xFE54, 0xE93A, 0x628D,
- 0x285B, 0xA3EC, 0xB482, 0x3F35, 0x9A5E, 0x11E9, 0x0687, 0x8D30,
- 0xE232, 0x6985, 0x7EEB, 0xF55C, 0x5037, 0xDB80, 0xCCEE, 0x4759,
- 0x0D8F, 0x8638, 0x9156, 0x1AE1, 0xBF8A, 0x343D, 0x2353, 0xA8E4,
- 0xB6FF, 0x3D48, 0x2A26, 0xA191, 0x04FA, 0x8F4D, 0x9823, 0x1394,
- 0x5942, 0xD2F5, 0xC59B, 0x4E2C, 0xEB47, 0x60F0, 0x779E, 0xFC29,
- 0x4BA8, 0xC01F, 0xD771, 0x5CC6, 0xF9AD, 0x721A, 0x6574, 0xEEC3,
- 0xA415, 0x2FA2, 0x38CC, 0xB37B, 0x1610, 0x9DA7, 0x8AC9, 0x017E,
- 0x1F65, 0x94D2, 0x83BC, 0x080B, 0xAD60, 0x26D7, 0x31B9, 0xBA0E,
- 0xF0D8, 0x7B6F, 0x6C01, 0xE7B6, 0x42DD, 0xC96A, 0xDE04, 0x55B3
-};
+static struct crypto_shash *crct10dif_tfm;
__u16 crc_t10dif(const unsigned char *buffer, size_t len)
{
- __u16 crc = 0;
- unsigned int i;
+ struct {
+ struct shash_desc shash;
+ char ctx[2];
+ } desc;
+ int err;
+
+ desc.shash.tfm = crct10dif_tfm;
+ desc.shash.flags = 0;
+ *(__u16 *)desc.ctx = 0;
- for (i = 0 ; i < len ; i++)
- crc = (crc << 8) ^ t10_dif_crc_table[((crc >> 8) ^ buffer[i]) & 0xff];
+ err = crypto_shash_update(&desc.shash, buffer, len);
+ BUG_ON(err);
- return crc;
+ return *(__u16 *)desc.ctx;
}
EXPORT_SYMBOL(crc_t10dif);
+static int __init crc_t10dif_mod_init(void)
+{
+ crct10dif_tfm = crypto_alloc_shash("crct10dif", 0, 0);
+ if (IS_ERR(crct10dif_tfm))
+ return PTR_ERR(crct10dif_tfm);
+ return 0;
+}
+
+static void __exit crc_t10dif_mod_fini(void)
+{
+ crypto_free_shash(crct10dif_tfm);
+}
+
+module_init(crc_t10dif_mod_init);
+module_exit(crc_t10dif_mod_fini);
+
MODULE_DESCRIPTION("T10 DIF CRC calculation");
MODULE_LICENSE("GPL");
Cheers,
--
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 related
* Re: [PATCH 16/39] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()
From: Linus Walleij @ 2013-05-20 12:12 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, Andreas Westin
In-Reply-To: <1368611522-9984-17-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 controller currently takes configuration information from
> information passed though dma_channel_request(), but it shouldn't.
> Using the API, the DMA channel should only be configured during
> a dma_slave_config() call.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andreas Westin <andreas.westin@stericsson.com>
> Cc: linux-crypto@vger.kernel.org
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Patch applied with Herbert's ACK.
Thanks,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 15/39] crypto: ux500/cryp - Prepare clock before enabling it
From: Linus Walleij @ 2013-05-20 12:10 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, Andreas Westin
In-Reply-To: <1368611522-9984-16-git-send-email-lee.jones@linaro.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
> If we fail to prepare the ux500-cryp clock before enabling it the
> platform will fail to boot. Here we insure this happens.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andreas Westin <andreas.westin@stericsson.com>
> Cc: linux-crypto@vger.kernel.org
> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Patch applied with Herbert's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 14/39] ARM: ux500: Stop passing Hash DMA channel config information though pdata
From: Linus Walleij @ 2013-05-20 12:09 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-15-git-send-email-lee.jones@linaro.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
> DMA channel configuration information should be setup in the driver.
> The Ux500 Hash driver now does this, so there's no need to send it
> though here too.
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Patch applied now that the deps are in!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 13/39] crypto: ux500/hash - Set DMA configuration though dma_slave_config()
From: Linus Walleij @ 2013-05-20 12:06 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, Andreas Westin
In-Reply-To: <1368611522-9984-14-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:
> The DMA controller currently takes configuration information from
> information passed though dma_channel_request(), but it shouldn't.
> Using the API, the DMA channel should only be configured during
> a dma_slave_config() call.
>
> Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
> Cc: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
> Cc: Andreas Westin <andreas.westin-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
> Cc: linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Signed-off-by: Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Patch applied to my dma40 branch with Herbert'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
* Re: [PATCH 12/39] crypto: ux500/hash - Prepare clock before enabling it
From: Linus Walleij @ 2013-05-20 12:05 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, Andreas Westin
In-Reply-To: <1368611522-9984-13-git-send-email-lee.jones@linaro.org>
On Wed, May 15, 2013 at 11:51 AM, Lee Jones <lee.jones@linaro.org> wrote:
> If we fail to prepare the ux500-hash clock before enabling it the
> platform will fail to boot. Here we insure this happens.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Andreas Westin <andreas.westin@stericsson.com>
> Cc: linux-crypto@vger.kernel.org
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Patch applied to my dma40 branch with Herbert's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 02/39] dmaengine: ste_dma40: Remove unnecessary call to d40_phy_cfg()
From: Linus Walleij @ 2013-05-20 12:01 UTC (permalink / raw)
To: Lee Jones
Cc: Vinod Koul, 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, Arnd Bergmann, Linus WALLEIJ,
Srinidhi KASAGAR
In-Reply-To: <20130516105959.GI3269@gmail.com>
On Thu, May 16, 2013 at 12:59 PM, Lee Jones <lee.jones@linaro.org> wrote:
> On Thu, 16 May 2013, Vinod Koul wrote:
>
>> On Thu, May 16, 2013 at 08:25:57AM +0100, Lee Jones wrote:
>> > On Thu, 16 May 2013, Vinod Koul wrote:
>> >
>> > > On Wed, May 15, 2013 at 10:51:25AM +0100, Lee Jones wrote:
>> > > > All configuration left in d40_phy_cfg() is runtime configurable and
>> > > > there is already a call into it from d40_runtime_config(), so let's
>> > > > rely on that.
>> > > >
>> > > > Acked-by: Vinod Koul <vnod.koul@intel.com>
>> > > That needs up update!
>> >
>> > Ah, where did I get that from that?
>> >
>> > Was that my mistake, or was this in the MAINTAINERS file?
>> Certainly not in MAINTAINERS file :)
>
> My bad then, sorry.
>
> Linus,
>
> Would you be kind enough to fix it please, as it's in your tree now.
I've fixed it up!
Yours,
Linus Walleij
^ permalink raw reply
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Herbert Xu @ 2013-05-20 11:47 UTC (permalink / raw)
To: Tim Chen
Cc: Geert Uytterhoeven, Xiong Zhou, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <1368727412.27102.289.camel@schen9-DESK>
On Thu, May 16, 2013 at 11:03:32AM -0700, Tim Chen wrote:
>
> Need to also add select CRYPTO for CRC_T10DIF. Updated fix below:
>
>
> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
> ---
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index d1ca631..015df24 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
> config CRYPTO_CRCT10DIF
> tristate "CRCT10DIF algorithm"
> select CRYPTO_HASH
> + depends on CRC_T10DIF
> help
> CRC T10 Data Integrity Field computation is being cast as
> a crypto transform. This allows for faster crc t10 diff
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 0cee056..6407793 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -63,7 +63,8 @@ config CRC16
>
> config CRC_T10DIF
> tristate "CRC calculation for the T10 Data Integrity Field"
> - select CRYPTO_CRCT10DIF
> + select CRYPTO
> + select CRYPTO_HASH
> help
> This option is only needed if a module that's not in the
> kernel tree needs to calculate CRC checks for use with the
Nope this is still broken. We need to move the actual crct10dif
code into crypto/. I'll fix up the patch in the tree.
Also I'm going to get rid of crc_t10dif_update_lib function. If you
still want to maintain the ordering you should do so using the
*_init constructs.
Cheers,
--
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
* NIST SP800-138 availibility using kernel crypto APIs for SMB3.0 MAC generation
From: Shirish Pargaonkar @ 2013-05-20 2:49 UTC (permalink / raw)
To: LKML, linux-crypto, linux-cifs
With the recent patches added to kernel crypto for improving AES
support, adding aesni etc, it seems like it is time to add AES CMAC
to the cifs kernel module (for the popular SMB3 signing and per-share
encryption) but needed for an implementation for SP800-138 in kernel
crypto codebase.
Was specifically interested using the way defined in 3.1.4.2 of
MS-SMB2 document, in particular
KDF in Counter mode (section 5.1 of NIST SP 800-108) or a way to specify a mode
PRF as HMAC-SHA256 (or a way to specify a PRF)
cifs client would use this algorithm for SMB3.0 MAC generation
(network packet signing on network file system mounts to newer
generation NAS, and Windows 2012) and also for per-share encryption
(which is also available on the most recent generation of NAS via
SMB3). Apparently with current Intel processors having hardware for
this kind of encryption offload - full packet encryption is faster
than packet signing used to be (with the older standard algorithms)
and just doing packet signing is really fast.
Are their APIs in crypto kernel code to use for this purpose?
Regards,
Shirish
^ permalink raw reply
* [PATCH v2 1/1] crypto: Added support for Freescale's DCP co-processor
From: Tobias Rauter @ 2013-05-19 19:59 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto; +Cc: Tobias Rauter
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>
---
arch/arm/boot/dts/imx28.dtsi | 2 +-
drivers/crypto/Kconfig | 10 +
drivers/crypto/Makefile | 1 +
drivers/crypto/dcp.c | 925 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 937 insertions(+), 1 deletion(-)
create mode 100644 drivers/crypto/dcp.c
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 600f7cb..077d0eb 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -699,7 +699,7 @@
dcp@80028000 {
reg = <0x80028000 0x2000>;
interrupts = <52 53 54>;
- status = "disabled";
+ compatible = "fsl-dcp";
};
pxp@8002a000 {
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index dffb855..3e11215 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -286,6 +286,16 @@ config CRYPTO_DEV_SAHARA
This option enables support for the SAHARA HW crypto accelerator
found in some Freescale i.MX chips.
+config CRYPTO_DEV_DCP
+ tristate "Support for the DCP engine"
+ depends on ARCH_MXS && OF
+ select CRYPTO_BLKCIPHER
+ select CRYPTO_AES
+ select CRYPTO_CBC
+ help
+ This options enables support for the hardware crypto-acceleration
+ capabilities of the DCP co-processor
+
config CRYPTO_DEV_S5P
tristate "Support for Samsung S5PV210 crypto accelerator"
depends on ARCH_S5PV210
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 38ce13d..b4946dd 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_CRYPTO_DEV_OMAP_SHAM) += omap-sham.o
obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o
obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o
obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o
+obj-$(CONFIG_CRYPTO_DEV_DCP) += dcp.o
obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o
obj-$(CONFIG_CRYPTO_DEV_TEGRA_AES) += tegra-aes.o
obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
diff --git a/drivers/crypto/dcp.c b/drivers/crypto/dcp.c
new file mode 100644
index 0000000..eea194c
--- /dev/null
+++ b/drivers/crypto/dcp.c
@@ -0,0 +1,925 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for DCP cryptographic accelerator.
+ *
+ * Copyright (c) 2013
+ * Author: Tobias Rauter <tobias.rauter@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ *
+ * Based on tegra-aes.c, dcp.c (from freescale SDK) and sahara.c
+ */
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/dma-mapping.h>
+#include <linux/io.h>
+#include <linux/mutex.h>
+#include <linux/interrupt.h>
+#include <linux/completion.h>
+#include <linux/workqueue.h>
+#include <linux/delay.h>
+#include <linux/crypto.h>
+#include <linux/miscdevice.h>
+
+#include <crypto/scatterwalk.h>
+#include <crypto/aes.h>
+
+
+/* IOCTL for DCP OTP Key AES - taken from Freescale's SDK*/
+#define DBS_IOCTL_BASE 'd'
+#define DBS_ENC _IOW(DBS_IOCTL_BASE, 0x00, uint8_t[16])
+#define DBS_DEC _IOW(DBS_IOCTL_BASE, 0x01, uint8_t[16])
+
+/* DCP channel used for AES */
+#define USED_CHANNEL 1
+/* Ring Buffers' maximum size */
+#define DCP_MAX_PKG 20
+
+/* Control Register */
+#define DCP_REG_CTRL 0x000
+#define DCP_CTRL_SFRST (1<<31)
+#define DCP_CTRL_CLKGATE (1<<30)
+#define DCP_CTRL_CRYPTO_PRESENT (1<<29)
+#define DCP_CTRL_SHA_PRESENT (1<<28)
+#define DCP_CTRL_GATHER_RES_WRITE (1<<23)
+#define DCP_CTRL_ENABLE_CONTEXT_CACHE (1<<22)
+#define DCP_CTRL_ENABLE_CONTEXT_SWITCH (1<<21)
+#define DCP_CTRL_CH_IRQ_E_0 0x01
+#define DCP_CTRL_CH_IRQ_E_1 0x02
+#define DCP_CTRL_CH_IRQ_E_2 0x04
+#define DCP_CTRL_CH_IRQ_E_3 0x08
+
+/* Status register */
+#define DCP_REG_STAT 0x010
+#define DCP_STAT_OTP_KEY_READY (1<<28)
+#define DCP_STAT_CUR_CHANNEL(stat) ((stat>>24)&0x0F)
+#define DCP_STAT_READY_CHANNEL(stat) ((stat>>16)&0x0F)
+#define DCP_STAT_IRQ(stat) (stat&0x0F)
+#define DCP_STAT_CHAN_0 (0x01)
+#define DCP_STAT_CHAN_1 (0x02)
+#define DCP_STAT_CHAN_2 (0x04)
+#define DCP_STAT_CHAN_3 (0x08)
+
+/* Channel Control Register */
+#define DCP_REG_CHAN_CTRL 0x020
+#define DCP_CHAN_CTRL_CH0_IRQ_MERGED (1<<16)
+#define DCP_CHAN_CTRL_HIGH_PRIO_0 (0x0100)
+#define DCP_CHAN_CTRL_HIGH_PRIO_1 (0x0200)
+#define DCP_CHAN_CTRL_HIGH_PRIO_2 (0x0400)
+#define DCP_CHAN_CTRL_HIGH_PRIO_3 (0x0800)
+#define DCP_CHAN_CTRL_ENABLE_0 (0x01)
+#define DCP_CHAN_CTRL_ENABLE_1 (0x02)
+#define DCP_CHAN_CTRL_ENABLE_2 (0x04)
+#define DCP_CHAN_CTRL_ENABLE_3 (0x08)
+
+/*
+ * Channel Registers:
+ * The DCP has 4 channels. Each of this channels
+ * has 4 registers (command pointer, semaphore, status and options).
+ * The address of register REG of channel CHAN is obtained by
+ * dcp_chan_reg(REG, CHAN)
+ */
+#define DCP_REG_CHAN_PTR 0x00000100
+#define DCP_REG_CHAN_SEMA 0x00000110
+#define DCP_REG_CHAN_STAT 0x00000120
+#define DCP_REG_CHAN_OPT 0x00000130
+
+#define DCP_CHAN_STAT_NEXT_CHAIN_IS_0 0x010000
+#define DCP_CHAN_STAT_NO_CHAIN 0x020000
+#define DCP_CHAN_STAT_CONTEXT_ERROR 0x030000
+#define DCP_CHAN_STAT_PAYLOAD_ERROR 0x040000
+#define DCP_CHAN_STAT_INVALID_MODE 0x050000
+#define DCP_CHAN_STAT_PAGEFAULT 0x40
+#define DCP_CHAN_STAT_DST 0x20
+#define DCP_CHAN_STAT_SRC 0x10
+#define DCP_CHAN_STAT_PACKET 0x08
+#define DCP_CHAN_STAT_SETUP 0x04
+#define DCP_CHAN_STAT_MISMATCH 0x02
+
+/* hw packet control*/
+
+#define DCP_PKT_PAYLOAD_KEY (1<<11)
+#define DCP_PKT_OTP_KEY (1<<10)
+#define DCP_PKT_CIPHER_INIT (1<<9)
+#define DCP_PKG_CIPHER_ENCRYPT (1<<8)
+#define DCP_PKT_CIPHER_ENABLE (1<<5)
+#define DCP_PKT_DECR_SEM (1<<1)
+#define DCP_PKT_CHAIN (1<<2)
+#define DCP_PKT_IRQ 1
+
+#define DCP_PKT_MODE_CBC (1<<4)
+#define DCP_PKT_KEYSELECT_OTP (0xFF<<8)
+
+/* cipher flags */
+#define DCP_ENC 0x0001
+#define DCP_DEC 0x0002
+#define DCP_ECB 0x0004
+#define DCP_CBC 0x0008
+#define DCP_CBC_INIT 0x0010
+#define DCP_NEW_KEY 0x0040
+#define DCP_OTP_KEY 0x0080
+#define DCP_AES 0x1000
+
+/* DCP Flags */
+#define DCP_FLAG_BUSY 0x01
+#define DCP_FLAG_PRODUCING 0x02
+
+/* clock defines */
+#define CLOCK_ON 1
+#define CLOCK_OFF 0
+
+struct dcp_dev_req_ctx {
+ int mode;
+};
+
+struct dcp_op {
+ unsigned int flags;
+ u8 key[AES_KEYSIZE_128];
+ int keylen;
+
+ struct ablkcipher_request *req;
+ struct crypto_ablkcipher *fallback;
+
+ uint32_t stat;
+ uint32_t pkt1;
+ uint32_t pkt2;
+ struct ablkcipher_walk walk;
+};
+
+struct dcp_dev {
+ struct device *dev;
+ void __iomem *dcp_regs_base;
+
+ int dcp_vmi_irq;
+ int dcp_irq;
+
+ spinlock_t queue_lock;
+ struct crypto_queue queue;
+
+ uint32_t pkt_produced;
+ uint32_t pkt_consumed;
+
+ struct dcp_hw_packet *hw_pkg[DCP_MAX_PKG];
+ dma_addr_t hw_phys_pkg;
+
+ /* [KEY][IV] Both with 16 Bytes */
+ u8 *payload_base;
+ dma_addr_t payload_base_dma;
+
+
+ struct tasklet_struct done_task;
+ struct tasklet_struct queue_task;
+ struct timer_list watchdog;
+
+ unsigned long flags;
+
+ struct dcp_op *ctx;
+
+ struct miscdevice dcp_bootstream_misc;
+};
+
+struct dcp_hw_packet {
+ uint32_t next;
+ uint32_t pkt1;
+ uint32_t pkt2;
+ uint32_t src;
+ uint32_t dst;
+ uint32_t size;
+ uint32_t payload;
+ uint32_t stat;
+};
+
+struct dcp_dev *global_dev;
+
+static inline u32 dcp_chan_reg(u32 reg, int chan)
+{
+ return reg + (chan) * 0x40;
+}
+
+static inline void dcp_write(struct dcp_dev *dev, u32 data, u32 reg)
+{
+ writel(data, dev->dcp_regs_base + reg);
+}
+
+static inline void dcp_set(struct dcp_dev *dev, u32 data, u32 reg)
+{
+ writel(data, dev->dcp_regs_base + (reg | 0x04));
+}
+
+static inline void dcp_clear(struct dcp_dev *dev, u32 data, u32 reg)
+{
+ writel(data, dev->dcp_regs_base + (reg | 0x08));
+}
+
+static inline void dcp_toggle(struct dcp_dev *dev, u32 data, u32 reg)
+{
+ writel(data, dev->dcp_regs_base + (reg | 0x0C));
+}
+
+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)
+{
+ 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,
+ struct ablkcipher_walk *walk, struct dcp_hw_packet *pkt)
+{
+ dev_dbg(dev->dev, "map packet %x", (unsigned int) pkt);
+ /* align to length = 16 */
+ pkt->size = walk->nbytes - (walk->nbytes % 16);
+
+ pkt->src = dma_map_page(dev->dev, walk->src.page, walk->src.offset,
+ pkt->size, DMA_TO_DEVICE);
+
+ if (pkt->src == 0) {
+ dev_err(dev->dev, "Unable to map src");
+ return -ENOMEM;
+ }
+
+ pkt->dst = dma_map_page(dev->dev, walk->dst.page, walk->dst.offset,
+ pkt->size, DMA_FROM_DEVICE);
+
+ if (pkt->dst == 0) {
+ dev_err(dev->dev, "Unable to map dst");
+ dma_unmap_page(dev->dev, pkt->src, pkt->size, DMA_TO_DEVICE);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void dcp_op_one(struct dcp_dev *dev, struct dcp_hw_packet *pkt,
+ uint8_t last)
+{
+ struct dcp_op *ctx = dev->ctx;
+ pkt->pkt1 = ctx->pkt1;
+ pkt->pkt2 = ctx->pkt2;
+
+ pkt->payload = (u32) dev->payload_base_dma;
+ pkt->stat = 0;
+
+ if (ctx->flags & DCP_CBC_INIT) {
+ pkt->pkt1 |= DCP_PKT_CIPHER_INIT;
+ ctx->flags &= ~DCP_CBC_INIT;
+ }
+
+ mod_timer(&dev->watchdog, jiffies + msecs_to_jiffies(500));
+ pkt->pkt1 |= DCP_PKT_IRQ;
+ if (!last)
+ pkt->pkt1 |= DCP_PKT_CHAIN;
+
+ dev->pkt_produced++;
+
+ dcp_write(dev, 1,
+ dcp_chan_reg(DCP_REG_CHAN_SEMA, USED_CHANNEL));
+}
+
+static void dcp_op_proceed(struct dcp_dev *dev)
+{
+ struct dcp_op *ctx = dev->ctx;
+ struct dcp_hw_packet *pkt;
+
+ while (ctx->walk.nbytes) {
+ int err = 0;
+
+ pkt = dev->hw_pkg[dev->pkt_produced % DCP_MAX_PKG];
+ err = dcp_dma_map(dev, &ctx->walk, pkt);
+ if (err) {
+ dev->ctx->stat |= err;
+ /* start timer to wait for already set up calls */
+ mod_timer(&dev->watchdog,
+ jiffies + msecs_to_jiffies(500));
+ break;
+ }
+
+
+ err = ctx->walk.nbytes - pkt->size;
+ ablkcipher_walk_done(dev->ctx->req, &dev->ctx->walk, err);
+
+ dcp_op_one(dev, pkt, ctx->walk.nbytes == 0);
+ /* we have to wait if no space is left in buffer */
+ if (dev->pkt_produced - dev->pkt_consumed == DCP_MAX_PKG)
+ break;
+ }
+ clear_bit(DCP_FLAG_PRODUCING, &dev->flags);
+}
+
+static void dcp_op_start(struct dcp_dev *dev, uint8_t use_walk)
+{
+ struct dcp_op *ctx = dev->ctx;
+
+ if (ctx->flags & DCP_NEW_KEY) {
+ memcpy(dev->payload_base, ctx->key, ctx->keylen);
+ ctx->flags &= ~DCP_NEW_KEY;
+ }
+
+ ctx->pkt1 = 0;
+ ctx->pkt1 |= DCP_PKT_CIPHER_ENABLE;
+ ctx->pkt1 |= DCP_PKT_DECR_SEM;
+
+ if (ctx->flags & DCP_OTP_KEY)
+ ctx->pkt1 |= DCP_PKT_OTP_KEY;
+ else
+ ctx->pkt1 |= DCP_PKT_PAYLOAD_KEY;
+
+ if (ctx->flags & DCP_ENC)
+ ctx->pkt1 |= DCP_PKG_CIPHER_ENCRYPT;
+
+ ctx->pkt2 = 0;
+ if (ctx->flags & DCP_CBC)
+ ctx->pkt2 |= DCP_PKT_MODE_CBC;
+
+ dev->pkt_produced = 0;
+ dev->pkt_consumed = 0;
+
+ ctx->stat = 0;
+ dcp_clear(dev, -1, dcp_chan_reg(DCP_REG_CHAN_STAT, USED_CHANNEL));
+ dcp_write(dev, (u32) dev->hw_phys_pkg,
+ dcp_chan_reg(DCP_REG_CHAN_PTR, USED_CHANNEL));
+
+ set_bit(DCP_FLAG_PRODUCING, &dev->flags);
+
+ if (use_walk) {
+ ablkcipher_walk_init(&ctx->walk, ctx->req->dst,
+ ctx->req->src, ctx->req->nbytes);
+ ablkcipher_walk_phys(ctx->req, &ctx->walk);
+ dcp_op_proceed(dev);
+ } else {
+ dcp_op_one(dev, dev->hw_pkg[0], 1);
+ clear_bit(DCP_FLAG_PRODUCING, &dev->flags);
+ }
+}
+
+static void dcp_done_task(unsigned long data)
+{
+ struct dcp_dev *dev = (struct dcp_dev *)data;
+ struct dcp_hw_packet *last_packet;
+ int fin;
+ fin = 0;
+
+ for (last_packet = dev->hw_pkg[(dev->pkt_consumed) % DCP_MAX_PKG];
+ last_packet->stat == 1;
+ last_packet =
+ dev->hw_pkg[++(dev->pkt_consumed) % DCP_MAX_PKG]) {
+
+ dcp_dma_unmap(dev, last_packet);
+ last_packet->stat = 0;
+ fin++;
+ }
+ /* the last call of this function already consumed this IRQ's packet */
+ if (fin == 0)
+ return;
+
+ dev_dbg(dev->dev,
+ "Packet(s) done with status %x; finished: %d, produced:%d, complete consumed: %d",
+ dev->ctx->stat, fin, dev->pkt_produced, dev->pkt_consumed);
+
+ last_packet = dev->hw_pkg[(dev->pkt_consumed - 1) % DCP_MAX_PKG];
+ if (!dev->ctx->stat && last_packet->pkt1 & DCP_PKT_CHAIN) {
+ if (!test_and_set_bit(DCP_FLAG_PRODUCING, &dev->flags))
+ dcp_op_proceed(dev);
+ return;
+ }
+
+ while (unlikely(dev->pkt_consumed < dev->pkt_produced)) {
+ dcp_dma_unmap(dev,
+ dev->hw_pkg[dev->pkt_consumed++ % DCP_MAX_PKG]);
+ }
+
+ if (dev->ctx->flags & DCP_OTP_KEY) {
+ /* we used the miscdevice, no walk to finish */
+ clear_bit(DCP_FLAG_BUSY, &dev->flags);
+ return;
+ }
+
+ ablkcipher_walk_complete(&dev->ctx->walk);
+ dev->ctx->req->base.complete(&dev->ctx->req->base,
+ dev->ctx->stat);
+ dev->ctx->req = 0;
+ /* in case there are other requests in the queue */
+ tasklet_schedule(&dev->queue_task);
+}
+
+void dcp_watchdog(unsigned long data)
+{
+ struct dcp_dev *dev = (struct dcp_dev *)data;
+ dev->ctx->stat |= dcp_read(dev,
+ dcp_chan_reg(DCP_REG_CHAN_STAT, USED_CHANNEL));
+
+ dev_err(dev->dev, "Timeout, Channel status: %x", dev->ctx->stat);
+
+ if (!dev->ctx->stat)
+ dev->ctx->stat = -ETIMEDOUT;
+
+ dcp_done_task(data);
+}
+
+
+static irqreturn_t dcp_common_irq(int irq, void *context)
+{
+ u32 msk;
+ struct dcp_dev *dev = (struct dcp_dev *) context;
+
+ del_timer(&dev->watchdog);
+
+ msk = DCP_STAT_IRQ(dcp_read(dev, DCP_REG_STAT));
+ dcp_clear(dev, msk, DCP_REG_STAT);
+ if (msk == 0)
+ return IRQ_NONE;
+
+ dev->ctx->stat |= dcp_read(dev,
+ dcp_chan_reg(DCP_REG_CHAN_STAT, USED_CHANNEL));
+
+ if (msk & DCP_STAT_CHAN_1)
+ tasklet_schedule(&dev->done_task);
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t dcp_vmi_irq(int irq, void *context)
+{
+ return dcp_common_irq(irq, context);
+}
+
+static irqreturn_t dcp_irq(int irq, void *context)
+{
+ return dcp_common_irq(irq, context);
+}
+
+static void dcp_crypt(struct dcp_dev *dev, struct dcp_op *ctx)
+{
+ dev->ctx = ctx;
+
+ if ((ctx->flags & DCP_CBC) && ctx->req->info) {
+ ctx->flags |= DCP_CBC_INIT;
+ memcpy(dev->payload_base + AES_KEYSIZE_128,
+ ctx->req->info, AES_KEYSIZE_128);
+ }
+
+ dcp_op_start(dev, 1);
+}
+
+static void dcp_queue_task(unsigned long data)
+{
+ struct dcp_dev *dev = (struct dcp_dev *) data;
+ struct crypto_async_request *async_req, *backlog;
+ struct crypto_ablkcipher *tfm;
+ struct dcp_op *ctx;
+ struct dcp_dev_req_ctx *rctx;
+ struct ablkcipher_request *req;
+ unsigned long flags;
+
+ spin_lock_irqsave(&dev->queue_lock, flags);
+
+ backlog = crypto_get_backlog(&dev->queue);
+ async_req = crypto_dequeue_request(&dev->queue);
+
+ spin_unlock_irqrestore(&dev->queue_lock, flags);
+
+ if (!async_req)
+ goto ret_nothing_done;
+
+ if (backlog)
+ backlog->complete(backlog, -EINPROGRESS);
+
+ req = ablkcipher_request_cast(async_req);
+ tfm = crypto_ablkcipher_reqtfm(req);
+ rctx = ablkcipher_request_ctx(req);
+ ctx = crypto_ablkcipher_ctx(tfm);
+
+ if (!req->src || !req->dst)
+ goto ret_nothing_done;
+
+ ctx->flags |= rctx->mode;
+ ctx->req = req;
+
+ dcp_crypt(dev, ctx);
+
+ return;
+
+ret_nothing_done:
+ clear_bit(DCP_FLAG_BUSY, &dev->flags);
+}
+
+
+static int dcp_cra_init(struct crypto_tfm *tfm)
+{
+ const char *name = tfm->__crt_alg->cra_name;
+ struct dcp_op *ctx = crypto_tfm_ctx(tfm);
+
+ tfm->crt_ablkcipher.reqsize = sizeof(struct dcp_dev_req_ctx);
+
+ ctx->fallback = crypto_alloc_ablkcipher(name, 0,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
+
+ if (IS_ERR(ctx->fallback)) {
+ dev_err(global_dev->dev, "Error allocating fallback algo %s\n",
+ name);
+ return PTR_ERR(ctx->fallback);
+ }
+
+ return 0;
+}
+
+static void dcp_cra_exit(struct crypto_tfm *tfm)
+{
+ struct dcp_op *ctx = crypto_tfm_ctx(tfm);
+
+ if (ctx->fallback)
+ crypto_free_ablkcipher(ctx->fallback);
+
+ ctx->fallback = NULL;
+}
+
+/* async interface */
+static int dcp_aes_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
+ unsigned int len)
+{
+ struct dcp_op *ctx = crypto_ablkcipher_ctx(tfm);
+ unsigned int ret = 0;
+ ctx->keylen = len;
+ ctx->flags = 0;
+ if (len == AES_KEYSIZE_128) {
+ if (memcmp(ctx->key, key, AES_KEYSIZE_128)) {
+ memcpy(ctx->key, key, len);
+ ctx->flags |= DCP_NEW_KEY;
+ }
+ return 0;
+ }
+
+ ctx->fallback->base.crt_flags &= ~CRYPTO_TFM_REQ_MASK;
+ ctx->fallback->base.crt_flags |=
+ (tfm->base.crt_flags & CRYPTO_TFM_REQ_MASK);
+
+ ret = crypto_ablkcipher_setkey(ctx->fallback, key, len);
+ if (ret) {
+ struct crypto_tfm *tfm_aux = crypto_ablkcipher_tfm(tfm);
+
+ tfm_aux->crt_flags &= ~CRYPTO_TFM_RES_MASK;
+ tfm_aux->crt_flags |=
+ (ctx->fallback->base.crt_flags & CRYPTO_TFM_RES_MASK);
+ }
+ return ret;
+}
+
+static int dcp_aes_cbc_crypt(struct ablkcipher_request *req, int mode)
+{
+ struct dcp_dev_req_ctx *rctx = ablkcipher_request_ctx(req);
+ struct dcp_dev *dev = global_dev;
+ unsigned long flags;
+ int err = 0;
+
+ if (!IS_ALIGNED(req->nbytes, AES_BLOCK_SIZE))
+ return -EINVAL;
+
+ rctx->mode = mode;
+
+ spin_lock_irqsave(&dev->queue_lock, flags);
+ err = ablkcipher_enqueue_request(&dev->queue, req);
+ spin_unlock_irqrestore(&dev->queue_lock, flags);
+
+ flags = test_and_set_bit(DCP_FLAG_BUSY, &dev->flags);
+
+ if (!(flags & DCP_FLAG_BUSY))
+ tasklet_schedule(&dev->queue_task);
+
+ return err;
+}
+
+static int dcp_aes_cbc_encrypt(struct ablkcipher_request *req)
+{
+ struct crypto_tfm *tfm =
+ crypto_ablkcipher_tfm(crypto_ablkcipher_reqtfm(req));
+ struct dcp_op *ctx = crypto_ablkcipher_ctx(
+ crypto_ablkcipher_reqtfm(req));
+
+ if (unlikely(ctx->keylen != AES_KEYSIZE_128)) {
+ int err = 0;
+ ablkcipher_request_set_tfm(req, ctx->fallback);
+ err = crypto_ablkcipher_encrypt(req);
+ ablkcipher_request_set_tfm(req, __crypto_ablkcipher_cast(tfm));
+ return err;
+ }
+
+ return dcp_aes_cbc_crypt(req, DCP_AES | DCP_ENC | DCP_CBC);
+}
+
+static int dcp_aes_cbc_decrypt(struct ablkcipher_request *req)
+{
+ struct crypto_tfm *tfm =
+ crypto_ablkcipher_tfm(crypto_ablkcipher_reqtfm(req));
+ struct dcp_op *ctx = crypto_ablkcipher_ctx(
+ crypto_ablkcipher_reqtfm(req));
+
+ if (unlikely(ctx->keylen != AES_KEYSIZE_128)) {
+ int err = 0;
+ ablkcipher_request_set_tfm(req, ctx->fallback);
+ err = crypto_ablkcipher_decrypt(req);
+ ablkcipher_request_set_tfm(req, __crypto_ablkcipher_cast(tfm));
+ return err;
+ }
+ return dcp_aes_cbc_crypt(req, DCP_AES | DCP_DEC | DCP_CBC);
+}
+
+static struct crypto_alg algs[] = {
+ {
+ .cra_name = "cbc(aes)",
+ .cra_driver_name = "dcp-cbc-aes",
+ .cra_alignmask = 3,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER | CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_NEED_FALLBACK,
+ .cra_blocksize = AES_KEYSIZE_128,
+ .cra_type = &crypto_ablkcipher_type,
+ .cra_priority = 300,
+ .cra_u.ablkcipher = {
+ .min_keysize = AES_KEYSIZE_128,
+ .max_keysize = AES_KEYSIZE_128,
+ .setkey = dcp_aes_setkey,
+ .encrypt = dcp_aes_cbc_encrypt,
+ .decrypt = dcp_aes_cbc_decrypt,
+ .ivsize = AES_KEYSIZE_128,
+ }
+
+ },
+};
+
+/* DCP bootstream verification interface: uses OTP key for crypto */
+static int dcp_bootstream_open(struct inode *inode, struct file *file)
+{
+ file->private_data = container_of((file->private_data),
+ struct dcp_dev, dcp_bootstream_misc);
+ return 0;
+}
+
+static long dcp_bootstream_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ struct dcp_dev *dev = (struct dcp_dev *) file->private_data;
+ void __user *argp = (void __user *)arg;
+ int ret;
+
+ if (dev == NULL)
+ return -EBADF;
+
+ if (cmd != DBS_ENC && cmd != DBS_DEC)
+ return -EINVAL;
+
+ if (copy_from_user(dev->payload_base, argp, 16))
+ return -EFAULT;
+
+ if (test_and_set_bit(DCP_FLAG_BUSY, &dev->flags))
+ return -EAGAIN;
+
+ dev->ctx = kzalloc(sizeof(struct dcp_op), GFP_KERNEL);
+ if (!dev->ctx) {
+ dev_err(dev->dev,
+ "cannot allocate context for OTP crypto");
+ clear_bit(DCP_FLAG_BUSY, &dev->flags);
+ return -ENOMEM;
+ }
+
+ dev->ctx->flags = DCP_AES | DCP_ECB | DCP_OTP_KEY | DCP_CBC_INIT;
+ dev->ctx->flags |= (cmd == DBS_ENC) ? DCP_ENC : DCP_DEC;
+ dev->hw_pkg[0]->src = dev->payload_base_dma;
+ dev->hw_pkg[0]->dst = dev->payload_base_dma;
+ dev->hw_pkg[0]->size = 16;
+
+ dcp_op_start(dev, 0);
+
+ while (test_bit(DCP_FLAG_BUSY, &dev->flags))
+ cpu_relax();
+
+ ret = dev->ctx->stat;
+ if (!ret && copy_to_user(argp, dev->payload_base, 16))
+ ret = -EFAULT;
+
+ kfree(dev->ctx);
+
+ return ret;
+}
+
+static const struct file_operations dcp_bootstream_fops = {
+ .owner = THIS_MODULE,
+ .unlocked_ioctl = dcp_bootstream_ioctl,
+ .open = dcp_bootstream_open,
+};
+
+static int dcp_probe(struct platform_device *pdev)
+{
+ struct dcp_dev *dev = NULL;
+ 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;
+ }
+ global_dev = dev;
+ dev->dev = &pdev->dev;
+
+ platform_set_drvdata(pdev, dev);
+
+ 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;
+ }
+ dev->dcp_regs_base = ioremap(r->start, resource_size(r));
+
+
+ dcp_set(dev, DCP_CTRL_SFRST, DCP_REG_CTRL);
+ udelay(10);
+ dcp_clear(dev, DCP_CTRL_SFRST | DCP_CTRL_CLKGATE, DCP_REG_CTRL);
+
+ dcp_write(dev, DCP_CTRL_GATHER_RES_WRITE |
+ DCP_CTRL_ENABLE_CONTEXT_CACHE | DCP_CTRL_CH_IRQ_E_1,
+ DCP_REG_CTRL);
+
+ dcp_write(dev, DCP_CHAN_CTRL_ENABLE_1, DCP_REG_CHAN_CTRL);
+
+ for (i = 0; i < 4; i++)
+ dcp_clear(dev, -1, dcp_chan_reg(DCP_REG_CHAN_STAT, i));
+
+ dcp_clear(dev, -1, DCP_REG_STAT);
+
+
+ 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;
+ }
+ 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;
+ }
+
+ r = platform_get_resource(pdev, IORESOURCE_IRQ, 1);
+ if (!r) {
+ dev_err(&pdev->dev, "can't get IRQ resource (1)\n");
+ ret = -EIO;
+ goto err_free_irq0;
+ }
+ dev->dcp_irq = r->start;
+ ret = request_irq(dev->dcp_irq, dcp_irq, 0, "dcp", dev);
+ if (ret != 0) {
+ dev_err(&pdev->dev, "can't request_irq (1)\n");
+ ret = -EIO;
+ goto err_free_irq0;
+ }
+
+ dev->hw_pkg[0] = dma_alloc_coherent(&pdev->dev,
+ DCP_MAX_PKG * sizeof(struct dcp_hw_packet),
+ &dev->hw_phys_pkg,
+ GFP_KERNEL);
+ if (!dev->hw_pkg[0]) {
+ dev_err(&pdev->dev, "Could not allocate hw descriptors\n");
+ ret = -ENOMEM;
+ goto err_free_irq1;
+ }
+
+ for (i = 1; i < DCP_MAX_PKG; i++) {
+ dev->hw_pkg[i - 1]->next = dev->hw_phys_pkg
+ + i * sizeof(struct dcp_hw_packet);
+ dev->hw_pkg[i] = dev->hw_pkg[i - 1] + 1;
+ }
+ dev->hw_pkg[i - 1]->next = dev->hw_phys_pkg;
+
+
+ dev->payload_base = dma_alloc_coherent(&pdev->dev, 2 * AES_KEYSIZE_128,
+ &dev->payload_base_dma, GFP_KERNEL);
+ if (!dev->payload_base) {
+ dev_err(&pdev->dev, "Could not allocate memory for key\n");
+ ret = -ENOMEM;
+ goto err_free_hw_packet;
+ }
+ tasklet_init(&dev->queue_task, dcp_queue_task,
+ (unsigned long) dev);
+ tasklet_init(&dev->done_task, dcp_done_task,
+ (unsigned long) dev);
+ spin_lock_init(&dev->queue_lock);
+
+ crypto_init_queue(&dev->queue, 10);
+
+ init_timer(&dev->watchdog);
+ dev->watchdog.function = &dcp_watchdog;
+ dev->watchdog.data = (unsigned long)dev;
+
+ dev->dcp_bootstream_misc.minor = MISC_DYNAMIC_MINOR,
+ dev->dcp_bootstream_misc.name = "dcpboot",
+ dev->dcp_bootstream_misc.fops = &dcp_bootstream_fops,
+ ret = misc_register(&dev->dcp_bootstream_misc);
+ if (ret != 0) {
+ dev_err(dev->dev, "Unable to register misc device\n");
+ goto err_free_key_iv;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(algs); i++) {
+ algs[i].cra_priority = 300;
+ algs[i].cra_ctxsize = sizeof(struct dcp_op);
+ algs[i].cra_module = THIS_MODULE;
+ algs[i].cra_init = dcp_cra_init;
+ algs[i].cra_exit = dcp_cra_exit;
+ if (crypto_register_alg(&algs[i])) {
+ dev_err(&pdev->dev, "register algorithm failed\n");
+ ret = -ENOMEM;
+ goto err_unregister;
+ }
+ }
+ dev_notice(&pdev->dev, "DCP crypto enabled.!\n");
+
+ return 0;
+
+err_unregister:
+ for (j = 0; j < i; j++)
+ crypto_unregister_alg(&algs[j]);
+err_free_key_iv:
+ dma_free_coherent(&pdev->dev, 2 * AES_KEYSIZE_128, dev->payload_base,
+ dev->payload_base_dma);
+err_free_hw_packet:
+ dma_free_coherent(&pdev->dev, DCP_MAX_PKG *
+ sizeof(struct dcp_hw_packet), dev->hw_pkg[0],
+ dev->hw_phys_pkg);
+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;
+}
+
+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),
+ dev->hw_pkg[0], dev->hw_phys_pkg);
+
+ dma_free_coherent(&pdev->dev, 2 * AES_KEYSIZE_128, dev->payload_base,
+ dev->payload_base_dma);
+
+ free_irq(dev->dcp_irq, dev);
+ free_irq(dev->dcp_vmi_irq, dev);
+
+ 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;
+}
+
+static struct of_device_id fs_dcp_of_match[] = {
+ { .compatible = "fsl-dcp"},
+ {},
+};
+
+static struct platform_driver fs_dcp_driver = {
+ .probe = dcp_probe,
+ .remove = dcp_remove,
+ .driver = {
+ .name = "fsl-dcp",
+ .owner = THIS_MODULE,
+ .of_match_table = fs_dcp_of_match
+ }
+};
+
+module_platform_driver(fs_dcp_driver);
+
+
+MODULE_AUTHOR("Tobias Rauter <tobias.rauter@gmail.com>");
+MODULE_DESCRIPTION("Freescale DCP Crypto Driver");
+MODULE_LICENSE("GPL");
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH v2] OMAP: AES: Don't idle/start AES device between Encrypt operations
From: Mark A. Greer @ 2013-05-17 21:14 UTC (permalink / raw)
To: Joel A Fernandes; +Cc: linux-crypto, linux-omap, khilman
In-Reply-To: <1368500867-7737-1-git-send-email-joelagnel@ti.com>
On Mon, May 13, 2013 at 10:07:47PM -0500, 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>
> ---
FWIW,
Acked-by: Mark A. Greer <mgreer@animalcreek.com>
^ permalink raw reply
* Re: [PATCH 20/39] usb: musb: ux500: move channel number knowledge into the driver
From: Linus Walleij @ 2013-05-17 6:35 UTC (permalink / raw)
To: Fabio Baltieri
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: <20130515201439.GA10141@balto.lan>
On Wed, May 15, 2013 at 10:14 PM, Fabio Baltieri
<fabio.baltieri@linaro.org> wrote:
> 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.
>
> Not really, I only sent some coding style fix for the dma driver, as
> almost all of my work was in the usb phy files. I also checked my
> latest series against Lee's tree and the two seems to merge without any
> conflict, so as far as I'm concerned it's really up to you and Felipe.
OK so Felipe can merge these smallish patches to musb, fine...
The other (DMA) stuff needs to be merged together with the rest
of the DMA40 series, so here basically Felipe needs an indication
if he can ACK it so I merge it through ARM SoC without colissions
and it sounds like we can make the assumption that this will work.
Yours,
Linus Walleij
^ permalink raw reply
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Xiong Zhou @ 2013-05-17 3:09 UTC (permalink / raw)
To: Tim Chen
Cc: Geert Uytterhoeven, Herbert Xu, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <1368727412.27102.289.camel@schen9-DESK>
2013/5/17 Tim Chen <tim.c.chen@linux.intel.com>:
> On Thu, 2013-05-16 at 09:59 -0700, Tim Chen wrote:
>> On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
>> > On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou <jencce.kernel@gmail.com> wrote:
>> > > --- a/crypto/Kconfig
>> > > +++ b/crypto/Kconfig
>> > > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>> > >
>> > > config CRYPTO_CRCT10DIF
>> > > tristate "CRCT10DIF algorithm"
>> > > + depends on CRC_T10DIF
>> >
>> > This is a library symbol, so "select CRC_T10DIF"?
>> >
>> > > select CRYPTO_HASH
>> > > help
>> > > CRC T10 Data Integrity Field computation is being cast as
>> >
>> > Gr{oetje,eeting}s,
>> >
>> > Geert
>> >
>>
>> This is the fix I think that will resolve the build issues. The generic
>> crc-t10dif transform depends on the library function crc_t10dif_generic
>> in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
>> needed.
>>
>> Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
>> allocate a T10DIF transform if it is available. If not, it will simply
>> use the crc_t10dif_generic function. Loading the
>> generic t10dif crypto transform is not mandatory for the library
>> function crc_t10dif.
>>
>> Thanks for catching the issues.
>>
>> Tim
>>
cool.
>
> Need to also add select CRYPTO for CRC_T10DIF. Updated fix below:
>
>
> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
> ---
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index d1ca631..015df24 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
> config CRYPTO_CRCT10DIF
> tristate "CRCT10DIF algorithm"
> select CRYPTO_HASH
> + depends on CRC_T10DIF
> help
> CRC T10 Data Integrity Field computation is being cast as
> a crypto transform. This allows for faster crc t10 diff
> diff --git a/lib/Kconfig b/lib/Kconfig
> index 0cee056..6407793 100644
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -63,7 +63,8 @@ config CRC16
>
> config CRC_T10DIF
> tristate "CRC calculation for the T10 Data Integrity Field"
> - select CRYPTO_CRCT10DIF
> + select CRYPTO
> + select CRYPTO_HASH
> help
> This option is only needed if a module that's not in the
> kernel tree needs to calculate CRC checks for use with the
>
>
^ permalink raw reply
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Xiong Zhou @ 2013-05-17 3:06 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: tim.c.chen, Herbert Xu, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <CAMuHMdUmD2DMNeezetHNbe9DgQXpTN4BEfEmJSztyzCivQpyXQ@mail.gmail.com>
2013/5/16 Geert Uytterhoeven <geert@linux-m68k.org>:
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou <jencce.kernel@gmail.com> wrote:
>> --- a/crypto/Kconfig
>> +++ b/crypto/Kconfig
>> @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
>>
>> config CRYPTO_CRCT10DIF
>> tristate "CRCT10DIF algorithm"
>> + depends on CRC_T10DIF
>
> This is a library symbol, so "select CRC_T10DIF"?
En.. make sense, Thanks.
Xiong
>
>> select CRYPTO_HASH
>> help
>> CRC T10 Data Integrity Field computation is being cast as
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
^ permalink raw reply
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Tim Chen @ 2013-05-16 18:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Xiong Zhou, Herbert Xu, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <1368723552.27102.286.camel@schen9-DESK>
On Thu, 2013-05-16 at 09:59 -0700, Tim Chen wrote:
> On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> > On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou <jencce.kernel@gmail.com> wrote:
> > > --- a/crypto/Kconfig
> > > +++ b/crypto/Kconfig
> > > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> > >
> > > config CRYPTO_CRCT10DIF
> > > tristate "CRCT10DIF algorithm"
> > > + depends on CRC_T10DIF
> >
> > This is a library symbol, so "select CRC_T10DIF"?
> >
> > > select CRYPTO_HASH
> > > help
> > > CRC T10 Data Integrity Field computation is being cast as
> >
> > Gr{oetje,eeting}s,
> >
> > Geert
> >
>
> This is the fix I think that will resolve the build issues. The generic
> crc-t10dif transform depends on the library function crc_t10dif_generic
> in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
> needed.
>
> Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
> allocate a T10DIF transform if it is available. If not, it will simply
> use the crc_t10dif_generic function. Loading the
> generic t10dif crypto transform is not mandatory for the library
> function crc_t10dif.
>
> Thanks for catching the issues.
>
> Tim
>
Need to also add select CRYPTO for CRC_T10DIF. Updated fix below:
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
---
diff --git a/crypto/Kconfig b/crypto/Kconfig
index d1ca631..015df24 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
config CRYPTO_CRCT10DIF
tristate "CRCT10DIF algorithm"
select CRYPTO_HASH
+ depends on CRC_T10DIF
help
CRC T10 Data Integrity Field computation is being cast as
a crypto transform. This allows for faster crc t10 diff
diff --git a/lib/Kconfig b/lib/Kconfig
index 0cee056..6407793 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -63,7 +63,8 @@ config CRC16
config CRC_T10DIF
tristate "CRC calculation for the T10 Data Integrity Field"
- select CRYPTO_CRCT10DIF
+ select CRYPTO
+ select CRYPTO_HASH
help
This option is only needed if a module that's not in the
kernel tree needs to calculate CRC checks for use with the
^ permalink raw reply related
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Tim Chen @ 2013-05-16 16:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Xiong Zhou, Herbert Xu, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <CAMuHMdUmD2DMNeezetHNbe9DgQXpTN4BEfEmJSztyzCivQpyXQ@mail.gmail.com>
On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou <jencce.kernel@gmail.com> wrote:
> > --- a/crypto/Kconfig
> > +++ b/crypto/Kconfig
> > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> >
> > config CRYPTO_CRCT10DIF
> > tristate "CRCT10DIF algorithm"
> > + depends on CRC_T10DIF
>
> This is a library symbol, so "select CRC_T10DIF"?
>
> > select CRYPTO_HASH
> > help
> > CRC T10 Data Integrity Field computation is being cast as
>
> Gr{oetje,eeting}s,
>
> Geert
>
This is the fix I think that will resolve the build issues. The generic
crc-t10dif transform depends on the library function crc_t10dif_generic
in lib/crc-t10dif.c, so "depends on CRC_T10DIF" for CRYPTO_CRCT10DIF is
needed.
Now for CRC_T10DIF, we should use select CRYPTO_HASH, so it can try to
allocate a T10DIF transform if it is available. If not, it will simply
use the crc_t10dif_generic function. Loading the
generic t10dif crypto transform is not mandatory for the library
function crc_t10dif.
Thanks for catching the issues.
Tim
Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
---
diff --git a/crypto/Kconfig b/crypto/Kconfig
index d1ca631..015df24 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -379,6 +379,7 @@ config CRYPTO_CRC32_PCLMUL
config CRYPTO_CRCT10DIF
tristate "CRCT10DIF algorithm"
select CRYPTO_HASH
+ depends on CRC_T10DIF
help
CRC T10 Data Integrity Field computation is being cast as
a crypto transform. This allows for faster crc t10 diff
diff --git a/lib/Kconfig b/lib/Kconfig
index 0cee056..e6ad2e4 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -63,7 +63,7 @@ config CRC16
config CRC_T10DIF
tristate "CRC calculation for the T10 Data Integrity Field"
- select CRYPTO_CRCT10DIF
+ select CRYPTO_HASH
help
This option is only needed if a module that's not in the
kernel tree needs to calculate CRC checks for use with the
^ permalink raw reply related
* Re: linux-next: Tree for May 15 (crypto /crct10dif)
From: Tim Chen @ 2013-05-16 16:09 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Xiong Zhou, Herbert Xu, Stephen Rothwell, Linux-Next,
linux-kernel@vger.kernel.org, linux-crypto, Randy Dunlap
In-Reply-To: <CAMuHMdUmD2DMNeezetHNbe9DgQXpTN4BEfEmJSztyzCivQpyXQ@mail.gmail.com>
On Thu, 2013-05-16 at 09:22 +0200, Geert Uytterhoeven wrote:
> On Thu, May 16, 2013 at 5:57 AM, Xiong Zhou <jencce.kernel@gmail.com> wrote:
> > --- a/crypto/Kconfig
> > +++ b/crypto/Kconfig
> > @@ -378,6 +378,7 @@ config CRYPTO_CRC32_PCLMUL
> >
> > config CRYPTO_CRCT10DIF
> > tristate "CRCT10DIF algorithm"
> > + depends on CRC_T10DIF
>
> This is a library symbol, so "select CRC_T10DIF"?
>
I think "depends on" CRC_T10DIF is okay. This generic transform is not
needed if we are not using the T10-DIF library. It is meant for
wrapping the library call to t10-dif as a crypto transform.
> > select CRYPTO_HASH
> > help
> > CRC T10 Data Integrity Field computation is being cast as
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Oops on 3.10-rc1 related to ssh256_ssse3
From: Julian Wollrath @ 2013-05-16 13:41 UTC (permalink / raw)
To: linux-crypto
Hello,
I have an encrypted disc (dm-crypt, type LUKS1, ssh256 as hash
algorithm). I have an Intel Core i5 M450 that supports ssse3. Find
below the output from netconsole with the oops. The last warning
appeared when I restart the pc using the magic sysrq key combination
REISUB. I have the same problem with a different laptop with an AMD
E-450 APU.
If you need further information, feel free to ask.
Best regards,
Julian Wollrath
[ 3.647071] device-mapper: uevent: version 1.0.3
[ 3.647245] device-mapper: ioctl: 4.24.0-ioctl (2013-01-15) initialised: dm-devel@redhat.com
[ 11.619603] sha256_ssse3: Using SSSE3 optimized SHA-256 implementation
[ 12.131483] BUG: unable to handle kernel paging request at ffff8800bb593000
[ 12.131848] IP: [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
[ 12.132032] PGD 1a32067 PUD 1a35067 PMD 1a36067 PTE 0
[ 12.132427] Oops: 0000 [#1] SMP
[ 12.132670] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169 mii usbcore usb_common thermal thermal_sys
[ 12.135396] CPU: 3 PID: 276 Comm: cryptomgr_test Not tainted 3.10.0-rc1+ #2
[ 12.135559] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010
[ 12.135720] task: ffff880037572090 ti: ffff8800b66b6000 task.ti: ffff8800b66b6000
[ 12.135836] RIP: 0010:[<ffffffffa016b083>] [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
[ 12.136032] RSP: 0018:ffff8800b66b7af0 EFLAGS: 00010287
[ 12.136130] RAX: 00000000a186fc15 RBX: 00000000704bb939 RCX: 00000000d1b791ec
[ 12.136232] RDX: 000000001fd2088a RSI: ffff880037a97ee8 RDI: ffff8800bb592fc8
[ 12.136334] RBP: ffffffffa016f000 R08: 0000000052a5c3c8 R09: 000000005db427ef
[ 12.136439] R10: 00000000b80a833e R11: 0000000029c53567 R12: ffff8800b66b7b08
[ 12.136543] R13: 000000003158a213 R14: 00000000c7fc368e R15: 0000000001008012
[ 12.136647] FS: 0000000000000000(0000) GS:ffff8800bb180000(0000) knlGS:0000000000000000
[ 12.136763] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 12.136863] CR2: ffff8800bb593000 CR3: 000000000180b000 CR4: 00000000000007e0
[ 12.136964] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 12.137066] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 12.137167] Stack:
[ 12.137257] ffff880108c634c8 ffff8800bb592f88 6033fb357b8c96fd c5e119eaebeb38a3
[ 12.137668] ffff880037a97f08 ffff8800b66b7b80 0000000000000008 0000000000000008
[ 12.138077] ffff880037a97ed0 ffffffffa016dc4e ffff880001496ae5 ffff880037a97ee0
[ 12.138484] Call Trace:
[ 12.138580] [<ffffffffa016dc4e>] ? __sha256_ssse3_update+0x5e/0xe0 [sha256_ssse3]
[ 12.138701] [<ffffffffa016df15>] ? sha256_ssse3_final+0x145/0x1ec [sha256_ssse3]
[ 12.138825] [<ffffffff81214362>] ? shash_ahash_finup+0x32/0x80
[ 12.138931] [<ffffffff81217523>] ? test_hash+0x383/0x6b0
[ 12.139034] [<ffffffff8120c8a0>] ? crypto_mod_get+0x10/0x30
[ 12.139141] [<ffffffff811186d6>] ? __kmalloc+0x1c6/0x1f0
[ 12.139243] [<ffffffff8120cdfc>] ? __crypto_alg_lookup+0xac/0xf0
[ 12.139344] [<ffffffff8120ca48>] ? crypto_create_tfm+0x48/0xd0
[ 12.139445] [<ffffffff812146cd>] ? crypto_init_shash_ops_async+0x2d/0xd0
[ 12.139548] [<ffffffff81217893>] ? alg_test_hash+0x43/0xa0
[ 12.139650] [<ffffffff81215b9b>] ? alg_test+0x9b/0x230
[ 12.139753] [<ffffffff81421351>] ? __schedule+0x271/0x650
[ 12.139856] [<ffffffff81214940>] ? cryptomgr_probe+0xb0/0xb0
[ 12.139954] [<ffffffff81214978>] ? cryptomgr_test+0x38/0x40
[ 12.140058] [<ffffffff8105c53f>] ? kthread+0xaf/0xc0
[ 12.140219] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
[ 12.140382] [<ffffffff814237ac>] ? ret_from_fork+0x7c/0xb0
[ 12.140482] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
[ 12.140585] Code: c4 40 00 00 48 8d 2d 9d 3f 00 00 f3 0f 6f 27 66 41 0f 38 00 e4 f3 0f 6f 6f 10 66 41 0f 38 00 ec f3 0f 6f 77 20 66 41 0f 38 00 f4 <f3> 0f 6f 7f 30 66 41 0f 38 00 fc 48 89 7c 24 08 48 c7 c7 03 00
[ 12.145708] RIP [<ffffffffa016b083>] loop0+0x27/0x44 [sha256_ssse3]
[ 12.145885] RSP <ffff8800b66b7af0>
[ 12.145979] CR2: ffff8800bb593000
[ 12.146075] ---[ end trace 0382cf30f3465fd1 ]---
[ 12.146173] note: cryptomgr_test[276] exited with preempt_count 1
[ 12.146347] BUG: scheduling while atomic: cryptomgr_test/276/0x10000001
[ 12.146485] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169 mii usbcore usb_common thermal thermal_sys
[ 12.150126] CPU: 3 PID: 276 Comm: cryptomgr_test Tainted: G D 3.10.0-rc1+ #2
[ 12.150282] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010
[ 12.150428] ffffffff8141eaf7 ffffffff8141bca7 ffffffff8142167a 0000000000000035
[ 12.151034] 0000000000000046 ffff8800b66b7fd8 ffff8800b66b7fd8 ffff8800b66b7fd8
[ 12.151610] ffff880037572090 ffff8800b66b6000 ffff8800375725d0 0000000000000046
[ 12.152215] Call Trace:
[ 12.152352] [<ffffffff8141eaf7>] ? dump_stack+0xc/0x15
[ 12.152496] [<ffffffff8141bca7>] ? __schedule_bug+0x3f/0x4c
[ 12.152637] [<ffffffff8142167a>] ? __schedule+0x59a/0x650
[ 12.152764] [<ffffffff81067ccd>] ? __cond_resched+0x1d/0x30
[ 12.152898] [<ffffffff814217a6>] ? _cond_resched+0x26/0x30
[ 12.153033] [<ffffffff81420405>] ? mutex_lock+0x15/0x40
[ 12.153169] [<ffffffff810cfba0>] ? perf_event_exit_task+0x20/0x1e0
[ 12.153277] [<ffffffff8103e24f>] ? do_exit+0x29f/0xa10
[ 12.153414] [<ffffffff81005ca6>] ? oops_end+0x96/0xe0
[ 12.153550] [<ffffffff8141afd9>] ? no_context+0x24c/0x275
[ 12.153692] [<ffffffff8102d51e>] ? __do_page_fault+0x2ee/0x480
[ 12.153834] [<ffffffff810db066>] ? __alloc_pages_nodemask+0x106/0x8f0
[ 12.153962] [<ffffffff81423332>] ? page_fault+0x22/0x30
[ 12.154102] [<ffffffffa016b083>] ? loop0+0x27/0x44 [sha256_ssse3]
[ 12.154232] [<ffffffffa016dc4e>] ? __sha256_ssse3_update+0x5e/0xe0 [sha256_ssse3]
[ 12.154380] [<ffffffffa016df15>] ? sha256_ssse3_final+0x145/0x1ec [sha256_ssse3]
[ 12.154532] [<ffffffff81214362>] ? shash_ahash_finup+0x32/0x80
[ 12.154660] [<ffffffff81217523>] ? test_hash+0x383/0x6b0
[ 12.154800] [<ffffffff8120c8a0>] ? crypto_mod_get+0x10/0x30
[ 12.154940] [<ffffffff811186d6>] ? __kmalloc+0x1c6/0x1f0
[ 12.155042] [<ffffffff8120cdfc>] ? __crypto_alg_lookup+0xac/0xf0
[ 12.155183] [<ffffffff8120ca48>] ? crypto_create_tfm+0x48/0xd0
[ 12.155327] [<ffffffff812146cd>] ? crypto_init_shash_ops_async+0x2d/0xd0
[ 12.155466] [<ffffffff81217893>] ? alg_test_hash+0x43/0xa0
[ 12.155609] [<ffffffff81215b9b>] ? alg_test+0x9b/0x230
[ 12.155746] [<ffffffff81421351>] ? __schedule+0x271/0x650
[ 12.155886] [<ffffffff81214940>] ? cryptomgr_probe+0xb0/0xb0
[ 12.156018] [<ffffffff81214978>] ? cryptomgr_test+0x38/0x40
[ 12.156150] [<ffffffff8105c53f>] ? kthread+0xaf/0xc0
[ 12.156275] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
[ 12.156408] [<ffffffff814237ac>] ? ret_from_fork+0x7c/0xb0
[ 12.156542] [<ffffffff8105c490>] ? kthread_create_on_node+0x110/0x110
[ 16.822251] SysRq : Keyboard mode set to system default
[ 18.165412] SysRq : Terminate All Tasks
[ 18.165722] ------------[ cut here ]------------
[ 18.165825] WARNING: at crypto/algapi.c:329 crypto_wait_for_test+0x55/0x70()
[ 18.165846] Modules linked in: sha256_ssse3(+) sha256_generic twofish_generic twofish_x86_64_3way xts lrw gf128mul glue_helper twofish_x86_64 twofish_common cbc dm_crypt dm_mod netconsole sg sr_mod sd_mod cdrom crc_t10dif crc32c_intel microcode ahci libahci ehci_pci ehci_hcd libata scsi_mod r8169 mii usbcore usb_common thermal thermal_sys
[ 18.165847] CPU: 3 PID: 273 Comm: modprobe Tainted: G D W 3.10.0-rc1+ #2
[ 18.165849] Hardware name: Dell Inc. Vostro 3500/0NVXFV, BIOS A10 10/25/2010
[ 18.165851] ffffffff8141eaf7 ffffffff810390fa ffff8800b669b400 ffff8800b669b400
[ 18.165853] ffffffffa016f660 ffffffffa016f6b0 0000000000000001 ffffffff8120e4d5
[ 18.165854] 0000000000000000 ffffffff8120e634 ffffffffa0046000 0000000000000000
[ 18.165855] Call Trace:
[ 18.165858] [<ffffffff8141eaf7>] ? dump_stack+0xc/0x15
[ 18.165861] [<ffffffff810390fa>] ? warn_slowpath_common+0x6a/0xa0
[ 18.165863] [<ffffffff8120e4d5>] ? crypto_wait_for_test+0x55/0x70
[ 18.165864] [<ffffffff8120e634>] ? crypto_register_alg+0x64/0x80
[ 18.165867] [<ffffffffa0046000>] ? 0xffffffffa0045fff
[ 18.165868] [<ffffffff810002fa>] ? do_one_initcall+0x10a/0x160
[ 18.165873] [<ffffffff81090a57>] ? load_module+0x1b37/0x2450
[ 18.165875] [<ffffffff8108ca90>] ? unset_module_init_ro_nx+0x80/0x80
[ 18.165877] [<ffffffff81091430>] ? SyS_init_module+0xc0/0xf0
[ 18.165879] [<ffffffff81423852>] ? system_call_fastpath+0x16/0x1b
[ 18.165880] ---[ end trace 0382cf30f3465fd2 ]---
[ 18.166140] bio: create slab <bio-1> at 1
[ 20.123114] SysRq : Kill All Tasks
[ 20.882858] SysRq : Emergency Sync
[ 20.883148] Emergency Sync complete
[ 22.531845] SysRq : Emergency Remount R/O
[ 22.532141] Emergency Remount complete
[ 23.386434] SysRq : Resetting
[ 23.386663] ACPI MEMORY or I/O RESET_REG.
^ 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