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 A44ECC636D4 for ; Fri, 17 Feb 2023 10:50:13 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A5C2910EF53; Fri, 17 Feb 2023 10:50:12 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id A0E5610EF53 for ; Fri, 17 Feb 2023 10:50:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1676631010; x=1708167010; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=oesV3PQujutHfB7j+SlHkyxVpPTQ5Dz190YNXIcxXEc=; b=chPcKEknA5l2zpnPxXgdF/Rivr9ehL59ouITbDYqgO7RJagxzSP864Jx fIo6pjShOmGdugvv/XnHkajyTH+oIYvFh4avZJkn05m1WWC2i9roDsedB v1gkuOM8uyHyT2J4D/usPga8uoS55CpB2OVMicXBKcphgcccyZCNPFzfP QwiNP4n3gvDnW9rP387qiFQMGI20HGS8n0Wf0rPJTFP/+0h1952pXiexA +7jtz3tCRsL3U8umGFSdAwMHNGMeXDBk2xWVlFyDZmwzvGL40V102tDXc vlCRtBXPwhZu0vJ55e8S6h9WGxlsyy46El3cf1P/hoRd3TmhTmGqFxEn0 A==; X-IronPort-AV: E=McAfee;i="6500,9779,10623"; a="320066517" X-IronPort-AV: E=Sophos;i="5.97,304,1669104000"; d="scan'208";a="320066517" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2023 02:49:51 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10623"; a="670500094" X-IronPort-AV: E=Sophos;i="5.97,304,1669104000"; d="scan'208";a="670500094" Received: from akocherg-mobl1.ccr.corp.intel.com (HELO localhost) ([10.252.53.1]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Feb 2023 02:49:44 -0800 From: Jani Nikula To: Stanislaw Gruszka Subject: Re: [PATCH 3/3] drm/debugfs: remove dev->debugfs_list and debugfs_mutex In-Reply-To: <20230217103501.GC2862577@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20230209081838.45273-1-christian.koenig@amd.com> <20230209081838.45273-4-christian.koenig@amd.com> <20230216163757.GK2849548@linux.intel.com> <87lekxzgih.fsf@intel.com> <20230217103501.GC2862577@linux.intel.com> Date: Fri, 17 Feb 2023 12:49:41 +0200 Message-ID: <871qmozhve.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Christian =?utf-8?Q?K=C3=B6nig?= , mcanal@igalia.com, dri-devel@lists.freedesktop.org, mwen@igalia.com, mairacanal@riseup.net, maxime@cerno.tech, daniel.vetter@ffwll.ch, wambui.karugax@gmail.com Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, 17 Feb 2023, Stanislaw Gruszka wrote: > On Thu, Feb 16, 2023 at 07:06:46PM +0200, Jani Nikula wrote: >> > >> > But should not this the driver responsibility, call drm_debugfs_add_file() >> > whenever you are ready to handle operations on added file ? >> >> In theory, yes, but in practice it's pretty hard for a non-trivial >> driver to maintain that all the conditions are met. > > Hmmm... > >> In i915 we call debugfs register all over the place only after we've >> called drm_dev_register(), because it's the only sane way. But it means >> we need the init and register separated everywhere, instead of init >> adding files to a list to be registered later. > > Isn't this done this way in i915 only because it was not possible > (and still isn't) to call drm_debugfs_create_file() before registration ? > > I think it's should be ok by i915 subsystem to create it's debugfs > files and allow to access to them just after that subsystem init. > > Or there are some complex dependencies between i915 subsystems, > that reading registers from one subsystem will corrupt some > other subsystem that did non finish initialization yet? That's the point. It's really hard to figure it all out. Why bother? BR, Jani. > > Regards > Stanislaw -- Jani Nikula, Intel Open Source Graphics Center