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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29BFBC35DF5 for ; Tue, 25 Feb 2020 12:29:59 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 017A120CC7 for ; Tue, 25 Feb 2020 12:29:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 017A120CC7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 664486E8C4; Tue, 25 Feb 2020 12:29:58 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 719586E8C4 for ; Tue, 25 Feb 2020 12:29:56 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Feb 2020 04:29:56 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,484,1574150400"; d="scan'208";a="284657856" Received: from aquilante.fi.intel.com (HELO intel.com) ([10.237.72.158]) by FMSMGA003.fm.intel.com with ESMTP; 25 Feb 2020 04:29:54 -0800 Date: Tue, 25 Feb 2020 14:29:53 +0200 From: Andi Shyti To: Tvrtko Ursulin Message-ID: <20200225122953.GA5050@intel.intel> References: <20200219190223.16972-1-andi.shyti@intel.com> <20200219193020.17673-1-andi.shyti@intel.com> <20200224163029.GA1579@intel.intel> <421b0bd8-6bc6-e6c2-7e08-6d112c57a860@linux.intel.com> <20200225013208.GA2708@intel.intel> <2b7d426d-a8e9-40f9-fb1c-184f0f9b0dfd@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <2b7d426d-a8e9-40f9-fb1c-184f0f9b0dfd@linux.intel.com> Subject: Re: [Intel-gfx] [PATCH v5] drm/i915/gt: make a gt sysfs group and move power management files 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: , Cc: Intel GFX Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" > > > > > > +void intel_gt_sysfs_register(struct intel_gt *gt) > > > > > > +{ > > > > > > + struct kobject *parent = kobject_get(gt_get_parent_obj(gt)); > > > > > > + int ret; > > > > > > + > > > > and if I need to call kobject_put at the end. If for some reason > > the files have failed to be initialized, I would have an > > unbalanced put and a warning would be printed. > > > > I'll summarize in pseudo code: > > > > intel_gt_sysfs_register() > > { > > kobject_init_and_add(sysfs_root...); /* which calls kobject_get() inside */ > > if (fails) > > kobject_put(sysfs_root); /* reference goes to '0' */ > > } > > > > intel_gt_sysfs_unregister() > > { > > option1: I don't call kobject_put(), I have an unbalanced > > situation as you reviewed in patch 1. > > > > option2: I call kobject_put(), if it did fail during init > > there is an unbalanced situation, which is > > handled but an annoying WARN() is issued. > > > > option3: I check if "state_initialized" which I suppose > > has been properly initialised during declaration > > (maybe too paranoic?) and call _put() > > accordingly > > } > > Yes you are right, I confused the two parents again. :I this little things are good for jambling the brain up :) > Okay then, is the extra kobject_get/put on the parent > (kobject_get(gt_get_parent_obj(gt) - this one) needed? I do not see any strong reason for calling kobject_get, I do it only because I am creating files in there and I don't want anyone to free those without my permission. Otherwise, the creation and the destruction of the son object would take care of the refcount. Will it ever happen that parent will be destroyed before I have time to release the files? I don't think so, but I do it more for the form than for the use. In the sense that "I have stuff in there and I declare I have stuff in there and I declare when I won't need them anymore". Andi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx