Print error message on platform_get_irq failure before return.
Signed-off-by: Gustavo A. R. Silva
---
drivers/crypto/mxs-dcp.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index 625ee50..764be3e 100644
--- a/drive
Print error message on platform_get_irq failure before return.
Signed-off-by: Gustavo A. R. Silva
---
drivers/crypto/ccp/ccp-platform.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-platform.c
b/drivers/crypto/ccp/ccp-platform.c
index e26969e..602
Propagate the return value of platform_get_irq on failure.
Signed-off-by: Gustavo A. R. Silva
---
drivers/crypto/mediatek/mtk-platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/mediatek/mtk-platform.c
b/drivers/crypto/mediatek/mtk-platform.c
index 000b
On 6/29/2017 7:10 PM, Logan Gunthorpe wrote:
> From: Horia Geantă
>
> We can now make use of the io-64-nonatomic-hi-lo header to always
Typo: we are using io-64-nonatomic-lo-hi, not hi-lo.
Thanks,
Horia
On Mon, 2017-06-26 at 19:38 +0200, Stephan Müller wrote:
> Am Montag, 26. Juni 2017, 03:23:09 CEST schrieb Nicholas A. Bellinger:
>
> Hi Nicholas,
>
> > Hi Stephan, Lee & Jason,
> >
> > (Adding target-devel CC')
> >
> > Apologies for coming late to the discussion. Comments below.
> >
> > On S
Hi Harald,
Can you split this patch into two? One patch to choose rng based on
the quality and another for not overriding user decided rng.
Some more minor comments below.
On 29 June 2017 at 15:33, Harald Freudenberger
wrote:
> The hwrng core implementation currently doesn't consider the
> qual
Currently, the AES-GCM implementation for arm64 systems that support the
ARMv8 Crypto Extensions is based on the generic GCM module, which combines
the AES-CTR implementation using AES instructions with the PMULL based
GHASH driver. This is suboptimal, given the fact that the input data needs
to be
From: Karthik Tummala
Fixed following checkpatch.pl warning:
WARNING: Prefer using '"%s...", __func__' to using
the function's name, in a string
It is prefered to use '%s & __func__' instead of function
name for logging.
Signed-off-by: Karthik Tummala
---
Changes for v2:
v1 was a patch
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
---
drivers/crypto/ccp/sp-dev.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/crypto/ccp/sp-dev.c b/d
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 than renaming file and structures
Signed-off-by:
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 invoked upon interrupt.
Signed-off-by: Brijesh Sing
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: Brijesh Singh
---
drivers/crypto/Kconfig
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
---
drivers/crypto/ccp/ccp-dev-v3.c | 7 +++
drivers/crypto/ccp/ccp-d
(Copying Tom Lendacky)
CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor,
which is not dedicated solely to crypto. The AMD Secure Processor includes
CCP and PSP (Platform Secure Processor) devices.
This patch series adds a framework that allows functional component of the
AMD
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
---
drivers/crypto/ccp/sp-dev.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/crypto/ccp/sp-dev.c b/d
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 invoked upon interrupt.
Signed-off-by: Brijesh Sing
CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor,
which is not dedicated solely to crypto. The AMD Secure Processor includes
CCP and PSP (Platform Secure Processor) devices.
This patch series adds a framework that allows functional component of the
AMD Secure Processor to be
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: Brijesh Singh
---
drivers/crypto/Kconfig
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 than renaming file and structures
Signed-off-by:
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
---
drivers/crypto/ccp/ccp-dev-v3.c | 7 +++
drivers/crypto/ccp/ccp-d
On 29.06.2017 13:12, Gilad Ben-Yossef wrote:
Perhaps I missed something but it sounds like a classic case to use a
work queue:
Makes sense, thanks!
ta
Hi,
Here's my third attempt. This time we add functions to io-64-nonatomic-*
which call io{read|write}32 twice so that the pio is done correctly.
I've also included a patch that adds these functions to the generic iomap
library so that readq/writeq can be used while still splitting pio
operations
In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.
These functions are only defined if readq a
This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).
The patch also points io{read|write}64[be] to the variant specified by the
header name.
This is because new drivers are enco
Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.
Signed-off-by: Logan Gunthorpe
Cc: Jon Mason
Cc: Allen Hubbe
Acked-by: Dave Jiang
---
drivers/ntb/hw/intel/ntb_hw_intel.c | 31 +---
From: Horia Geantă
We can now make use of the io-64-nonatomic-hi-lo header to always
provide 64 bit IO operations. So this patch cleans up the extra
CONFIG_64BIT ifdefs.
To be consistent with CAAM engine HW spec: in case of 64-bit registers,
irrespective of device endianness, the lower address s
On Tue, Jun 27, 2017 at 9:27 AM, Gilad Ben-Yossef wrote:
> Align block comments according to coding style.
>
> Signed-off-by: Gilad Ben-Yossef
> ---
> drivers/staging/ccree/cc_hw_queue_defs.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/ccree/c
On Tue, Jun 27, 2017 at 11:47:56AM +0530, bincy_k_phi...@yahoo.co.in wrote:
> From: Bincy K Philip
>
> Trivial fix for Line over 80 characters
>
> Moved the comment to top of the definition
> ---
> drivers/staging/ccree/cc_hw_queue_defs.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-
On Thu, Jun 29, 2017 at 04:13:38PM +0530, karthik wrote:
> On Wednesday 28 June 2017 03:15 PM, Gilad Ben-Yossef wrote:
> > Thank you Karthik,
> >
> > On Wed, Jun 28, 2017 at 12:37 PM, wrote:
> > > From: Karthik Tummala
> > >
> > > This patch series fixes coding style and removes the following
On Wednesday 28 June 2017 03:15 PM, Gilad Ben-Yossef wrote:
Thank you Karthik,
On Wed, Jun 28, 2017 at 12:37 PM, wrote:
From: Karthik Tummala
This patch series fixes coding style and removes the following
checkpatch.pl warnings:
Prefer using '"%s...", __func__' to using the function's name
On 6/28/2017 4:42 PM, Horia Geantă wrote:
> On 6/28/2017 4:27 PM, David Gstir wrote:
>> Certain cipher modes like CTS expect the IV (req->info) of
>> ablkcipher_request (or equivalently req->iv of skcipher_request) to
>> contain the last ciphertext block when the {en,de}crypt operation is done.
>>
On Thu, Jun 29, 2017 at 1:05 PM, Tudor Ambarus
wrote:
> Hi, Herbert, all,
>
> I need an advice. I'm writing a driver for a crypto device that
> communicates over I2C. Reads and writes from/to the i2c device are
> sequential, I use a lock to synchronize the requests.
>
> There are no interrupts for
Hi, Herbert, all,
I need an advice. I'm writing a driver for a crypto device that
communicates over I2C. Reads and writes from/to the i2c device are
sequential, I use a lock to synchronize the requests.
There are no interrupts for the i2c client. Each request has to send
a command, to wait for a
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
On 6/28/2017 7:51 PM, Logan Gunthorpe wrote:
>
>
> On 28/06/17 04:20 AM, Arnd Bergmann wrote:
>> On Wed, Jun 28, 2017 at 1:02 AM, Logan Gunthorpe wrote:
>>> #include
>>> #include
>>> -#include
>>> +#include
>>
>> Here you include the hi-lo variant unconditionally.
>>
Arnd, thanks for spott
35 matches
Mail list logo
