Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp3014599pxp; Tue, 8 Mar 2022 06:18:14 -0800 (PST) X-Google-Smtp-Source: ABdhPJyRNrwz5dA5JEsiKDsGV6gzXpwA41GbEEA5VjDBmRj/I5DgB7FhU6SC0PcWZpInQ7jGGiE+ X-Received: by 2002:a05:6402:1bc8:b0:416:2375:f815 with SMTP id ch8-20020a0564021bc800b004162375f815mr15296797edb.130.1646749094505; Tue, 08 Mar 2022 06:18:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646749094; cv=none; d=google.com; s=arc-20160816; b=wLrrVaIdATa969OdIqBbMdb3142bi1VazDsy2LqTPidMgYQ86XMI4n/k4gX7OZWM0w h7mxH+poPwrPqRDXBhCeLVTXe2QB9jdTVu4h5RwOoVqaB+MVNVF+3b3rwpbp63VTmTzc EXqtQTPPtY+K+jj5oL19/LoD6ZhLZ3cAp0TRdeBKNpnStTrj8uTWdx2HmII3RuH8Erx3 sP2putcLqYvGYdAkhSgoW9U71wkdLq3gqES2qPKhXfDBHSkt5KcsdhgPX3ggrTaqVnpm tZzIRlwbL+agnNmTNfpmQyJPud75eTUUe2GOMVfHF8Oivvlb2S9fYadEA1jI+DTug/7R aRKg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:to:subject :cc; bh=J+d0ZqB6rWFU4CEubEpdextFNNaZuFT4Zm7w8mH8J0Y=; b=AGTGrX4FsOwx1RlbgcTbzxUsq4vg8J8WOxA9xty7IbZbUR7uiWUnBW9HzFuQTy6iBH qd5bg94joT0yuG2RSroO5o9lkghm6kPrXMRH41IGkLL1SGvyn/vq48MkE1fnvTLA1htM 5uGMKs+V6TQKWuHnUcVGERXv9fJqbgdBbyoDUJpWRxrFiVuhc8a1KiaTxZKa0vA427J9 4Tzc7yn8dpzcBadbngfMStwionanatkmfKI+bwsgZkw1+V/oacwamV2cpd1Bozi1tqdO 5XJpOn96mMjCmWS8z9sSGxI4MIeDY3mrIaiRhb5IY1ErU/1vFF+7nVT5tX7zaTfmWe4x /dpg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y3-20020a170906448300b006d0a271a913si10168890ejo.919.2022.03.08.06.17.50; Tue, 08 Mar 2022 06:18:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346392AbiCHLON (ORCPT + 99 others); Tue, 8 Mar 2022 06:14:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1346350AbiCHLOI (ORCPT ); Tue, 8 Mar 2022 06:14:08 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CF2943A5F6; Tue, 8 Mar 2022 03:13:10 -0800 (PST) Received: from canpemm500009.china.huawei.com (unknown [172.30.72.56]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4KCXf02Jckz9sQw; Tue, 8 Mar 2022 19:09:28 +0800 (CST) Received: from [10.67.102.169] (10.67.102.169) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 8 Mar 2022 19:13:08 +0800 CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH v5 3/8] hisi_ptt: Register PMU device for PTT trace To: Jonathan Cameron , Yicong Yang References: <20220308084930.5142-1-yangyicong@hisilicon.com> <20220308084930.5142-4-yangyicong@hisilicon.com> <20220308102157.00003725@Huawei.com> From: Yicong Yang Message-ID: Date: Tue, 8 Mar 2022 19:13:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20220308102157.00003725@Huawei.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.102.169] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To canpemm500009.china.huawei.com (7.192.105.203) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/3/8 18:21, Jonathan Cameron wrote: > On Tue, 8 Mar 2022 16:49:25 +0800 > Yicong Yang wrote: > >> Register PMU device of PTT trace, then users can use trace through perf >> command. The driver makes use of perf AUX trace and support following >> events to configure the trace: >> >> - filter: select Root port or Endpoint to trace >> - type: select the type of traced TLP headers >> - direction: select the direction of traced TLP headers >> - format: select the data format of the traced TLP headers >> >> This patch adds the PMU driver part of PTT trace. The perf command support >> of PTT trace is added in the following patch. >> >> Signed-off-by: Yicong Yang > > It seems to me that you ended up doing both suggestions for > how to clean up the remove order when it was meant to be > a question of picking one or the other. > > Otherwise this looks good to me - so with that tidied up > Hi Jonathan, Thanks for the comments. I'd like to illustrate the reason why I decide to manually unregister the PMU device. The DMA buffers are devm allocated when necessary. They're only allocated when user is going to use the PTT in the first time after the driver's probe, so when driver removal the buffers are released prior to the PMU device's unregistration. I think there's a race condition. IIUC, The PMU device(as the user interface) should be unregistered first then we're safe to free the DMA buffers. But unregister the PMU device by devm cannot keep that order. Thanks, Yicong > Reviewed-by: Jonathan Cameron > >> --- > >> + >> +static int hisi_ptt_register_pmu(struct hisi_ptt *hisi_ptt) >> +{ >> + u16 core_id, sicl_id; >> + char *pmu_name; >> + u32 reg; >> + >> + hisi_ptt->hisi_ptt_pmu = (struct pmu) { >> + .module = THIS_MODULE, >> + .capabilities = PERF_PMU_CAP_EXCLUSIVE | PERF_PMU_CAP_ITRACE, >> + .task_ctx_nr = perf_sw_context, >> + .attr_groups = hisi_ptt_pmu_groups, >> + .event_init = hisi_ptt_pmu_event_init, >> + .setup_aux = hisi_ptt_pmu_setup_aux, >> + .free_aux = hisi_ptt_pmu_free_aux, >> + .start = hisi_ptt_pmu_start, >> + .stop = hisi_ptt_pmu_stop, >> + .add = hisi_ptt_pmu_add, >> + .del = hisi_ptt_pmu_del, >> + }; >> + >> + reg = readl(hisi_ptt->iobase + HISI_PTT_LOCATION); >> + core_id = FIELD_GET(HISI_PTT_CORE_ID, reg); >> + sicl_id = FIELD_GET(HISI_PTT_SICL_ID, reg); >> + >> + pmu_name = devm_kasprintf(&hisi_ptt->pdev->dev, GFP_KERNEL, "hisi_ptt%u_%u", >> + sicl_id, core_id); >> + if (!pmu_name) >> + return -ENOMEM; >> + >> + return perf_pmu_register(&hisi_ptt->hisi_ptt_pmu, pmu_name, -1); > > As below, you can put back the devm cleanup that you had in v4 now you > have modified how the filter cleanup is done to also be devm managed. > >> +} >> + >> /* >> * The DMA of PTT trace can only use direct mapping, due to some >> * hardware restriction. Check whether there is an IOMMU or the >> @@ -303,15 +825,32 @@ static int hisi_ptt_probe(struct pci_dev *pdev, >> >> pci_set_master(pdev); >> >> + ret = hisi_ptt_register_irq(hisi_ptt); >> + if (ret) >> + return ret; >> + >> ret = hisi_ptt_init_ctrls(hisi_ptt); >> if (ret) { >> pci_err(pdev, "failed to init controls, ret = %d.\n", ret); >> return ret; >> } >> >> + ret = hisi_ptt_register_pmu(hisi_ptt); >> + if (ret) { >> + pci_err(pdev, "failed to register pmu device, ret = %d", ret); >> + return ret; >> + } >> + >> return 0; >> } >> >> +void hisi_ptt_remove(struct pci_dev *pdev) >> +{ >> + struct hisi_ptt *hisi_ptt = pci_get_drvdata(pdev); >> + >> + perf_pmu_unregister(&hisi_ptt->hisi_ptt_pmu); > > Now you have the filter cleanup occurring using a devm_add_action_or_reset() > there is no need to have a manual cleanup of this - you can > use the approach of a devm_add_action_or_reset like you had in v4. > > As it is the last call in the probe() order it will be the first one > called in the device managed cleanup. > >> +} >> + > > > . >