All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Wroblewski <tomasz.wroblewski@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] Fix acpi_dmar_zap/reinstate() (fixes S3 regression)
Date: Tue, 22 Jan 2013 14:36:46 +0100	[thread overview]
Message-ID: <50FE95EE.207@citrix.com> (raw)
In-Reply-To: <50FE9B1802000078000B84A1@nat28.tlf.novell.com>

On 22/01/13 13:58, Jan Beulich wrote:

Jan, thanks for your comments

> I recognize the need of fixing this, but not this way. We have
> ioremap() now, and hence the patch could be using this,
> without re-running the whole acpi_get_table(), but just using
> the stored physical address of the table (retrieving of which
> would be the only real code addition needed here).
>
> For the older trees with non-functional ioremap(), I'd prefer
> simply adding the table range to the 1:1 mapping (thus making
> ioremap() work for that range, should use of that be needed;
> if not needed, that's certainly worth considering this even for
> -unstable).
>
> Also, with your change not even attempting to fix the underlying
> issue of the ACPI code storing a pointer to the mapped table in
> acpi_gbl_root_table_list.tables[].pointer, I can't even see how
> your patch is supposed to work. I'd expect the stored pointer to
> get re-used by acpi_get_table()/acpi_tb_verify_table(), and hence
> this shouldn't win you anything.
>    
It works because the existing code in acpi_get_table actually sets 
acpi_gbl_root_table_list.tables[i].pointer = NULL every call anyway 
(after setting *out_table pointer).

I'll have a go at trying this with ioremap() and retrievable table's 
physical pointer instead.

  reply	other threads:[~2013-01-22 13:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22 12:08 [PATCH] Fix acpi_dmar_zap/reinstate() (fixes S3 regression) Tomasz Wroblewski
2013-01-22 12:58 ` Jan Beulich
2013-01-22 13:36   ` Tomasz Wroblewski [this message]
2013-01-22 14:13     ` Jan Beulich
2013-01-22 15:27   ` Tomasz Wroblewski
2013-01-22 15:55     ` Jan Beulich
2013-01-22 17:22       ` [PATCH v3] " Tomasz Wroblewski
2013-01-23  8:47         ` Jan Beulich
2013-01-23  9:02           ` [PATCH v4] " Tomasz Wroblewski
2013-01-23  9:26             ` Jan Beulich

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=50FE95EE.207@citrix.com \
    --to=tomasz.wroblewski@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=xen-devel@lists.xen.org \
    /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.