> This attribute is a no-go. It is not even remotely related to hardware > monitoring, and thus must not be attached to the hwmon device. > > I don't know exactly where it belongs, but it appears to be related > to the keyboard. Its natural place therefore seems to be a keyboard driver. > We could possibly also attach it to the platform device, but there would > have to be some precedence of other drivers doing the same. Question > in that case though would be if this is just the first of many attributes > to come. If so, we would need to find a different solution. > > Guenter Sure! Should this driver with those changes go into a platform driver? Seems a better fit to me. The case against keyboard driver is the switch changes behaviour of the key but both the behaviour with the switch on and off is device defined. Some use the key as part of an AT Translated Keyboard and others just operate on the EC itself to grab the fan and set a special TDP for "Silent mode". For now this is the first such attribute found by the community and some talks with the manufacturer but it doesn't mean there wouldn't be others. Specially with such new form factors adding some "control panels" on Windows to set some hardware behaviour via EC writes. My goal is to allow those same functions to be available to linux users in a way some other userspace tools can serve as front ends. Would taking this same driver to the platform side be a solution to that going forward? It would be a combination of hwmon monitoring attributes and some other special functions with custom attributes. Seems a better fit to me. -- Joaquín I. Aramendía
