On Apr 3, 2014, at 11:33 AM, Stanimir Varbanov wrote:
> Hi,
>
> On 04/03/2014 07:24 PM, Kumar Gala wrote:
>>
>> On Apr 3, 2014, at 11:17 AM, Stanimir Varbanov wrote:
>>
>>> Here are all register addresses and bit/masks used by the driver.
>&
On Apr 3, 2014, at 11:17 AM, Stanimir Varbanov wrote:
> Here are all register addresses and bit/masks used by the driver.
>
> Signed-off-by: Stanimir Varbanov
> ---
> drivers/crypto/qce/regs-v5.h | 327 +++
> 1 file changed, 327 insertions(+)
> create mod
On Aug 12, 2013, at 7:05 AM, Lothar Waßmann wrote:
> Hi,
>
> Shawn Guo writes:
>> On Thu, Aug 08, 2013 at 03:30:27PM +0200, Lothar Waßmann wrote:
>>> Reintroduce 'status = "disabled"' for the dcp node that was dropped by
>>> commit 519d8b1a "Added support for Freescale's DCP co-processor".
>>
>
On Aug 8, 2013, at 8:30 AM, Lothar Waßmann wrote:
> This patch series does the following:
>
> - let the driver be "disabled" by default in imx28.dtsi
> - coding style cleanups in drivers/crypto/dcp.c
> - use the "official" 'fsl,' prefix in the 'compatible' property
>
> The last patch adds a new
On Jan 23, 2013, at 1:21 AM, Vakul Garg wrote:
> This new property defines the era of the particular SEC version.
> The compatible property in device tree "crypto" node has been updated
> not to contain SEC era numbers.
>
> Signed-off-by: Vakul Garg
> ---
> Changelog:
> 1. Marked fsl,sec-
On Dec 7, 2012, at 2:57 AM, Vakul Garg wrote:
> This reverts commit a2c0911c09190125f52c9941b9d187f601c2f7be.
>
> Signed-off-by: Vakul Garg
> ---
> Instead of adding SEC era information in crypto node's compatible, a new
> property 'fsl,sec-era' is being introduced into crypto node.
>
> .../de
On Mar 22, 2012, at 2:08 PM, Kent Yoder wrote:
> Hi Kumar,
>
>> Is there a reason this isn't in drivers/crypto/
>
> Other arch-specific dirs have their crypto subdir as well such as
> arch/s390. I was just matching that.
>
> Kent
>
>> - k
>
>From what I can tell this isn't ISA level instr
On Mar 21, 2012, at 4:28 PM, Kent Yoder wrote:
> arch/powerpc/crypto/nx/Makefile | 11 +
> arch/powerpc/crypto/nx/nx-aes-cbc.c | 135 +
> arch/powerpc/crypto/nx/nx-aes-ccm.c | 466 ++
> arch/powerpc/crypto/nx/nx-aes-ctr.c | 175 +++
> a
On Dec 17, 2009, at 11:44 AM, Dan Williams wrote:
> Ira W. Snyder wrote:
>> Yes, I have used the device_prep_dma_interrupt() functionality quite a
>> while back. However, I found it to be pretty much useless.
>
> The specific case it is needed for Talitos/raid is a channel switch
> interrupt.
On Dec 17, 2009, at 11:09 AM, Ira W. Snyder wrote:
> On Wed, Dec 16, 2009 at 03:47:48PM -0700, Dan Williams wrote:
>> Kumar Gala wrote:
>>>>> Changes with respect to v1 as per comments received
>>>>> o. Rebased to linux-next as of 20091216
>>>
On Dec 16, 2009, at 4:41 PM, Kim Phillips wrote:
> On Wed, 16 Dec 2009 21:04:58 +0530
> Vishnu Suresh wrote:
>
>> Expose Talitos's XOR functionality to be used for
>> RAID Parity calculation via the Async_tx layer.
>>
>> Known Issue:
>> When used with fsldma, random crashes are observed
>> on
On Dec 3, 2008, at 8:52 AM, Kumar Gala wrote:
On Dec 3, 2008, at 6:06 AM, Herbert Xu wrote:
On Tue, Dec 02, 2008 at 10:29:16PM -0600, Kumar Gala wrote:
Removed __devexit from talitos_remove() since its also called from
talitos_probe().
WARNING: vmlinux.o(.text+0x28a008): Section mismatch
On Dec 3, 2008, at 6:06 AM, Herbert Xu wrote:
On Tue, Dec 02, 2008 at 10:29:16PM -0600, Kumar Gala wrote:
Removed __devexit from talitos_remove() since its also called from
talitos_probe().
WARNING: vmlinux.o(.text+0x28a008): Section mismatch in reference
from the function talitos_probe
section.
Often the function talitos_remove() has valid usage outside the exit section
and the fix is to remove the __devexit annotation of talitos_remove.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
drivers/crypto/talitos.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
On Jul 17, 2008, at 10:27 AM, Kim Phillips wrote:
On Thu, 17 Jul 2008 07:26:14 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
On Jul 17, 2008, at 7:17 AM, Herbert Xu wrote:
On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote:
On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
On Jul 17, 2008, at 7:17 AM, Herbert Xu wrote:
On Wed, Jul 16, 2008 at 06:33:45PM -0500, Kumar Gala wrote:
On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
use GFP_ATOMIC when necessary; use atomic_t when allocating
submit_count.
why?
You mean why are atomics required? Yes that is a
On Jul 16, 2008, at 6:22 PM, Kim Phillips wrote:
use GFP_ATOMIC when necessary; use atomic_t when allocating
submit_count.
why?
- k
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ke
17 matches
Mail list logo
