From: Arnd Bergmann <arnd@arndb.de>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>,
Liviu Dudau <Liviu.Dudau@arm.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Jingoo Han <jg1.han@samsung.com>,
Kukjin Kim <kgene.kim@samsung.com>,
Suravee Suthikulanit <suravee.suthikulpanit@amd.com>,
linux-pci <linux-pci@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
LAKML <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] drivers: pci: convert generic host controller to DT host bridge creation API
Date: Thu, 04 Sep 2014 16:05:53 +0200 [thread overview]
Message-ID: <6930538.Get2YiuMvJ@wuerfel> (raw)
In-Reply-To: <20140904133956.GA12351@e102568-lin.cambridge.arm.com>
On Thursday 04 September 2014 14:39:56 Lorenzo Pieralisi wrote:
> > > + if (!res_valid) {
> > > + dev_err(dev, "non-prefetchable memory resource required\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + if (iores) {
> > > + if (!PAGE_ALIGNED(io_cpuaddr))
> > > + return -EINVAL;
> >
> > Why is this alignment check not in the core code? Probably a question for
> > somebody like Arnd, but do we need to deal with multiple IO resources?
> > Currently we'll just silently take the last one that we found, which doesn't
> > sound ideal.
>
> (1) Yes, the alignment check should be made in core code
Makes sense. In theory we could support unaligned addresses (as long as
the offset in the page is the same for virtual and physical), but I don't
see why we should implement that unless some implementation absolutely
requires it.
> (2) I could take the first IO resource and warn on multiple IO resources if
> they are detected. Thoughts ?
I think we should either warn, or be reasonably sure that it will work.
Again, in theory this should work, but no sane hardware implementation
would do it like that.
> > > + if (err)
> > > + return err;
> > > + }
> > > +
> > > + /* Parse and map our Configuration Space windows */
> > > + err = gen_pci_parse_map_cfg_windows(host);
> > > + if (err)
> > > + return err;
> > > +
> > > + pci_add_flags(PCI_ENABLE_PROC_DOMAINS);
> > > + pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
> >
> > Why does this belong in the host controller driver and how does it interact
> > with the probe-only property?
>
> That's a very good question and it is one that confuses me too.
>
> Current code in pci_common_init_dev() sets PCI_REASSIGN_ALL_RSRC behind
> our backs silently. That flag has a side effect only if the probing code
> detects PCI bridges in the list of devices, since PCI core probing code
> will try to reassign the bus numbers upon PCI bridge detection IIUC. I do
> not think that PCI_REASSIGN_ALL_BUS has any side effect on ARM (by grepping
> around I noticed that PCI_REASSIGN_ALL_RSRC is used in
>
> pcibios_assign_all_busses()
>
> which in turn is triggered only if PCI bridges are detected, still grokking
> the code though).
Interesting point: the generic implementation should probably not default
to reassigning all buses at all. We could have a (host controller specific,
but with standardized name) DT property for it, but it would be best if
firmware already probes it to not have to do it again.
> Apart from the PCI_ENABLE_PROC_DOMAINS flag which I think it is safe to
> set by default (but let me check that too),
I think it should be enabled here, as no legacy machine will use this
driver.
> I *think* that setting of
>
> PCI_REASSIGN_ALL_BUS and PCI_REASSIGN_ALL_RSRC
>
> should be set by DT, as the probe-only flag is. At the moment this is not a
> problem (well...) since:
>
> (a) PCI_REASSIGN_ALL_RSRC is forced by pcibios on ARM
> (b) it has no implications on the generic host controller since it is
> run on kvmtools with no PCI bridge devices
>
> If Bjorn or Arnd can help me understand the complete reasoning behind
> those flags I would be very grateful and update code according to
> Liviu's v10.
I suspect they were just copied over to preserve the existing behavior.
Arnd
next prev parent reply other threads:[~2014-09-04 14:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-12 16:41 [PATCH] drivers: pci: convert generic host controller to DT host bridge creation API Liviu Dudau
2014-08-19 12:05 ` Will Deacon
2014-08-20 11:23 ` Arnd Bergmann
2014-09-04 13:39 ` Lorenzo Pieralisi
2014-09-04 14:05 ` Arnd Bergmann [this message]
2014-09-04 16:02 ` Lorenzo Pieralisi
2014-09-04 18:56 ` Arnd Bergmann
2014-08-20 11:27 ` Arnd Bergmann
2014-08-20 12:31 ` Liviu Dudau
2014-08-20 19:39 ` Arnd Bergmann
2014-08-21 23:07 ` Liviu Dudau
2014-08-20 22:35 ` Bjorn Helgaas
2014-08-21 18:02 ` Bjorn Helgaas
2014-08-21 22:13 ` Liviu Dudau
2014-08-21 23:01 ` Liviu Dudau
2014-08-22 5:13 ` Bjorn Helgaas
2014-08-22 12:32 ` Liviu Dudau
2014-08-22 15:27 ` 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=6930538.Get2YiuMvJ@wuerfel \
--to=arnd@arndb.de \
--cc=Catalin.Marinas@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=bhelgaas@google.com \
--cc=jg1.han@samsung.com \
--cc=kgene.kim@samsung.com \
--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=suravee.suthikulpanit@amd.com \
--cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox