On Thu, May 12, 2022 at 01:11:39PM -0700, Stephen Boyd wrote: > Quoting Stephen Boyd (2022-05-12 11:58:02) > > Quoting Dmitry Torokhov (2022-05-12 03:22:30) > > > > > > Have we solved module loading in the presence of multiple compatibles? > > > IIRC we only ever try to load module on the first compatible, so you'd > > > be breaking autoloading cros-ec-keyb on these older kernels. I think the > > > cure that is being proposed is worse than the disease. > > > > > > > The first compatible is still cros-ec-keyb in the driver though? Or you > > mean the first compatible in the node? I'm not aware of this problem at > > all but I can certainly test out a fake node and module and see if it > > gets autoloaded. > > I can't get this test module to fail to load no matter what I do. I > commented out the second match table entry, and kept it there and > removed 'vendor,switch-compat' from the DTS. Module still autoloads. > Ah, indeed, if the module contains both compatibles we will load it. It is broken when we have 2 or more modules and DT lists several compatibles for a device. OK, it looks like you feel very strongly regarding having a dedicated compatible. In this case please make sure that the compatible's behavior is properly documented (i.e. google,cros-ec-keyb compatible does not imply that there are *NO* switches, and users having buttons and switches in addition to matrix keys can also use google,cros-ec-keyb as a compatible for their device). We also need to mention that with the 2nd compatible the device still can report key/button events, it is simply that there is no matrix component. Should we call the other compatible google,cros-ec-bs? We should also abort binding the device if it specifies the new compatible, but EC does not report any buttons or switches. Thanks. -- Dmitry
