From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752417AbcEZQ06 (ORCPT ); Thu, 26 May 2016 12:26:58 -0400 Received: from prv-mh.provo.novell.com ([137.65.248.74]:56107 "EHLO prv-mh.provo.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750906AbcEZQ05 convert rfc822-to-8bit (ORCPT ); Thu, 26 May 2016 12:26:57 -0400 Message-Id: <574731DD02000078000E92FC@prv-mh.provo.novell.com> X-Mailer: Novell GroupWise Internet Agent 14.2.0 Date: Thu, 26 May 2016 10:26:53 -0600 From: "Jan Beulich" To: Cc: , , , , , , , , , Subject: Re: [PATCH v2 08/13] ACPICA: Hardware: Add optimized access bit width support References: <5745FA2C.8020303@oracle.com> In-Reply-To: <5745FA2C.8020303@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8BIT Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >>> Boris Ostrovsky 05/25/16 9:17 PM >>> >On 05/05/2016 12:58 AM, Lv Zheng wrote: >> +static u8 >> +acpi_hw_get_access_bit_width(struct acpi_generic_address *reg, u8 max_bit_width) >> +{ >> + u64 address; >> + >> + if (!reg->access_width) { >> + /* >> + * Detect old register descriptors where only the bit_width field >> + * makes senses. The target address is copied to handle possible >> + * alignment issues. >> + */ >> + ACPI_MOVE_64_TO_64(&address, ®->address); >> + if (!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)) { >> + return (reg->bit_width); >> + } else { >> + if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_IO) { >> + return (32); > >This (together with "... Add access_width/bit_offset support in >acpi_hw_write") breaks Xen guests using older QEMU which doesn't support >4-byte IO accesses. > >Why not return "reg->bit_width?:max_bit_width" ? This will preserve >original behavior. Did you figure out why we get here in the first place, instead of taking the first "return"? I.e. isn't the issue the apparently wrong use of the second ACPI_IS_ALIGNED() above? Afaict it ought to be ACPI_IS_ALIGNED(address, reg->bit_width / 8)... Jan