From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com [74.125.83.41]) by dpdk.org (Postfix) with ESMTP id 05C163253 for ; Wed, 19 Jul 2017 14:12:41 +0200 (CEST) Received: by mail-pg0-f41.google.com with SMTP id 123so29933384pgj.1 for ; Wed, 19 Jul 2017 05:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fridaylinux-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TmXiPLKRTdKIqrn+Y85LneK3KZVcfsrGjGBsHr2W9yk=; b=N/lZlRE+jjcKN1DCJqBFyI02gXoHD5lFk2gIlINvM49k6Ckd20veeHTODHKRazQgI6 2uZuwoJL4tWoW1IPabQOa36cctRFN8uwOTMcuvb29rbVeLiZHG3sa/cjfixQyguiH/gQ rlUWsBF2GjpERa42v2azRoLxgKqwlhaIOv0eWvdj1emlp9ZLwzj1i7QP0NAuxFSZNSR4 6iX6XxrPzilGDMp0TyIvjnvMQor5hVZMKlq4GN/b92jCbfRV6/3LHSn+dCHQLjBvjZRf Felac47yOO9INAHLBHN4YejKuM4tLfzyrUM5XjHvfOmJxyzvujk21t1lrb/wRzl5w6p4 3klQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TmXiPLKRTdKIqrn+Y85LneK3KZVcfsrGjGBsHr2W9yk=; b=GO7FLJBJnKqP+QaAqP4S85B6/kw3bQeAfxG90bBeqCUpTWsAUHFOSl7xa+k6P4hUxx xCssxE/ciYf7bgSzjghPNoRaZybfAgVPPOY5nzX4PZC94iuGg0HSYvFVQviMQwQQpqZW waBcnZVWjLh/QyAfCROSpnPgkTI3WJiuJOJyiEor+iIInRAwKXBNSSFuiAQLeyoiG22Y TchlHbG1FWfsq1TpD1Uf2Dm1r9Jig6m/p4uydm9r+fwF0GklVszMdd2ShCivNAeDiQNA QCV3tgV7vjoZd0hQg2uJXBk7xAr8LprgB3cWJ1bgMF7VitRFsBtoP2spzm1OOG2n7Hxs 9+bA== X-Gm-Message-State: AIVw110T49zIBh5cPfk4Cqjfic8KD/Ggjm91BaPw5JhFcsxywTr5SoXR CyoaLD7zU72Q8eOg X-Received: by 10.84.254.11 with SMTP id b11mr2791028plm.250.1500466360947; Wed, 19 Jul 2017 05:12:40 -0700 (PDT) Received: from yliu-home ([45.63.61.64]) by smtp.gmail.com with ESMTPSA id g82sm401880pfb.186.2017.07.19.05.12.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 19 Jul 2017 05:12:39 -0700 (PDT) Date: Wed, 19 Jul 2017 20:12:34 +0800 From: Yuanhan Liu To: Hemant Agrawal Cc: "De Lara Guarch, Pablo" , Akhil Goyal , "dev@dpdk.org" , "stable@dpdk.org" Message-ID: <20170719121234.GY11626@yliu-home> References: <20170718073356.14288-1-akhil.goyal@nxp.com> <20170718143907.GV11626@yliu-home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [dpdk-dev] [PATCH v2] crypto/dpaa2_sec: fix the return of supported API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jul 2017 12:12:42 -0000 On Tue, Jul 18, 2017 at 05:32:44PM +0000, Hemant Agrawal wrote: > > > > > Subject: [PATCH v2] crypto/dpaa2_sec: fix the return of supported > > > > > API > > > > > > > > > > call to dpaa2_sec_dev_configure() is made mandatory, but > > > > > dpaa2_sec_pmd returns a ENOTSUP which results in device not > > > > > getting > > > configured. > > > > > > > > > > dpaa2_sec PMD does not need any further configuration to be done > > > > > in dpaa2_sec_dev_configure, hence returning 0 > > > > > > > > > > Fixes: e5cbdfc53765 ("crypto/dpaa2_sec: add basic operations") > > > > > > > > > > Cc: stable@dpdk.org > > > > > > > > > > Signed-off-by: Akhil Goyal > > > > > > > > Looks ok to me, but this is only applicable in the stable branch, so > > > > no need to send it to dev@dpdk.org. > > > > > > Why? We already have such fix in upstream? Normally, we just pick > > > upstream commits (but not patches: the emails) to stable release. > > > > It looks like this fix was included in > > 13273250eec5 ("crypto/dpaa2_sec: support AES-GCM and CTR"). > > Unfortunately, this patch should have been split into two different patches. > > Since this has already been merged, I think our only way to integrate this In > > 17.05.1 is by getting it separately. > > In general, there may be other incidents, where a patch is only applicable for the stable tree. It may not be applicable for upstream tree due to architecture changes or other reasons. > How do you want to handle such patches? > > e.g. in OVS, we can do it by marking the patch header with "[branch-2.6]" Yes, you are right, it might happen. Then you need cook a standalone patch and send it to stable ml only. Since I don't usually pick stable patches directly from stable ML, you probably need add some marks in the commit log. Something like "this is for stable tree only and add a bit explanation". Normally, every time I saw a patch sent only to stable ML I will ask the same question I have asked in this email. But I could just miss it. So you are suggested to do above. For this case, just as Pablo said, the patch should be split in the beginning, then only the (small) bug fixing patch will be picked to a specific stable release. And since it already happened, you could just send it to stable ML only, and better, with me cc-ed. Thanks. --yliu