On 8/27/21 11:47 AM, Daniel Dadap wrote:
On 8/25/21 5:26 PM, Daniel Dadap wrote:
On 8/24/21 5:47 PM, Barnabás Pőcze wrote:
Have you looked at `devm_backlight_device_register()`?
So regarding this suggestion, I have switched to
devm_backlight_device_register(), but now I can't unload the module;
it fails with EBUSY. I tried unbinding the device (via
/sys/class/backlight/wmaa_backlight/device/driver/unbind), but that
fails with ENODEV, maybe due to missing plumbing in wmi?
I'm not sure if it's expected for users to be able to unload their
backlight drivers; on the random selection of notebooks that I have
immediately available to me at the moment, the backlight driver is
registered by the GPU driver, and that tends to be not unloadable
because e.g. it's driving the console.
It's probably best to use devm_backlight_device_register() anyway
since it seems the ordinary backlight_device_register() is
deprecated, but I wanted to see if there were any strong opinions
about whether it would be a problem that the driver can't be unloaded.
Okay, actually, I *can* unbind the device; I was apparently pasting a
truncated GUID into the shell so it wasn't finding it. However, even
after successfully unbinding, I still can't unload the module; it
still fails with EBUSY, even if I explicitly call
devm_backlight_device_unregister() in a wmi_driver .remove callback. I
confirmed that .remove() is getting called when the device is unbound.
Sorry for the noise. It can be unloaded after unbinding if I *don't*
explicitly call devm_backlight_device_unregister() and leave the
.remove() callback unimplemented. I must have accidentally been
test-loading the wrong version of the kernel module in an earlier
experiment. So all does indeed seem to be well. I'll provide a revised
patch shortly, after some additional testing.
