All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Thomas Renninger <trenn@suse.de>,
	Myron Stowe <myron.stowe@redhat.com>,
	Len Brown <len.brown@intel.com>,
	bondd@us.ibm.com, lenb@kernel.org, linux-acpi@vger.kernel.org,
	ying.huang@intel.com
Subject: Re: [PATCH 0/2] ACPI: Re-factor and remove ./drivers/acpi/atomicio.[ch]
Date: Sun, 6 Nov 2011 14:23:03 +0100	[thread overview]
Message-ID: <201111061423.03858.rjw@sisk.pl> (raw)
In-Reply-To: <CAErSpo5waF5Nz92d612tp60bV=oLNyb=yo1xh6_TMhGSvQ07tw@mail.gmail.com>

On Friday, October 28, 2011, Bjorn Helgaas wrote:
> On Thu, Oct 27, 2011 at 7:49 PM, Thomas Renninger <trenn@suse.de> wrote:
> > On Thursday 29 September 2011 23:59:08 Myron Stowe wrote:
> > ..
> >> Myron Stowe (2):
> >>       ACPI: Convert acpi_pre_map_gar()/acpi_atomic_read() and remove ./drivers/acpi/atomicio.[ch]
> >>       ACPI: Export interfaces for ioremapping/iounmapping ACPI registers
> >
> > Would be great to know whether these are going to be accepted.
> > If yes, this check should get removed as well:
> >
> > drivers/acpi/acpica/hwregs.c:
> > acpi_status
> > acpi_hw_validate_register(struct acpi_generic_address *reg,
> >                          u8 max_bit_width, u64 *address)
> > {
> > ...
> >        if (reg->bit_offset != 0) {
> >                ACPI_WARNING((AE_INFO,
> >                              "Unsupported register bit offset: 0x%X",
> >                              reg->bit_offset));
> >        }
> >
> > because APEI GAR declarations do use bit_offset != 0.
> 
> Half of this makes sense to me.  Myron's patch changes APEI from using
> acpi_atomic_read() (which doesn't call acpi_hw_validate_register()) to
> using acpi_read(), which *does* call it.  So after Myron's patch,
> we'll see warnings we didn't see before.
> 
> The part that doesn't make sense to me is just removing the warning.
> That warning looks to me like it's saying "oops, here's something we
> should support, but haven't implemented yet."  Wouldn't it be better
> to implement support for bit_offset in acpi_read() at the same time we
> remove the warning?  Then Myron could update his patch to drop the
> bit_offset support in __apei_exec_read_register() when converting to
> acpi_read().
> 
> If APEI uses bit_offset != 0, it's at least possible that other areas
> will use it in the future, and it'd be nicer to have all the support
> in acpi_read() rather than forcing APEI and others to each implement
> their own support for it.

Agreed.

Thanks,
Rafael

  parent reply	other threads:[~2011-11-06 13:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-29 21:59 [PATCH 0/2] ACPI: Re-factor and remove ./drivers/acpi/atomicio.[ch] Myron Stowe
2011-09-29 21:59 ` [PATCH 1/2] ACPI: Export interfaces for ioremapping/iounmapping ACPI registers Myron Stowe
2011-11-06 12:49   ` Rafael J. Wysocki
2011-09-29 21:59 ` [PATCH 2/2] ACPI: Convert acpi_pre_map_gar()/acpi_atomic_read() and remove ./drivers/acpi/atomicio.[ch] Myron Stowe
2011-11-06 13:05   ` Rafael J. Wysocki
2011-10-28  1:49 ` [PATCH 0/2] ACPI: Re-factor " Thomas Renninger
2011-10-28 15:03   ` Bjorn Helgaas
2011-10-31 10:47     ` Thomas Renninger
2011-11-03  1:42       ` Myron Stowe
2011-11-06 13:30         ` Rafael J. Wysocki
2011-11-04 23:54       ` Myron Stowe
2011-11-05  2:42         ` Thomas Renninger
2011-11-06 13:42           ` Rafael J. Wysocki
2011-11-15 18:45         ` Bjorn Helgaas
2011-11-06 13:25       ` Rafael J. Wysocki
2011-11-06 13:23     ` Rafael J. Wysocki [this message]
2011-10-28 15:14   ` Bjorn Helgaas
2011-10-31 10:33     ` Thomas Renninger
2011-10-31 15:51       ` Bjorn Helgaas
2011-11-03  9:16         ` Thomas Renninger
2011-11-03 13:53           ` Bjorn Helgaas
2011-11-03 16:18             ` Thomas Renninger
2011-11-03 16:44               ` Myron Stowe
2011-11-04  2:16                 ` Thomas Renninger
2011-11-04  1:55                   ` Myron Stowe
2011-10-28 22:40   ` Myron Stowe
2011-11-06 13:19   ` Rafael J. Wysocki
2011-11-03 16:31 ` Thomas Renninger
2011-11-04  0:56   ` Huang Ying
2011-11-04  2:24     ` Thomas Renninger
2011-11-04  1:32       ` Huang Ying

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201111061423.03858.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=bhelgaas@google.com \
    --cc=bondd@us.ibm.com \
    --cc=len.brown@intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=myron.stowe@redhat.com \
    --cc=trenn@suse.de \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.