From: "Christian König" <deathsimple@vodafone.de>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Yinghai Lu <yinghai@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
David Miller <davem@davemloft.net>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Wei Yang <weiyang@linux.vnet.ibm.com>,
Khalid Aziz <khalid.aziz@oracle.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 11/13] PCI: Add has_mem64 for struct host_bridge
Date: Tue, 9 May 2017 13:38:25 +0200 [thread overview]
Message-ID: <0c80f9fb-652d-d5d2-4428-71fe08ee0e82@vodafone.de> (raw)
In-Reply-To: <20170508132504.GA18996@bhelgaas-glaptop.roam.corp.google.com>
Am 08.05.2017 um 15:25 schrieb Bjorn Helgaas:
> On Mon, May 08, 2017 at 10:54:55AM +0200, Christian König wrote:
>> Am 05.05.2017 um 01:04 schrieb Bjorn Helgaas:
>>> I *think* this will be broken by the current implementation of
>>> Christian's patch to enable a 64-bit host bridge window:
>>>
>>> https://lkml.kernel.org/r/1493890270-1188-5-git-send-email-deathsimple@vodafone.de
>>>
>>> because pci_register_host_bridge() runs before we scan the bus, and
>>> Christian's patch adds a quirk that runs when we enumerate the AMD
>>> host bridge device.
>>>
>>> If we apply this and Christian's patch, I think we could end up with
>>> a host bridge window above 4G, but with bridge->has_mem64 not set.
>> Yes, indeed. I can adjust my patch, but I would prefer not to do so.
>>
>> I don't completely understand the background of this change, but
>> from what I know how the BIOS (at least on X86) allocates resources
>> it doesn't sounds correct to me.
>>
>> Maybe we just need a Sparc specific quirk here instead of changing
>> the common logic?
> There's nothing in Yinghai's patch that's conceptually Sparc-specific,
> so I would prefer not to artificially tie it to Sparc.
That's possible, I would need to take a closer look on them which I
currently don't have time for.
It was more of a gut feeling considering that the current allocation
code already looks rather complex.
> One possibility would be to compute has_mem64 when we need it instead
> of caching it.
Sounds like a good idea to me as well. I mean the code using this isn't
time critical, isn't it?
And scanning the parent resources if a 64bit window can be found
shouldn't be much overhead.
Christian.
next prev parent reply other threads:[~2017-05-09 11:38 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-21 5:04 [PATCH 00/13] PCI: sparc related 64bit resource fixup Yinghai Lu
2017-04-21 5:04 ` [PATCH 01/13] sparc/PCI: Use correct offset for bus address to resource Yinghai Lu
2017-04-21 5:04 ` Yinghai Lu
2017-04-21 5:04 ` [PATCH 02/13] PCI: Add pci_find_bus_resource() Yinghai Lu
2017-04-21 5:04 ` [PATCH 03/13] sparc/PCI: Reserve legacy mmio after PCI mmio Yinghai Lu
2017-04-21 5:04 ` Yinghai Lu
2017-05-03 22:03 ` Bjorn Helgaas
2017-05-03 22:03 ` Bjorn Helgaas
2017-04-21 5:04 ` [PATCH 04/13] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing Yinghai Lu
2017-04-21 5:04 ` Yinghai Lu
2017-05-05 13:34 ` Bjorn Helgaas
2017-05-05 13:34 ` Bjorn Helgaas
2017-04-21 5:04 ` [PATCH 05/13] sparc/PCI: Keep resource idx order with bridge register number Yinghai Lu
2017-04-21 5:04 ` Yinghai Lu
2017-04-21 5:04 ` [PATCH 06/13] powerpc/PCI: " Yinghai Lu
2017-04-21 5:04 ` [PATCH 07/13] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing Yinghai Lu
2017-04-21 5:04 ` [PATCH 08/13] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource Yinghai Lu
2017-04-24 14:12 ` Rob Herring
2017-04-24 14:12 ` Rob Herring
2017-04-21 5:04 ` [PATCH 09/13] PCI: Check pref compatible bit for mem64 resource of PCIe device Yinghai Lu
2017-04-21 5:04 ` Yinghai Lu
2017-05-04 21:19 ` Bjorn Helgaas
2017-05-04 21:19 ` Bjorn Helgaas
2017-04-21 5:04 ` [PATCH 10/13] PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64 Yinghai Lu
2017-05-04 21:43 ` Bjorn Helgaas
2017-04-21 5:04 ` [PATCH 11/13] PCI: Add has_mem64 for struct host_bridge Yinghai Lu
2017-05-04 23:04 ` Bjorn Helgaas
2017-05-08 8:54 ` Christian König
2017-05-08 13:25 ` Bjorn Helgaas
2017-05-09 11:38 ` Christian König [this message]
2017-04-21 5:04 ` [PATCH 12/13] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64 Yinghai Lu
2017-04-21 5:05 ` [PATCH 13/13] PCI: Restore pref MMIO allocation logic for host bridge without mmio64 Yinghai Lu
2017-05-05 1:24 ` Bjorn Helgaas
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=0c80f9fb-652d-d5d2-4428-71fe08ee0e82@vodafone.de \
--to=deathsimple@vodafone.de \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=davem@davemloft.net \
--cc=helgaas@kernel.org \
--cc=khalid.aziz@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=weiyang@linux.vnet.ibm.com \
--cc=yinghai@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.