If one looks at acpi_os_read_port() it is very similar to the acpi_os_read_memory() aside from the underlying I/O method. However we zero out the u32 in the former and not in the latter, when it seems prudent to do so in both.
This was found by quasi-random code inspection, and as such there is no known symptom or bug to associate with possibly having stale data in the high bits of "value". Signed-off-by: Paul Gortmaker <[email protected]> --- drivers/acpi/osl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index bad25b070fe0..a7373f1f31c8 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -953,6 +953,7 @@ acpi_os_read_memory(acpi_physical_address phys_addr, u64 *value, u32 width) if (!value) value = &dummy; + *value = 0; switch (width) { case 8: *(u8 *) value = readb(virt_addr); -- 1.9.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
