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
next prev parent 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: linkBe 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.