[PATCH v6 0/5] PCI: Unify ECAM constants in native PCI Express drivers
helgaas at kernel.org
Wed Dec 9 17:05:30 EST 2020
On Wed, Dec 09, 2020 at 11:43:59PM +0200, Vladimir Oltean wrote:
> On Wed, Dec 09, 2020 at 03:34:49PM -0600, Bjorn Helgaas wrote:
> > On Wed, Dec 09, 2020 at 11:20:17PM +0200, Vladimir Oltean wrote:
> > > On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote:
> > > > Yep, that's the theory. Thanks for testing it!
> > >
> > > Testing what? I'm not following.
> > You posted a patch that you said fixed the bug for you. The fix is
> > exactly the theory we've been discussing, so you have already verified
> > that the theory is correct.
> > I'm sure Krzysztof will update his patch, and we'll get this tidied up
> > in -next again.
> If you were discussing this already, I missed it. I was copied to this
> thread out of the blue two emails ago. I also looked at the full thread
> on patchwork, I don't see anything being said about the culprit being
> the size of the config space mapping.
Oh, sorry, this was an IRC discussion on #linux-pci (OFTC):
10:51 AM <bjorn_> so the fault is on the first read for 00:00.1. forget my noise about extracting the device/func from the *virtual* address. the *physical* address is supposed to be aligned so you can do that, but not the virtual address
10:55 AM <bjorn_> kwilczynski: oh, i think i see it: pci_ecam_create() does "bsz = 1 << ops->bus_shift", but we removed .bus_shift for this case
10:55 AM <bjorn_> needs to default to 20 if it's not specified
10:56 AM <bjorn_> result is that we only map one page of the ECAM space, so we fault when we access the second page (which is where 00:00.1 starts)
Anyway, thanks very much again for fixing this and confirming the fix!
More information about the linux-arm-kernel