On Mon, Jul 07, 2014 at 10:42:12AM +0530, Ruchika Gupta wrote:
The layer which registers with the crypto API should check for the presence of
the CAAM device it is going to use. If the platform's device tree doesn't
have
the required CAAM node, the layer should return an error and not
On Tue, Jul 08, 2014 at 01:59:07PM +0300, Dan Carpenter wrote:
The cast to (unsigned int *) doesn't hurt anything but it is pointless.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Patch applied.
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page:
On Mon, Jul 07, 2014 at 11:52:41AM +0300, Cristian Stoica wrote:
This patch fixes a memory leak that appears when caam_jr module is unloaded.
Cc: sta...@vger.kernel.org # 3.13+
Signed-off-by: Cristian Stoica cristian.sto...@freescale.com
Patch applied.
--
Email: Herbert Xu
Hi Linus:
This push fixes an error in sha512_ssse3 that leads to incorrect
output as well as a memory leak in caam_jr when the module is
unloaded.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
On Thursday, July 10, 2014 at 01:05:39 AM, Dmitry Kasatkin wrote:
On 10 July 2014 00:00, Marek Vasut ma...@denx.de wrote:
On Tuesday, July 08, 2014 at 10:07:16 AM, Dmitry Kasatkin wrote:
[...]
Right, but my concern is not about unloading the kernel module, but
about the IMA module
On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
The above function looks like almost verbatim copy of print_hex_dump().
The only difference I can spot is that it's calling seq_printf() instead
of printk(). Can you not
On Thu, 2014-07-10 at 09:58 +0200, Marek Vasut wrote:
On Wednesday, July 09, 2014 at 11:21:08 PM, Joe Perches wrote:
On Wed, 2014-07-09 at 22:39 +0200, Marek Vasut wrote:
The above function looks like almost verbatim copy of print_hex_dump().
The only difference I can spot is that it's
On Thu, 2014-07-10 at 12:50 +0300, Andy Shevchenko wrote:
I have considered to modify hex_dump_to_buffer() to return how many
bytes it actually proceed to the buffer. In that case we can directly
print to m-buf like other seq_foo calls do.
But I still have doubts about it. Any opinion?
On 10/07/14 11:02, Marek Vasut wrote:
On Thursday, July 10, 2014 at 01:05:39 AM, Dmitry Kasatkin wrote:
On 10 July 2014 00:00, Marek Vasut ma...@denx.de wrote:
On Tuesday, July 08, 2014 at 10:07:16 AM, Dmitry Kasatkin wrote:
[...]
Right, but my concern is not about unloading the kernel
On Wed, 2014-07-09 at 11:31 -0700, Tadeusz Struk wrote:
On 07/09/2014 08:24 AM, Andy Shevchenko wrote:
In this case it slightly changes the output, namely the four tetrads will be
output on one line.
Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
It's ok, I can
On Thursday, July 10, 2014 at 01:18:41 PM, Dmitry Kasatkin wrote:
[...]
All right, that was my understanding of the entire discussion -- an
accelerator dying mid-way and what will IMA do about that.
But as we fallback to early allocated shash, which is not USB yet,
then there is no
The default cache operations for ARM64 were changed during 3.15.
To use coherent operations a dma-coherent device tree property
is required. If that property is not present in the device tree
node then the non-coherent operations are assigned for the device.
Add support to the ccp driver to
For the special case when we have a null input string, we want
to initialize the entry len to 0 for the hash/ahash walk, so
cyrpto_hash_walk_last will return the correct result indicating
that we have completed the scatter list walk. Otherwise we may
keep walking the sg list and access bogus
13 matches
Mail list logo
