Currently all writes to the dev interface are done
by WriteStringToFd that uses char internally.
The current values seem to expect to be written as s32,
this sadly won't happen and triggers a special case in
the write handling of pm_qos_power_write:
it expects char buffers to be encoded as base16 and
decodes them.
This means the current 44 is actually 0x44 -> 68 seen by
the kernel.
Luckily it seems like both accepted values for this node
don't hit the threshold to enter C2, so it was never
noticed in real usage and didn't effect the device
C-States handling during hints.
Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com>
Change-Id: Ic544d4dcaa1edc3de913aed737baf1af88a45360
71ee92703e