linux-next: manual merge of the staging tree with the crypto tree

linux-next: manual merge of the staging tree with the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/skein/skein_generic.c

between commit:

  e50944e219f9 ("crypto: shash - remove useless setting of type flags")

from the crypto tree and commit:

  ee55fe552fcd ("staging/skein: Remove Skein and Threefish code")

from the staging tree.

I fixed it up (I removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

Hi all,

On Mon, 9 Jul 2018 14:15:10 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/skein/skein_generic.c
> 
> between commit:
> 
>   e50944e219f9 ("crypto: shash - remove useless setting of type flags")
> 
> from the crypto tree and commit:
> 
>   ee55fe552fcd ("staging/skein: Remove Skein and Threefish code")
> 
> from the staging tree.
> 
> I fixed it up (I removed the file) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

This is now a conflict between Linus' tree and the staging tree.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the crypto tree

[Greg KH]

On Fri, Sep 18, 2020 at 05:50:36PM +1000, Herbert Xu wrote:
> On Fri, Sep 18, 2020 at 09:49:11AM +0200, Greg KH wrote:
> >
> > Ok, I'll go revert these.
> 
> Thanks!
> 
> > > As the driver has been converted over to the lib arc4 API, it
> > > does not need to select CRYPTO at all.
> > 
> > Is it converted in your tree?  If so, have a branch/tag I can pull in to
> > prevent merge issues in the future?
> 
> It's in the cryptodev tree, but unfortunately it's not in a
> topic branch so you'd be pulling all other crypto changes along
> with it.

Sorry for the delay, this is now fixed up in my tree.

greg k-h

Re: linux-next: manual merge of the staging tree with the crypto tree

[Greg KH]

On Fri, Sep 18, 2020 at 05:50:36PM +1000, Herbert Xu wrote:
> On Fri, Sep 18, 2020 at 09:49:11AM +0200, Greg KH wrote:
> >
> > Ok, I'll go revert these.
> 
> Thanks!
> 
> > > As the driver has been converted over to the lib arc4 API, it
> > > does not need to select CRYPTO at all.
> > 
> > Is it converted in your tree?  If so, have a branch/tag I can pull in to
> > prevent merge issues in the future?
> 
> It's in the cryptodev tree, but unfortunately it's not in a
> topic branch so you'd be pulling all other crypto changes along
> with it.

Ok, no worries, I'll just revert the above commits and all should be
good.

thanks,

greg k-h

Re: linux-next: manual merge of the staging tree with the crypto tree

[Herbert Xu]

On Fri, Sep 18, 2020 at 09:49:11AM +0200, Greg KH wrote:
>
> Ok, I'll go revert these.

Thanks!

> > As the driver has been converted over to the lib arc4 API, it
> > does not need to select CRYPTO at all.
> 
> Is it converted in your tree?  If so, have a branch/tag I can pull in to
> prevent merge issues in the future?

It's in the cryptodev tree, but unfortunately it's not in a
topic branch so you'd be pulling all other crypto changes along
with it.

Cheers,
-- 
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

Re: linux-next: manual merge of the staging tree with the crypto tree

[Greg KH]

On Fri, Sep 18, 2020 at 03:41:34PM +1000, Herbert Xu wrote:
> On Fri, Sep 18, 2020 at 03:21:27PM +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the staging tree got a conflict in:
> > 
> >   drivers/staging/rtl8192e/Kconfig
> > 
> > between commit:
> > 
> >   054694a46d64 ("staging/rtl8192e: switch to RC4 library interface")
> > 
> > from the crypto tree and commits:
> > 
> >   243d040a6e4a ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_TKIP")
> >   02c4260713d6 ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_WEP")
> > 
> > from the staging tree.
> 
> Those two commits should just be dropped.

Ok, I'll go revert these.

>  
> > diff --cc drivers/staging/rtl8192e/Kconfig
> > index 4c440bdaaf6e,31e076cc6f16..000000000000
> > --- a/drivers/staging/rtl8192e/Kconfig
> > +++ b/drivers/staging/rtl8192e/Kconfig
> > @@@ -25,7 -26,8 +26,8 @@@ config RTLLIB_CRYPTO_CCM
> >   config RTLLIB_CRYPTO_TKIP
> >   	tristate "Support for rtllib TKIP crypto"
> >   	depends on RTLLIB
> > + 	select CRYPTO
> >  -	select CRYPTO_ARC4
> >  +	select CRYPTO_LIB_ARC4
> 
> As the driver has been converted over to the lib arc4 API, it
> does not need to select CRYPTO at all.

Is it converted in your tree?  If so, have a branch/tag I can pull in to
prevent merge issues in the future?

thanks,

greg k-h

Re: linux-next: manual merge of the staging tree with the crypto tree

[Herbert Xu]

On Fri, Sep 18, 2020 at 03:21:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/rtl8192e/Kconfig
> 
> between commit:
> 
>   054694a46d64 ("staging/rtl8192e: switch to RC4 library interface")
> 
> from the crypto tree and commits:
> 
>   243d040a6e4a ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_TKIP")
>   02c4260713d6 ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_WEP")
> 
> from the staging tree.

Those two commits should just be dropped.
 
> diff --cc drivers/staging/rtl8192e/Kconfig
> index 4c440bdaaf6e,31e076cc6f16..000000000000
> --- a/drivers/staging/rtl8192e/Kconfig
> +++ b/drivers/staging/rtl8192e/Kconfig
> @@@ -25,7 -26,8 +26,8 @@@ config RTLLIB_CRYPTO_CCM
>   config RTLLIB_CRYPTO_TKIP
>   	tristate "Support for rtllib TKIP crypto"
>   	depends on RTLLIB
> + 	select CRYPTO
>  -	select CRYPTO_ARC4
>  +	select CRYPTO_LIB_ARC4

As the driver has been converted over to the lib arc4 API, it
does not need to select CRYPTO at all.

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

linux-next: manual merge of the staging tree with the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]

