[PATCH i-g-t 2/2] lib/igt_kmod: Do not explicitly unload intel mei driver
Luis Chamberlain
mcgrof at kernel.org
Fri Jan 3 18:54:20 UTC 2025
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
More information about the igt-dev
mailing list