From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: "Jan Kundrát" <jan.kundrat@cesnet.cz>,
"Baruch Siach" <baruch@tkos.co.il>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Jason Cooper" <jason@lakedaemon.net>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Date: Mon, 24 Sep 2018 11:12:13 +0100 [thread overview]
Message-ID: <20180924101213.GO30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20180913104241.65db8243@windsurf>
On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundrát wrote:
> > On čtvrtek 13. září 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > > What about something like the below. I tested it, including the error
> > > case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
> > > after pci_unmap_iospace(). Actually, I would prefer to use
> > > pci_remap_iospace() and pci_unmap_iospace() but for now this API
> > > doesn't allow overloading the memory type used for the mapping.
> >
> > Thanks for providing this fix so quickly, Thomas. I can confirm that this
> > patch -- tested on top of 54eda9df17f3215b9ed16629ee71ea07413efdaf ("Merge
> > tag 'pci-v4.19-fixes-1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci"). Disclaimer: I
> > have zero familiarity with Linux' PCI code.
> >
> > Tested-by: Jan Kundrát <jan.kundrat@cesnet.cz>
>
> Thanks for the testing. I'll wait for Russell to say if he is happy
> (or not) with the addition of pci_unmap_io() in the ARM code, if that's
> the case, I'll send a proper patch to fix the issue.
I'd prefer not to provide an unmapping API, because it gives the
impression that it's okay to unmap the IO space mapping, and we'll
end up with drivers that decide to call it in their cleanup path.
IO space isn't expected to ever go away - eg, on a PC, it's always
present.
I've been toying with the idea of making pci_map_io() ignore
subsequent attempts to overwrite the mapping with an identical
mapping, and WARN() if there is an attempt to overwrite an existing
mapping with other physical address, but I'm not entirely happy
with that either (which is why I haven't responded sooner.)
At the moment, I don't have a way forward that I'm happy with for
this.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured"
Date: Mon, 24 Sep 2018 11:12:13 +0100 [thread overview]
Message-ID: <20180924101213.GO30658@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20180913104241.65db8243@windsurf>
On Thu, Sep 13, 2018 at 10:42:41AM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Thu, 13 Sep 2018 10:20:45 +0200, Jan Kundr?t wrote:
> > On ?tvrtek 13. z??? 2018 9:45:15 CEST, Thomas Petazzoni wrote:
> > > What about something like the below. I tested it, including the error
> > > case by forcing an -EPROBE_DEFER. The new pci_unmap_io() is modeled
> > > after pci_unmap_iospace(). Actually, I would prefer to use
> > > pci_remap_iospace() and pci_unmap_iospace() but for now this API
> > > doesn't allow overloading the memory type used for the mapping.
> >
> > Thanks for providing this fix so quickly, Thomas. I can confirm that this
> > patch -- tested on top of 54eda9df17f3215b9ed16629ee71ea07413efdaf ("Merge
> > tag 'pci-v4.19-fixes-1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci"). Disclaimer: I
> > have zero familiarity with Linux' PCI code.
> >
> > Tested-by: Jan Kundr?t <jan.kundrat@cesnet.cz>
>
> Thanks for the testing. I'll wait for Russell to say if he is happy
> (or not) with the addition of pci_unmap_io() in the ARM code, if that's
> the case, I'll send a proper patch to fix the issue.
I'd prefer not to provide an unmapping API, because it gives the
impression that it's okay to unmap the IO space mapping, and we'll
end up with drivers that decide to call it in their cleanup path.
IO space isn't expected to ever go away - eg, on a PC, it's always
present.
I've been toying with the idea of making pci_map_io() ignore
subsequent attempts to overwrite the mapping with an identical
mapping, and WARN() if there is an attempt to overwrite an existing
mapping with other physical address, but I'm not entirely happy
with that either (which is why I haven't responded sooner.)
At the moment, I don't have a way forward that I'm happy with for
this.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 13.8Mbps down 630kbps up
According to speedtest.net: 13Mbps down 490kbps up
next prev parent reply other threads:[~2018-09-24 10:12 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-12 16:11 [BISECTED] Regression: Solidrun Clearfog Base won't boot since "PCI: mvebu: Only remap I/O space if configured" Jan Kundrát
2018-09-12 16:11 ` Jan Kundrát
2018-09-12 16:11 ` Jan Kundrát
2018-09-12 18:49 ` Baruch Siach
2018-09-12 18:49 ` Baruch Siach
2018-09-12 18:49 ` Baruch Siach
2018-09-12 18:50 ` Thomas Petazzoni
2018-09-12 18:50 ` Thomas Petazzoni
2018-09-12 18:50 ` Thomas Petazzoni
2018-09-12 19:00 ` Jan Kundrát
2018-09-12 19:00 ` Jan Kundrát
2018-09-12 19:00 ` Jan Kundrát
2018-09-12 23:10 ` Russell King - ARM Linux
2018-09-12 23:10 ` Russell King - ARM Linux
2018-09-12 23:10 ` Russell King - ARM Linux
2018-09-13 3:19 ` Baruch Siach
2018-09-13 3:19 ` Baruch Siach
2018-09-13 3:19 ` Baruch Siach
2018-09-13 7:45 ` Thomas Petazzoni
2018-09-13 7:45 ` Thomas Petazzoni
2018-09-13 7:45 ` Thomas Petazzoni
2018-09-13 8:20 ` Jan Kundrát
2018-09-13 8:20 ` Jan Kundrát
2018-09-13 8:20 ` Jan Kundrát
2018-09-13 8:42 ` Thomas Petazzoni
2018-09-13 8:42 ` Thomas Petazzoni
2018-09-13 8:42 ` Thomas Petazzoni
2018-09-24 10:02 ` Jan Kundrát
2018-09-24 10:02 ` Jan Kundrát
2018-09-24 10:10 ` Thomas Petazzoni
2018-09-24 10:10 ` Thomas Petazzoni
2018-09-24 10:12 ` Russell King - ARM Linux [this message]
2018-09-24 10:12 ` Russell King - ARM Linux
2018-09-24 10:26 ` Thomas Petazzoni
2018-09-24 10:26 ` Thomas Petazzoni
2018-09-24 11:13 ` Russell King - ARM Linux
2018-09-24 11:13 ` Russell King - ARM Linux
2018-09-24 12:12 ` Thomas Petazzoni
2018-09-24 12:12 ` Thomas Petazzoni
2018-09-24 12:46 ` Lorenzo Pieralisi
2018-09-24 12:46 ` Lorenzo Pieralisi
2018-09-24 13:10 ` Thomas Petazzoni
2018-09-24 13:10 ` Thomas Petazzoni
2018-09-24 14:15 ` Lorenzo Pieralisi
2018-09-24 14:15 ` Lorenzo Pieralisi
2018-09-24 14:52 ` Thomas Petazzoni
2018-09-24 14:52 ` Thomas Petazzoni
2018-09-24 16:42 ` Lorenzo Pieralisi
2018-09-24 16:42 ` Lorenzo Pieralisi
2018-10-01 10:56 ` Jan Kundrát
2018-10-01 10:56 ` Jan Kundrát
2018-10-01 12:51 ` Thomas Petazzoni
2018-10-01 12:51 ` Thomas Petazzoni
2018-10-01 21:01 ` Bjorn Helgaas
2018-10-01 21:01 ` Bjorn Helgaas
2018-09-25 8:18 ` Andrew Murray
2018-09-25 8:18 ` Andrew Murray
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=20180924101213.GO30658@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=baruch@tkos.co.il \
--cc=bhelgaas@google.com \
--cc=jan.kundrat@cesnet.cz \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=thomas.petazzoni@bootlin.com \
/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.