Remove the node from the DT. If I can verify that the platforms using this DT have CrosECs that support the discoverability, then this seems a reasonable option. The DT is supposed to describe devices that can't be discovered otherwise.
Add the keyboard backlight driver's compatible to the compatible_ignore_list in the test. The reasoning would be that we can't expect it to be probed through the DT since it might be probed through MFD instead.
Extend the dt-extract-compatible script to ignore all compatibles that might be probed through MFD (ie ignore if the driver name appears in a struct mfd_cell). Should check first if there even are enough devices in this situation to justify the added complexity in the script.
There's a regression on a DT kselftest case on MT8195-Tomato (https://lava.collabora.dev/scheduler/job/14714396):
But the log shows the keyboard backlight is still there:
Starting [0;1;39msystemd-backlight…of leds:chromeos::kbd_backlight...
.It is caused by this series: https://lore.kernel.org/all/20240526-cros_ec-kbd-led-framework-v3-0-ee577415a521@weissschuh.net/ , which allowed the keyboard backlight to be discovered through communication with the ChromeOS EC and probed through a separate device instantiated by the MFD framework, hence the device created for the DT node goes unused (and unprobed).
I see a few options:
compatible_ignore_list
in the test. The reasoning would be that we can't expect it to be probed through the DT since it might be probed through MFD instead.dt-extract-compatible
script to ignore all compatibles that might be probed through MFD (ie ignore if the driver name appears in astruct mfd_cell
). Should check first if there even are enough devices in this situation to justify the added complexity in the script.