On Wed, Aug 05, 2020 at 09:22:59AM +0300, Gilad Ben-Yossef wrote:
> the CryptoCell HW has support for ciphers and modes not supported
> and used at this time by Linux. Remove the code supporting this
> in the ccree ddriver until such time support is added in the kernel.
>
> Gilad Ben-Yossef (2):
>
the CryptoCell HW has support for ciphers and modes not supported
and used at this time by Linux. Remove the code supporting this
in the ccree ddriver until such time support is added in the kernel.
Gilad Ben-Yossef (2):
crypto: ccree: remove data unit size support
crypto: ccree: remove bitloc
The driver was full of code checking "if (x != 0)".
Replace by "if (x)" for better readability.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 28 +--
drivers/staging/ccree/ssi_buffer_mgr.c | 74 ++---
drivers/staging/ccree/ssi_ciph
On Tue, Nov 07, 2017 at 09:40:03AM +, Gilad Ben-Yossef wrote:
> diff --git a/drivers/staging/ccree/ssi_aead.c
> b/drivers/staging/ccree/ssi_aead.c
> index f1a3976..e9d03ee 100644
> --- a/drivers/staging/ccree/ssi_aead.c
> +++ b/drivers/staging/ccree/ssi_aead.c
> @@ -240,7 +240,7 @@ static void
The driver was full of code checking "if (x != 0)".
Replace by "if (x)" for better readability.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_aead.c| 34 +++---
drivers/staging/ccree/ssi_buffer_mgr.c | 74 ++---
drivers/staging/ccree/ssi_c
The original ccree driver was registering a useless setkey
method even for non-MAC hash transformations. Somewhere
around v4.9 a check was added that failed hash operations
if a setkey method was registered but was not called,
so during the initial upstream port code was added to
only register the
On Fri, Jun 23, 2017 at 7:29 PM, Greg Kroah-Hartman
wrote:
> On Thu, Jun 22, 2017 at 04:36:56PM +0300, Gilad Ben-Yossef wrote:
>> Fix a bug where the transformation init code did
>> not register a setkey method for none hash based MACs.
>
> "none hash based MACs"?
On Thu, Jun 22, 2017 at 04:36:56PM +0300, Gilad Ben-Yossef wrote:
> Fix a bug where the transformation init code did
> not register a setkey method for none hash based MACs.
"none hash based MACs"? Is that the correct language, I don't
understand it, sorry, can you expand o
Fix a bug where the transformation init code did
not register a setkey method for none hash based MACs.
Fixes commit 50cfbbb7e627 ("staging: ccree: add ahash support").
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_hash.c | 83 --
Fix a bug where the transformation init code did
not register a setkey method for none hash based MACs.
Fixes commit 50cfbbb7e627 ("staging: ccree: add ahash support").
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_hash.c | 83 --
The sample code was showing use of wait_for_completion_interruptible()
for waiting for an async. crypto op to finish. However, if a signal
arrived it would free the buffers used even while crypto HW might
still DMA from/into the buffers.
Resolve this by using wait_for_completion() instead.
Report
The sample code was showing use of wait_for_completion_interruptible()
for waiting for an async. crypto op to finish. However, if a signal
arrived it would free the buffers used even while crypto HW might
still DMA from/into the buffers.
Resolve this by using wait_for_completion() instead.
Report
On Thu, May 11, 2017 at 02:53:45PM +0300, Gilad Ben-Yossef wrote:
> The sample code was showing use of wait_for_completion_interruptible()
> for waiting for an async. crypto op to finish. However, if a signal
> arrived it would free the buffers used even while crypto HW might
> still DMA from/into
The sample code was showing use of wait_for_completion_interruptible()
for waiting for an async. crypto op to finish. However, if a signal
arrived it would free the buffers used even while crypto HW might
still DMA from/into the buffers.
Resolve this by using wait_for_completion() instead.
Report
On Wed, Jun 01, 2016 at 02:59:21AM -0400, Jeffrey Walton wrote:
>
> $ cat /proc/modules | egrep -i '(via|padlock|rng)'
> padlock_sha 16384 0 - Live 0x
> padlock_aes 16384 0 - Live 0x
> via_cputemp 16384 0 - Live 0x
> hwmon_vid 16384 1 via_cputemp, Live 0x
> via_rng
Am Mittwoch, 1. Juni 2016, 02:59:21 schrieb Jeffrey Walton:
Hi Jeffrey,
> On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu
wrote:
> > On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
> >> I thought via-rng.c covers the VIA Padlock RNG?
> >
> > Indeed, you're quite right. In that cas
On Wed, Jun 1, 2016 at 2:19 AM, Herbert Xu wrote:
> On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
>>
>> I thought via-rng.c covers the VIA Padlock RNG?
>
> Indeed, you're quite right. In that case Jeffrey was the via-rng
> driver loaded?
$ cat /proc/modules | egrep -i '(via|pa
On Wed, Jun 01, 2016 at 07:53:38AM +0200, Stephan Mueller wrote:
>
> I thought via-rng.c covers the VIA Padlock RNG?
Indeed, you're quite right. In that case Jeffrey was the via-rng
driver loaded?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gond
Am Mittwoch, 1. Juni 2016, 12:59:43 schrieb Herbert Xu:
Hi Herbert,
> Jeffrey Walton wrote:
> > Please forgive my ignorance here...
> >
> > I have test system with a VIA C7-M processor and PM-400 chipset. This
> > is one of those Thin Client/Internet of Things processor and chipsets
> > I test
Jeffrey Walton wrote:
> Please forgive my ignorance here...
>
> I have test system with a VIA C7-M processor and PM-400 chipset. This
> is one of those Thin Client/Internet of Things processor and chipsets
> I test security libraries on (like OpenSSL, Cryptlib and Crypto++).
>
> The processor in
20 matches
Mail list logo
