* [cryptodev:master 41/47] ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
From: kbuild test robot @ 2016-10-26 0:47 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: kbuild-all, linux-crypto, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 927 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: d7db7a882debaffc78f91aabedee973aa1f73390
commit: 1ab53a77b772bf7369464a0e4fa6fd6499acf8f1 [41/47] crypto: acomp - add driver-side scomp interface
config: x86_64-randconfig-s4-10260656 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 1ab53a77b772bf7369464a0e4fa6fd6499acf8f1
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> ERROR: "crypto_acomp_scomp_free_ctx" [crypto/acompress.ko] undefined!
>> ERROR: "crypto_acomp_scomp_alloc_ctx" [crypto/acompress.ko] undefined!
>> ERROR: "crypto_init_scomp_ops_async" [crypto/acompress.ko] undefined!
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 19304 bytes --]
^ permalink raw reply
* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Trond Myklebust @ 2016-10-25 21:47 UTC (permalink / raw)
To: Fields Bruce James
Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161025195930.GB5129-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
> On Oct 25, 2016, at 15:59, Fields Bruce James <bfields@fieldses.org> wrote:
>
> On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
>>
>>> On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
>>>
>>> From: "J. Bruce Fields" <bfields@redhat.com>
>>>
>>> As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
>>> mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
>>> among other callers, passes it memory on the stack.
>>>
>>> We only need a scatterlist to pass this to the crypto code, and it seems
>>> like overkill to require kmalloc'd memory just to encrypt a few bytes,
>>> but for now this seems the best fix.
>>>
>>> Note many of these callers are in the NFS write paths, so we shouldn't
>>> really be allocating GFP_KERNEL. But we already have other allocations
>>> in these code paths. A larger redesign may be necessary to allow
>>> allocations to be done earlier.
>>
>> NACK… I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
>
> OK. Any disadvantage to keeping this patch with just GFP_NOFS
> allocations everywhere that might be in the write path?
It’s what we have to do everywhere else in the RPC client, so I can’t see why it should be a problem.
^ permalink raw reply
* [PATCH] crypto: caam: fix type mismatch warning
From: Arnd Bergmann @ 2016-10-25 21:29 UTC (permalink / raw)
To: Herbert Xu
Cc: Arnd Bergmann, David S. Miller, Horia Geantă, Catalin Vasile,
linux-crypto, linux-kernel
Building the caam driver on arm64 produces a harmless warning:
drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct pointer types lacks a cast
We can use min_t to tell the compiler which type we want it to use
here.
Fixes: 5ecf8ef9103c ("crypto: caam - fix sg dump")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This is currently the only warning reported by kernelci.org for
linux-4.9 on arm, arm64 and x86.
---
drivers/crypto/caam/caamalg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 156aad167cd6..8de85dfb1b04 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -137,7 +137,7 @@ static void dbg_dump_sg(const char *level, const char *prefix_str,
}
buf = it_page + it->offset;
- len = min(tlen, it->length);
+ len = min_t(size_t, tlen, it->length);
print_hex_dump(level, prefix_str, prefix_type, rowsize,
groupsize, buf, len, ascii);
tlen -= len;
--
2.9.0
^ permalink raw reply related
* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Fields Bruce James @ 2016-10-25 19:59 UTC (permalink / raw)
To: Trond Myklebust
Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
linux-crypto@vger.kernel.org
In-Reply-To: <A4086E5B-B808-4828-A25D-4AAB2504EC57@primarydata.com>
On Tue, Oct 25, 2016 at 07:34:43PM +0000, Trond Myklebust wrote:
>
> > On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
> >
> > From: "J. Bruce Fields" <bfields@redhat.com>
> >
> > As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> > mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
> > among other callers, passes it memory on the stack.
> >
> > We only need a scatterlist to pass this to the crypto code, and it seems
> > like overkill to require kmalloc'd memory just to encrypt a few bytes,
> > but for now this seems the best fix.
> >
> > Note many of these callers are in the NFS write paths, so we shouldn't
> > really be allocating GFP_KERNEL. But we already have other allocations
> > in these code paths. A larger redesign may be necessary to allow
> > allocations to be done earlier.
>
> NACK… I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
OK. Any disadvantage to keeping this patch with just GFP_NOFS
allocations everywhere that might be in the write path?
--b.
^ permalink raw reply
* Re: [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: Trond Myklebust @ 2016-10-25 19:34 UTC (permalink / raw)
To: Fields Bruce James
Cc: List Linux NFS Mailing, Rusty Russell, Christoph Hellwig,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161025184538.GA4612-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
> On Oct 25, 2016, at 14:45, J. Bruce Fields <bfields@fieldses.org> wrote:
>
> From: "J. Bruce Fields" <bfields@redhat.com>
>
> As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
> mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
> among other callers, passes it memory on the stack.
>
> We only need a scatterlist to pass this to the crypto code, and it seems
> like overkill to require kmalloc'd memory just to encrypt a few bytes,
> but for now this seems the best fix.
>
> Note many of these callers are in the NFS write paths, so we shouldn't
> really be allocating GFP_KERNEL. But we already have other allocations
> in these code paths. A larger redesign may be necessary to allow
> allocations to be done earlier.
NACK… I agree that there may already be borkage in RPCSEC_GSS-land, but that’s not a reason to be adding to the pile of things that need to be fixed… The allocations that lie in the RPC client’s encode/decode path do need to be GFP_NOFS….
^ permalink raw reply
* [PATCH] sunrpc: don't pass on-stack memory to sg_set_buf
From: J. Bruce Fields @ 2016-10-25 18:45 UTC (permalink / raw)
To: linux-nfs-u79uwXL29TY76Z2rM5mHXA
Cc: Rusty Russell, Christoph Hellwig,
linux-crypto-u79uwXL29TY76Z2rM5mHXA
From: "J. Bruce Fields" <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
among other callers, passes it memory on the stack.
We only need a scatterlist to pass this to the crypto code, and it seems
like overkill to require kmalloc'd memory just to encrypt a few bytes,
but for now this seems the best fix.
Note many of these callers are in the NFS write paths, so we shouldn't
really be allocating GFP_KERNEL. But we already have other allocations
in these code paths. A larger redesign may be necessary to allow
allocations to be done earlier.
Cc: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
Signed-off-by: J. Bruce Fields <bfields-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
net/sunrpc/auth_gss/auth_gss.c | 13 ++++--
net/sunrpc/auth_gss/gss_krb5_crypto.c | 82 ++++++++++++++++++++---------------
net/sunrpc/auth_gss/svcauth_gss.c | 21 ++++++---
3 files changed, 71 insertions(+), 45 deletions(-)
diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
index d8bd97a5a7c9..6ecc30058f95 100644
--- a/net/sunrpc/auth_gss/auth_gss.c
+++ b/net/sunrpc/auth_gss/auth_gss.c
@@ -1616,7 +1616,7 @@ gss_validate(struct rpc_task *task, __be32 *p)
{
struct rpc_cred *cred = task->tk_rqstp->rq_cred;
struct gss_cl_ctx *ctx = gss_cred_get_ctx(cred);
- __be32 seq;
+ __be32 *seq = NULL;
struct kvec iov;
struct xdr_buf verf_buf;
struct xdr_netobj mic;
@@ -1631,9 +1631,12 @@ gss_validate(struct rpc_task *task, __be32 *p)
goto out_bad;
if (flav != RPC_AUTH_GSS)
goto out_bad;
- seq = htonl(task->tk_rqstp->rq_seqno);
- iov.iov_base = &seq;
- iov.iov_len = sizeof(seq);
+ seq = kmalloc(4, GFP_KERNEL);
+ if (!seq)
+ goto out_bad;
+ *seq = htonl(task->tk_rqstp->rq_seqno);
+ iov.iov_base = seq;
+ iov.iov_len = 4;
xdr_buf_from_iov(&iov, &verf_buf);
mic.data = (u8 *)p;
mic.len = len;
@@ -1653,11 +1656,13 @@ gss_validate(struct rpc_task *task, __be32 *p)
gss_put_ctx(ctx);
dprintk("RPC: %5u %s: gss_verify_mic succeeded.\n",
task->tk_pid, __func__);
+ kfree(seq);
return p + XDR_QUADLEN(len);
out_bad:
gss_put_ctx(ctx);
dprintk("RPC: %5u %s failed ret %ld.\n", task->tk_pid, __func__,
PTR_ERR(ret));
+ kfree(seq);
return ret;
}
diff --git a/net/sunrpc/auth_gss/gss_krb5_crypto.c b/net/sunrpc/auth_gss/gss_krb5_crypto.c
index 244245bcbbd2..8a280a810439 100644
--- a/net/sunrpc/auth_gss/gss_krb5_crypto.c
+++ b/net/sunrpc/auth_gss/gss_krb5_crypto.c
@@ -166,8 +166,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
unsigned int usage, struct xdr_netobj *cksumout)
{
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
u8 rc4salt[4];
struct crypto_ahash *md5;
struct crypto_ahash *hmac_md5;
@@ -187,23 +187,22 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+ if (!checksumdata)
+ return GSS_S_FAILURE;
+
md5 = crypto_alloc_ahash("md5", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(md5))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
hmac_md5 = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0,
CRYPTO_ALG_ASYNC);
- if (IS_ERR(hmac_md5)) {
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (IS_ERR(hmac_md5))
+ goto out_free_md5;
req = ahash_request_alloc(md5, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(hmac_md5);
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_hmac_md5;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -232,11 +231,8 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
ahash_request_free(req);
req = ahash_request_alloc(hmac_md5, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(hmac_md5);
- crypto_free_ahash(md5);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_hmac_md5;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -258,8 +254,12 @@ make_checksum_hmac_md5(struct krb5_ctx *kctx, char *header, int hdrlen,
cksumout->len = kctx->gk5e->cksumlength;
out:
ahash_request_free(req);
- crypto_free_ahash(md5);
+out_free_hmac_md5:
crypto_free_ahash(hmac_md5);
+out_free_md5:
+ crypto_free_ahash(md5);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -276,8 +276,8 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
struct crypto_ahash *tfm;
struct ahash_request *req;
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
unsigned int checksumlen;
if (kctx->gk5e->ctype == CKSUMTYPE_HMAC_MD5_ARCFOUR)
@@ -291,15 +291,17 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+ if (checksumdata == NULL)
+ return GSS_S_FAILURE;
+
tfm = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
req = ahash_request_alloc(tfm, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(tfm);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_ahash;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -349,7 +351,10 @@ make_checksum(struct krb5_ctx *kctx, char *header, int hdrlen,
cksumout->len = kctx->gk5e->cksumlength;
out:
ahash_request_free(req);
+out_free_ahash:
crypto_free_ahash(tfm);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -368,8 +373,8 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
struct crypto_ahash *tfm;
struct ahash_request *req;
struct scatterlist sg[1];
- int err;
- u8 checksumdata[GSS_KRB5_MAX_CKSUM_LEN];
+ int err = -1;
+ u8 *checksumdata;
unsigned int checksumlen;
if (kctx->gk5e->keyed_cksum == 0) {
@@ -383,16 +388,18 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
return GSS_S_FAILURE;
}
+ checksumdata = kmalloc(GSS_KRB5_MAX_CKSUM_LEN, GFP_KERNEL);
+ if (!checksumdata)
+ return GSS_S_FAILURE;
+
tfm = crypto_alloc_ahash(kctx->gk5e->cksum_name, 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
- return GSS_S_FAILURE;
+ goto out_free_cksum;
checksumlen = crypto_ahash_digestsize(tfm);
req = ahash_request_alloc(tfm, GFP_KERNEL);
- if (!req) {
- crypto_free_ahash(tfm);
- return GSS_S_FAILURE;
- }
+ if (!req)
+ goto out_free_ahash;
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_SLEEP, NULL, NULL);
@@ -433,7 +440,10 @@ make_checksum_v2(struct krb5_ctx *kctx, char *header, int hdrlen,
}
out:
ahash_request_free(req);
+out_free_ahash:
crypto_free_ahash(tfm);
+out_free_cksum:
+ kfree(checksumdata);
return err ? GSS_S_FAILURE : 0;
}
@@ -666,14 +676,17 @@ gss_krb5_cts_crypt(struct crypto_skcipher *cipher, struct xdr_buf *buf,
u32 ret;
struct scatterlist sg[1];
SKCIPHER_REQUEST_ON_STACK(req, cipher);
- u8 data[GSS_KRB5_MAX_BLOCKSIZE * 2];
+ u8 *data;
struct page **save_pages;
u32 len = buf->len - offset;
- if (len > ARRAY_SIZE(data)) {
+ if (len > GSS_KRB5_MAX_BLOCKSIZE * 2) {
WARN_ON(0);
return -ENOMEM;
}
+ data = kmalloc(GSS_KRB5_MAX_BLOCKSIZE * 2, GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
/*
* For encryption, we want to read from the cleartext
@@ -708,6 +721,7 @@ gss_krb5_cts_crypt(struct crypto_skcipher *cipher, struct xdr_buf *buf,
ret = write_bytes_to_xdr_buf(buf, offset, data, len);
out:
+ kfree(data);
return ret;
}
diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
index d67f7e1bc82d..45662d7f0943 100644
--- a/net/sunrpc/auth_gss/svcauth_gss.c
+++ b/net/sunrpc/auth_gss/svcauth_gss.c
@@ -718,30 +718,37 @@ gss_write_null_verf(struct svc_rqst *rqstp)
static int
gss_write_verf(struct svc_rqst *rqstp, struct gss_ctx *ctx_id, u32 seq)
{
- __be32 xdr_seq;
+ __be32 *xdr_seq;
u32 maj_stat;
struct xdr_buf verf_data;
struct xdr_netobj mic;
__be32 *p;
struct kvec iov;
+ int err = -1;
svc_putnl(rqstp->rq_res.head, RPC_AUTH_GSS);
- xdr_seq = htonl(seq);
+ xdr_seq = kmalloc(4, GFP_KERNEL);
+ if (!xdr_seq)
+ return -1;
+ *xdr_seq = htonl(seq);
- iov.iov_base = &xdr_seq;
- iov.iov_len = sizeof(xdr_seq);
+ iov.iov_base = xdr_seq;
+ iov.iov_len = 4;
xdr_buf_from_iov(&iov, &verf_data);
p = rqstp->rq_res.head->iov_base + rqstp->rq_res.head->iov_len;
mic.data = (u8 *)(p + 1);
maj_stat = gss_get_mic(ctx_id, &verf_data, &mic);
if (maj_stat != GSS_S_COMPLETE)
- return -1;
+ goto out;
*p++ = htonl(mic.len);
memset((u8 *)p + mic.len, 0, round_up_to_quad(mic.len) - mic.len);
p += XDR_QUADLEN(mic.len);
if (!xdr_ressize_check(rqstp, p))
- return -1;
- return 0;
+ goto out;
+ err = 0;
+out:
+ kfree(xdr_seq);
+ return err;
}
struct gss_domain {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Maxime Ripard @ 2016-10-25 13:26 UTC (permalink / raw)
To: LABBE Corentin
Cc: wens, srinivas.kandagatla, linux-kernel, linux-arm-kernel,
linux-crypto
In-Reply-To: <20161025053855.GA901@Red>
[-- Attachment #1.1: Type: text/plain, Size: 1646 bytes --]
On Tue, Oct 25, 2016 at 07:38:55AM +0200, LABBE Corentin wrote:
> On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> >
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> >
>
> On my cubieboard2 (A20)
> hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
>
> So clearly for me its constant.
It's constant across reboots, but not across devices. Each device have
a different SID content, therefore it's a relevant source of entropy
in the system.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] crypto: sahara: fix typo "Decidated" -> "Dedicated"
From: Colin King @ 2016-10-25 11:07 UTC (permalink / raw)
To: Herbert Xu, linux-crypto; +Cc: David S . Miller, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to typo in dev_dbg message
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/crypto/sahara.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 0c49956..7ba0eae 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -390,7 +390,7 @@ static void sahara_decode_status(struct sahara_dev *dev, unsigned int status)
if (status & SAHARA_STATUS_MODE_BATCH)
dev_dbg(dev->device, " - Batch Mode.\n");
else if (status & SAHARA_STATUS_MODE_DEDICATED)
- dev_dbg(dev->device, " - Decidated Mode.\n");
+ dev_dbg(dev->device, " - Dedicated Mode.\n");
else if (status & SAHARA_STATUS_MODE_DEBUG)
dev_dbg(dev->device, " - Debug Mode.\n");
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v2] char: hw_random: atmel-rng: disable TRNG during suspend
From: Nicolas Ferre @ 2016-10-25 8:49 UTC (permalink / raw)
To: Wenyou Yang, Herbert Xu, Matt Mackall
Cc: linux-crypto, Wenyou Yang, linux-arm-kernel
In-Reply-To: <1477356993-27778-1-git-send-email-wenyou.yang@atmel.com>
Le 25/10/2016 à 02:56, Wenyou Yang a écrit :
> To fix the over consumption on the VDDCore due to the TRNG enabled,
> disable the TRNG during suspend, not only disable the user interface
> clock (which is controlled by PMC). Because the user interface clock
> is independent from any clock that may be used in the entropy source
> logic circuitry.
>
> Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Thanks
> ---
>
> Changes in v2:
> - Enable the user interface first, then enable the internal clock
> when resume.
>
> drivers/char/hw_random/atmel-rng.c | 24 +++++++++++++++++++++---
> 1 file changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/hw_random/atmel-rng.c b/drivers/char/hw_random/atmel-rng.c
> index 0fcc9e6..ae7cae5 100644
> --- a/drivers/char/hw_random/atmel-rng.c
> +++ b/drivers/char/hw_random/atmel-rng.c
> @@ -48,6 +48,16 @@ static int atmel_trng_read(struct hwrng *rng, void *buf, size_t max,
> return 0;
> }
>
> +static void atmel_trng_enable(struct atmel_trng *trng)
> +{
> + writel(TRNG_KEY | 1, trng->base + TRNG_CR);
> +}
> +
> +static void atmel_trng_disable(struct atmel_trng *trng)
> +{
> + writel(TRNG_KEY, trng->base + TRNG_CR);
> +}
> +
> static int atmel_trng_probe(struct platform_device *pdev)
> {
> struct atmel_trng *trng;
> @@ -71,7 +81,7 @@ static int atmel_trng_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - writel(TRNG_KEY | 1, trng->base + TRNG_CR);
> + atmel_trng_enable(trng);
> trng->rng.name = pdev->name;
> trng->rng.read = atmel_trng_read;
>
> @@ -94,7 +104,7 @@ static int atmel_trng_remove(struct platform_device *pdev)
>
> hwrng_unregister(&trng->rng);
>
> - writel(TRNG_KEY, trng->base + TRNG_CR);
> + atmel_trng_disable(trng);
> clk_disable_unprepare(trng->clk);
>
> return 0;
> @@ -105,6 +115,7 @@ static int atmel_trng_suspend(struct device *dev)
> {
> struct atmel_trng *trng = dev_get_drvdata(dev);
>
> + atmel_trng_disable(trng);
> clk_disable_unprepare(trng->clk);
>
> return 0;
> @@ -113,8 +124,15 @@ static int atmel_trng_suspend(struct device *dev)
> static int atmel_trng_resume(struct device *dev)
> {
> struct atmel_trng *trng = dev_get_drvdata(dev);
> + int ret;
> +
> + ret = clk_prepare_enable(trng->clk);
> + if (ret)
> + return ret;
>
> - return clk_prepare_enable(trng->clk);
> + atmel_trng_enable(trng);
> +
> + return 0;
> }
>
> static const struct dev_pm_ops atmel_trng_pm_ops = {
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: Jean-Francois Moine @ 2016-10-25 7:06 UTC (permalink / raw)
To: LABBE Corentin
Cc: Maxime Ripard, wens, srinivas.kandagatla, linux-kernel,
linux-arm-kernel, linux-crypto
In-Reply-To: <20161025053855.GA901@Red>
On Tue, 25 Oct 2016 07:38:55 +0200
LABBE Corentin <clabbe.montjoie@gmail.com> wrote:
> > On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > > Since SID's content is constant over reboot,
> >
> > That's not true, at least not across all the Allwinner SoCs, and
> > especially not on the A10 and A20 that this driver supports.
> >
>
> On my cubieboard2 (A20)
> hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
> cubiedev ~ # reboot
> cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
> 00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
> 00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> *
> 00000200
>
> So clearly for me its constant.
Even after power off/power on?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* Re: [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: LABBE Corentin @ 2016-10-25 5:38 UTC (permalink / raw)
To: Maxime Ripard
Cc: srinivas.kandagatla, wens, linux-kernel, linux-arm-kernel,
linux-crypto
In-Reply-To: <20161024201020.h6akyqad2o42xkhq@lukather>
On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > Since SID's content is constant over reboot,
>
> That's not true, at least not across all the Allwinner SoCs, and
> especially not on the A10 and A20 that this driver supports.
>
On my cubieboard2 (A20)
hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
cubiedev ~ # reboot
cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
So clearly for me its constant.
> > it must not be used as source of randomness.
>
> And I don't think that's true either. A constant entropy provider will
> not add any entropy, but will not remove any, would it?
I cced linux-crypto at the begining for confirmation on that.
But the problem is increased as a part of the content is predicatable over same type of device (at least the thirst bytes and all the zeros).
^ permalink raw reply
* Re: [PATCH v10 0/8] crypto: asynchronous compression api
From: Herbert Xu @ 2016-10-25 3:47 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto
In-Reply-To: <1477052394-19826-1-git-send-email-giovanni.cabiddu@intel.com>
On Fri, Oct 21, 2016 at 01:19:46PM +0100, Giovanni Cabiddu wrote:
> The following patch set introduces acomp, a generic asynchronous
> (de)compression api with support for SG lists.
> We propose a new crypto type called crypto_acomp_type, a new struct acomp_alg
> and struct crypto_acomp, together with number of helper functions to register
> acomp type algorithms and allocate tfm instances.
> This interface will allow the following operations:
>
> int (*compress)(struct acomp_req *req);
> int (*decompress)(struct acomp_req *req);
>
> Together with acomp we propose a new driver-side interface, scomp, which
> handles compression implementations which use linear buffers. We converted all
> compression algorithms available in LKCF to use this interface so that those
> algorithms will be accessible through the acomp api.
>
> Changes in v10:
> - fixed build issues for configurations where CONFIG_CRYPTO_USER is defined
All applied. Thanks a lot Giovanni!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH][TRIVIAL] crypto: ccp - fix typo "CPP"
From: Herbert Xu @ 2016-10-25 3:46 UTC (permalink / raw)
To: Paul Bolle
Cc: trivial, thomas.lendacky, gary.hook, linux-crypto, linux-kernel
In-Reply-To: <1476991259-4061-1-git-send-email-pebolle@tiscali.nl>
Paul Bolle <pebolle@tiscali.nl> wrote:
> The abbreviation for Cryptographic Coprocessor is "CCP".
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS
From: Herbert Xu @ 2016-10-25 3:43 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Kevin Hilman, Neil Armstrong,
PrasannaKumar Muralidharan, Carlo Caione, linux-amlogic,
Matt Mackall, linux-arm-kernel, linux-crypto
In-Reply-To: <1476906618-14455-1-git-send-email-javier@osg.samsung.com>
On Wed, Oct 19, 2016 at 04:50:18PM -0300, Javier Martinez Canillas wrote:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
>
> So there's no need to have a MODULE_ALIAS("platform:meson-rng") since
> the reported uevent MODALIAS to user-space will always be the OF one.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: engine - Handle the kthread worker using the new API
From: Herbert Xu @ 2016-10-25 3:43 UTC (permalink / raw)
To: Petr Mladek; +Cc: David S. Miller, linux-crypto, Tejun Heo, linux-kernel
In-Reply-To: <1476878070-12024-1-git-send-email-pmladek@suse.com>
On Wed, Oct 19, 2016 at 01:54:30PM +0200, Petr Mladek wrote:
> Use the new API to create and destroy the crypto engine kthread
> worker. The API hides some implementation details.
>
> In particular, kthread_create_worker() allocates and initializes
> struct kthread_worker. It runs the kthread the right way
> and stores task_struct into the worker structure.
>
> kthread_destroy_worker() flushes all pending works, stops
> the kthread and frees the structure.
>
> This patch does not change the existing behavior except for
> dynamically allocating struct kthread_worker and storing
> only the pointer of this structure.
>
> It is compile tested only because I did not find an easy
> way how to run the code. Well, it should be pretty safe
> given the nature of the change.
>
> Signed-off-by: Petr Mladek <pmladek@suse.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ccp - Clean up the LSB slot allocation code
From: Herbert Xu @ 2016-10-25 3:43 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147683001790.8273.9550490485955104780.stgit@taos.amd.com>
On Tue, Oct 18, 2016 at 05:33:37PM -0500, Gary R Hook wrote:
> Fix a few problems revealed by testing: verify consistent
> units, especially in public slot allocation. Percolate
> some common initialization code up to a common routine.
> Add some comments.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ccp - remove unneeded code
From: Herbert Xu @ 2016-10-25 3:42 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147682972966.8169.12625496646634682202.stgit@taos.amd.com>
On Tue, Oct 18, 2016 at 05:28:49PM -0500, Gary R Hook wrote:
> Clean up patch for an unneeded structure member.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] hwrng: meson: Fix module autoload for OF registration
From: Herbert Xu @ 2016-10-25 3:40 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-kernel, Jason Gunthorpe, Kevin Hilman, Neil Armstrong,
PrasannaKumar Muralidharan, Carlo Caione, linux-amlogic,
Matt Mackall, linux-arm-kernel, linux-crypto
In-Reply-To: <1476733877-20275-1-git-send-email-javier@osg.samsung.com>
On Mon, Oct 17, 2016 at 04:51:17PM -0300, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
>
> After this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
> alias: of:N*T*Camlogic,meson-rngC*
> alias: of:N*T*Camlogic,meson-rng
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: ccp - change bitfield type to unsigned ints
From: Herbert Xu @ 2016-10-25 3:40 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <147682971521.8147.5364792807816963275.stgit@taos.amd.com>
On Tue, Oct 18, 2016 at 05:28:35PM -0500, Gary R Hook wrote:
> Bit fields are not sensitive to endianness, so use
> a transparent standard data type
>
> Signed-off-by: Gary R Hook <gary.hook@amd.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH -next] crypto: gcm - Fix error return code in crypto_gcm_create_common()
From: Herbert Xu @ 2016-10-25 3:39 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Wei Yongjun, linux-crypto
In-Reply-To: <1476717006-10086-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 17, 2016 at 03:10:06PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return error code -EINVAL from the invalid alg ivsize error
> handling case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH -next] crypto: ccp - Fix non static symbol warning
From: Herbert Xu @ 2016-10-25 3:39 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Tom Lendacky, Gary Hook, Wei Yongjun, linux-crypto
In-Reply-To: <1476716930-9831-1-git-send-email-weiyj.lk@gmail.com>
On Mon, Oct 17, 2016 at 03:08:50PM +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/crypto/ccp/ccp-dev.c:44:6: warning:
> symbol 'ccp_error_codes' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RESEND][PATCH] crypto: caam: add support for iMX6UL
From: Herbert Xu @ 2016-10-25 3:39 UTC (permalink / raw)
To: Marcus Folkesson
Cc: David S . Miller, Rob Herring, Mark Rutland, Horia Geanta,
Arnd Bergmann, Alex Porosanu, Srinivas Kandagatla, Baoyou Xie,
Russell King, linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1476703680-22676-1-git-send-email-marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Oct 17, 2016 at 01:28:00PM +0200, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
>
> Signed-off-by: Marcus Folkesson <marcus.folkesson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Reviewed-by: Horia Geantă <horia.geanta-3arQi8VN3Tc@public.gmane.org>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] padata: Remove unused but set variables
From: Herbert Xu @ 2016-10-25 3:38 UTC (permalink / raw)
To: Steffen Klassert; +Cc: tklauser, linux-crypto, linux-kernel
In-Reply-To: <20161021090047.GO19080@gauss.secunet.com>
Steffen Klassert <steffen.klassert@secunet.com> wrote:
> On Mon, Oct 17, 2016 at 12:16:08PM +0200, Tobias Klauser wrote:
>> Remove the unused but set variable pinst in padata_parallel_worker to
>> fix the following warning when building with 'W=1':
>>
>> kernel/padata.c: In function ‘padata_parallel_worker’:
>> kernel/padata.c:68:26: warning: variable ‘pinst’ set but not used [-Wunused-but-set-variable]
>>
>> Also remove the now unused variable pd which is only used to set pinst.
>>
>> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>
> Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: Move RSA+MPI constructs into an #include file
From: Herbert Xu @ 2016-10-25 2:48 UTC (permalink / raw)
To: Gary R Hook; +Cc: linux-crypto, thomas.lendacky, davem
In-Reply-To: <20161014193559.4342.74036.stgit@taos>
On Fri, Oct 14, 2016 at 02:36:00PM -0500, Gary R Hook wrote:
> Move RSA support of general use into internal/rsa.h.
> This allows reuse of, e.g. RSA MPI keys and support
> functions.
>
> Signed-off-by: Gary R Hook <gary.hook@amd.com>
Please fold this patch into the series that makes use of it.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 0/8] Conversion crypto API documentation to Sphinx
From: Herbert Xu @ 2016-10-25 2:35 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Jonathan Corbet, linux-crypto, linux-doc
In-Reply-To: <1645861.DSRXbPG5tl@positron.chronox.de>
On Sun, Oct 23, 2016 at 06:46:12PM +0200, Stephan Mueller wrote:
> Am Sonntag, 23. Oktober 2016, 10:32:38 CEST schrieb Jonathan Corbet:
>
> Hi Jonathan,
>
> > On Fri, 21 Oct 2016 04:53:45 +0200
> >
> > Stephan Mueller <smueller@chronox.de> wrote:
> > > the attached patch set converts the existing crypto API documentation
> > > from DocBook to Sphinx.
> >
> > This looks generally good to me - thanks for doing it!
> >
> > Is there any chance of running the Documentation/ parts through the docs
> > tree? Documentation/index.rst has become a bit of a conflict point
> > otherwise...
>
> Unless Herbert objects, I would not see any reason why we should not push it
> through the docs tree.
No objections from me.
> Yet we should wait for Herbert's ack as I have added also new information in
> the patch set (the KPP API documentation and the change in the AEAD
> documentation).
Looks good to me.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox