Re: [PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver
On Mon, Feb 6, 2017 at 10:24 PM, Vinod Koul wrote:
> On Mon, Feb 06, 2017 at 05:31:15PM +0530, Anup Patel wrote:
>
>> >> +
>> >> +/* SBA C_MDATA helper macros */
>> >> +#define SBA_C_MDATA_LOAD_VAL(__bnum0)((__bnum0) & 0x3)
>> >> +#define SBA_C_MDATA_WRITE_VAL(__bnum0) ((__bnum0) & 0x3)
>> >> +#define SBA_C_MDATA_XOR_VAL(__bnum1, __bnum0)\
>> >> + ({ u32 __v = ((__bnum0) & 0x3);\
>> >> + __v |= ((__bnum1) & 0x3) << 2; \
>> >> + __v;\
>> >> + })
>> >> +#define SBA_C_MDATA_PQ_VAL(__dnum, __bnum1, __bnum0) \
>> >> + ({ u32 __v = ((__bnum0) & 0x3);\
>> >> + __v |= ((__bnum1) & 0x3) << 2; \
>> >> + __v |= ((__dnum) & 0x1f) << 5; \
>> >> + __v;\
>> >> + })
>> >
>> > ah why are we usig complex macros, why can't these be simple functions..
>>
>> "static inline functions" seemed too complicated here because most of
>> these macros are two lines of c-code.
>
> and thats where I have an issue with this. Macros for simple things is fine
> but not for couple of line of logic!
>
>>
>> Do you still insist on using "static inline functions"?
>
> Yes
Sure, will use "static inline functions" instead these macros.
>
>>
>> >
>> >> +#define SBA_C_MDATA_LS(__c_mdata_val)((__c_mdata_val) & 0xff)
>> >> +#define SBA_C_MDATA_MS(__c_mdata_val)(((__c_mdata_val) >> 8) &
>> >> 0x3)
>> >> +
>> >> +/* Driver helper macros */
>> >> +#define to_sba_request(tx) \
>> >> + container_of(tx, struct sba_request, tx)
>> >> +#define to_sba_device(dchan) \
>> >> + container_of(dchan, struct sba_device, dma_chan)
>> >> +
>> >> +enum sba_request_state {
>> >> + SBA_REQUEST_STATE_FREE = 1,
>> >> + SBA_REQUEST_STATE_ALLOCED = 2,
>> >> + SBA_REQUEST_STATE_PENDING = 3,
>> >> + SBA_REQUEST_STATE_ACTIVE = 4,
>> >> + SBA_REQUEST_STATE_COMPLETED = 5,
>> >> + SBA_REQUEST_STATE_ABORTED = 6,
>> >
>> > whats up with a very funny indentation setting, we use 8 chars.
>> >
>> > Please re-read the Documentation/process/coding-style.rst
>>
>> I have double checked this enum. The indentation is fine
>> and as-per coding style. Am I missing anything else?
>
> Somehow the initial indent doesnt seem to be 8 chars to me.
>
>> >> +static enum dma_status sba_tx_status(struct dma_chan *dchan,
>> >> + dma_cookie_t cookie,
>> >> + struct dma_tx_state *txstate)
>> >> +{
>> >> + int mchan_idx;
>> >> + enum dma_status ret;
>> >> + struct sba_device *sba = to_sba_device(dchan);
>> >> +
>> >> + ret = dma_cookie_status(dchan, cookie, txstate);
>> >> + if (ret == DMA_COMPLETE)
>> >> + return ret;
>> >> +
>> >> + for (mchan_idx = 0; mchan_idx < sba->mchans_count; mchan_idx++)
>> >> + mbox_client_peek_data(sba->mchans[mchan_idx]);
>> >
>> > what is this achieving?
>>
>> The mbox_client_peek_data() is a hint to mailbox controller driver
>> to check for available messages.
>>
>> This gives good performance improvement when some DMA client
>> code is polling using tx_status() callback.
>
> Then why do it before and then check status.
If there was a work completed when mbox_client_peek_data()
is called then sba_receive_message() will be called immediately
by mailbox controller driver.
We are doing dma_cookie_complete() in sba_receive_message()
so if mbox_client_peek_data() is called before dma_cookie_status()
then dma_cookie_status() will see correct state of cookie.
Also, I explored virt-dma APIs for BCM-SBA-RAID driver. The virt-dma
implements tasklet based bottom-half for each virt-dma-channel. This
bottom-half is not required for BCM-FS4-RAID driver because its a
mailbox client driver and the mailbox controller driver already implements
bottom-half for each mailbox channel.
If we still go ahead and use virt-dma in BCM-FS4-RAID driver then we
will have two bottom-halfs in-action one in mailbox controller driver and
another in BCM-FS4-RAID driver which in-turn will add bottom-half
scheduling overhead thereby reducing performance of BCM-FS4-RAID
driver.
Regards,
Anup
[PATCH] hwrng: cavium: Use per device name to allow for multiple devices.
Systems containing the Cavium HW RNG may have one device per NUMA node. A typical configuration is a 2-node NUMA system, which results in 2 RNG devices. The hwrng subsystem refuses (and rightly so) to register more than one device with he same name, so we get failure messages on these systems. Make the hwrng name unique by including the underlying device name. Also remove spaces from the name to make it possible to switch devices via the sysfs knobs. Signed-off-by: David Daney --- drivers/char/hw_random/cavium-rng-vf.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/char/hw_random/cavium-rng-vf.c b/drivers/char/hw_random/cavium-rng-vf.c index 066ae0e..dd1007a 100644 --- a/drivers/char/hw_random/cavium-rng-vf.c +++ b/drivers/char/hw_random/cavium-rng-vf.c @@ -57,7 +57,11 @@ static int cavium_rng_probe_vf(structpci_dev *pdev, return -ENOMEM; } - rng->ops.name= "cavium rng"; + rng->ops.name = devm_kasprintf(&pdev->dev, GFP_KERNEL, + "cavium-rng-%s", dev_name(&pdev->dev)); + if (!rng->ops.name) + return -ENOMEM; + rng->ops.read= cavium_rng_read; rng->ops.quality = 1000; -- 1.8.3.1
Re: crypto: atmel - Fix authenc compile test warnings
Hi Herbert,
[auto build test WARNING on cryptodev/master]
[also build test WARNING on v4.10-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Herbert-Xu/crypto-atmel-Fix-authenc-compile-test-warnings/20170206-171201
base:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile
All warnings (new ones prefixed by >>):
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_sg_copy':
>> drivers/crypto/atmel-tdes.c:157:11: warning: comparison of distinct pointer
>> types lacks a cast [enabled by default]
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_pdc_stop':
>> drivers/crypto/atmel-tdes.c:339:4: warning: format '%u' expects argument of
>> type 'unsigned int', but argument 2 has type 'size_t' [-Wformat]
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_buff_init':
>> drivers/crypto/atmel-tdes.c:364:3: warning: format '%d' expects argument of
>> type 'int', but argument 3 has type 'size_t' [-Wformat]
drivers/crypto/atmel-tdes.c:372:3: warning: format '%d' expects argument of
type 'int', but argument 3 has type 'size_t' [-Wformat]
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_start':
drivers/crypto/atmel-tdes.c:528:11: warning: comparison of distinct pointer
types lacks a cast [enabled by default]
drivers/crypto/atmel-tdes.c:529:11: warning: comparison of distinct pointer
types lacks a cast [enabled by default]
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_dma_stop':
drivers/crypto/atmel-tdes.c:664:5: warning: format '%u' expects argument of
type 'unsigned int', but argument 2 has type 'size_t' [-Wformat]
vim +157 drivers/crypto/atmel-tdes.c
13802005 Nicolas Royer 2012-07-01 151 void *buf,
size_t buflen, size_t total, int out)
13802005 Nicolas Royer 2012-07-01 152 {
13802005 Nicolas Royer 2012-07-01 153 unsigned int count, off = 0;
13802005 Nicolas Royer 2012-07-01 154
13802005 Nicolas Royer 2012-07-01 155 while (buflen && total) {
13802005 Nicolas Royer 2012-07-01 156 count =
min((*sg)->length - *offset, total);
13802005 Nicolas Royer 2012-07-01 @157 count = min(count,
buflen);
13802005 Nicolas Royer 2012-07-01 158
13802005 Nicolas Royer 2012-07-01 159 if (!count)
13802005 Nicolas Royer 2012-07-01 160 return off;
13802005 Nicolas Royer 2012-07-01 161
13802005 Nicolas Royer 2012-07-01 162
scatterwalk_map_and_copy(buf + off, *sg, *offset, count, out);
13802005 Nicolas Royer 2012-07-01 163
13802005 Nicolas Royer 2012-07-01 164 off += count;
13802005 Nicolas Royer 2012-07-01 165 buflen -= count;
13802005 Nicolas Royer 2012-07-01 166 *offset += count;
13802005 Nicolas Royer 2012-07-01 167 total -= count;
13802005 Nicolas Royer 2012-07-01 168
13802005 Nicolas Royer 2012-07-01 169 if (*offset ==
(*sg)->length) {
13802005 Nicolas Royer 2012-07-01 170 *sg =
sg_next(*sg);
13802005 Nicolas Royer 2012-07-01 171 if (*sg)
13802005 Nicolas Royer 2012-07-01 172 *offset
= 0;
13802005 Nicolas Royer 2012-07-01 173 else
13802005 Nicolas Royer 2012-07-01 174 total =
0;
13802005 Nicolas Royer 2012-07-01 175 }
13802005 Nicolas Royer 2012-07-01 176 }
13802005 Nicolas Royer 2012-07-01 177
13802005 Nicolas Royer 2012-07-01 178 return off;
13802005 Nicolas Royer 2012-07-01 179 }
13802005 Nicolas Royer 2012-07-01 180
13802005 Nicolas Royer 2012-07-01 181 static inline u32
atmel_tdes_read(struct atmel_tdes_dev *dd, u32 offset)
13802005 Nicolas Royer 2012-07-01 182 {
13802005 Nicolas Royer 2012-07-01 183 return
readl_relaxed(dd->io_base + offset);
13802005 Nicolas Royer 2012-07-01 184 }
13802005 Nicolas Royer 2012-07-01 185
13802005 Nicolas Royer 2012-07-01 186 static inline void
atmel_tdes_write(struct atmel_tdes_dev *dd,
13802005 Nicolas Royer 2012-07-01 187
u32 offset, u32 value)
13802005 Nicolas Royer 2012-07-01 188 {
13802005 Nicolas Royer 2012
Re: crypto: atmel - Fix authenc compile test warnings
Hi Herbert,
[auto build test WARNING on cryptodev/master]
[also build test WARNING on v4.10-rc7 next-20170206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Herbert-Xu/crypto-atmel-Fix-authenc-compile-test-warnings/20170206-171201
base:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address':
unknown attribute
>> drivers/crypto/atmel-tdes.c:157:25: sparse: incompatible types in comparison
>> expression (different type sizes)
drivers/crypto/atmel-tdes.c:528:25: sparse: incompatible types in comparison
expression (different type sizes)
drivers/crypto/atmel-tdes.c:529:25: sparse: incompatible types in comparison
expression (different type sizes)
In file included from drivers/crypto/atmel-tdes.c:17:0:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_sg_copy':
include/linux/kernel.h:753:16: warning: comparison of distinct pointer types
lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:756:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^
drivers/crypto/atmel-tdes.c:157:11: note: in expansion of macro 'min'
count = min(count, buflen);
^~~
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-tdes.c:17:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_pdc_stop':
include/linux/kern_levels.h:4:18: warning: format '%u' expects argument of
type 'unsigned int', but argument 2 has type 'size_t {aka long unsigned int}'
[-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
include/linux/printk.h:292:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
drivers/crypto/atmel-tdes.c:339:4: note: in expansion of macro 'pr_err'
pr_err("not all data converted: %u\n", count);
^~
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_buff_init':
drivers/crypto/atmel-tdes.c:364:26: warning: format '%d' expects argument of
type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_err(dd->dev, "dma %d bytes error\n", dd->buflen);
^
drivers/crypto/atmel-tdes.c:372:26: warning: format '%d' expects argument of
type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_err(dd->dev, "dma %d bytes error\n", dd->buflen);
^
In file included from drivers/crypto/atmel-tdes.c:17:0:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_start':
include/linux/kernel.h:753:16: warning: comparison of distinct pointer types
lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:756:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^
drivers/crypto/atmel-tdes.c:528:11: note: in expansion of macro 'min'
count = min(dd->total, sg_dma_len(dd->in_sg));
^~~
include/linux/kernel.h:753:16: warning: comparison of distinct pointer types
lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:756:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^
drivers/crypto/atmel-tdes.c:529:11: note: in expansion of macro 'min'
count = min(count, sg_dma_len(dd->out_sg));
^~~
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-tdes.c:17:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_dma_stop':
include/linux/kern_levels.h:4:18: warning: format '%u' expects argument of
type 'unsigned int', but argument 2 has type 'size_t {aka long unsigned int}'
[-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_
Re: [PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver
On Mon, Feb 06, 2017 at 05:31:15PM +0530, Anup Patel wrote:
> >> +
> >> +/* SBA C_MDATA helper macros */
> >> +#define SBA_C_MDATA_LOAD_VAL(__bnum0)((__bnum0) & 0x3)
> >> +#define SBA_C_MDATA_WRITE_VAL(__bnum0) ((__bnum0) & 0x3)
> >> +#define SBA_C_MDATA_XOR_VAL(__bnum1, __bnum0)\
> >> + ({ u32 __v = ((__bnum0) & 0x3);\
> >> + __v |= ((__bnum1) & 0x3) << 2; \
> >> + __v;\
> >> + })
> >> +#define SBA_C_MDATA_PQ_VAL(__dnum, __bnum1, __bnum0) \
> >> + ({ u32 __v = ((__bnum0) & 0x3);\
> >> + __v |= ((__bnum1) & 0x3) << 2; \
> >> + __v |= ((__dnum) & 0x1f) << 5; \
> >> + __v;\
> >> + })
> >
> > ah why are we usig complex macros, why can't these be simple functions..
>
> "static inline functions" seemed too complicated here because most of
> these macros are two lines of c-code.
and thats where I have an issue with this. Macros for simple things is fine
but not for couple of line of logic!
>
> Do you still insist on using "static inline functions"?
Yes
>
> >
> >> +#define SBA_C_MDATA_LS(__c_mdata_val)((__c_mdata_val) & 0xff)
> >> +#define SBA_C_MDATA_MS(__c_mdata_val)(((__c_mdata_val) >> 8) &
> >> 0x3)
> >> +
> >> +/* Driver helper macros */
> >> +#define to_sba_request(tx) \
> >> + container_of(tx, struct sba_request, tx)
> >> +#define to_sba_device(dchan) \
> >> + container_of(dchan, struct sba_device, dma_chan)
> >> +
> >> +enum sba_request_state {
> >> + SBA_REQUEST_STATE_FREE = 1,
> >> + SBA_REQUEST_STATE_ALLOCED = 2,
> >> + SBA_REQUEST_STATE_PENDING = 3,
> >> + SBA_REQUEST_STATE_ACTIVE = 4,
> >> + SBA_REQUEST_STATE_COMPLETED = 5,
> >> + SBA_REQUEST_STATE_ABORTED = 6,
> >
> > whats up with a very funny indentation setting, we use 8 chars.
> >
> > Please re-read the Documentation/process/coding-style.rst
>
> I have double checked this enum. The indentation is fine
> and as-per coding style. Am I missing anything else?
Somehow the initial indent doesnt seem to be 8 chars to me.
> >> +static enum dma_status sba_tx_status(struct dma_chan *dchan,
> >> + dma_cookie_t cookie,
> >> + struct dma_tx_state *txstate)
> >> +{
> >> + int mchan_idx;
> >> + enum dma_status ret;
> >> + struct sba_device *sba = to_sba_device(dchan);
> >> +
> >> + ret = dma_cookie_status(dchan, cookie, txstate);
> >> + if (ret == DMA_COMPLETE)
> >> + return ret;
> >> +
> >> + for (mchan_idx = 0; mchan_idx < sba->mchans_count; mchan_idx++)
> >> + mbox_client_peek_data(sba->mchans[mchan_idx]);
> >
> > what is this achieving?
>
> The mbox_client_peek_data() is a hint to mailbox controller driver
> to check for available messages.
>
> This gives good performance improvement when some DMA client
> code is polling using tx_status() callback.
Then why do it before and then check status.
--
~Vinod
Re: [PATCH 0/6] Add support for ECDSA algorithm
Am Donnerstag, 2. Februar 2017, 21:57:21 CET schrieb Herbert Xu: Hi Herbert, > On Thu, Jan 26, 2017 at 11:30:04AM +0530, Nitin Kumbhar wrote: > > This ECDSA implementation is analogous to the RSA kernel implementation > > for > > signature generation / verification. It extends ECC family of algorithms > > like ECDH to support signature verification using akcipher. This will be > > used in a way similar to RSA. > > Yes but RSA had an in-kernel user in the form of module signature > verification. We don't add algorithms to the kernel without > actual users. So this patch-set needs to come with an actual > in-kernel user of ECDSA. If I understood correctly, the crypto API should also provide device drivers for cryptographic accelerators to user space. This would be of special importance for asymmetric ciphers considering their resource intense operation. As for each HW implementation there should be a SW fallback, shouldn't ECDSA therefore be added? Please note that I am currently updating algif_akcipher to be en-par with algif_skcipher and algif_aead, including an AIO operation. Ciao Stephan
Re: [PATCH] dm: switch dm-verity to async hash crypto API
Hi Eric, On Mon, Jan 30, 2017 at 2:28 AM, Eric Biggers wrote: ... > As for the patch, I haven't looked at it in detail, but I agree that if > dm-verity is indeed operating on sufficiently large buffers in physically > contiguous memory, then the ahash API would be better than the shash API. > Note, > that it also could be useful look into supporting having multiple async > requests > issued and pending at the same time, similar to what dm-crypt does. Thank you for the feedback Eric. I just sent out a v2 with fixes based on Ondrej feedback. Supporting multiple outstanding async requests is a great idea. I will look into supporting it. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru
[PATCH v2] dm: switch dm-verity to async hash crypto API
Use of the synchronous digest API limits dm-verity to using pure
CPU based algorithm providers and rules out the use of off CPU
algorithm providers which are normally asynchronous by nature,
potentially freeing CPU cycles.
This can reduce performance per Watt in situations such as during
boot time when a lot of concurrent file accesses are made to the
protected volume.
Move DM_VERITY to the asynchronous hash API.
Signed-off-by: Gilad Ben-Yossef
CC: Eric Biggers
CC: Ondrej Mosnáček
---
The patch was tested on an Armv7 based dual core Zynq ZC706 development
board with SHA256-asm, SHA256-neon synchronous providers with no visible
degradation of performance and with off tree Arm CryptoCell asynchronous
provider.
Changes from v1:
- Use a 0 mask to allocate crypto alg indicating we welcome async algo
providers, as suggested by Ondrej Mosnáček.
- Fix use of un-initialized completion when using async provider for IO
blocks hashing
- Pass flag indicating we are OK with crypto provider backlog
- Re-factor checking for need to wait into a common function
drivers/md/dm-verity-fec.c| 4 +-
drivers/md/dm-verity-target.c | 202 +-
drivers/md/dm-verity.h| 23 +++--
3 files changed, 158 insertions(+), 71 deletions(-)
diff --git a/drivers/md/dm-verity-fec.c b/drivers/md/dm-verity-fec.c
index 0f0eb8a..dab98fe 100644
--- a/drivers/md/dm-verity-fec.c
+++ b/drivers/md/dm-verity-fec.c
@@ -188,7 +188,7 @@ static int fec_decode_bufs(struct dm_verity *v, struct
dm_verity_fec_io *fio,
static int fec_is_erasure(struct dm_verity *v, struct dm_verity_io *io,
u8 *want_digest, u8 *data)
{
- if (unlikely(verity_hash(v, verity_io_hash_desc(v, io),
+ if (unlikely(verity_hash(v, verity_io_hash_req(v, io),
data, 1 << v->data_dev_block_bits,
verity_io_real_digest(v, io
return 0;
@@ -397,7 +397,7 @@ static int fec_decode_rsb(struct dm_verity *v, struct
dm_verity_io *io,
}
/* Always re-validate the corrected block against the expected hash */
- r = verity_hash(v, verity_io_hash_desc(v, io), fio->output,
+ r = verity_hash(v, verity_io_hash_req(v, io), fio->output,
1 << v->data_dev_block_bits,
verity_io_real_digest(v, io));
if (unlikely(r < 0))
diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index 7335d8a..f0b24cc 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -93,81 +93,124 @@ static sector_t verity_position_at_level(struct dm_verity
*v, sector_t block,
}
/*
- * Wrapper for crypto_shash_init, which handles verity salting.
+ * Callback function for asynchrnous crypto API completion notification
*/
-static int verity_hash_init(struct dm_verity *v, struct shash_desc *desc)
+static void verity_op_done(struct crypto_async_request *base, int err)
{
- int r;
+ struct verity_result *res = (struct verity_result *)base->data;
- desc->tfm = v->tfm;
- desc->flags = CRYPTO_TFM_REQ_MAY_SLEEP;
+ if (err == -EINPROGRESS)
+ return;
- r = crypto_shash_init(desc);
+ res->err = err;
+ complete(&res->completion);
+}
- if (unlikely(r < 0)) {
- DMERR("crypto_shash_init failed: %d", r);
- return r;
- }
+/*
+ * Wait for async crypto API callback
+ */
+static inline int verity_complete_op(struct verity_result *res, int ret)
+{
+ switch (ret) {
+ case 0:
+ break;
- if (likely(v->version >= 1)) {
- r = crypto_shash_update(desc, v->salt, v->salt_size);
+ case -EINPROGRESS:
+ case -EBUSY:
+ ret = wait_for_completion_interruptible(&res->completion);
+ if (!ret)
+ ret = res->err;
+ reinit_completion(&res->completion);
+ break;
- if (unlikely(r < 0)) {
- DMERR("crypto_shash_update failed: %d", r);
- return r;
- }
+ default:
+ DMERR("verity_wait_hash: crypto op submission failed: %d", ret);
}
- return 0;
+ if (unlikely(ret < 0))
+ DMERR("verity_wait_hash: crypto op failed: %d", ret);
+
+ return ret;
}
-static int verity_hash_update(struct dm_verity *v, struct shash_desc *desc,
- const u8 *data, size_t len)
+static int verity_hash_update(struct dm_verity *v, struct ahash_request *req,
+ const u8 *data, size_t len,
+ struct verity_result *res)
{
- int r = crypto_shash_update(desc, data, len);
+ struct scatterlist sg;
- if (unlikely(r < 0))
- DMERR("crypto_shash_update failed: %d", r);
+ sg_init_table(&sg, 1);
+ sg_set_buf(
Re: crypto: atmel - Fix authenc compile test warnings
Hi Herbert,
[auto build test WARNING on cryptodev/master]
[also build test WARNING on v4.10-rc7 next-20170206]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Herbert-Xu/crypto-atmel-Fix-authenc-compile-test-warnings/20170206-171201
base:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
In file included from drivers/crypto/atmel-tdes.c:17:0:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_sg_copy':
include/linux/kernel.h:753:16: warning: comparison of distinct pointer types
lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:756:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^
>> drivers/crypto/atmel-tdes.c:157:11: note: in expansion of macro 'min'
count = min(count, buflen);
^~~
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-tdes.c:17:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_pdc_stop':
>> include/linux/kern_levels.h:4:18: warning: format '%u' expects argument of
>> type 'unsigned int', but argument 2 has type 'size_t {aka long unsigned
>> int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
include/linux/printk.h:292:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~
>> drivers/crypto/atmel-tdes.c:339:4: note: in expansion of macro 'pr_err'
pr_err("not all data converted: %u\n", count);
^~
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_buff_init':
>> drivers/crypto/atmel-tdes.c:364:26: warning: format '%d' expects argument of
>> type 'int', but argument 3 has type 'size_t {aka long unsigned int}'
>> [-Wformat=]
dev_err(dd->dev, "dma %d bytes error\n", dd->buflen);
^
drivers/crypto/atmel-tdes.c:372:26: warning: format '%d' expects argument of
type 'int', but argument 3 has type 'size_t {aka long unsigned int}' [-Wformat=]
dev_err(dd->dev, "dma %d bytes error\n", dd->buflen);
^
In file included from drivers/crypto/atmel-tdes.c:17:0:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_start':
include/linux/kernel.h:753:16: warning: comparison of distinct pointer types
lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:756:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^
drivers/crypto/atmel-tdes.c:528:11: note: in expansion of macro 'min'
count = min(dd->total, sg_dma_len(dd->in_sg));
^~~
include/linux/kernel.h:753:16: warning: comparison of distinct pointer types
lacks a cast
(void) (&min1 == &min2); \
^
include/linux/kernel.h:756:2: note: in expansion of macro '__min'
__min(typeof(x), typeof(y), \
^
drivers/crypto/atmel-tdes.c:529:11: note: in expansion of macro 'min'
count = min(count, sg_dma_len(dd->out_sg));
^~~
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-tdes.c:17:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_dma_stop':
>> include/linux/kern_levels.h:4:18: warning: format '%u' expects argument of
>> type 'unsigned int', but argument 2 has type 'size_t {aka long unsigned
>> int}' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~
include/linux/printk.h:292:9: note: in expansion of macro 'KERN_ERR'
printk(KER
[PATCH 2/2] crypto: atmel - fix 64-bit build warnings
When we enable COMPILE_TEST building for the Atmel sha and tdes implementations,
we run into a couple of warnings about incorrect format strings, e.g.
In file included from include/linux/platform_device.h:14:0,
from drivers/crypto/atmel-sha.c:24:
drivers/crypto/atmel-sha.c: In function 'atmel_sha_xmit_cpu':
drivers/crypto/atmel-sha.c:571:19: error: format '%d' expects argument of type
'int', but argument 6 has type 'size_t {aka long unsigned int}'
[-Werror=format=]
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from drivers/crypto/atmel-tdes.c:17:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_dma_stop':
include/linux/kern_levels.h:4:18: error: format '%u' expects argument of type
'unsigned int', but argument 2 has type 'size_t {aka long unsigned int}'
[-Werror=format=]
These are all fixed by using the "%z" modifier for size_t data.
There are also a few uses of min()/max() with incompatible types:
drivers/crypto/atmel-tdes.c: In function 'atmel_tdes_crypt_start':
drivers/crypto/atmel-tdes.c:528:181: error: comparison of distinct pointer
types lacks a cast [-Werror]
Where possible, we should use consistent types here, otherwise we can use
min_t()/max_t() to get well-defined behavior without a warning.
Signed-off-by: Arnd Bergmann
---
drivers/crypto/atmel-sha.c | 16
drivers/crypto/atmel-tdes.c | 14 +++---
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index 22d0c0c118da..50a1dcd50c46 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -568,7 +568,7 @@ static int atmel_sha_xmit_cpu(struct atmel_sha_dev *dd,
const u8 *buf,
int count, len32;
const u32 *buffer = (const u32 *)buf;
- dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final:
%d\n",
+ dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %zd, final:
%d\n",
ctx->digcnt[1], ctx->digcnt[0], length, final);
atmel_sha_write_ctrl(dd, 0);
@@ -597,7 +597,7 @@ static int atmel_sha_xmit_pdc(struct atmel_sha_dev *dd,
dma_addr_t dma_addr1,
struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
int len32;
- dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final:
%d\n",
+ dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %zd, final:
%d\n",
ctx->digcnt[1], ctx->digcnt[0], length1, final);
len32 = DIV_ROUND_UP(length1, sizeof(u32));
@@ -644,7 +644,7 @@ static int atmel_sha_xmit_dma(struct atmel_sha_dev *dd,
dma_addr_t dma_addr1,
struct dma_async_tx_descriptor *in_desc;
struct scatterlist sg[2];
- dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final:
%d\n",
+ dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %zd, final:
%d\n",
ctx->digcnt[1], ctx->digcnt[0], length1, final);
dd->dma_lch_in.dma_conf.src_maxburst = 16;
@@ -723,7 +723,7 @@ static int atmel_sha_xmit_dma_map(struct atmel_sha_dev *dd,
ctx->dma_addr = dma_map_single(dd->dev, ctx->buffer,
ctx->buflen + ctx->block_size, DMA_TO_DEVICE);
if (dma_mapping_error(dd->dev, ctx->dma_addr)) {
- dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
+ dev_err(dd->dev, "dma %zu bytes error\n", ctx->buflen +
ctx->block_size);
atmel_sha_complete(dd, -EINVAL);
}
@@ -744,7 +744,7 @@ static int atmel_sha_update_dma_slow(struct atmel_sha_dev
*dd)
final = (ctx->flags & SHA_FLAGS_FINUP) && !ctx->total;
- dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
+ dev_dbg(dd->dev, "slow: bufcnt: %zu, digcnt: 0x%llx 0x%llx, final:
%d\n",
ctx->bufcnt, ctx->digcnt[1], ctx->digcnt[0], final);
if (final)
@@ -772,7 +772,7 @@ static int atmel_sha_update_dma_start(struct atmel_sha_dev
*dd)
if (ctx->bufcnt || ctx->offset)
return atmel_sha_update_dma_slow(dd);
- dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
+ dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %zd, total:
%u\n",
ctx->digcnt[1], ctx->digcnt[0], ctx->bufcnt, ctx->total);
sg = ctx->sg;
@@ -814,7 +814,7 @@ static int atmel_sha_update_dma_start(struct atmel_sha_dev
*dd)
ctx->dma_addr = dma_map_single(dd->dev, ctx->buffer,
ctx->buflen + ctx->block_size, DMA_TO_DEVICE);
if (dma_mapping_error(dd->dev, ctx->dma_addr)) {
- dev_err(dd->dev, "dma %u bytes error\n",
+ dev_err(dd->dev, "dma %zu bytes error\n",
ctx->buflen + ctx->block_size);
atmel_sha_complete(dd, -
[PATCH 1/2] crypto: atmel - refine Kconfig dependencies
With the new authenc support, we get a harmless Kconfig warning:
warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has
unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
The problem is that each of the options has slightly different dependencies,
although they all seem to want the same thing: allow building for real AT91
targets that actually have the hardware, and possibly for compile testing.
This makes all four options consistent: instead of depending on a particular
dmaengine implementation, we depend on the ARM platform, CONFIG_COMPILE_TEST
as an alternative when that is turned off. This makes the 'select' statements
work correctly.
Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to
authenc(hmac(shaX), Y(aes)) modes")
Signed-off-by: Arnd Bergmann
---
drivers/crypto/Kconfig | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 74824612d3e9..f60de152a90d 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -417,7 +417,8 @@ config CRYPTO_DEV_BFIN_CRC
config CRYPTO_DEV_ATMEL_AUTHENC
tristate "Support for Atmel IPSEC/SSL hw accelerator"
- depends on (ARCH_AT91 && HAS_DMA) || COMPILE_TEST
+ depends on HAS_DMA
+ depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AUTHENC
select CRYPTO_DEV_ATMEL_AES
select CRYPTO_DEV_ATMEL_SHA
@@ -430,7 +431,7 @@ config CRYPTO_DEV_ATMEL_AUTHENC
config CRYPTO_DEV_ATMEL_AES
tristate "Support for Atmel AES hw accelerator"
depends on HAS_DMA
- depends on AT_XDMAC || AT_HDMAC || COMPILE_TEST
+ depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_AES
select CRYPTO_AEAD
select CRYPTO_BLKCIPHER
@@ -444,7 +445,7 @@ config CRYPTO_DEV_ATMEL_AES
config CRYPTO_DEV_ATMEL_TDES
tristate "Support for Atmel DES/TDES hw accelerator"
- depends on ARCH_AT91
+ depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_DES
select CRYPTO_BLKCIPHER
help
@@ -457,7 +458,7 @@ config CRYPTO_DEV_ATMEL_TDES
config CRYPTO_DEV_ATMEL_SHA
tristate "Support for Atmel SHA hw accelerator"
- depends on ARCH_AT91
+ depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_HASH
help
Some Atmel processors have SHA1/SHA224/SHA256/SHA384/SHA512
--
2.9.0
Re: [PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver
On Sun, Feb 5, 2017 at 11:36 AM, Vinod Koul wrote:
> On Thu, Feb 02, 2017 at 10:17:15AM +0530, Anup Patel wrote:
>> +config BCM_SBA_RAID
>> +tristate "Broadcom SBA RAID engine support"
>> +depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
>> +select DMA_ENGINE
>> +select DMA_ENGINE_RAID
>> + select ASYNC_TX_ENABLE_CHANNEL_SWITCH
>> + default ARCH_BCM_IPROC
>
> whats with the funny alignement?
Sure, I will use tabs here.
>
>> +/* SBA command related defines */
>> +#define SBA_TYPE_SHIFT 48
>> +#define SBA_TYPE_MASK0x3
>> +#define SBA_TYPE_A 0x0
>> +#define SBA_TYPE_B 0x2
>> +#define SBA_TYPE_C 0x3
>> +#define SBA_USER_DEF_SHIFT 32
>> +#define SBA_USER_DEF_MASK0x
>> +#define SBA_R_MDATA_SHIFT24
>> +#define SBA_R_MDATA_MASK 0xff
>> +#define SBA_C_MDATA_MS_SHIFT 18
>> +#define SBA_C_MDATA_MS_MASK 0x3
>> +#define SBA_INT_SHIFT17
>> +#define SBA_INT_MASK 0x1
>> +#define SBA_RESP_SHIFT 16
>> +#define SBA_RESP_MASK0x1
>> +#define SBA_C_MDATA_SHIFT8
>> +#define SBA_C_MDATA_MASK 0xff
>> +#define SBA_CMD_SHIFT0
>> +#define SBA_CMD_MASK 0xf
>> +#define SBA_CMD_ZERO_ALL_BUFFERS 0x8
>> +#define SBA_CMD_LOAD_BUFFER 0x9
>> +#define SBA_CMD_XOR 0xa
>> +#define SBA_CMD_GALOIS_XOR 0xb
>> +#define SBA_CMD_ZERO_BUFFER 0x4
>> +#define SBA_CMD_WRITE_BUFFER 0xc
>
> Try using BIT and GENMAST for hardware descriptions
Sure, will do.
>
>> +
>> +/* SBA C_MDATA helper macros */
>> +#define SBA_C_MDATA_LOAD_VAL(__bnum0)((__bnum0) & 0x3)
>> +#define SBA_C_MDATA_WRITE_VAL(__bnum0) ((__bnum0) & 0x3)
>> +#define SBA_C_MDATA_XOR_VAL(__bnum1, __bnum0)\
>> + ({ u32 __v = ((__bnum0) & 0x3);\
>> + __v |= ((__bnum1) & 0x3) << 2; \
>> + __v;\
>> + })
>> +#define SBA_C_MDATA_PQ_VAL(__dnum, __bnum1, __bnum0) \
>> + ({ u32 __v = ((__bnum0) & 0x3);\
>> + __v |= ((__bnum1) & 0x3) << 2; \
>> + __v |= ((__dnum) & 0x1f) << 5; \
>> + __v;\
>> + })
>
> ah why are we usig complex macros, why can't these be simple functions..
"static inline functions" seemed too complicated here because most of
these macros are two lines of c-code.
Do you still insist on using "static inline functions"?
>
>> +#define SBA_C_MDATA_LS(__c_mdata_val)((__c_mdata_val) & 0xff)
>> +#define SBA_C_MDATA_MS(__c_mdata_val)(((__c_mdata_val) >> 8) & 0x3)
>> +
>> +/* Driver helper macros */
>> +#define to_sba_request(tx) \
>> + container_of(tx, struct sba_request, tx)
>> +#define to_sba_device(dchan) \
>> + container_of(dchan, struct sba_device, dma_chan)
>> +
>> +enum sba_request_state {
>> + SBA_REQUEST_STATE_FREE = 1,
>> + SBA_REQUEST_STATE_ALLOCED = 2,
>> + SBA_REQUEST_STATE_PENDING = 3,
>> + SBA_REQUEST_STATE_ACTIVE = 4,
>> + SBA_REQUEST_STATE_COMPLETED = 5,
>> + SBA_REQUEST_STATE_ABORTED = 6,
>
> whats up with a very funny indentation setting, we use 8 chars.
>
> Please re-read the Documentation/process/coding-style.rst
I have double checked this enum. The indentation is fine
and as-per coding style. Am I missing anything else?
>
>> +static int sba_alloc_chan_resources(struct dma_chan *dchan)
>> +{
>> + /*
>> + * We only have one channel so we have pre-alloced
>> + * channel resources. Over here we just return number
>> + * of free request.
>> + */
>> + return sba_free_request_count(to_sba_device(dchan));
>> +}
>
> essentially you are not doing much, so you can skip it. Its an optional
> call.
Sure, will do.
>
>> +static void sba_free_chan_resources(struct dma_chan *dchan)
>> +{
>> + /*
>> + * Channel resources are pre-alloced so we just free-up
>> + * whatever we can so that we can re-use pre-alloced
>> + * channel resources next time.
>> + */
>> + sba_cleanup_inflight_requests(to_sba_device(dchan));
>
> well this one checks for pending requests as well, which shouldn't be there
> when freeing
Re: [PATCH v3 2/3] crypto: ccm - switch to separate cbcmac driver
On 3 February 2017 at 14:49, Ard Biesheuvel wrote:
> Update the generic CCM driver to defer CBC-MAC processing to a
> dedicated CBC-MAC ahash transform rather than open coding this
> transform (and much of the associated scatterwalk plumbing) in
> the CCM driver itself.
>
> This cleans up the code considerably, but more importantly, it allows
> the use of alternative CBC-MAC implementations that don't suffer from
> performance degradation due to significant setup time (e.g., the NEON
> based AES code needs to enable/disable the NEON, and load the S-box
> into 16 SIMD registers, which cannot be amortized over the entire input
> when using the cipher interface)
>
> Signed-off-by: Ard Biesheuvel
> ---
> crypto/Kconfig | 1 +
> crypto/ccm.c | 381 +---
> 2 files changed, 245 insertions(+), 137 deletions(-)
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 160f08e721cc..e8269d1b0282 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -263,6 +263,7 @@ comment "Authenticated Encryption with Associated Data"
> config CRYPTO_CCM
> tristate "CCM support"
> select CRYPTO_CTR
> + select CRYPTO_HASH
> select CRYPTO_AEAD
> help
> Support for Counter with CBC MAC. Required for IPsec.
> diff --git a/crypto/ccm.c b/crypto/ccm.c
> index 26b924d1e582..52e307807ff6 100644
> --- a/crypto/ccm.c
> +++ b/crypto/ccm.c
> @@ -11,6 +11,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -23,11 +24,11 @@
>
> struct ccm_instance_ctx {
> struct crypto_skcipher_spawn ctr;
> - struct crypto_spawn cipher;
> + struct crypto_ahash_spawn mac;
> };
>
> struct crypto_ccm_ctx {
> - struct crypto_cipher *cipher;
> + struct crypto_ahash *mac;
> struct crypto_skcipher *ctr;
> };
>
> @@ -44,15 +45,22 @@ struct crypto_rfc4309_req_ctx {
>
> struct crypto_ccm_req_priv_ctx {
> u8 odata[16];
> - u8 idata[16];
> u8 auth_tag[16];
> - u32 ilen;
> u32 flags;
> struct scatterlist src[3];
> struct scatterlist dst[3];
> struct skcipher_request skreq;
> };
>
> +struct cbcmac_tfm_ctx {
> + struct crypto_cipher *child;
> +};
> +
> +struct cbcmac_desc_ctx {
> + unsigned int len;
> + u8 dg[];
This should be
u8 dg[] CRYPTO_MINALIGN_ATTR;
> +};
> +
> static inline struct crypto_ccm_req_priv_ctx *crypto_ccm_reqctx(
> struct aead_request *req)
> {
> @@ -84,7 +92,7 @@ static int crypto_ccm_setkey(struct crypto_aead *aead,
> const u8 *key,
> {
> struct crypto_ccm_ctx *ctx = crypto_aead_ctx(aead);
> struct crypto_skcipher *ctr = ctx->ctr;
> - struct crypto_cipher *tfm = ctx->cipher;
> + struct crypto_ahash *mac = ctx->mac;
> int err = 0;
>
> crypto_skcipher_clear_flags(ctr, CRYPTO_TFM_REQ_MASK);
> @@ -96,11 +104,11 @@ static int crypto_ccm_setkey(struct crypto_aead *aead,
> const u8 *key,
> if (err)
> goto out;
>
> - crypto_cipher_clear_flags(tfm, CRYPTO_TFM_REQ_MASK);
> - crypto_cipher_set_flags(tfm, crypto_aead_get_flags(aead) &
> + crypto_ahash_clear_flags(mac, CRYPTO_TFM_REQ_MASK);
> + crypto_ahash_set_flags(mac, crypto_aead_get_flags(aead) &
> CRYPTO_TFM_REQ_MASK);
> - err = crypto_cipher_setkey(tfm, key, keylen);
> - crypto_aead_set_flags(aead, crypto_cipher_get_flags(tfm) &
> + err = crypto_ahash_setkey(mac, key, keylen);
> + crypto_aead_set_flags(aead, crypto_ahash_get_flags(mac) &
> CRYPTO_TFM_RES_MASK);
>
> out:
> @@ -167,119 +175,61 @@ static int format_adata(u8 *adata, unsigned int a)
> return len;
> }
>
> -static void compute_mac(struct crypto_cipher *tfm, u8 *data, int n,
> - struct crypto_ccm_req_priv_ctx *pctx)
> -{
> - unsigned int bs = 16;
> - u8 *odata = pctx->odata;
> - u8 *idata = pctx->idata;
> - int datalen, getlen;
> -
> - datalen = n;
> -
> - /* first time in here, block may be partially filled. */
> - getlen = bs - pctx->ilen;
> - if (datalen >= getlen) {
> - memcpy(idata + pctx->ilen, data, getlen);
> - crypto_xor(odata, idata, bs);
> - crypto_cipher_encrypt_one(tfm, odata, odata);
> - datalen -= getlen;
> - data += getlen;
> - pctx->ilen = 0;
> - }
> -
> - /* now encrypt rest of data */
> - while (datalen >= bs) {
> - crypto_xor(odata, data, bs);
> - crypto_cipher_encrypt_one(tfm, odata, odata);
> -
> - datalen -= bs;
> - data += bs;
> - }
> -
> - /* check and see if there's leftover data that wasn't
> -* enough to fill a block.
> -*/
> - if (datalen) {
> - memcpy(idata + pctx->ilen, data, datalen);
> - pctx->ilen += da
Crypto Fixes for 4.10
Hi Linus: This push fixes the following issues: - Use after free in algif_aead. - Modular aesni regression when pcbc is modular but absent. - Bug causing IO page faults in ccp. - Double list add in ccp. - Null pointer dereference in qat (two patches). - Panic in chcr. - Null pointer dereference in chcr. - Out-of-bound access in chcr. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Gary R Hook (2): crypto: ccp - Fix DMA operations when IOMMU is enabled crypto: ccp - Fix double add when creating new DMA command Giovanni Cabiddu (2): crypto: qat - fix bar discovery for c62x crypto: qat - zero esram only for DH85x devices Harsh Jain (4): crypto: chcr - Fix panic on dma_unmap_sg crypto: chcr - Check device is allocated before use crypto: algif_aead - Fix kernel panic on list_del crypto: chcr - Fix key length for RFC4106 Herbert Xu (1): crypto: aesni - Fix failure when pcbc module is absent arch/x86/crypto/aesni-intel_glue.c|8 ++-- crypto/algif_aead.c |2 +- drivers/crypto/ccp/ccp-dev-v5.c |2 +- drivers/crypto/ccp/ccp-dev.h |1 + drivers/crypto/ccp/ccp-dmaengine.c|6 ++- drivers/crypto/chelsio/chcr_algo.c| 53 +++-- drivers/crypto/chelsio/chcr_core.c| 18 --- drivers/crypto/chelsio/chcr_crypto.h |3 ++ drivers/crypto/qat/qat_c62x/adf_drv.c |2 +- drivers/crypto/qat/qat_common/adf_accel_devices.h |1 + drivers/crypto/qat/qat_common/qat_hal.c |4 +- 11 files changed, 55 insertions(+), 45 deletions(-) Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: linux-next: build warnings after merge of the crypto tree
Hi Stephen:
On Mon, Feb 06, 2017 at 12:28:37PM +1100, Stephen Rothwell wrote:
>
> After merging the crypto tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has
> unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
> warning: (CRYPTO_DEV_ATMEL_AUTHENC) selects CRYPTO_DEV_ATMEL_SHA which has
> unmet direct dependencies (CRYPTO && CRYPTO_HW && ARCH_AT91)
>
> Introduced by commit
>
> 89a82ef87e01 ("crypto: atmel-authenc - add support to authenc(hmac(shaX),
> Y(aes)) modes")
>
> In file included from include/linux/printk.h:329:0,
> from include/linux/kernel.h:13,
> from drivers/crypto/atmel-sha.c:17:
This patch should fix both issues. Thanks,
---8<---
Subject: crypto: atmel - Fix authenc compile test warnings
The authenc code depends on the sha code so in order to allow
compile testing on the former we must allow it on sha as well.
This patch enables compile testing on sha as well as tdes and
fixes the few x86-64 warnings that arise in the sha code.
Reported-by: Stephen Rothwell
Signed-off-by: Herbert Xu
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 7482461..9b7e19e 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -444,7 +444,7 @@ config CRYPTO_DEV_ATMEL_AES
config CRYPTO_DEV_ATMEL_TDES
tristate "Support for Atmel DES/TDES hw accelerator"
- depends on ARCH_AT91
+ depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_DES
select CRYPTO_BLKCIPHER
help
@@ -457,7 +457,7 @@ config CRYPTO_DEV_ATMEL_TDES
config CRYPTO_DEV_ATMEL_SHA
tristate "Support for Atmel SHA hw accelerator"
- depends on ARCH_AT91
+ depends on ARCH_AT91 || COMPILE_TEST
select CRYPTO_HASH
help
Some Atmel processors have SHA1/SHA224/SHA256/SHA384/SHA512
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index 22d0c0c..b081e78 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -568,7 +568,7 @@ static int atmel_sha_xmit_cpu(struct atmel_sha_dev *dd,
const u8 *buf,
int count, len32;
const u32 *buffer = (const u32 *)buf;
- dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %d, final:
%d\n",
+ dev_dbg(dd->dev, "xmit_cpu: digcnt: 0x%llx 0x%llx, length: %zu, final:
%d\n",
ctx->digcnt[1], ctx->digcnt[0], length, final);
atmel_sha_write_ctrl(dd, 0);
@@ -597,7 +597,7 @@ static int atmel_sha_xmit_pdc(struct atmel_sha_dev *dd,
dma_addr_t dma_addr1,
struct atmel_sha_reqctx *ctx = ahash_request_ctx(dd->req);
int len32;
- dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %d, final:
%d\n",
+ dev_dbg(dd->dev, "xmit_pdc: digcnt: 0x%llx 0x%llx, length: %zu, final:
%d\n",
ctx->digcnt[1], ctx->digcnt[0], length1, final);
len32 = DIV_ROUND_UP(length1, sizeof(u32));
@@ -644,7 +644,7 @@ static int atmel_sha_xmit_dma(struct atmel_sha_dev *dd,
dma_addr_t dma_addr1,
struct dma_async_tx_descriptor *in_desc;
struct scatterlist sg[2];
- dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %d, final:
%d\n",
+ dev_dbg(dd->dev, "xmit_dma: digcnt: 0x%llx 0x%llx, length: %zu, final:
%d\n",
ctx->digcnt[1], ctx->digcnt[0], length1, final);
dd->dma_lch_in.dma_conf.src_maxburst = 16;
@@ -723,7 +723,7 @@ static int atmel_sha_xmit_dma_map(struct atmel_sha_dev *dd,
ctx->dma_addr = dma_map_single(dd->dev, ctx->buffer,
ctx->buflen + ctx->block_size, DMA_TO_DEVICE);
if (dma_mapping_error(dd->dev, ctx->dma_addr)) {
- dev_err(dd->dev, "dma %u bytes error\n", ctx->buflen +
+ dev_err(dd->dev, "dma %zu bytes error\n", ctx->buflen +
ctx->block_size);
atmel_sha_complete(dd, -EINVAL);
}
@@ -744,7 +744,7 @@ static int atmel_sha_update_dma_slow(struct atmel_sha_dev
*dd)
final = (ctx->flags & SHA_FLAGS_FINUP) && !ctx->total;
- dev_dbg(dd->dev, "slow: bufcnt: %u, digcnt: 0x%llx 0x%llx, final: %d\n",
+ dev_dbg(dd->dev, "slow: bufcnt: %zu, digcnt: 0x%llx 0x%llx, final:
%d\n",
ctx->bufcnt, ctx->digcnt[1], ctx->digcnt[0], final);
if (final)
@@ -772,7 +772,7 @@ static int atmel_sha_update_dma_start(struct atmel_sha_dev
*dd)
if (ctx->bufcnt || ctx->offset)
return atmel_sha_update_dma_slow(dd);
- dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %u, total: %u\n",
+ dev_dbg(dd->dev, "fast: digcnt: 0x%llx 0x%llx, bufcnt: %zu, total:
%u\n",
ctx->digcnt[1], ctx->digcnt[0], ctx->bufcnt, ctx->total);
sg = ctx->sg;
@@ -814,7 +814,7 @@ static int atmel_sha_update_dma_start(struct atmel_sha_dev
*dd)
ctx->dma_addr = dma
