> > > > Since it's not mentioned I can only guess your firmware implementation > associated > > with this code. I would think for example that touching some PLx related > MSR or > > possibly RAPL interface might cause unexpected behaviors. > > > > Assuming that's right kernel lockdown might prevent some of the MSR, but > if you really > > want user fully in control of this decision by one knob, you shouldn't > let common > > userspace tools like thermald, tuned, tlp or the like touch the related > objects. > > > Hmmm - I think I disagree here. > > I don't think this should control what other userspace tools (like > thermald) want to do with the CPU registers. Adding hooks into those > other pieces of code also seems to me to be complicated and unnecessary > in the kernel (and way beyond the scope of this patch). As an aside - my > experience from testing is that thermald will override what the firmware > is doing anyway. I'm actually in agreement it is potentially quite complicated and shouldn't be in this specific patch. I was going to suggest it should either come as other patches, or perhaps in documentation along the lines of "Users using this interface should not use other tools to modify X, Y and Z". No need to mention the actual tools, but you should try to help prevent users shooting themselves in the foot unintentionally. > > I can see the value of adding a feature to *disable* the Lenovo firmware > implementation as that doesn't currently exist. I will talk to the > firmware team and see what can be done and take that on as a separate > task. If there's a mechanism to do that already in a safe way then I'll > add that to this. This is actually even better to me. Back to the H/M/L approach if you can have an extra one for "off" then userspace tools that want to control the same levers can turn this off when they are taking control. _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
