summaryrefslogtreecommitdiff
path: root/drivers
diff options
context:
space:
mode:
authorLv Zheng <lv.zheng@intel.com>2016-06-01 11:03:20 +0800
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>2016-06-01 22:44:22 +0200
commit7f9bef9debafcb767d00efb177d0f2edd4940eab (patch)
tree37aa6a6b767b52ab30339404a86b45f57b8cfe0b /drivers
parentd1ce3bb95511dacf8b9eea899c421f1b18a3ef6a (diff)
ACPICA / Hardware: Fix old register check in acpi_hw_get_access_bit_width()
The address check in acpi_hw_get_access_bit_width() should be byte width based, not bit width based. This patch fixes this mistake. For those who want to review acpi_hw_access_bit_width(), here is the concerns and the design details of the function: It is supposed that the GAS Address field should be aligned to the byte width indicated by the GAS AccessSize field. Similarly, for the old non GAS register, it is supposed that its Address should be aligned to its Length. For the "AccessSize = 0 (meaning ANY)" case, we try to return the maximum instruction width (64 for MMIO or 32 for PIO) or the user expected access bit width (64 for acpi_read()/acpi_write() or 32 for acpi_hw_read()/ acpi_hw_write()) and it is supposed that the GAS Address field should always be aligned to the maximum expected access bit width (otherwise it can't be accessed using ANY access bit width). The problem is in acpi_tb_init_generic_address(), where the non GAS register's Length is converted into the GAS BitWidth field, its Address is converted into the GAS Address field, and the GAS AccessSize field is left 0 but most of the registers actually cannot be accessed using "ANY" accesses. As a conclusion, when AccessSize = 0 (ANY), the Address should either be aligned to the BitWidth (wrong conversion) or aligned to 32 for PIO or 64 for MMIO (real GAS). Since currently, max_bit_width is 32, then: 1. BitWidth for the wrong conversion is 8,16,32; and 2. The Address of the real GAS should always be aligned to 8,16,32. The address alignment check to exclude false matched real GAS is not necessary. Thus this patch fixes the issue by removing the address alignment check. On the other hand, we in fact could use a simpler check of "reg->bit_width < max_bit_width" to exclude the "BitWidth=64 PIO" case that may be issued from acpi_read()/acpi_write() in the future. Fixes: b314a172ee96 (ACPICA: Hardware: Add optimized access bit width support) Reported-and-tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by: Mike Marshall <hubcap@omnibond.com> Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'drivers')
-rw-r--r--drivers/acpi/acpica/hwregs.c23
1 files changed, 9 insertions, 14 deletions
diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index 0f18dbc9a37f..daceb80022b0 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -83,27 +83,22 @@ acpi_hw_write_multiple(u32 value,
static u8
acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 max_bit_width)
{
- u64 address;
-
if (!reg->access_width) {
+ if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
+ max_bit_width = 32;
+ }
+
/*
* Detect old register descriptors where only the bit_width field
- * makes senses. The target address is copied to handle possible
- * alignment issues.
+ * makes senses.
*/
- ACPI_MOVE_64_TO_64(&address, &reg->address);
- if (!reg->bit_offset && reg->bit_width &&
+ if (reg->bit_width < max_bit_width &&
+ !reg->bit_offset && reg->bit_width &&
ACPI_IS_POWER_OF_TWO(reg->bit_width) &&
- ACPI_IS_ALIGNED(reg->bit_width, 8) &&
- ACPI_IS_ALIGNED(address, reg->bit_width)) {
+ ACPI_IS_ALIGNED(reg->bit_width, 8)) {
return (reg->bit_width);
- } else {
- if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) {
- return (32);
- } else {
- return (max_bit_width);
- }
}
+ return (max_bit_width);
} else {
return (1 << (reg->access_width + 2));
}