| Message ID | 1562314645-22949-1-git-send-email-pvanleeuwen@verimatrix.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | crypto: inside-secure - remove unused struct entry | expand |
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
> -----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
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
> -----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
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
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;
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(-)