Hi all,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/rtl8192e/Kconfig

between commit:

  054694a46d64 ("staging/rtl8192e: switch to RC4 library interface")

from the crypto tree and commits:

  243d040a6e4a ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_TKIP")
  02c4260713d6 ("staging: rtl8192e: fix kconfig dependency warning for RTLLIB_CRYPTO_WEP")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/rtl8192e/Kconfig
index 4c440bdaaf6e,31e076cc6f16..000000000000
--- a/drivers/staging/rtl8192e/Kconfig
+++ b/drivers/staging/rtl8192e/Kconfig
@@@ -25,7 -26,8 +26,8 @@@ config RTLLIB_CRYPTO_CCM
  config RTLLIB_CRYPTO_TKIP
  	tristate "Support for rtllib TKIP crypto"
  	depends on RTLLIB
+ 	select CRYPTO
 -	select CRYPTO_ARC4
 +	select CRYPTO_LIB_ARC4
  	select CRYPTO_MICHAEL_MIC
  	default y
  	help
@@@ -35,7 -37,8 +37,8 @@@
  
  config RTLLIB_CRYPTO_WEP
  	tristate "Support for rtllib WEP crypto"
+ 	select CRYPTO
 -	select CRYPTO_ARC4
 +	select CRYPTO_LIB_ARC4
  	depends on RTLLIB
  	default y
  	help

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the crypto tree

[Greg KH]

On Thu, Mar 15, 2018 at 05:58:41PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got conflicts in:
> 
>   drivers/staging/ccree/Kconfig
>   drivers/staging/ccree/Makefile
> 
> between commit:
> 
>   e294ca1cca3a ("staging: ccree: rename staging ver and mark as broken")
> 
> from the crypto tree and commit:
> 
>   8b0217965418 ("staging: ccree: remove ccree staging driver copy")
> 
> from the staging tree.
> 
> I fixed it up (I just removed the files) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging.  You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.

