Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1776467ybh; Fri, 17 Jul 2020 00:17:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzdcIgSmcyUoYbkg6hzR4oq4pVpuMTKtBWfl228b9DhJaOfTweh26TbeswYjImeNCae0c5O X-Received: by 2002:a17:906:6406:: with SMTP id d6mr7056867ejm.30.1594970243452; Fri, 17 Jul 2020 00:17:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594970243; cv=none; d=google.com; s=arc-20160816; b=NAFVM7+kA0z/H2hO1ME+7a5Ds42SoVj1mktveTmDOcSwUsE+DWVYAT7LrFCGkq0hpP y/myWu6fgeivy08eKQMpGTvyLHs5acrqSUsascKVVsjuIn6GyFyWNF3IFDAjVgNcGQex 3hbr/0ggjGTNp6wSj8YPDIq0H2L2Jcc6s4/c7zORh3r/1nymSqYt1+z3UcKlJIcsuBlo I3yONRrhg97bw6QfLZATfLvMKGKlWIXXs0CZ8rhYOfHZ0cF0wuyYSAL2d7Imr+W382qc MRA2bOK4HYHpbniS1oYfTsuGr81VA+Cgo4fTQTlmGHlUSJO96sb3lN40kIIy3oG/u+XO ZOow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=TAaJzSgihk89uiqkGWnxKTWSA3W4/v0ptu/H/KDczkA=; b=V+D9Rh5T1SsRm/zqkpiVN9Wa/ZF4wSOT1iM/YSiQET/MTQa/T7rkKwOcwdd5O8pX1O eRrcU96Y2uMImSHQB3MqJK8ecefzU/t5BHXWYDYflVzWaUp3gWE3mnooeri4S0WXqfSj hDip3Z9AVtfQjPu2jA084/vwbkpsOdBlMRqzeIOzaIeX7Ph5RfsuOGJyQEkq+ilX54uK e45HuzYzWH/t80kv3puEU1fdrg6FwQtrLpdR884id6cxzw/PbOeI3zys7HLLDGRzTRyV DajjwF4VJu1Ba22VQZnptJGFrCQdYV1ekXJiN2VItb/zPwvVNIfwzCd8xV+NWjqW5ox3 XsXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c9si4392890ejb.631.2020.07.17.00.16.54; Fri, 17 Jul 2020 00:17:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726250AbgGQHQv (ORCPT + 99 others); Fri, 17 Jul 2020 03:16:51 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:45068 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726113AbgGQHQv (ORCPT ); Fri, 17 Jul 2020 03:16:51 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id DB4F6A595D59FC99BA9F; Fri, 17 Jul 2020 15:16:48 +0800 (CST) Received: from [127.0.0.1] (10.74.173.29) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.487.0; Fri, 17 Jul 2020 15:16:42 +0800 Subject: Re: [Patch v2 8/9] crypto: hisilicon/qm - fix the process of register algorithms to crypto To: Herbert Xu References: <1593587995-7391-1-git-send-email-shenyang39@huawei.com> <1593587995-7391-9-git-send-email-shenyang39@huawei.com> <20200709053619.GA5637@gondor.apana.org.au> <4e79b1ce-2b2a-7db3-dc55-380c2229657a@huawei.com> <20200709120259.GA11508@gondor.apana.org.au> CC: , , , From: "shenyang (M)" Message-ID: <7bf55d0c-76c3-8a39-4e75-7dbb393cbf82@huawei.com> Date: Fri, 17 Jul 2020 15:16:42 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20200709120259.GA11508@gondor.apana.org.au> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.74.173.29] X-CFilter-Loop: Reflected Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On 2020/7/9 20:02, Herbert Xu wrote: > On Thu, Jul 09, 2020 at 07:05:11PM +0800, shenyang (M) wrote: >> >> Yes, this patch just fixes the bug for 'hisi_zip'. As for 'hisi_hpre' >> and 'hisi_sec2', this patch doesn't change the logic. >> We have noticed the problem you say, and the patch is prepared. We fix >> this in 'hisi_qm', and you will see it soon. > > I cannot accept a clearly buggy patch. So please fix this and > resubmit. > > Thanks, > Here I give a example of hisi_hpre.ko. When the user unbind or remove the driver, the driver checks whether the current device is stopped. --- a/drivers/crypto/hisilicon/hpre/hpre_main.c +++ b/drivers/crypto/hisilicon/hpre/hpre_main.c @@ -903,9 +903,11 @@ static void hpre_remove(struct pci_dev *pdev) struct hisi_qm *qm = pci_get_drvdata(pdev); int ret; + hisi_qm_wait_task_finish(qm, &hpre_devices); + hisi_qm_alg_unregister(qm, &hpre_devices); if (qm->fun_type == QM_HW_PF && qm->vfs_num) { - ret = hisi_qm_sriov_disable(pdev); + ret = hisi_qm_sriov_disable(pdev, qm->is_frozen); if (ret) { pci_err(pdev, "Disable SRIOV fail!\n"); return; This patch will be add on V3. And in 'hisi_qm_alg_unregister', the driver will only unregister algorithm when remove the last device. So here the algorithm will be unregistered only when nobody holds a reference count on it. Thanks, Yang