Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp2512236ybg; Fri, 31 Jul 2020 01:46:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyttlQM2gYs3TuUxbae1PH/PRKTLENzMABEflaI6UvbobkqwHb+dgW+ZibNYAIvUsI671do X-Received: by 2002:a05:6402:22fc:: with SMTP id dn28mr2700719edb.381.1596185168680; Fri, 31 Jul 2020 01:46:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596185168; cv=none; d=google.com; s=arc-20160816; b=wox64mWVaE1iL0xdTjXFQGKzg/yT2dGbC9DCDWsSDelW/PbS5ZHkbHO7c8S+29xJ3P jj8TeobJUq4POQpfUCUc7934Q4iOWBFJEXvMm4RNfJzi1555LcR1ri7paK/ph/PJSecz Ju9pQUWYtD42oPrqSC3ucgLYvKcQ7KDCwGKj2QLs3x3+XitjA/GB6e8jvqUI8lAn7Z4N rgYS2KScRAqBXdbElncNgdz9F8g5fP8UD3D/H03C4T3rajOoW9c2goehW9lmDylpS/1q e6MpIW7+6f8GnzXLY3UjXURBcRKJiouqq21Ho7GUNrPK2yv4PTloLsMunzcIT7RGgiBU GhMw== 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=BEVOA4LAuBKPLo+vtM7LvrY0USwLGr9CQM0w26gvLCA=; b=TbPPVekXxGG7q7rmyPLGXsJjKZFOClP+KbPT9k9U4/Bdyc0x2QWYhNpwAhQoFj9OfK 1PpfaTqj1o6c+moK7k8ypuuoHNvavvoTg/EFUijdqI5R6hoYNimxnRZyn+CxdRk8bjI4 FZuXLFKJ97XtnxdhB/uFNf5RVbpINVhpx3ccyqpRruLc73DilYJYXfL/nQRwCGY0QnjJ h6En8ra85ZaLZ+SzbLH6Y8aH5kpErk20zt2H/KNnAlQRCqZFCFFlts08TJX2xlrtnfVn vZC6Rq/j/bX2hq6EnDNfnCL+iD0L//QKhcNi0XiL9ao4+AEz/qv0CwXrt2O/PMkdC/rC atrg== 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 gr8si4530102ejb.601.2020.07.31.01.45.40; Fri, 31 Jul 2020 01:46:08 -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 S1731927AbgGaIo4 (ORCPT + 99 others); Fri, 31 Jul 2020 04:44:56 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:9307 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731896AbgGaIo4 (ORCPT ); Fri, 31 Jul 2020 04:44:56 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 8170F17E78DA4AA8876E; Fri, 31 Jul 2020 16:44:53 +0800 (CST) Received: from [127.0.0.1] (10.74.173.29) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.487.0; Fri, 31 Jul 2020 16:44:42 +0800 Subject: Re: [PATCH v3 08/10] crypto: hisilicon/qm - fix the process of register algorithms to crypto To: Herbert Xu References: <1595488780-22085-1-git-send-email-shenyang39@huawei.com> <1595488780-22085-9-git-send-email-shenyang39@huawei.com> <20200731075722.GA20350@gondor.apana.org.au> <79b37e17-8eb6-b89b-d49f-46a3faf2783a@huawei.com> <20200731082030.GA21715@gondor.apana.org.au> CC: , , , From: "shenyang (M)" Message-ID: Date: Fri, 31 Jul 2020 16:44: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: <20200731082030.GA21715@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/31 16:20, Herbert Xu wrote: > On Fri, Jul 31, 2020 at 04:15:41PM +0800, shenyang (M) wrote: >> >> Here if the user alloc a tfm of the algorithm the driver registers, >> the function 'hisi_qm_wait_task_finish' which be added in patch 10 will >> stop to remove the driver until the tfm is freed. > > 1. You don't introduce a bug in patch 8 only to fix it in patch 10. > Lay the groundwork first before you rely on it. > Sorry, I'll move the patch 10 before patch 8 > 2. You need to explain how the wait fixes the problem of unregistering > an algorithm under a live tfm. Can you even do a wait at all > in the face of a PCI unbind? What happens when the device reappears? > The function 'hisi_qm_wait_task_finish' will check the device status. If it is free, the function will freeze all queues in the device and go on. Otherwise, the function will wait until the device is free. And the function is added in 'pci_driver.remove'. So the operation of unbind will call it too. Q:'What happens when the device reappears?' A:Do you means the scene like bind and unbind? There is a device list in the driver. The registration or unregistration of algorithms will only happen when the list is empty. So the function register or unregister will be called only once. > Cheers, >