public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Ni, Ruiyu" <ruiyu.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	 Dong Wei <Dong.Wei@arm.com>,
	Benjamin Herrenschmidt <benh@au1.ibm.com>,
	Andrew Fish <afish@apple.com>
Subject: Re: [PATCH] MdeModulePkg/PciBusDxe: GetBarAttributes() returns Host address
Date: Tue, 12 Sep 2017 07:44:02 +0100	[thread overview]
Message-ID: <CAKv+Gu_N6pMNV2_mCB7BnmXPwbE2ce4ORyJseqZwGqmRuGq=6A@mail.gmail.com> (raw)
In-Reply-To: <734D49CCEBEEF84792F5B80ED585239D5BA2BABB@SHSMSX104.ccr.corp.intel.com>

On 12 September 2017 at 06:01, Ni, Ruiyu <ruiyu.ni@intel.com> wrote:
> Laszlo,
> Your understanding is: DeviceAddress = HostAddress + AddressTranslationOffset
> But my patch assumes: HostAddress = DeviceAddress + AddressTranslationOffset
>
> They are totally different. If I follow your understanding, the patch is wrong!
> Since UEFI spec doesn't describe "apply to" in sentence " Offset to apply to the
> Starting address of a BAR to convert it to a PCI address" very clearly, I quoted
> the statement from ACPI spec.
> Your understanding to "apply to" is "add", my understanding is "minus".
>

Even though we are stretching the ACPI definition of a QWord
descriptor beyond its original meaning, I don't think there is a lot
of ambiguity here, to be honest. The AddrRangeMin field contains the
address on the secondary side of a bridge, and the primary value can
be obtained by 'applying' the ATO. In my opinion, applying a (positive
or negative) offset implies addition, not subtraction, as subtraction
involves negating the second addend before applying it. And the
secondary side of the host bridge is clearly the PCI side. It does
mean the offset field is signed, though.

So I don't agree with the conclusion that no clarification is
required. We need to make sure the spec is crystal clear in this
regard. But I do agree with the change, I think it is the only
solution that makes sense.


  reply	other threads:[~2017-09-12  6:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-11  5:01 [PATCH] MdeModulePkg/PciBusDxe: GetBarAttributes() returns Host address Ruiyu Ni
2017-09-11  6:46 ` Laszlo Ersek
2017-09-12  4:32   ` Ard Biesheuvel
2017-09-12  5:01   ` Ni, Ruiyu
2017-09-12  6:44     ` Ard Biesheuvel [this message]
2017-09-12  8:40       ` Laszlo Ersek
2017-09-12 15:49         ` Ard Biesheuvel
2017-09-12 16:15           ` Laszlo Ersek
     [not found]             ` <1505259457.12628.157.camel@au1.ibm.com>
2017-09-13  3:07               ` Ni, Ruiyu

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-list 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='CAKv+Gu_N6pMNV2_mCB7BnmXPwbE2ce4ORyJseqZwGqmRuGq=6A@mail.gmail.com' \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox