Re: [PATCH 2/2] ACPICA: support Generic Address Structure bit_offset in acpi_read/write

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Thursday, November 17, 2011, Huang Ying wrote:
> On Thu, 2011-11-17 at 07:27 +0800, Rafael J. Wysocki wrote:
> > On Wednesday, November 16, 2011, Bjorn Helgaas wrote:
> > > On Tue, Nov 15, 2011 at 9:49 AM, Thomas Renninger <trenn@suse.de> wrote:
> > > > On Tuesday, November 15, 2011 04:13:15 PM Bjorn Helgaas wrote:
> > > >> On Fri, Nov 11, 2011 at 4:05 PM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > > >> > acpi_read(), acpi_write(), acpi_hw_read(), and acpi_hw_write() currently
> > > >> > ignore the GAS bit_offset field (but they do warn if it is non-zero).
> > > >> >
> > > >> > APEI tables are starting to use non-zero bit_offsets.  APEI uses
> > > >> > special-purpose apei_exec_read_register() and apei_exec_write_register()
> > > >> > interfaces that apply the bit_offset.
> > > >> >
> > > >> > This patch adds bit_offset support to the generic interfaces, which is
> > > >> > one small step toward using them instead of the special-purpose APEI ones.
> > > >>
> > > >> Eww, brown paper bag time.  Just pretend you never saw this lame
> > > >> implementation attempt.
> > > >>
> > > >> I do think we need to make acpi_read() smart enough to extract a bit
> > > >> field, but this try doesn't work.
> > > >
> > > > As a first step it would be great if Ying's and Myron's patches which
> > > > afaik conflict get serialized and pushed into an "acpi branch".
> > > > What the status there?
> > > 
> > > Ying's patch ("Add RAM mapping support") fixes a real issue with using
> > > EINJ, so we need to do something with it.
> > 
> > I kind of agree, but I wonder if page_is_ram() is the right check?
> 
> page_is_ram() is used by x86 ioremap implementation to exclude RAM
> range.  So I think it can be used here.

Except that ACPI is not going to be x86-specific any more in the (near?)
future.  Have you taken that into consideration?

Rafael