All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] Revert "arm64: PCI: Exclude ACPI "consumer" resources from host bridge windows"
Date: Thu, 27 May 2021 17:56:55 +0100	[thread overview]
Message-ID: <20210527165655.GA21788@lpieralisi> (raw)
In-Reply-To: <20210527163452.GA1402454@bjorn-Precision-5520>

On Thu, May 27, 2021 at 11:34:52AM -0500, Bjorn Helgaas wrote:

[...]

> > > https://lore.kernel.org/r/20210510234020.1330087-1-luzmaximilian@gmail.com
> > 
> > Sigh. We can't apply this patch since it would trigger regressions on
> > other platforms (IIUC the root complex registers would end up in the
> > host bridge memory windows).
> > 
> > I am not keen on reverting commit 8fd4391ee717 because it does the
> > right thing.
> > 
> > I think this requires a quirk and immediate reporting to Microsoft.
> > 
> > Bjorn, what are your thoughts on this ?
> 
> In retrospect, I think 8fd4391ee717 (which I wrote), was probably a
> mistake.
> 
> Sure, it's a nice idea to have PNP0A03 _CRS methods that work nicely
> as designed, by describing host bridge registers as "consumer"
> resources and host bridge windows as "producer" registers, instead of
> having the bridge registers in _CRS of an unrelated PNP0C02 device.
> 
> But realistically, the PNP0A03/PNP0C02 issue is a solved problem, even
> though it's ugly, and I'm not sure why I thought Microsoft would see
> value in doing this differently on arm64 than on x86 and ia64.

We hoped we could comply with the specs, given that we were starting
from a clean slate (and not from ACPI tables cut and paste)

> What would break if we reverted 8fd4391ee717?  I guess any arm64
> platforms that described host bridge register space in PNP0A03 _CRS
> "consumer" resources ?

Yes. We would end up with that register space in the host bridge memory
windows - this does not sound right.

> And Windows probably doesn't work or isn't supported on those
> platforms?

By the look of it the answer is yes, Windows was not bootstrapped on
those platforms given that I *assume* Windows does not discriminate
between producer and consumer resources at all.

Lorenzo

WARNING: multiple messages have this Message-ID (diff)
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Will Deacon <will@kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Maximilian Luz <luzmaximilian@gmail.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	linux-pci@vger.kernel.org, linux-acpi@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] Revert "arm64: PCI: Exclude ACPI "consumer" resources from host bridge windows"
Date: Thu, 27 May 2021 17:56:55 +0100	[thread overview]
Message-ID: <20210527165655.GA21788@lpieralisi> (raw)
In-Reply-To: <20210527163452.GA1402454@bjorn-Precision-5520>

On Thu, May 27, 2021 at 11:34:52AM -0500, Bjorn Helgaas wrote:

[...]

> > > https://lore.kernel.org/r/20210510234020.1330087-1-luzmaximilian@gmail.com
> > 
> > Sigh. We can't apply this patch since it would trigger regressions on
> > other platforms (IIUC the root complex registers would end up in the
> > host bridge memory windows).
> > 
> > I am not keen on reverting commit 8fd4391ee717 because it does the
> > right thing.
> > 
> > I think this requires a quirk and immediate reporting to Microsoft.
> > 
> > Bjorn, what are your thoughts on this ?
> 
> In retrospect, I think 8fd4391ee717 (which I wrote), was probably a
> mistake.
> 
> Sure, it's a nice idea to have PNP0A03 _CRS methods that work nicely
> as designed, by describing host bridge registers as "consumer"
> resources and host bridge windows as "producer" registers, instead of
> having the bridge registers in _CRS of an unrelated PNP0C02 device.
> 
> But realistically, the PNP0A03/PNP0C02 issue is a solved problem, even
> though it's ugly, and I'm not sure why I thought Microsoft would see
> value in doing this differently on arm64 than on x86 and ia64.

We hoped we could comply with the specs, given that we were starting
from a clean slate (and not from ACPI tables cut and paste)

> What would break if we reverted 8fd4391ee717?  I guess any arm64
> platforms that described host bridge register space in PNP0A03 _CRS
> "consumer" resources ?

Yes. We would end up with that register space in the host bridge memory
windows - this does not sound right.

> And Windows probably doesn't work or isn't supported on those
> platforms?

By the look of it the answer is yes, Windows was not bootstrapped on
those platforms given that I *assume* Windows does not discriminate
between producer and consumer resources at all.

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-27 16:57 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-10 23:40 [RFC PATCH] Revert "arm64: PCI: Exclude ACPI "consumer" resources from host bridge windows" Maximilian Luz
2021-05-10 23:40 ` Maximilian Luz
2021-05-26 20:58 ` Will Deacon
2021-05-26 20:58   ` Will Deacon
2021-05-27  9:32   ` Lorenzo Pieralisi
2021-05-27  9:32     ` Lorenzo Pieralisi
2021-05-27 11:31     ` Maximilian Luz
2021-05-27 11:31       ` Maximilian Luz
2021-05-27 16:34     ` Bjorn Helgaas
2021-05-27 16:34       ` Bjorn Helgaas
2021-05-27 16:56       ` Lorenzo Pieralisi [this message]
2021-05-27 16:56         ` Lorenzo Pieralisi

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=20210527165655.GA21788@lpieralisi \
    --to=lorenzo.pieralisi@arm.com \
    --cc=bhelgaas@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=helgaas@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=luzmaximilian@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=will@kernel.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.