Thanks for this, we knew it was going to happen, sorry :(

You did the correct merge.

greg k-h

linux-next: manual merge of the staging tree with the crypto tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

Hi Greg,

Today's linux-next merge of the staging tree got conflicts in:

  drivers/staging/ccree/Kconfig
  drivers/staging/ccree/Makefile

between commit:

  e294ca1cca3a ("staging: ccree: rename staging ver and mark as broken")

from the crypto tree and commit:

  8b0217965418 ("staging: ccree: remove ccree staging driver copy")

from the staging tree.

I fixed it up (I just removed the files) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the staging tree with the crypto tree

[Greg KH]

On Mon, Feb 22, 2016 at 02:55:25PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/lustre/lustre/libcfs/linux/linux-crypto.c
> 
> between commit:
> 
>   6dae10001e84 ("staging: lustre: Use ahash")
> 
> from the crypto tree and commit:
> 
>   15d9f5201fc3 ("staging/lustre/libcfs: Adjust NULL comparison codestyle")
>   3e1f3db1b29b ("staging/lustre: Remove space after cast in cfs_crypto_hash_final()")
> 
> from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good, thanks.

greg k-h

linux-next: manual merge of the staging tree with the crypto tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in:

  drivers/staging/lustre/lustre/libcfs/linux/linux-crypto.c

between commit:

  6dae10001e84 ("staging: lustre: Use ahash")

from the crypto tree and commit:

  15d9f5201fc3 ("staging/lustre/libcfs: Adjust NULL comparison codestyle")
  3e1f3db1b29b ("staging/lustre: Remove space after cast in cfs_crypto_hash_final()")

from the staging tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/lustre/lustre/libcfs/linux/linux-crypto.c
index 94c01aad844b,ec758019bad6..000000000000
--- a/drivers/staging/lustre/lustre/libcfs/linux/linux-crypto.c
+++ b/drivers/staging/lustre/lustre/libcfs/linux/linux-crypto.c
@@@ -76,10 -69,10 +76,10 @@@ static int cfs_crypto_hash_alloc(unsign
  	 * Skip this function for digest, because we use shash logic at
  	 * cfs_crypto_hash_alloc.
  	 */
- 	if (key != NULL)
+ 	if (key)
 -		err = crypto_hash_setkey(desc->tfm, key, key_len);
 +		err = crypto_ahash_setkey(tfm, key, key_len);
  	else if ((*type)->cht_key != 0)
 -		err = crypto_hash_setkey(desc->tfm,
 +		err = crypto_ahash_setkey(tfm,
  					 (unsigned char *)&((*type)->cht_key),
  					 (*type)->cht_size);
  
@@@ -110,17 -99,16 +110,17 @@@ int cfs_crypto_hash_digest(unsigned cha
  	int			err;
  	const struct cfs_crypto_hash_type	*type;
  
- 	if (buf == NULL || buf_len == 0 || hash_len == NULL)
+ 	if (!buf || buf_len == 0 || !hash_len)
  		return -EINVAL;
  
 -	err = cfs_crypto_hash_alloc(alg_id, &type, &hdesc, key, key_len);
 +	err = cfs_crypto_hash_alloc(alg_id, &type, &req, key, key_len);
  	if (err != 0)
  		return err;
  
- 	if (hash == NULL || *hash_len < type->cht_size) {
+ 	if (!hash || *hash_len < type->cht_size) {
  		*hash_len = type->cht_size;
 -		crypto_free_hash(hdesc.tfm);
 +		crypto_free_ahash(crypto_ahash_reqtfm(req));
 +		ahash_request_free(req);
  		return -ENOSPC;
  	}
  	sg_init_one(&sl, buf, buf_len);
@@@ -183,15 -172,14 +183,15 @@@ int cfs_crypto_hash_final(struct cfs_cr
  			  unsigned char *hash, unsigned int *hash_len)
  {
  	int     err;
 -	int     size = crypto_hash_digestsize(((struct hash_desc *)hdesc)->tfm);
 +	struct ahash_request *req = (void *)hdesc;
 +	int size = crypto_ahash_digestsize(crypto_ahash_reqtfm(req));
  
- 	if (hash_len == NULL) {
+ 	if (!hash_len) {
 -		crypto_free_hash(((struct hash_desc *)hdesc)->tfm);
 -		kfree(hdesc);
 +		crypto_free_ahash(crypto_ahash_reqtfm(req));
 +		ahash_request_free(req);
  		return 0;
  	}
- 	if (hash == NULL || *hash_len < size) {
+ 	if (!hash || *hash_len < size) {
  		*hash_len = size;
  		return -ENOSPC;
  	}