On Mon, May 07, 2018 at 06:35:39AM -0300, Mauro Carvalho Chehab wrote:
> A number of new docs were added, but they're currently not on
> the index.rst from the session they're supposed to be, causing
> Sphinx warnings.
>
> Add them.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-by: Greg Kro
fscrypt currently only supports AES encryption. However, many low-end
mobile devices have older CPUs that don't have AES instructions, e.g.
the ARMv8 Cryptography Extensions. Currently, user data on such devices
is not encrypted at rest because AES is too slow, even when the NEON
bit-sliced imple
Hi Samuel,
On Thu, Apr 26, 2018 at 03:05:44AM +0100, Samuel Neves wrote:
> On Wed, Apr 25, 2018 at 8:49 PM, Eric Biggers wrote:
> > I agree that my explanation should have been better, and should have
> > considered
> > more crypto algorithms. The main difficulty is that we have extreme
> > pe
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
Add support for io{read|write}64() functions in parisc architecture.
These are pretty straightforward copies of similar functions which
make use of readq and writeq.
Also, indicate that the lo_hi and hi_lo variants of these functions
are not provided by this architecture.
Signed-off-by: Logan Gun
Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64
functions in non-64bit cases in favour of the new common
io-64-nonatomic-lo-hi header.
To be consistent with CAAM engine HW spec: in case of 64-bit registers,
irrespective of device endianness, the lower address should be read from
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
Reviewed-by: Andy Shevchenko
Acked-by: Dave Jiang
Acked-by: Allen Hubbe
Acked-by: Jon Mason
---
drivers/ntb/hw/
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
This is a resend of my cleanup series to push a number of instances of
people defining their own io{read|write}64 functions into common
headers seing they don't exist in non-64bit systems. This series adds
inline functions to the io-64-nonatomic headers and then cleans up the
drivers that defined t
Fix an asymmetry in the io{read|write}XXbe functions in that the
big-endian variants make use of the raw io accessors while the
little-endian variants use the regular accessors. Some architectures
implement barriers to order against both spinlocks and DMA accesses
and for these case, the big-endian
Clean up the ifdefs which conditionally defined the io{read|write}64
functions in favour of the new common io-64-nonatomic-lo-hi header.
Per a nit from Andy Shevchenko, the include list is also made
alphabetical.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Andy Shevchenko
Cc: Jon Mason
---
dr
On Mon, May 7, 2018 at 2:29 PM, Stephan Mueller wrote:
> Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> ah... so if I have hardware that can implement say, seqiv, I can
>> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are
>> right, it will be used
Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
> ah... so if I have hardware that can implement say, seqiv, I can
> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are
> right, it will be used?
That is the question I cannot fully answer. Seqiv is a templat
On Mon, May 7, 2018 at 2:02 PM, Stephan Mueller wrote:
> Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> Hi,
>>
>> A quick question: am I correct in my understanding that there is now
>> no automatic IV generation support for either skcipher nor aead?
>> And if I
Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef:
Hi Gilad,
> Hi,
>
> A quick question: am I correct in my understanding that there is now
> no automatic IV generation support for either skcipher nor aead?
> And if I'm wrong, can someone point to an example of a driver that
> imple
Hi Wenwen,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on cryptodev/master]
[also build test WARNING on v4.17-rc3 next-20180504]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0da
A number of new docs were added, but they're currently not on
the index.rst from the session they're supposed to be, causing
Sphinx warnings.
Add them.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/crypto/index.rst | 1 +
Documentation/driver-api/index.rst | 1 +
Documentation/proc
./Documentation/crypto/crypto_engine.rst:13: WARNING: Unexpected indentation.
./Documentation/crypto/crypto_engine.rst:15: WARNING: Block quote ends without
a blank line; unexpected unindent.
Signed-off-by: Mauro Carvalho Chehab
---
Documentation/crypto/crypto_engine.rst | 8 +---
1 file ch
I decided to give a try with Sphinx last stable version
(1.17.4), and noticed several issues. The worse one was
with the networking book: a non-standard footnote there
with [*] instead of a number causes it to break PDF building.
So, I took some spare time to address some warnings all over
the tre
On Tue, May 01, 2018 at 10:39:15PM +, Dey, Megha wrote:
>
> crypto/simd.c provides a simd_skcipher_create_compat. I have used the same
> template to introduce simd_ahash_create_compat
> which would wrap around the inner hash algorithm.
>
> Hence we would still register 2 algs, outer and inner
20 matches
Mail list logo
