From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 7ABED10E3D2 for ; Fri, 1 Apr 2022 01:18:42 +0000 (UTC) Date: Thu, 31 Mar 2022 18:18:40 -0700 Message-ID: <87tubdha8f.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Ceraolo Spurio, Daniele" In-Reply-To: <4fffd5fe-5605-d0ad-a295-0773036f0726@intel.com> References: <20220330183259.3003663-1-daniele.ceraolospurio@intel.com> <20220330183259.3003663-2-daniele.ceraolospurio@intel.com> <87v8vthgzb.wl-ashutosh.dixit@intel.com> <4fffd5fe-5605-d0ad-a295-0773036f0726@intel.com> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Subject: Re: [igt-dev] [PATCH i-g-t 1/2] lib/igt_kmod: Wait for a kmod to finish its probe before unloding it. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: igt-dev@lists.freedesktop.org, Alexander Usyskin Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" List-ID: On Thu, 31 Mar 2022 16:09:32 -0700, Ceraolo Spurio, Daniele wrote: > > On 3/31/2022 3:52 PM, Dixit, Ashutosh wrote: > > On Wed, 30 Mar 2022 11:32:58 -0700, Daniele Ceraolo Spurio wrote: > >> Modprobing i915 can result in other dependent modules being loaded > >> automatically as a follow up. This means that by the time the i915 load > >> function returns these modules may still be going through their init, so > >> if we try to immediately unload i915 again we will fail with an > >> -EBUSY. > > Can you explain a bit where we see this happening and if any tests fail > > because of this? My expectation would be if module A depends on module B, > > loading A will cause B to load, but loading B will not cause A to load. So > > what is causing these dependent modules to load when we load i915? Is there > > e.g. something in /etc/modprobe.d or udev which is causing this to happen? > > This is a new scenario, introduced with the GSC series where i915 exposes > the GSC as an aux device and the mei-gsc module binds to it (link to the > kernel series in the cover letter). The kernel handles the addition of an > aux device similarly to a device hot-plug, with the relevant driver > (mei-gsc in this case) being automatically probed, without requiring an > explicit modprobe. This aux device probe happens separately from the parent > device probe, which means that the i915 probe can complete and return > before the mei-gsc probe is done. The fact that mei-gsc binds to an i915 > aux device creates a dependency, even if mei-gsc doesn't actually > explicitly use any function exported by i915, so we need to unload it to be > able to unload i915. > > > Currently in IGT we maintain a list of modules depenedent on i915 which we > > unload prior to unloading i915. An alternative approach to this patch may > > be to maintain a similar list in igt_i915_driver_load() and load dependent > > modules after loading i915 as long as they are present on the system. So we > > would not need to wait for these dependent modules to complete loading when > > we unload i915. Do you think this is feasible? > > No, as mentioned above the module is loaded automatically. OK, thanks for the explanation, this corresponds to my understanding of how these buses (in this case aux bus) work. I have a couple more questions which let me ask separately. Thanks.