Using a u64 here creates an endian bug.  We store a u32 number in the
top byte which is a larger number than intended on big endian systems.
There is no reason to use a 64 bit data type here, I guess it was just
an oversight.
I removed the initialization to zero as well.  It's needed with a u64
but with a u32, the variable gets initialized properly inside the call
to acpi_os_read_port().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Len Brown <len.brown@intel.com>
                                        u64 *value)
 {
        u32 bit_width, bit_offset;
-       u64 ptc_value;
+       u32 ptc_value;
        u64 ptc_mask;
        struct acpi_processor_throttling *throttling;
        int ret = -1;
        throttling = &pr->throttling;
        switch (throttling->status_register.space_id) {
        case ACPI_ADR_SPACE_SYSTEM_IO:
-               ptc_value = 0;
                bit_width = throttling->status_register.bit_width;
                bit_offset = throttling->status_register.bit_offset;
 
                acpi_os_read_port((acpi_io_address) throttling->status_register.
-                                 address, (u32 *) &ptc_value,
+                                 address, &ptc_value,
                                  (u32) (bit_width + bit_offset));
                ptc_mask = (1 << bit_width) - 1;
                *value = (u64) ((ptc_value >> bit_offset) & ptc_mask);