From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 52998C4345F for ; Tue, 16 Apr 2024 04:05:48 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 17D1B1129D8; Tue, 16 Apr 2024 04:05:47 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="UQCTdkKL"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by gabe.freedesktop.org (Postfix) with ESMTPS id 32D7E1129D8; Tue, 16 Apr 2024 04:05:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1713240346; x=1744776346; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=qYqFQxG3GvJkIgbdj07EURxXDW2TY/tvCr3y2HRKj/0=; b=UQCTdkKLG/kdccRy0CNo7P/djq42FPEl6KgLNRio3dRoli1R8RmbXIUv w919DBr/E5F7UMP9nBm3iiz2dJXr9rgM9io27tOTKdfXwSoetaZ0kocgg qcPuIB7PxY6RcnZVQGfIO+De1eoJ8VOMIbEKz6ov0W9w+hBKU8YX364jE KXocDNQB2dNrO2Gc5xO+O20pc25YjxAqbdu22jnERpPbED/niTxAzbzRO Szu7aOIA+cNStlBe+sAfg+0CVE9GWuyolM8YBny9g7qAm/CKRyIT5lUT1 wfncFCnB8rOGRuUg7JBxcxgrpTuVlN0xrAL8e9PvjuIekl9bollpJYFnJ w==; X-CSE-ConnectionGUID: nJERFumhReWbPJHQzNVIKg== X-CSE-MsgGUID: ndoFPJoBTumAJSCJGhQFvQ== X-IronPort-AV: E=McAfee;i="6600,9927,11045"; a="19806192" X-IronPort-AV: E=Sophos;i="6.07,204,1708416000"; d="scan'208";a="19806192" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2024 21:05:45 -0700 X-CSE-ConnectionGUID: P5RiF+FQSCOOfh8QDOT3Qw== X-CSE-MsgGUID: 28oq5WzRSEuiDM/RxaLK1A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,204,1708416000"; d="scan'208";a="26545199" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.138]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Apr 2024 21:05:44 -0700 Date: Mon, 15 Apr 2024 21:05:44 -0700 Message-ID: <857cgyt0iv.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Armin Wolf Cc: intel-gfx@lists.freedesktop.org, Badal Nilawar , Andi Shyti , Ville =?ISO-8859-1?Q?Syrj=E4l=E4?= , linux-hwmon@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH v2] drm/i915/hwmon: Get rid of devm In-Reply-To: <020612d1-2e6b-4bd7-87a6-dbd31574fdd8@gmx.de> References: <20240415223612.738535-1-ashutosh.dixit@intel.com> <020612d1-2e6b-4bd7-87a6-dbd31574fdd8@gmx.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Mon, 15 Apr 2024 16:35:02 -0700, Armin Wolf wrote: > Hi Armin, > Am 16.04.24 um 00:36 schrieb Ashutosh Dixit: > > @@ -818,10 +818,10 @@ void i915_hwmon_register(struct drm_i915_private *i915) > > hwm_get_preregistration_info(i915); > > > > /* hwmon_dev points to device hwmon */ > > - hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat->name, > > - ddat, > > - &hwm_chip_info, > > - hwm_groups); > > + hwmon_dev = hwmon_device_register_with_info(dev, ddat->name, > > + ddat, > > + &hwm_chip_info, > > + hwm_groups); > > if (IS_ERR(hwmon_dev)) { > > i915->hwmon = NULL; > > you need to free hwmon here, since it is not managed by devres anymore. Thanks a lot for catching this, I had missed it in v2, it's fixed in v3. I am actually reusing i915_hwmon_unregister() for error unwinding in v3. > > > return; > > @@ -838,10 +838,10 @@ void i915_hwmon_register(struct drm_i915_private *i915) > > if (!hwm_gt_is_visible(ddat_gt, hwmon_energy, hwmon_energy_input, 0)) > > continue; > > > > - hwmon_dev = devm_hwmon_device_register_with_info(dev, ddat_gt->name, > > - ddat_gt, > > - &hwm_gt_chip_info, > > - NULL); > > + hwmon_dev = hwmon_device_register_with_info(dev, ddat_gt->name, > > + ddat_gt, > > + &hwm_gt_chip_info, > > + NULL); > > if (!IS_ERR(hwmon_dev)) > > ddat_gt->hwmon_dev = hwmon_dev; > > } > > @@ -849,5 +849,26 @@ void i915_hwmon_register(struct drm_i915_private *i915) > > > > void i915_hwmon_unregister(struct drm_i915_private *i915) > > { > > - fetch_and_zero(&i915->hwmon); > > + struct i915_hwmon *hwmon = fetch_and_zero(&i915->hwmon); > > Why is fetch_and_zero() necessary here? As mentioned, in v3 i915_hwmon_unregister() itself is used for error unwinding so we need to prevent multiple device_unregister's etc. That is the purpose of setting i915->hwmon to NULL. But even earlier, though it is not obvious, i915_hwmon_unregister() is called multiple times. So e.g. it will be called at device unbind as well as module unload. So once again we prevent multiple device_unregister's by setting and checking for NULL i915->hwmon. > > > + struct hwm_drvdata *ddat = &hwmon->ddat; > > + struct intel_gt *gt; > > + int i; > > + > > + if (!hwmon) > > + return; > > + > > + for_each_gt(gt, i915, i) { > > + struct hwm_drvdata *ddat_gt = hwmon->ddat_gt + i; > > + > > + if (ddat_gt->hwmon_dev) { > > + hwmon_device_unregister(ddat_gt->hwmon_dev); > > + ddat_gt->hwmon_dev = NULL; > > + } > > + } > > + > > + if (ddat->hwmon_dev) > > + hwmon_device_unregister(ddat->hwmon_dev); > > + > > + mutex_destroy(&hwmon->hwmon_lock); > > + kfree(hwmon); > > } Thanks. -- Ashutosh