> > No, writing trip-points is neither a fix, nor it is reasonable. > > It is a workaround at best, and it is a dangerous and mis-leading hack. > > > > The OS has no capability to actually change the ACPI trip points > > that are used by the BIOS. Changing the OS copy of them > > to make the user think that trip events will actually > > happen when the temperature crosses the OS copy is crazy. > > Aha... wait. It seemed to work for me when I enabled thermal > polling... That's exactly the point. If you allow a user to think they over-rode a trip-point but that trip point never fires unless they enable polling mode, then they're not going to get what they asked for. Yes, SuSE enables polling mode by default, but that is just distro specific "value add" that should eventually be fixed. > Slowing cpu down / shutdown / turn the fan on is done in the os after > all. Should we just start polling temperatures when user writes custom > trip points? I actually agree with you for passively cooled embedded systems. Indeed, that is the topic of one of my OLS papers. However, for an off-the-shelf laptop that the vendor ships with a specific active and passive cooling model, Linux is not currently set up to ignore what the vendor provided and go off on its own. Yes, it could be done, but for 99.99% of cases, I expect it would be a mistake. > > If there are systems with broken thermals and the > > ACPI thermal control needs and over-ride to turn > > on the fan, then that is fine -- but using > > fake trip-points and giving the user the impression > > that they are real is not viable. > > They become real when we fake _TSP, too, ..? We are mis-using _TSP today, and over-riding it is a hack on top of a bug... _TSP is only supposed to be for the passive cooling algorithm -- which by definition is polling based. It is not intended to be used for active cooling at all. That is what active trip were invented for... -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
