crypto: inside-secure - remove unused struct entry
diff mbox series

Message ID 1562314645-22949-1-git-send-email-pvanleeuwen@verimatrix.com
State Not Applicable
Delegated to: Herbert Xu
Headers show
Series
  • crypto: inside-secure - remove unused struct entry
Related show

Commit Message

Pascal van Leeuwen July 5, 2019, 8:17 a.m. UTC
This patch removes 'engines' from struct safexcel_alg_template, as it is
no longer used.

Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
---
 drivers/crypto/inside-secure/safexcel.h | 1 -
 1 file changed, 1 deletion(-)

Comments

Antoine Tenart July 5, 2019, 2:18 p.m. UTC | #1
Hello Pascal,

On Fri, Jul 05, 2019 at 10:17:25AM +0200, Pascal van Leeuwen wrote:
> This patch removes 'engines' from struct safexcel_alg_template, as it is
> no longer used.
> 
> Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
> ---
>  drivers/crypto/inside-secure/safexcel.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/crypto/inside-secure/safexcel.h b/drivers/crypto/inside-secure/safexcel.h
> index 379d0b0..30a222e 100644
> --- a/drivers/crypto/inside-secure/safexcel.h
> +++ b/drivers/crypto/inside-secure/safexcel.h
> @@ -660,7 +660,6 @@ struct safexcel_ahash_export_state {
>  struct safexcel_alg_template {
>  	struct safexcel_crypto_priv *priv;
>  	enum safexcel_alg_type type;
> -	u32 engines;

This patch can't be applied to the cryptodev branch, as 'engines' is
still used. I guess this is done as other (non-applied) patches are
removing the use of this member.

You should wait for either those patches to be merged (or directly
integrate this change in a newer version of those patches), or send this
patch in the same series. Otherwise it's problematic as you do not know
which patches will be applied first.

Thanks,
Antoine
Pascal Van Leeuwen July 5, 2019, 2:32 p.m. UTC | #2
> -----Original Message-----
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Sent: Friday, July 5, 2019 4:18 PM
> To: Pascal van Leeuwen <pascalvanl@gmail.com>
> Cc: linux-crypto@vger.kernel.org; antoine.tenart@bootlin.com; herbert@gondor.apana.org.au; davem@davemloft.net; Pascal Van
> Leeuwen <pvanleeuwen@verimatrix.com>
> Subject: Re: [PATCH] crypto: inside-secure - remove unused struct entry
> 
> Hello Pascal,
> 
> On Fri, Jul 05, 2019 at 10:17:25AM +0200, Pascal van Leeuwen wrote:
> > This patch removes 'engines' from struct safexcel_alg_template, as it is
> > no longer used.
> >
> > Signed-off-by: Pascal van Leeuwen <pvanleeuwen@verimatrix.com>
> > ---
> >  drivers/crypto/inside-secure/safexcel.h | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/crypto/inside-secure/safexcel.h b/drivers/crypto/inside-secure/safexcel.h
> > index 379d0b0..30a222e 100644
> > --- a/drivers/crypto/inside-secure/safexcel.h
> > +++ b/drivers/crypto/inside-secure/safexcel.h
> > @@ -660,7 +660,6 @@ struct safexcel_ahash_export_state {
> >  struct safexcel_alg_template {
> >  	struct safexcel_crypto_priv *priv;
> >  	enum safexcel_alg_type type;
> > -	u32 engines;
> 
> This patch can't be applied to the cryptodev branch, as 'engines' is
> still used. I guess this is done as other (non-applied) patches are
> removing the use of this member.
> 
> You should wait for either those patches to be merged (or directly
> integrate this change in a newer version of those patches), or send this
> patch in the same series. Otherwise it's problematic as you do not know
> which patches will be applied first.
> 
> Thanks,
> Antoine
> 
> --
> Antoine Ténart, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com

This patch indeed depends on earlier patches. I was just assuming 
people to be smart enough to apply the patches in the correct order :-)

So please ignore, I'll either resend or incorporate it in an update of the 
earlier series later. It's nothing important (i.e. functional) anyway.

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
Antoine Tenart July 5, 2019, 2:39 p.m. UTC | #3
On Fri, Jul 05, 2019 at 02:32:46PM +0000, Pascal Van Leeuwen wrote:
> > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > 
> > You should wait for either those patches to be merged (or directly
> > integrate this change in a newer version of those patches), or send this
> > patch in the same series. Otherwise it's problematic as you do not know
> > which patches will be applied first.
> 
> This patch indeed depends on earlier patches. I was just assuming 
> people to be smart enough to apply the patches in the correct order :-)

It's actually very difficult for a maintainer to remember this,
especially when he has to deal with plenty of patches from many
contributors. And some series can take time to be merged while others
can be accepted easily, so it's hard to keep track of dependencies :)

> So please ignore, I'll either resend or incorporate it in an update of the 
> earlier series later. It's nothing important (i.e. functional) anyway.

Thank you!

Antoine
Pascal Van Leeuwen July 5, 2019, 2:54 p.m. UTC | #4
> -----Original Message-----
> From: Antoine Tenart <antoine.tenart@bootlin.com>
> Sent: Friday, July 5, 2019 4:40 PM
> To: Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
> Cc: Antoine Tenart <antoine.tenart@bootlin.com>; Pascal van Leeuwen <pascalvanl@gmail.com>; linux-crypto@vger.kernel.org;
> herbert@gondor.apana.org.au; davem@davemloft.net
> Subject: Re: [PATCH] crypto: inside-secure - remove unused struct entry
> 
> On Fri, Jul 05, 2019 at 02:32:46PM +0000, Pascal Van Leeuwen wrote:
> > > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > >
> > > You should wait for either those patches to be merged (or directly
> > > integrate this change in a newer version of those patches), or send this
> > > patch in the same series. Otherwise it's problematic as you do not know
> > > which patches will be applied first.
> >
> > This patch indeed depends on earlier patches. I was just assuming
> > people to be smart enough to apply the patches in the correct order :-)
> 
> It's actually very difficult for a maintainer to remember this,
> especially when he has to deal with plenty of patches from many
> contributors. And some series can take time to be merged while others
> can be accepted easily, so it's hard to keep track of dependencies :)
> 
That's an interesting point though, as dependencies between more 
complex/larger patches are rather unavoidable ...

So how should you handle that? Do you need to wait for the previous
patches to be accepted before submitting the next ones? Thats seems
rather inefficient as I could already be getting some (low-hanging fruit)
feedback on the next patchset that I can already work on while waiting 
for the previous patchset(s) to go through the process.

I'm a hardware guy. We pipeline stuff by default :-)

Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
Antoine Tenart July 5, 2019, 3:57 p.m. UTC | #5
Hi Pascal,

On Fri, Jul 05, 2019 at 02:54:25PM +0000, Pascal Van Leeuwen wrote:
> > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > On Fri, Jul 05, 2019 at 02:32:46PM +0000, Pascal Van Leeuwen wrote:
> > > > From: Antoine Tenart <antoine.tenart@bootlin.com>
> > > >
> > > > You should wait for either those patches to be merged (or directly
> > > > integrate this change in a newer version of those patches), or send this
> > > > patch in the same series. Otherwise it's problematic as you do not know
> > > > which patches will be applied first.
> > >
> > > This patch indeed depends on earlier patches. I was just assuming
> > > people to be smart enough to apply the patches in the correct order :-)
> > 
> > It's actually very difficult for a maintainer to remember this,
> > especially when he has to deal with plenty of patches from many
> > contributors. And some series can take time to be merged while others
> > can be accepted easily, so it's hard to keep track of dependencies :)
> > 
> That's an interesting point though, as dependencies between more 
> complex/larger patches are rather unavoidable ...
> 
> So how should you handle that? Do you need to wait for the previous
> patches to be accepted before submitting the next ones? Thats seems
> rather inefficient as I could already be getting some (low-hanging fruit)
> feedback on the next patchset that I can already work on while waiting 
> for the previous patchset(s) to go through the process.
> 
> I'm a hardware guy. We pipeline stuff by default :-)

Hehe :)

I'd say you usually try not to send too many patches / series in
parallel. If that is not possible, or if you have series with
dependencies you can explain the dependency in the cover letter (just
try not to have 10's of series with dependencies in parallel).

Also if you have series not aimed to be merged right now but you want
comments, you can use [RFC] instead of [PATCH] in the object of the
mail.

This is usually working quite OK :)

Antoine

Patch
diff mbox series

diff --git a/drivers/crypto/inside-secure/safexcel.h b/drivers/crypto/inside-secure/safexcel.h
index 379d0b0..30a222e 100644
--- a/drivers/crypto/inside-secure/safexcel.h
+++ b/drivers/crypto/inside-secure/safexcel.h
@@ -660,7 +660,6 @@  struct safexcel_ahash_export_state {
 struct safexcel_alg_template {
 	struct safexcel_crypto_priv *priv;
 	enum safexcel_alg_type type;
-	u32 engines;
 	union {
 		struct skcipher_alg skcipher;
 		struct aead_alg aead;