All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Guenter Roeck <linux@roeck-us.net>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
	Will Deacon <Will.Deacon@arm.com>
Subject: Re: [PATCH] PCI: Only enable IO window if supported
Date: Thu, 25 Jun 2015 12:27:33 +0100	[thread overview]
Message-ID: <20150625112733.GA9733@red-moon> (raw)
In-Reply-To: <1435101283.3996.17.camel@kernel.crashing.org>

On Wed, Jun 24, 2015 at 12:14:43AM +0100, Benjamin Herrenschmidt wrote:
> On Tue, 2015-06-23 at 18:02 -0500, Bjorn Helgaas wrote:
> > On Tue, Jun 23, 2015 at 5:46 PM, Benjamin Herrenschmidt
> > <benh@kernel.crashing.org> wrote:
> > > On Tue, 2015-06-02 at 15:55 +0100, Lorenzo Pieralisi wrote:
> > >> While at it, do you think it is reasonable to also claim the bridge
> > >> windows (resources) in the respective pci_read_bridge_* calls ?
> > >
> > > No, don't claim in read. There's a clear distinction between gathering
> > > resources and claiming them, and we need to keep that.
> > >
> > > Some fixups might happen in between the two for example.
> > 
> > Are there any existing fixups like that?  Concrete examples would help
> > figure out the best way forward.
> 
> Not off the top of my mind, it's been a long time since I wrote the
> resource claiming stuff in arch/powerpc but it does make me nervous. We
> collect resources when probing and we claim in the survey, those have
> been historically very distinct steps.

Yes, that makes me nervous too, that's why I posted my patch as an
RFC/RFT, I think there is little debate in moving
pci_read_bridge_bases() to core PCI, claiming the resources is a
different question though, and I can't have the overall picture
since it _seems_ arch specific (I know Bjorn does not agree with
this though - it might be due to platform specific quirks) even if
it should not.

> > Most arches call pci_read_bridge_bases() from pcibios_fixup_bus().  I
> > think that's a poor place to do it because it's code that normally
> > doesn't have to be arch-specific.  Resource claiming is also usually
> > done from arch code, and it shouldn't be arch-specific either.
> 
> Claiming as in putting in the resource tree etc... is different from
> actually reading the values from the HW and is traditionally done much
> later, no ?
> 
> > If we move both the read and claim into generic code, then we might
> > need to make sure there's a fixup phase in between or something.
> 
> Well, then there's a more general argument to be made as to whether we
> want the claiming to be "merged" as part of the probing/reading I
> suppose...

On PROBE_ONLY systems (that are the systems I really wanted to cover
by claiming as soon as pci_read_bridge_bases() is executed) I think
we all agree that merging the claiming/reading is sane (but I also
think that Bjorn is not happy with that :), I mean it should not
be PROBE_ONLY dependent).

> Then there's also the case where everything gets fully reassigned, like
> powernv, where the "read" phase is really only about sizing device
> BARs...

Exactly, there claiming right after reading should not be a problem
either. How do you want me to proceed ? Should I make bridge resources
claiming in PCI core PROBE_ONLY ? Or move it to ARM specific hooks ?

I will certainly move pci_read_bridge_bases() to core code since this
changes nothing to current behaviour and must be consolidated
regardless.

Thoughts appreciated.

Thanks,
Lorenzo

  reply	other threads:[~2015-06-25 11:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-23  0:52 [PATCH] PCI: Only enable IO window if supported Guenter Roeck
2015-05-27 21:04 ` Bjorn Helgaas
2015-05-28  2:23   ` Guenter Roeck
2015-05-28 12:41     ` Bjorn Helgaas
2015-06-18 18:01       ` Guenter Roeck
2015-06-18 19:51         ` Bjorn Helgaas
2015-06-18 20:53           ` Guenter Roeck
2015-06-19 16:24         ` Lorenzo Pieralisi
2015-06-19 16:24           ` Lorenzo Pieralisi
2015-07-07 14:40           ` Lorenzo Pieralisi
2015-07-07 15:01             ` Guenter Roeck
2015-07-07 17:28               ` Lorenzo Pieralisi
2015-07-07 18:13                 ` Guenter Roeck
2015-06-02 14:55   ` Lorenzo Pieralisi
2015-06-02 16:32     ` Bjorn Helgaas
2015-06-02 17:02     ` Guenter Roeck
2015-06-02 19:58       ` Bjorn Helgaas
2015-06-03 15:15         ` Guenter Roeck
2015-06-03 10:32       ` Lorenzo Pieralisi
2015-06-03 15:12         ` Guenter Roeck
2015-06-03 16:55           ` Lorenzo Pieralisi
2015-06-03 18:07             ` Guenter Roeck
2015-06-23 22:46     ` Benjamin Herrenschmidt
2015-06-23 23:02       ` Bjorn Helgaas
2015-06-23 23:14         ` Benjamin Herrenschmidt
2015-06-25 11:27           ` Lorenzo Pieralisi [this message]
2015-07-08  8:38         ` 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=20150625112733.GA9733@red-moon \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=suravee.suthikulpanit@amd.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.