On Thu, Dec 19, 2024 at 02:20:45PM -0600, Lucas De Marchi wrote: > On Wed, Dec 18, 2024 at 03:38:30PM -0800, Daniele Ceraolo Spurio wrote: > > The mei driver is a child of i915 on discrete, but not on integrated. > > This means we want to unplug it before removing i915 in the former case > > but not in the latter. Therefore, instead of manually unloading the mei > > driver, we can unbind i915 and leave it to the kernel to unplug all the > > dependencies. This also means that we don't need to explicitly disable > > the vtcon anymore. > > > > The other 2 dependencies are left untouched: > > - intel_ips uses symbol_get, so the automatic dependency detection won't > > unload it. > > and it shouldn't - that's a hack and from the linux-modules perspective > we'd like to drop symbol_get() users. Btw, symbol_get/symbol_put only > guarantees the module can't be removed (since there's code in the kernel > that can still call into them). Totally. Also if CONFIG_TRIM_UNUSED_KSYMS=y is used, you may end up with nulls in places where perhaps you did not expect. symbol_get() and friends are currently used as hacks and we should slowly transform users to use a proper API and dependencies. > It doesn't mean the hardware can't go > away (hotplugged or unbound from the driver). The module should be > prepared for that. At the very least, it should handle errors from the > function and release the symbols, but it's probably a candidate for a > component driver. Indeed, one way is to set a simple regstration mechanism, if the resource is not registered then request_module() can be used. Luis