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 <paul.gortmaker@xxxxxxxxxxxxx>
---
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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
