[Nexus 6  Original Android Development] bbedward:
Each row represents an array essentially, but if you specify something like 3 values for thresholds you need to specify 3 threshold_clr and 3 actions and 3 action parameters.

It's hard for me to say how the thermal engine behaves if you specify something wrong. Ideally you would assume that the parser is smart enough to handle things done incorrectly - and that the service itself is smart enough to have fallback for critical things if they are missing (I don't trust QC enough to assume that's the case), but it's impossible to say without guessing unless we saw the thermal-engine source (this is the service that's in the userspace - not in the kernel). Remember this is a qualcomm piece of software, and because /system is always mounted read-only in android (unless you access it with root access or through a custom recovery) they possibly didn't spend a lot of time working out error handling with respect to user error - because it's not something a user would ordinarily change.

Other Stuff:

Moto is cheap: (and so is everyone else). When it comes to a power supply there's more to it than just a battery - there's regulators, surge-protecting capacitors, protecting diodes, current sensors, etc. Each component in the device doesn't care about these things - they just draw a certain current. The cheapness comes in to play in that Motorola or any manufacturer is not going to bother building a power supply that's more than needed. In the case of the nexus 6 it appears that what they have is "just enough"

Battery efficiency degrades as it discharges. This certainly varies from battery to battery, but the faster the battery is discharging - the less ability it has to provide the required charge to power the device

Recall that there was a huge slurry of random reboot issues reported after the Nexus 6 launch. Something that occured apparently entirely at random, that didn't result from any sort of kernel panic - apparently simply the battery couldn't supply current demanded, so some current-limiting protection or a diode went into reverse bias and just cut the power (I can't say exactly because I didn't design the device).

The issue of unexplained random-rebooting seems to be almost entirely resolved in 5.1. The likely reason: the addition to the thermal-config-shamu file that restricts the maximum frequency, at 40% battery, to ~2.2GHz.

In short, it doesn't matter where you change this behavior. Changing the configuration file that directly communicates to the kernel ioctl is just as good as any kernel solution. The problem with a kernel solution is it goes through the same userspace process as thermal-related throttling. There are ways to block it in the kernel, but it is not configurable and not adjustable. It's more of an on/off type of thing.

Every device is different (different manufacturing tolerances). The majority of users probably had no issues with reboots or supply issues when they didn't have any throttling (until ~20%) on 5.0. But for the ones that did the only thing they could be told was to RMA their device.

I personally think google did the throttle at 40% to make up for a crummy power supply, rather than to gain an extra few minutes of battery life.

Also, there is no active hotplugging on 5.1 (Except for at something like 15% battery and while the device is sleeping - but not ACTIVE hotplugging). This could also be part of the reason why they added the 40% throttle, because when the cores are online all the time there's going to be more active draw from the power supply.