From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: "suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>, Will Deacon <Will.Deacon@arm.com>,
Liviu Dudau <Liviu.Dudau@arm.com>,
Krzysztof Halasa <khalasa@piap.pl>,
Phil Edworthy <phil.edworthy@renesas.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Jingoo Han <jg1.han@samsung.com>,
Russell King <linux@arm.linux.org.uk>,
Lucas Stach <l.stach@pengutronix.de>,
Simon Horman <horms@verge.net.au>,
Minghuan Lian <minghuan.Lian@freescale.com>,
Murali Karicheri <m-karicheri2@ti.com>,
Tanmay Inamdar <tinamdar@apm.com>,
Kishon Vijay Abraham I <kishon@ti.com>,
Thierry Reding <thierry.reding@gmail.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Jayachandran C <jchandra@broadcom.com>
Subject: Re: [RFC/RFT PATCH 2/2] ARM64: kernel: pci: implement PCI device resources claiming
Date: Wed, 20 May 2015 18:48:17 +0100 [thread overview]
Message-ID: <20150520174817.GA10750@red-moon> (raw)
In-Reply-To: <CAErSpo4OY+mm4R34_1DG5tb+tTJVGQbjuQ75esSF26LUzNWL9A@mail.gmail.com>
On Wed, May 20, 2015 at 02:02:52PM +0100, Bjorn Helgaas wrote:
[...]
> >> @@ -48,6 +48,11 @@ int pcibios_add_device(struct pci_dev *dev)
> >>
> >> dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >>
> >> + if (pci_has_flag(PCI_PROBE_ONLY) &&
> >
> > Does it really matter if PCI_PROBE_ONLY is set ?
> >
> >> + !pci_is_root_bus(dev->bus) &&
> >
> > This check is useless, since pci_read_bridge_bases checks that already.
> >
> >> + !pci_bridge_bases_is_read(dev->bus))
> >> + pci_read_bridge_bases(dev->bus);
> >> +
> >
> > Ok. Most of the archs do that in pcibios_fixup_bus, I would like to
> > understand:
> >
> > 1) Should we do it on PCI_PROBE_ONLY only
> > 2) Can we move this to generic code - ie pci_scan_child_bus (I guess answer
> > is no, because there are corner cases I am not aware of)
>
> In my opinion, we should call pci_read_bridge_bases() in all cases,
> regardless of PCI_PROBE_ONLY. pci_read_bridge_bases() doesn't
> *change* anything in the hardware; it only reads what's there. (It
> should attempt writes to learn whether I/O and prefetchable memory
> apertures are implemented, but those should be done as in
> pci_bridge_check_ranges(), where the original value is restored.)
>
> I also think this should be done in generic code, since there's
> nothing architecture-specific about bridge operation.
>
> I've been hoping to get rid of pcibios_fixup_bus() completely for
> years, and doing pci_read_bridge_bases() in generic code would be a
> big step.
I put together a patch to move it to pci_scan_child_bus, and to
remove it from almost all archs pcibios_fixup_bus implementations,
let's see how it goes.
> No doubt there are corner cases we'll trip over, but I'm not aware of them yet.
>
Let's find out :), posting tomorrow.
Thanks,
Lorenzo
WARNING: multiple messages have this Message-ID (diff)
From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC/RFT PATCH 2/2] ARM64: kernel: pci: implement PCI device resources claiming
Date: Wed, 20 May 2015 18:48:17 +0100 [thread overview]
Message-ID: <20150520174817.GA10750@red-moon> (raw)
In-Reply-To: <CAErSpo4OY+mm4R34_1DG5tb+tTJVGQbjuQ75esSF26LUzNWL9A@mail.gmail.com>
On Wed, May 20, 2015 at 02:02:52PM +0100, Bjorn Helgaas wrote:
[...]
> >> @@ -48,6 +48,11 @@ int pcibios_add_device(struct pci_dev *dev)
> >>
> >> dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> >>
> >> + if (pci_has_flag(PCI_PROBE_ONLY) &&
> >
> > Does it really matter if PCI_PROBE_ONLY is set ?
> >
> >> + !pci_is_root_bus(dev->bus) &&
> >
> > This check is useless, since pci_read_bridge_bases checks that already.
> >
> >> + !pci_bridge_bases_is_read(dev->bus))
> >> + pci_read_bridge_bases(dev->bus);
> >> +
> >
> > Ok. Most of the archs do that in pcibios_fixup_bus, I would like to
> > understand:
> >
> > 1) Should we do it on PCI_PROBE_ONLY only
> > 2) Can we move this to generic code - ie pci_scan_child_bus (I guess answer
> > is no, because there are corner cases I am not aware of)
>
> In my opinion, we should call pci_read_bridge_bases() in all cases,
> regardless of PCI_PROBE_ONLY. pci_read_bridge_bases() doesn't
> *change* anything in the hardware; it only reads what's there. (It
> should attempt writes to learn whether I/O and prefetchable memory
> apertures are implemented, but those should be done as in
> pci_bridge_check_ranges(), where the original value is restored.)
>
> I also think this should be done in generic code, since there's
> nothing architecture-specific about bridge operation.
>
> I've been hoping to get rid of pcibios_fixup_bus() completely for
> years, and doing pci_read_bridge_bases() in generic code would be a
> big step.
I put together a patch to move it to pci_scan_child_bus, and to
remove it from almost all archs pcibios_fixup_bus implementations,
let's see how it goes.
> No doubt there are corner cases we'll trip over, but I'm not aware of them yet.
>
Let's find out :), posting tomorrow.
Thanks,
Lorenzo
next prev parent reply other threads:[~2015-05-20 17:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-14 14:42 [RFC/RFT PATCH 1/2] ARM: kernel: bios32: implement PCI device resources claiming Lorenzo Pieralisi
2015-05-14 14:42 ` Lorenzo Pieralisi
2015-05-14 14:42 ` [RFC/RFT PATCH 2/2] ARM64: kernel: pci: " Lorenzo Pieralisi
2015-05-14 14:42 ` Lorenzo Pieralisi
2015-05-15 2:09 ` Suravee Suthikulanit
2015-05-15 2:09 ` Suravee Suthikulanit
2015-05-18 17:38 ` Lorenzo Pieralisi
2015-05-18 17:38 ` Lorenzo Pieralisi
2015-05-18 19:44 ` Suravee Suthikulanit
2015-05-18 19:44 ` Suravee Suthikulanit
2015-05-20 8:56 ` Lorenzo Pieralisi
2015-05-20 8:56 ` Lorenzo Pieralisi
2015-05-20 13:02 ` Bjorn Helgaas
2015-05-20 13:02 ` Bjorn Helgaas
2015-05-20 17:48 ` Lorenzo Pieralisi [this message]
2015-05-20 17:48 ` Lorenzo Pieralisi
2015-05-19 23:25 ` Bjorn Helgaas
2015-05-19 23:25 ` Bjorn Helgaas
2015-05-20 9:16 ` Lorenzo Pieralisi
2015-05-20 9:16 ` 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=20150520174817.GA10750@red-moon \
--to=lorenzo.pieralisi@arm.com \
--cc=Liviu.Dudau@arm.com \
--cc=Will.Deacon@arm.com \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=horms@verge.net.au \
--cc=jchandra@broadcom.com \
--cc=jg1.han@samsung.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=khalasa@piap.pl \
--cc=kishon@ti.com \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m-karicheri2@ti.com \
--cc=minghuan.Lian@freescale.com \
--cc=phil.edworthy@renesas.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=thierry.reding@gmail.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=tinamdar@apm.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.