[PATCH v5 5/6] ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks

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

[PATCH v5 4/6] io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros

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

[PATCH v5 0/6] make io{read|write}64 globally usable

Changes since v4: - Add functions so the powerpc implementation of iomap.c compiles. (As noticed by Horia) Changes since v3: - I noticed powerpc didn't use the appropriate functions seeing readq/writeq were not defined when iomap.h was included. Thus I've included a patch to adjust this - Fixed

[PATCH v5 6/6] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

From: Horia Geantă We can now make use of the io-64-nonatomic-lo-hi 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

[PATCH v5 3/6] iomap: introduce io{read|write}64_{lo_hi|hi_lo}

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

[PATCH v5 1/6] powerpc: io.h: move iomap.h include so that it can use readq/writeq defs

Subsequent patches in this series makes use of the readq and writeq defines in iomap.h. However, as is, they get missed on the powerpc platform seeing the include comes before the define. This patch moves the include down to fix this. Signed-off-by: Logan Gunthorpe Acked-By:

[PATCH v5 2/6] powerpc: iomap.c: introduce io{read|write}64_{lo_hi|hi_lo}

These functions will be introduced into the generic iomap.c so they can deal with PIO accesses in hi-lo/lo-hi variants. Thus, the powerpc version of iomap.c will need to provide the same functions even though, in this arch, they are identical to the regular io{read|write}64 functions. ---

Re: [PATCH v6 1/3] Documentation: devicetree: add Freescale RNGC binding

On Sun, Jul 23, 2017 at 12:49 PM, Martin Kaiser wrote: > From: Steffen Trumtrar > > Add binding documentation for the Freescale RNGC found on > some i.MX2/3 SoCs. > > Signed-off-by: Steffen Trumtrar > Signed-off-by: Martin

[PATCH v2 3/7] fscrypt: use HKDF-SHA512 to derive the per-inode encryption keys

From: Eric Biggers By design, the keys which userspace provides in the keyring are not used to encrypt data directly. Instead, a KDF (Key Derivation Function) is used to derive a unique encryption key for each inode, given a "master" key and a nonce. The current KDF

[PATCH v2 6/7] fscrypt: cache the HMAC transform for each master key

From: Eric Biggers Now that we have a key_hash field which securely identifies a master key payload, introduce a cache of the HMAC transforms for the master keys currently in use for inodes using v2+ encryption policies. The entries in this cache are called 'struct

[PATCH v2 7/7] fscrypt: for v2 policies, support "fscrypt:" key prefix only

From: Eric Biggers Since v2 encryption policies are opt-in, take the opportunity to also drop support for the legacy filesystem-specific key description prefixes "ext4:", "f2fs:", and "ubifs:", instead requiring the generic prefix "fscrypt:". The generic prefix is preferred

[PATCH v2 5/7] fscrypt: verify that the correct master key was supplied

From: Eric Biggers Currently, while a fscrypt master key is required to have a certain description in the keyring, its payload is never verified to be correct. While sufficient for well-behaved userspace, this is insecure in a multi-user system where a user has been given

[PATCH v2 1/7] fscrypt: add v2 encryption context and policy

From: Eric Biggers Currently, the fscrypt_context (i.e. the encryption xattr) does not contain a cryptographically secure identifier for the master key's payload. Therefore it's not possible to verify that the correct key was supplied, which is problematic in multi-user

[PATCH v2 0/7] fscrypt: key verification and KDF improvement

From: Eric Biggers This patch series solves two major problems which filesystem-level encryption has currently. First, the user-supplied master keys are not verified, which means a malicious user can provide the wrong key for another user's file and cause a DOS attack or

Re: [RESEND PATCH 0/2] crypto/rockchip: fix some issue which causes crypto failed

Greetings While I am not getting the original error anymore, using dm-crypt still fails at cryptsetup luksOpen with [rk_ablk_rx:331] Lack of data https://users.aalto.fi/~jkarlson/files/rk3288-fail_2017-07-24.jpg Test platform: Asus chromebook C201/rk3288 linux-4.12.3+ this patchset Best Regards