Received: by 2002:a05:6358:c692:b0:131:369:b2a3 with SMTP id fe18csp1214681rwb; Fri, 28 Jul 2023 06:29:53 -0700 (PDT) X-Google-Smtp-Source: APBJJlE/06vMaB7TUIT8bScU8vApWum45RVxwzwgXtmimNWN59PizCrr4b/PwEGCILmoT7GiR0PV X-Received: by 2002:a17:90a:8549:b0:268:218b:ad20 with SMTP id a9-20020a17090a854900b00268218bad20mr1316217pjw.7.1690550993198; Fri, 28 Jul 2023 06:29:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690550993; cv=none; d=google.com; s=arc-20160816; b=0gnJ/Vw/79SNNeV0HdTBgThkL4rcl1WtCV1eXihdCnjtZWkbn7VysJ1XJpBmSbXo5p Lrg5bqq8JUUzNLkAyZk9TUjpKqhySip+FIe/EPnUy9d546slucpYai1jVURSEZUFu7N6 OUqOPljFKplNeMgWFzNX9w898C0ecAMtnCA/CIKACCZ1Hce9IoiMFAB50s+pWbK8Z3Zp HQZ9ks7Ox494yRcdLzPciE7qKrTt64uGDDk6Uu8hOqCOjolgXvyQGyCU5Kmt0VJo+cIc R6Wn/eG+m8DnmvJSwFMjpC2jT1jQDjod45wZW8MQq4YDGwW0e48zCMbX1jnj50ASIAym s4pA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=n8ERHfc+oTFDjgsPgb3eK6rTWQ/3/fMig7yWrPI1mio=; fh=3ylupCRGW0WDQ7WI0cObLzjmtKCNj0R4IuvR7WJi5xg=; b=DnVawJNPfimtukDZVBKPSr6O12yvtRNH6UwDYjin8Gl5LKZ+OmyZ4SQnT23PfHSJDj gHxQeYdvbf7EIy+YBr5OrOZs4ijLqQ5NMh9ZFQypn4fPs1MyzrcMgq5c5QNMugezUxGe ZbnC8gh+KJ2kEVhR0PrW1/sroADs9l4IgtPgyCxQ2foRm0NV8ZbfmamUyXeO0ySUwgZ4 wBwu4pBU8ZUt5ssg2DV46JG3SGl/TCUwlrPyYpdcxKjrFRMKMsCcHUgfd4xuj/e5LIQR IFrd6K09nM1TWdNDGflvqlGsK99xij6u0yjFfkg8j5YXuGF8JZw5N/0fPtyuoxIM8Bhw dygA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WRfiWNez; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e3-20020a17090a6f8300b00250888e039csi3142755pjk.62.2023.07.28.06.29.39; Fri, 28 Jul 2023 06:29:53 -0700 (PDT) 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; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=WRfiWNez; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236327AbjG1NW1 (ORCPT + 99 others); Fri, 28 Jul 2023 09:22:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236230AbjG1NWZ (ORCPT ); Fri, 28 Jul 2023 09:22:25 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4303B1FC8; Fri, 28 Jul 2023 06:22:24 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CE2AF62139; Fri, 28 Jul 2023 13:22:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABD2BC433C8; Fri, 28 Jul 2023 13:22:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690550543; bh=W/bcRxC7HKPq+WV1f0L7wqNL6qKipJr/pW8p28YHdiw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=WRfiWNezqz7bKg30pZXD9X14kxEezE9wiYwkdXSnfB9e+W2dalsxwO+Ip8ZQuQ4kI 49CdbPIsyF8p+LM4O80t51G+DEGUm8blJxgq8PTJsh/LGn/lN28HdcE3PM/U9TfJ2+ dBcI+nCVLbcN38q9DDzvYOcCcjUxVlp77CpntqV8yxVWTBgozAzX/YpQLpCPnrJlz5 cMzM2yTUOo47ItovedppYQM4XN6YXyRNnihXTUxD2QNB2Mh5/SWATuzDw/pLSEijwL CQaZuhmta93WbqOlceD4iFd6vElUnKsoNOdEJI1vw9Qh263vGKqEH3r6rFufzRUtQw MII83kK+lAC3g== Date: Fri, 28 Jul 2023 14:22:17 +0100 From: Will Deacon To: Besar Wicaksono , suzuki.poulose@arm.com Cc: robin.murphy@arm.com, ilkka@os.amperecomputing.com, catalin.marinas@arm.com, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, treding@nvidia.com, jonathanh@nvidia.com, vsethi@nvidia.com, rwiley@nvidia.com, efunsten@nvidia.com Subject: Re: [PATCH v5] perf: arm_cspmu: Separate Arm and vendor module Message-ID: <20230728132216.GA21394@willie-the-truck> References: <20230705104745.52255-1-bwicaksono@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230705104745.52255-1-bwicaksono@nvidia.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, 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 Wed, Jul 05, 2023 at 05:47:45AM -0500, Besar Wicaksono wrote: > Arm Coresight PMU driver consists of main standard code and > vendor backend code. Both are currently built as a single module. > This patch adds vendor registration API to separate the two to > keep things modular. The main driver requests each known backend > module during initialization and defer device binding process. > The backend module then registers an init callback to the main > driver and continue the device driver binding process. > > Signed-off-by: Besar Wicaksono > --- > > Changes from v4: > * Fix warning reported by kernel test robot > v4: https://lore.kernel.org/linux-arm-kernel/20230620041438.32514-1-bwicaksono@nvidia.com/T/#u One minor comment below, but this mostly looks good to me. I'd like Suzuki's Ack before I queue it, though. > + /* Load implementer module and initialize the callbacks. */ > + if (match) { > + mutex_lock(&arm_cspmu_lock); > + > + if (match->impl_init_ops) { > + if (try_module_get(match->module)) { > + cspmu->impl.match = match; > + ret = match->impl_init_ops(cspmu); > + module_put(match->module); Why is it safe to drop the module reference here? If I'm understanding the flow correctly, ->impl_init_ops() will populate more function pointers in the cspmu->impl.ops structure, and we don't appear to take a module reference when calling those. What happens if the backend module is unloaded while the core module is executed those functions? Cheers, Will