Loop Dell Client Kernel M/B for any comments.
On 11/18/2024 21:47, Kurt Borja wrote:
Hi!
I'm planning on migrating the alienware-wmi driver to the new WMI
interface, as it's currently using the deprecated one.
🎉
My plan is to:
rename alienware-wmi.c -> alienware-wmi-base.c
create alienware-wmi.h
create alienware-wmi-legacy
create alienware-wmi-wmax
The last two files would not be independent modules, just includes for
the base module. The base module would be in charge of initializing the
platform driver plus the correct wmi_driver backend, but the wmi probes
would register the platform device. This would be very similar to what
other dell drivers already do. Aditionally I want to migrate everything
to the state container design pattern.
I would do this in such a way that the legacy and new code would be
completely independent of each other (i.e. different state containters,
dmi checks, etc).
As the original author of this driver when I was at Dell I'll add some
comments.
The 'legacy' code was very narrowly focused for supporting a handful of
hardware specifically for lighting control. One was the original
Alienware steam machine, and then a few generations of the X51.
I don't know how much of the driver continues to work on hardware since
then. Maybe Dell guys I added to CC can comment on how much of this has
stuck around over the years and keeps working.
Pros:
- Modern interfaces and design patterns
- This is compatible with Mario's upcoming platform profile changes as
the WMAX device would hold a reference to the platform device
- Would not break compatibility as legacy code is independent
- Easier to understand and develop in the future
Cons:
- Initialy alienware-wmi-base.c would be almost completely legacy code,
as new features don't require a platform device (yet), so
alienware-wmi-base would basically just register the wmax wmi driver
on newer machines
- With this design users would not be able to completely exclude legacy
code with CONFIG parameters
I wonder if you're better off just having the legacy driver as it's own
kernel object? If it only supports a handful of systems, most people
won't need it compiled.
After this I want to add HWMON and sparse keymap capabilities to the
wmax interface.
🎉
I'm sure there are things I'm not seeing so feedback is greatly
appreciated!
Regards,
Kurt
