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 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 559D5C2BA83 for ; Fri, 14 Feb 2020 13:57:13 +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 334352187F for ; Fri, 14 Feb 2020 13:57:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 334352187F 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 CE53E6E7EC; Fri, 14 Feb 2020 13:57:12 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id A63BD6E81F for ; Fri, 14 Feb 2020 13:57:11 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2020 05:57:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,440,1574150400"; d="scan'208";a="267564856" Received: from aquilante.fi.intel.com (HELO intel.com) ([10.237.72.158]) by fmsmga002.fm.intel.com with ESMTP; 14 Feb 2020 05:57:09 -0800 Date: Fri, 14 Feb 2020 15:57:08 +0200 From: Andi Shyti To: Tvrtko Ursulin Message-ID: <20200214135708.GB2502@intel.intel> References: <20200214110308.2268-1-andi.shyti@intel.com> <20200214131619.GA2502@intel.intel> <471dd284-eb06-1240-018a-a86899031fdb@linux.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <471dd284-eb06-1240-018a-a86899031fdb@linux.intel.com> Subject: Re: [Intel-gfx] [PATCH] 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" Hi Tvrtko, > > > > + } > > > > + > > > > + intel_gt_sysfs_pm_remove(gt, root); > > > > + kobject_put(root); > > > > > > Maybe stick to the same terminology regarding root and parent. > > > > yes. > > > > > Get/put on the parent looks unbalanced. Both register and unregister take a > > > reference and only unregister releases it. But do you even need a reference? > > > > why? I take it here: > > > > static inline struct kobject *gt_to_parent_obj(struct intel_gt *gt) > > { > > return kobject_get(>->i915->drm.primary->kdev->kobj); > > } > > > > at the beginning (when the driver is loaded) and I release it at > > the end (when the driver is unloaded). Am I not seeing something? > > Gt_to_parent_obj at the top of intel_gt_sysfs_register balances out with the > put at the end of the same function. What balances out gt_to_parent_obj from > intel_gt_sysfs_register? And... you are right! either nothing or too many :) > > > I am also tempted by the _once alternative, but then it makes less sense to > > > include name & pid. > > > > It's true, it can be an unrelenting message, and I thought of it, > > but if the user is resilient at reading out from the wrong > > directory, why shouldn't I :) > > Because we always try to avoid emitting spammy logs when they can be easily > triggered by userspace. Can we do rate limit? I think that could work well > with logging the process name & pid. yes, if two people suggested the same thing, most probably that's the right thing to do. > Also, we need an entry in Documentation/ABI/obsolete/. I was waiting this patch to get in shape before adding the interface to obsolete. I will include it in the next patch. Thanks a lot for the review, Andi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx