| Message ID | d9b5fade242f0806a587392d31c272709949479f.1560263641.git.christophe.leroy@c-s.fr (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | Additional fixes on Talitos driver | expand |
On 6/11/2019 5:39 PM, Christophe Leroy wrote: > Next patch will require struct talitos_edesc to be defined > earlier in talitos.c > > This patch moves it into talitos.h so that it can be used > from any place in talitos.c > > Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") > Cc: stable@vger.kernel.org > Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Again, this patch does not qualify as a fix. Horia
Le 13/06/2019 à 14:13, Horia Geanta a écrit : > On 6/11/2019 5:39 PM, Christophe Leroy wrote: >> Next patch will require struct talitos_edesc to be defined >> earlier in talitos.c >> >> This patch moves it into talitos.h so that it can be used >> from any place in talitos.c >> >> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") >> Cc: stable@vger.kernel.org >> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> > Again, this patch does not qualify as a fix. > But as I said, the following one is a fix and require that one, you told me to add stable in Cc: to make it explicit it was to go into stable. If someone tries to merge following one into stable with taking that one first, build will fail. Christophe
On 6/13/2019 3:16 PM, Christophe Leroy wrote: > > > Le 13/06/2019 à 14:13, Horia Geanta a écrit : >> On 6/11/2019 5:39 PM, Christophe Leroy wrote: >>> Next patch will require struct talitos_edesc to be defined >>> earlier in talitos.c >>> >>> This patch moves it into talitos.h so that it can be used >>> from any place in talitos.c >>> >>> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") >>> Cc: stable@vger.kernel.org >>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> >> Again, this patch does not qualify as a fix. >> > > But as I said, the following one is a fix and require that one, you told > me to add stable in Cc: to make it explicit it was to go into stable. Yes, but you should remove the Fixes tag. And probably replace "Next patch" with the commit headline. > If someone tries to merge following one into stable with taking that one > first, build will fail. This shouldn't happen, order from main tree should be preserved. Horia
Le 13/06/2019 à 14:24, Horia Geanta a écrit : > On 6/13/2019 3:16 PM, Christophe Leroy wrote: >> >> >> Le 13/06/2019 à 14:13, Horia Geanta a écrit : >>> On 6/11/2019 5:39 PM, Christophe Leroy wrote: >>>> Next patch will require struct talitos_edesc to be defined >>>> earlier in talitos.c >>>> >>>> This patch moves it into talitos.h so that it can be used >>>> from any place in talitos.c >>>> >>>> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") >>>> Cc: stable@vger.kernel.org >>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> >>> Again, this patch does not qualify as a fix. >>> >> >> But as I said, the following one is a fix and require that one, you told >> me to add stable in Cc: to make it explicit it was to go into stable. > Yes, but you should remove the Fixes tag. > And probably replace "Next patch" with the commit headline. > >> If someone tries to merge following one into stable with taking that one >> first, build will fail. > This shouldn't happen, order from main tree should be preserved. > When they pick up fixes, AFAIK they don't take all the preceeding commits. But ok, I'll resend. Christophe
On 6/13/2019 3:32 PM, Christophe Leroy wrote: > > > Le 13/06/2019 à 14:24, Horia Geanta a écrit : >> On 6/13/2019 3:16 PM, Christophe Leroy wrote: >>> >>> >>> Le 13/06/2019 à 14:13, Horia Geanta a écrit : >>>> On 6/11/2019 5:39 PM, Christophe Leroy wrote: >>>>> Next patch will require struct talitos_edesc to be defined >>>>> earlier in talitos.c >>>>> >>>>> This patch moves it into talitos.h so that it can be used >>>>> from any place in talitos.c >>>>> >>>>> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") >>>>> Cc: stable@vger.kernel.org >>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> >>>> Again, this patch does not qualify as a fix. >>>> >>> >>> But as I said, the following one is a fix and require that one, you told >>> me to add stable in Cc: to make it explicit it was to go into stable. >> Yes, but you should remove the Fixes tag. >> And probably replace "Next patch" with the commit headline. >> >>> If someone tries to merge following one into stable with taking that one >>> first, build will fail. >> This shouldn't happen, order from main tree should be preserved. >> > > When they pick up fixes, AFAIK they don't take all the preceeding commits. > This is not about Fixes tag, but Cc tag: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1 Horia
Le 13/06/2019 à 14:39, Horia Geanta a écrit : > On 6/13/2019 3:32 PM, Christophe Leroy wrote: >> >> >> Le 13/06/2019 à 14:24, Horia Geanta a écrit : >>> On 6/13/2019 3:16 PM, Christophe Leroy wrote: >>>> >>>> >>>> Le 13/06/2019 à 14:13, Horia Geanta a écrit : >>>>> On 6/11/2019 5:39 PM, Christophe Leroy wrote: >>>>>> Next patch will require struct talitos_edesc to be defined >>>>>> earlier in talitos.c >>>>>> >>>>>> This patch moves it into talitos.h so that it can be used >>>>>> from any place in talitos.c >>>>>> >>>>>> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") >>>>>> Cc: stable@vger.kernel.org >>>>>> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> >>>>> Again, this patch does not qualify as a fix. >>>>> >>>> >>>> But as I said, the following one is a fix and require that one, you told >>>> me to add stable in Cc: to make it explicit it was to go into stable. >>> Yes, but you should remove the Fixes tag. >>> And probably replace "Next patch" with the commit headline. >>> >>>> If someone tries to merge following one into stable with taking that one >>>> first, build will fail. >>> This shouldn't happen, order from main tree should be preserved. >>> >> >> When they pick up fixes, AFAIK they don't take all the preceeding commits. >> > This is not about Fixes tag, but Cc tag: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-1 > Ah, ok. So I need to keep the Cc tag. I misunderstood sorry.
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c index 3b3e99f1cddb..5b401aec6c84 100644 --- a/drivers/crypto/talitos.c +++ b/drivers/crypto/talitos.c @@ -951,36 +951,6 @@ static int aead_des3_setkey(struct crypto_aead *authenc, goto out; } -/* - * talitos_edesc - s/w-extended descriptor - * @src_nents: number of segments in input scatterlist - * @dst_nents: number of segments in output scatterlist - * @icv_ool: whether ICV is out-of-line - * @iv_dma: dma address of iv for checking continuity and link table - * @dma_len: length of dma mapped link_tbl space - * @dma_link_tbl: bus physical address of link_tbl/buf - * @desc: h/w descriptor - * @link_tbl: input and output h/w link tables (if {src,dst}_nents > 1) (SEC2) - * @buf: input and output buffeur (if {src,dst}_nents > 1) (SEC1) - * - * if decrypting (with authcheck), or either one of src_nents or dst_nents - * is greater than 1, an integrity check value is concatenated to the end - * of link_tbl data - */ -struct talitos_edesc { - int src_nents; - int dst_nents; - bool icv_ool; - dma_addr_t iv_dma; - int dma_len; - dma_addr_t dma_link_tbl; - struct talitos_desc desc; - union { - struct talitos_ptr link_tbl[0]; - u8 buf[0]; - }; -}; - static void talitos_sg_unmap(struct device *dev, struct talitos_edesc *edesc, struct scatterlist *src, diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h index 32ad4fc679ed..95f78c6d9206 100644 --- a/drivers/crypto/talitos.h +++ b/drivers/crypto/talitos.h @@ -42,6 +42,36 @@ struct talitos_desc { #define TALITOS_DESC_SIZE (sizeof(struct talitos_desc) - sizeof(__be32)) +/* + * talitos_edesc - s/w-extended descriptor + * @src_nents: number of segments in input scatterlist + * @dst_nents: number of segments in output scatterlist + * @icv_ool: whether ICV is out-of-line + * @iv_dma: dma address of iv for checking continuity and link table + * @dma_len: length of dma mapped link_tbl space + * @dma_link_tbl: bus physical address of link_tbl/buf + * @desc: h/w descriptor + * @link_tbl: input and output h/w link tables (if {src,dst}_nents > 1) (SEC2) + * @buf: input and output buffeur (if {src,dst}_nents > 1) (SEC1) + * + * if decrypting (with authcheck), or either one of src_nents or dst_nents + * is greater than 1, an integrity check value is concatenated to the end + * of link_tbl data + */ +struct talitos_edesc { + int src_nents; + int dst_nents; + bool icv_ool; + dma_addr_t iv_dma; + int dma_len; + dma_addr_t dma_link_tbl; + struct talitos_desc desc; + union { + struct talitos_ptr link_tbl[0]; + u8 buf[0]; + }; +}; + /** * talitos_request - descriptor submission request * @desc: descriptor pointer (kernel virtual)
Next patch will require struct talitos_edesc to be defined earlier in talitos.c This patch moves it into talitos.h so that it can be used from any place in talitos.c Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on SEC1") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> --- drivers/crypto/talitos.c | 30 ------------------------------ drivers/crypto/talitos.h | 30 ++++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+), 30 deletions(-)