On Mon, Jul 03, 2017 at 08:33:44PM +0800, Herbert Xu wrote:
> On Sat, Jun 24, 2017 at 12:56:52AM +, Albrekht, Ilya wrote:
> > Hello all,
> >
> > I'm sorry for late reply (I was out of office for a month).
> >
> > It's been a while since we touched this code. We are going to do our best
> > t
The Security System has a PRNG, this patch adds support for it via
crypto_rng.
Signed-off-by: Corentin Labbe
---
Change since v4
- Fixed some spelling issue in Kconfig and patch description
Changes since v3 (note: the v3 miss changes and version tag sorry)
- Replaced all len values with bits /
On Mon, Jun 26, 2017 at 02:36:43PM +0200, Frans Klaver wrote:
> Hi,
>
> On Mon, Jun 26, 2017 at 2:20 PM, Corentin Labbe
> wrote:
> > The Security System have a PRNG, this patch add support for it via
> > crypto_rng.
>
> s,have,has,
> s,add,adds,
>
> >
> > Signed-off-by: Corentin Labbe
> > ---
On 06/29/2017 11:54 AM, Singh, Brijesh wrote:
Since SP device driver supports multiples devices (e.g CCP, PSP), we
should not fail the driver init just because CCP device is not found.
Signed-off-by: Brijesh Singh
Acked-by: Gary R Hook
---
drivers/crypto/ccp/sp-dev.c | 12
1
On 06/29/2017 11:54 AM, Singh, Brijesh wrote:
CCP device initializes is now integerated into higher level SP device,
to avoid the confusion lets rename the ccp driver initialization files
(ccp-platform.c->sp-platform.c, ccp-pci.c->sp-pci.c). The patch does not
make any functional changes other th
On 06/29/2017 11:54 AM, Singh, Brijesh wrote:
The CCP device is part of the AMD Secure Processor. In order to expand
the usage of the AMD Secure Processor, create a framework that allows
functional components of the AMD Secure Processor to be initialized and
handled appropriately.
Signed-off-by:
On 06/29/2017 11:54 AM, Singh, Brijesh wrote:
The CCP and PSP devices part of AMD Secure Procesor may share the same
interrupt. Hence we expand the SP device to register a common interrupt
handler and provide functions to CCP and PSP devices to register their
interrupt callback which will be invo
On 06/29/2017 11:54 AM, Singh, Brijesh wrote:
Update pci and platform files to use devres interface to allocate the PCI
and iomap resources. Also add helper functions to consolicate module init,
exit and power mangagement code duplication.
Signed-off-by: Brijesh Singh
Acked-by: Gary R Hook
On Mon, Jul 3, 2017 at 3:35 PM, Herbert Xu wrote:
> On Sun, Jul 02, 2017 at 05:41:43PM +0300, Gilad Ben-Yossef wrote:
>> The crypto API was using the -EBUSY return value to indicate
>> both a hard failure to submit a crypto operation into a
>> transformation provider when the latter was busy and t
On Sun, Jul 02, 2017 at 05:41:43PM +0300, Gilad Ben-Yossef wrote:
> The crypto API was using the -EBUSY return value to indicate
> both a hard failure to submit a crypto operation into a
> transformation provider when the latter was busy and the backlog
> mechanism was not enabled as well as a noti
On Sat, Jun 24, 2017 at 12:56:52AM +, Albrekht, Ilya wrote:
> Hello all,
>
> I'm sorry for late reply (I was out of office for a month).
>
> It's been a while since we touched this code. We are going to do our best to
> support it. I'll be back to the office earlier next week and will figure
On Mon, Jul 03, 2017 at 10:19:31AM +0300, Gilad Ben-Yossef wrote:
> but for the few cases where its a complex expression that can be
> broken down like this one:
>
> WARNING: line over 80 characters
> #93: FILE: drivers/staging/ccree/ssi_buffer_mgr.c:437:
> + (AES_BLOCK_SIZE + areq_ctx->ccm_hd
Currently /dev/hwrng uses default device node permissions
which is 0600. So by default the device node is not accessible
by an ordinary user. Some distros do rewrite the device node
permissions via udev rule, others don't. This patch provides
0444 as the new mode value and so makes the device node
Implement a NEON fallback for systems that do support NEON but have
no support for the optional 64x64->128 polynomial multiplication
instruction that is part of the ARMv8 Crypto Extensions. It is based
on the paper "Fast Software Polynomial Multiplication on ARM Processors
Using the NEON Engine" by
When a user chooses a rng source via sysfs
attribute this rng should be sticky, even
when other sources with better quality to
register. This patch introduces a simple way
to remember the user's choise.
Signed-off-by: Harald Freudenberger
---
drivers/char/hw_random/core.c | 10 --
1 file
The hwrng core implementation currently doesn't consider the
quality field of the struct hwrng. So the first registered rng
is the winner and further rng sources even with much better
quality are ignored.
The behavior should be that always the best rng with the highest
quality rate should be used
This patch introduces a new sysfs attribute file 'rng_selected'
which shows the the rng chosen by userspace.
If a rng source is chosen by user via echo some valid string
to rng_current there should be a way to signal this choice to
userspace. The new attribute file 'rng_selected' shows either
the
This patch rewoks the hwrng to always use the
rng source with best entropy quality.
On registation and unregistration the hwrng now
tries to choose the best (= highest quality value)
rng source. The handling of the internal list
of registered rng sources is now always sorted
by quality and the top
Hi,
On Sun, Jul 2, 2017 at 2:25 AM, Simon Sandström wrote:
> Fixes a total of 195 alignment issues in staging/ccree reported by
> checkpatch.pl. Adds a few "line over 80 characters" warnings as a
> result of the realignments, but I could try to get rid of them in the
> same patchset if needed.
F
19 matches
Mail list logo
