* [PATCH 09/13] PCI, shpchp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/shpchp_pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/shpchp_pci.c b/drivers/pci/hotplug/shpchp_pci.c
index 2bf69fe..ea8ad31 100644
--- a/drivers/pci/hotplug/shpchp_pci.c
+++ b/drivers/pci/hotplug/shpchp_pci.c
@@ -64,8 +64,7 @@ int __ref shpchp_configure_device(struct slot *p_slot)
list_for_each_entry(dev, &parent->devices, bus_list) {
if (PCI_SLOT(dev->devfn) != p_slot->device)
continue;
- if ((dev->hdr_type == PCI_HEADER_TYPE_BRIDGE) ||
- (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS))
+ if (pci_is_bridge(dev))
pci_hp_add_bridge(dev);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 05/13] IA64/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-04-25 9:18 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, linux-kernel, Yijing Wang, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1398417515-8740-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/ia64/pci/fixup.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/ia64/pci/fixup.c b/arch/ia64/pci/fixup.c
index eee069a..1fe9aa5 100644
--- a/arch/ia64/pci/fixup.c
+++ b/arch/ia64/pci/fixup.c
@@ -49,9 +49,7 @@ static void pci_fixup_video(struct pci_dev *pdev)
* type BRIDGE, or CARDBUS. Host to PCI controllers use
* PCI header type NORMAL.
*/
- if (bridge
- &&((bridge->hdr_type == PCI_HEADER_TYPE_BRIDGE)
- ||(bridge->hdr_type == PCI_HEADER_TYPE_CARDBUS))) {
+ if (bridge && (pci_is_bridge(bridge))) {
pci_read_config_word(bridge, PCI_BRIDGE_CONTROL,
&config);
if (!(config & PCI_BRIDGE_CTL_VGA))
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Russell King - ARM Linux @ 2014-04-25 9:03 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <CAPDyKFr=2=dg1NTYb1_EAgxXZq2Rd+o2Q2B5TE+GZwr8MUU1_Q@mail.gmail.com>
On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:57, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > This is nothing new or unexpected - it was last posted back in February,
> > and I elected that it should be held off until after the last merge
> > window.
> >
> > Unfortunately, I didn't have time to post it immediately after the merge
> > window closed, partly because it needed to be rebased on top of tglx's
> > IRQ changes on which it depends. I was carrying those as separate commits
> > to the ones Thomas was carrying in his tree - and in the event, Thomas had
> > modified his patches slightly between sending me copies of them and the
> > versions he sent during the merge window.
>
> Okay, so let's keep up the frequency here then. I only had some minor
> comments, please fix them and send a v2.
Right, so I've updated the patches, and added one ack to one patch.
That seems insufficient to me - the only platform these have been
tested on is iMX6, which is sdhci-esdhc-imx.c.
They _really_ need testing elsewhere too. Or is the plan to merge
them and then see about getting people to test them and fix them up
afterwards?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization for platform
From: Scott Wood @ 2014-04-24 18:47 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org, haokexin@gmail.com,
Kushwaha Prabhakar-B32579, Jin Zhengxiong-R64188
In-Reply-To: <1398365188.7841.154.camel@snotra.buserror.net>
On Thu, 2014-04-24 at 13:46 -0500, Scott Wood wrote:
> On Thu, 2014-04-24 at 01:43 -0500, Wang Dongsheng-B40534 wrote:
> >
> > > -----Original Message-----
> > > From: Wood Scott-B07421
> > > Sent: Thursday, April 17, 2014 3:36 AM
> > > To: Wang Dongsheng-B40534
> > > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha Prabhakar-B32579;
> > > linuxppc-dev@lists.ozlabs.org
> > > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization
> > > for platform
> > >
> > > On Tue, 2014-04-15 at 21:58 -0500, Wang Dongsheng-B40534 wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Wood Scott-B07421
> > > > > Sent: Wednesday, April 16, 2014 3:39 AM
> > > > > To: Wang Dongsheng-B40534
> > > > > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha
> > > > > Prabhakar-B32579; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular
> > > > > initialization for platform
> > > > >
> > > > > On Tue, 2014-04-15 at 13:53 +0800, Dongsheng Wang wrote:
> > > > > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > > >
> > > > > > Corenet_generic is a generic platform initialization. Those based
> > > > > > on the corenet_generic board maybe need a particular initialize to
> > > > > > enable/set some IP-Blocks. So add "Fix Generic Initialization" to
> > > > > > solve this kind of special cases.
> > > > >
> > > > > I still don't understand what you mean by "fix". What are you
> > > > > fixing, or what is fixed?
> > > > >
> > > > > There is no need for adding an infrastructure layer here. Just add
> > > > > a new piece of code for t104x diu, and have it be called by an
> > > > > appropriate initfunc.
> > > > >
> > > >
> > > > "fix" is means to handle some boards those based on corenet_generic
> > > > config file, But those boards may need some special handle. Perhaps
> > > > these used to handle special feature codes not have an appropriate
> > > > initfunc we cannot *just find* an appropriate place,
> > >
> > > I'm not asking you to "just find" anything. I'm asking you to add an initfunc
> > > in a standalone file.
> > >
> > > > if more and more boards need to do this, at that time maybe *initfunc*
> > > > looks very complicated.
> > >
> > > They would each have their own initfunc. There is no reason to tie this in with
> > > anything else.
> > >
> >
> > Sorry, if those platforms are using corenet_generic, I don’t see any standalone file
> > for initfunc of platform. That's why I'm adding "fix" layer.
>
> It's totally unnecessary.
>
> Just do this:
>
> t104x_diu_init(void)
> {
s/t104x_diu_init/static void t104x_diu_init/ of course.
-Scott
^ permalink raw reply
* Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization for platform
From: Scott Wood @ 2014-04-24 18:46 UTC (permalink / raw)
To: Wang Dongsheng-B40534
Cc: linuxppc-dev@lists.ozlabs.org, haokexin@gmail.com,
Kushwaha Prabhakar-B32579, Jin Zhengxiong-R64188
In-Reply-To: <30c9d29df995426d9e01ffdf09fb1f33@BN1PR03MB188.namprd03.prod.outlook.com>
On Thu, 2014-04-24 at 01:43 -0500, Wang Dongsheng-B40534 wrote:
>
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, April 17, 2014 3:36 AM
> > To: Wang Dongsheng-B40534
> > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha Prabhakar-B32579;
> > linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular initialization
> > for platform
> >
> > On Tue, 2014-04-15 at 21:58 -0500, Wang Dongsheng-B40534 wrote:
> > >
> > > > -----Original Message-----
> > > > From: Wood Scott-B07421
> > > > Sent: Wednesday, April 16, 2014 3:39 AM
> > > > To: Wang Dongsheng-B40534
> > > > Cc: Jin Zhengxiong-R64188; haokexin@gmail.com; Kushwaha
> > > > Prabhakar-B32579; linuxppc-dev@lists.ozlabs.org
> > > > Subject: Re: [PATCH v2 1/2] fsl/corenet_generic: add a particular
> > > > initialization for platform
> > > >
> > > > On Tue, 2014-04-15 at 13:53 +0800, Dongsheng Wang wrote:
> > > > > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> > > > >
> > > > > Corenet_generic is a generic platform initialization. Those based
> > > > > on the corenet_generic board maybe need a particular initialize to
> > > > > enable/set some IP-Blocks. So add "Fix Generic Initialization" to
> > > > > solve this kind of special cases.
> > > >
> > > > I still don't understand what you mean by "fix". What are you
> > > > fixing, or what is fixed?
> > > >
> > > > There is no need for adding an infrastructure layer here. Just add
> > > > a new piece of code for t104x diu, and have it be called by an
> > > > appropriate initfunc.
> > > >
> > >
> > > "fix" is means to handle some boards those based on corenet_generic
> > > config file, But those boards may need some special handle. Perhaps
> > > these used to handle special feature codes not have an appropriate
> > > initfunc we cannot *just find* an appropriate place,
> >
> > I'm not asking you to "just find" anything. I'm asking you to add an initfunc
> > in a standalone file.
> >
> > > if more and more boards need to do this, at that time maybe *initfunc*
> > > looks very complicated.
> >
> > They would each have their own initfunc. There is no reason to tie this in with
> > anything else.
> >
>
> Sorry, if those platforms are using corenet_generic, I don’t see any standalone file
> for initfunc of platform. That's why I'm adding "fix" layer.
It's totally unnecessary.
Just do this:
t104x_diu_init(void)
{
if (t104x diu not in the device tree)
return;
...
}
early_initcall(t104x_diu_init);
> > > > > +config FIX_GENERIC_PLATFORM_INIT
> > > > > + bool "Fix Generic Initialization"
> > > > > + depends on CORENET_GENERIC
> > > >
> > > > Why does this depend on CORENET_GENERIC?
> > > >
> > >
> > > Because CORENET_GENERIC is a multiboards file, This is designed to handle this
> > situation.
> >
> > This DIU code is going to be just as applicable to a custom T104x board which
> > may or may not use CORENET_GENERIC.
> >
>
> "fix" is a middle layer, it's not only for T104xrdb-DIU.
My point is a custom t104x board might not use CORENET_GENERIC.
> > > > > + default y
> > > >
> > > > No.
> > > >
> > >
> > > Why not? This will not increase any redundant operations if there is not any
> > boards need fix.
> > > You can see my fix.c code.
> >
> > default y should not be used for hardware specific code.
> >
>
> fix.c and hardware no relationship at all. :), It's just a software layer.
No relationship to hardware, yet it depends on CORENET_GENERIC, reads a
Freescale-specific SPR, and lives in arch/powerpc/platforms/85xx. :-)
-Scott
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Ulf Hansson @ 2014-04-24 11:13 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <20140424105745.GM26756@n2100.arm.linux.org.uk>
On 24 April 2014 12:57, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
>> On 24 April 2014 12:17, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
>> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> >> I have looked though the patches up until patch 33 and this is clearly
>> >> a nice piece of clean-up /fixes work for sdhci. Besides my minor
>> >> comments per patch, I don't have any objections code-review wise to
>> >> proceed merging them.
>> >>
>> >> I have also tried to applied them on Chris' mmc-next branch,
>> >> unfortunate it fails at patch 23, so it would be nice to get a
>> >> re-based patchset for the mmc-next branch.
>> >
>> > I /could/ rebase it but then I wouldn't be able to produce the patch
>> > sets/patches for others [*] (such as the Novena project) to derive
>> > their kernel tree from my iMX6 patch set.
>> >
>> > What I'd prefer is to keep the patch set intact, and provide Chris
>> > with a pull request for it up to patch 33, which would need a
>> > conflict fixed - and this would mean that I can be sure that what
>> > I'm testing, and what I'm distributing is what Chris will also be
>> > submitting.
>>
>> Whether there are more than one conflict, I don't know. I just stopped
>> at patch 23.
>>
>> Moreover, there are other patches for sdhci that have been posted and
>> being discussed. In principle, we then need to put all these on hold
>> to prevent further conflicts. I guess that doable, as long as we don't
>> to that for too long. Maybe Chris have some more thoughts how to
>> handle this!?
>
> This is nothing new or unexpected - it was last posted back in February,
> and I elected that it should be held off until after the last merge
> window.
>
> Unfortunately, I didn't have time to post it immediately after the merge
> window closed, partly because it needed to be rebased on top of tglx's
> IRQ changes on which it depends. I was carrying those as separate commits
> to the ones Thomas was carrying in his tree - and in the event, Thomas had
> modified his patches slightly between sending me copies of them and the
> versions he sent during the merge window.
Okay, so let's keep up the frequency here then. I only had some minor
comments, please fix them and send a v2.
How about if I resolve the conflicts and send the pull request to
Chris? I suppose it makes life a bit easier for Chris.
Kind regards
Ulf Hansson
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Russell King - ARM Linux @ 2014-04-24 10:57 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <CAPDyKFrGReKF0ucer7D195boEoQW26=4vDXT+=Wn6BO-p_B1gQ@mail.gmail.com>
On Thu, Apr 24, 2014 at 12:52:11PM +0200, Ulf Hansson wrote:
> On 24 April 2014 12:17, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> > On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> >> I have looked though the patches up until patch 33 and this is clearly
> >> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> >> comments per patch, I don't have any objections code-review wise to
> >> proceed merging them.
> >>
> >> I have also tried to applied them on Chris' mmc-next branch,
> >> unfortunate it fails at patch 23, so it would be nice to get a
> >> re-based patchset for the mmc-next branch.
> >
> > I /could/ rebase it but then I wouldn't be able to produce the patch
> > sets/patches for others [*] (such as the Novena project) to derive
> > their kernel tree from my iMX6 patch set.
> >
> > What I'd prefer is to keep the patch set intact, and provide Chris
> > with a pull request for it up to patch 33, which would need a
> > conflict fixed - and this would mean that I can be sure that what
> > I'm testing, and what I'm distributing is what Chris will also be
> > submitting.
>
> Whether there are more than one conflict, I don't know. I just stopped
> at patch 23.
>
> Moreover, there are other patches for sdhci that have been posted and
> being discussed. In principle, we then need to put all these on hold
> to prevent further conflicts. I guess that doable, as long as we don't
> to that for too long. Maybe Chris have some more thoughts how to
> handle this!?
This is nothing new or unexpected - it was last posted back in February,
and I elected that it should be held off until after the last merge
window.
Unfortunately, I didn't have time to post it immediately after the merge
window closed, partly because it needed to be rebased on top of tglx's
IRQ changes on which it depends. I was carrying those as separate commits
to the ones Thomas was carrying in his tree - and in the event, Thomas had
modified his patches slightly between sending me copies of them and the
versions he sent during the merge window.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Ulf Hansson @ 2014-04-24 10:52 UTC (permalink / raw)
To: Russell King - ARM Linux, Chris Ball
Cc: Mark Rutland, Anton Vorontsov, linux-doc, Seungwon Jeon,
Thierry Reding, Ian Campbell, Michal Simek, Jaehoon Chung,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
Pawel Moll, Stephen Warren, spear-devel, Rob Herring, Ben Dooks,
linux-tegra@vger.kernel.org, Shawn Guo, Barry Song, Randy Dunlap,
linux-mmc, Viresh Kumar, Sascha Hauer, Kumar Gala, linuxppc-dev
In-Reply-To: <20140424101726.GH26756@n2100.arm.linux.org.uk>
On 24 April 2014 12:17, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
>> I have looked though the patches up until patch 33 and this is clearly
>> a nice piece of clean-up /fixes work for sdhci. Besides my minor
>> comments per patch, I don't have any objections code-review wise to
>> proceed merging them.
>>
>> I have also tried to applied them on Chris' mmc-next branch,
>> unfortunate it fails at patch 23, so it would be nice to get a
>> re-based patchset for the mmc-next branch.
>
> I /could/ rebase it but then I wouldn't be able to produce the patch
> sets/patches for others [*] (such as the Novena project) to derive
> their kernel tree from my iMX6 patch set.
>
> What I'd prefer is to keep the patch set intact, and provide Chris
> with a pull request for it up to patch 33, which would need a
> conflict fixed - and this would mean that I can be sure that what
> I'm testing, and what I'm distributing is what Chris will also be
> submitting.
Whether there are more than one conflict, I don't know. I just stopped
at patch 23.
Moreover, there are other patches for sdhci that have been posted and
being discussed. In principle, we then need to put all these on hold
to prevent further conflicts. I guess that doable, as long as we don't
to that for too long. Maybe Chris have some more thoughts how to
handle this!?
Kind regards
Ulf Hansson
>
> * - this currently stands at 230 patches in all - mmc + l2c + fec +
> imx-drm + other iMX6 changes.
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Russell King - ARM Linux @ 2014-04-24 10:17 UTC (permalink / raw)
To: Ulf Hansson
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <CAPDyKFozP69yngKAkdwHYyyvi+pdLEm05udOmBiVshQFi4hnLQ@mail.gmail.com>
On Thu, Apr 24, 2014 at 10:25:42AM +0200, Ulf Hansson wrote:
> I have looked though the patches up until patch 33 and this is clearly
> a nice piece of clean-up /fixes work for sdhci. Besides my minor
> comments per patch, I don't have any objections code-review wise to
> proceed merging them.
>
> I have also tried to applied them on Chris' mmc-next branch,
> unfortunate it fails at patch 23, so it would be nice to get a
> re-based patchset for the mmc-next branch.
I /could/ rebase it but then I wouldn't be able to produce the patch
sets/patches for others [*] (such as the Novena project) to derive
their kernel tree from my iMX6 patch set.
What I'd prefer is to keep the patch set intact, and provide Chris
with a pull request for it up to patch 33, which would need a
conflict fixed - and this would mean that I can be sure that what
I'm testing, and what I'm distributing is what Chris will also be
submitting.
* - this currently stands at 230 patches in all - mmc + l2c + fec +
imx-drm + other iMX6 changes.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
^ permalink raw reply
* Re: [PATCH 3/3] of: Handle memory@0 node on PPC32 only
From: Leif Lindholm @ 2014-04-24 9:26 UTC (permalink / raw)
To: Grant Likely, Mark Rutland
Cc: devicetree@vger.kernel.org, patches@linaro.org, Lee Jones,
linux-kernel@vger.kernel.org, Rob Herring, Geert Uytterhoeven,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140423131058.D94B6C408D2@trevor.secretlab.ca>
On Wed, Apr 23, 2014 at 02:10:58PM +0100, Grant Likely wrote:
> > Does anyone have a LongTrail DT to hand, and if so does the root have a
> > compatible string? From grepping through the kernel I could only find a
> > model string ("IBM,LongTrail").
>
> Actually, on LongTrail this can be removed from the common code
> entirely. It has real open firmware and PowerPC already has the
> infrastructure for fixing up the device tree.
>
> Here's a draft patch that I've compile tested, but nothing else.
I would certainly be happy with that.
Consider my 3/3 withdrawn.
And if the kernel proper will stop honoring nodes with no type,
there is no need for the stub to treat those specially either.
/
Leif
> g.
>
> ---
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 078145acf7fb..18b2c3fee98f 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2587,9 +2587,18 @@ static void __init fixup_device_tree_chrp(void)
> phandle ph;
> u32 prop[6];
> u32 rloc = 0x01006000; /* IO space; PCI device = 12 */
> - char *name;
> + char *name, strprop[16];
> int rc;
>
> + /* Deal with missing device_type in LongTrail memory node */
> + name = "/memory@0";
> + ph = call_prom("finddevice", 1, 1, ADDR(name));
> + rc = prom_getprop(ph, "device_type", strprop, sizeof(strprop));
> + if (rc == PROM_ERROR || strcmp(strprop, "memory") != 0) {
> + prom_printf("Fixing up missing device_type on /memory@0 node...\n");
> + prom_setprop(ph, name, "device_type", "memory", sizeof("memory"));
> + }
> +
> name = "/pci@80000000/isa@c";
> ph = call_prom("finddevice", 1, 1, ADDR(name));
> if (!PHANDLE_VALID(ph)) {
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 7a2ef7bb8022..7cda0d279cbe 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -886,14 +886,7 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
> unsigned long l;
>
> /* We are scanning "memory" nodes only */
> - if (type == NULL) {
> - /*
> - * The longtrail doesn't have a device_type on the
> - * /memory node, so look for the node called /memory@0.
> - */
> - if (depth != 1 || strcmp(uname, "memory@0") != 0)
> - return 0;
> - } else if (strcmp(type, "memory") != 0)
> + if (!type || strcmp(type, "memory") != 0)
> return 0;
>
> reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
>
^ permalink raw reply
* Re: [PATCH 00/38] MMC updates, plus CuBox-i WiFi support
From: Ulf Hansson @ 2014-04-24 8:25 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Mark Rutland, Stephen Warren, linux-doc, Seungwon Jeon,
Chris Ball, Thierry Reding, Anton Vorontsov, Michal Simek,
Jaehoon Chung, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, Pawel Moll, Ian Campbell, spear-devel,
Rob Herring, Ben Dooks, linux-tegra@vger.kernel.org, Shawn Guo,
Barry Song, Randy Dunlap, linux-mmc, Viresh Kumar, Sascha Hauer,
Kumar Gala, linuxppc-dev
In-Reply-To: <20140423185534.GA26756@n2100.arm.linux.org.uk>
On 23 April 2014 20:55, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> All,
>
> This is where I'm at with trying to clean up the SDHCI mess, and sort out
> issues I've noticed when trying to get UHS support working on CuBoxes.
> This is my full patch set, but I recommend not applying patch 37 as there
> appears to be a hardware issue preventing it working reliably.
>
> In any case, patches 0-33 inclusive are the SDHCI clean up, based against
> v3.15-rc1. Patches 34 and 35 are Olof's Wifi support, 36 is my fix against
> those, and 38 adds the Broadcom Wifi and BT support for CuBox.
>
> The questions over how to handle these devices were never properly settled,
> so I recommend against merging patch 34 onwards. As for the rest, I'm not
> planning on any further work, so it may be a good idea for people to
> consider testing them with a view to getting them merged.
>
I have looked though the patches up until patch 33 and this is clearly
a nice piece of clean-up /fixes work for sdhci. Besides my minor
comments per patch, I don't have any objections code-review wise to
proceed merging them.
I have also tried to applied them on Chris' mmc-next branch,
unfortunate it fails at patch 23, so it would be nice to get a
re-based patchset for the mmc-next branch.
Kind regards
Ulf Hansson
> Documentation/devicetree/bindings/mmc/mmc.txt | 11 +
> arch/arm/boot/dts/imx6qdl-cubox-i.dtsi | 34 +-
> arch/arm/boot/dts/imx6qdl-microsom.dtsi | 98 ++++
> drivers/mmc/core/core.c | 42 ++
> drivers/mmc/core/host.c | 68 +++
> drivers/mmc/core/sdio_irq.c | 41 +-
> drivers/mmc/host/Kconfig | 63 +--
> drivers/mmc/host/dw_mmc.c | 2 +
> drivers/mmc/host/sdhci-acpi.c | 8 +
> drivers/mmc/host/sdhci-bcm-kona.c | 4 +
> drivers/mmc/host/sdhci-bcm2835.c | 4 +
> drivers/mmc/host/sdhci-cns3xxx.c | 13 +-
> drivers/mmc/host/sdhci-dove.c | 4 +
> drivers/mmc/host/sdhci-esdhc-imx.c | 82 +--
> drivers/mmc/host/sdhci-esdhc.h | 4 +-
> drivers/mmc/host/sdhci-of-arasan.c | 4 +
> drivers/mmc/host/sdhci-of-esdhc.c | 70 ++-
> drivers/mmc/host/sdhci-of-hlwd.c | 4 +
> drivers/mmc/host/sdhci-pci.c | 9 +-
> drivers/mmc/host/sdhci-pltfm.c | 4 +
> drivers/mmc/host/sdhci-pxav2.c | 14 +-
> drivers/mmc/host/sdhci-pxav3.c | 13 +-
> drivers/mmc/host/sdhci-s3c.c | 36 +-
> drivers/mmc/host/sdhci-sirf.c | 4 +
> drivers/mmc/host/sdhci-spear.c | 5 +-
> drivers/mmc/host/sdhci-tegra.c | 27 +-
> drivers/mmc/host/sdhci.c | 728 +++++++++++++-------------
> drivers/mmc/host/sdhci.h | 20 +-
> include/linux/mmc/host.h | 8 +
> include/linux/mmc/sdhci.h | 15 +-
> 30 files changed, 885 insertions(+), 554 deletions(-)
>
>
> --
> FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
> improving, and getting towards what was expected from it.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 24/25] PCI: Fix return value from pci_user_{read, write}_config_*()
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
PCI accessors from user space pci_user_{read,write}_config_*()
return negative error number, which was introduced by commit
34e32072 ("PCI: handle positive error codes"). That patch coverts
all positive error numbers from platform specific PCI config
accessors to -EINVAL. The upper layer calling to those PCI config
accessors hardly know the specific cause from the return value
when hitting failures.
The patch fixes the issue by doing the conversion (from positive
to negative) using existing function pcibios_err_to_errno().
Signed-off-by: Gavin Shan <shangw@linux.vnet.ibm.com>
---
drivers/pci/access.c | 12 ++++--------
include/linux/pci.h | 6 ++++--
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/access.c b/drivers/pci/access.c
index 7f8b78c..8c148f3 100644
--- a/drivers/pci/access.c
+++ b/drivers/pci/access.c
@@ -148,7 +148,7 @@ static noinline void pci_wait_cfg(struct pci_dev *dev)
int pci_user_read_config_##size \
(struct pci_dev *dev, int pos, type *val) \
{ \
- int ret = 0; \
+ int ret = PCIBIOS_SUCCESSFUL; \
u32 data = -1; \
if (PCI_##size##_BAD) \
return -EINVAL; \
@@ -159,9 +159,7 @@ int pci_user_read_config_##size \
pos, sizeof(type), &data); \
raw_spin_unlock_irq(&pci_lock); \
*val = (type)data; \
- if (ret > 0) \
- ret = -EINVAL; \
- return ret; \
+ return pcibios_err_to_errno(ret); \
} \
EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
@@ -170,7 +168,7 @@ EXPORT_SYMBOL_GPL(pci_user_read_config_##size);
int pci_user_write_config_##size \
(struct pci_dev *dev, int pos, type val) \
{ \
- int ret = -EIO; \
+ int ret = PCIBIOS_SUCCESSFUL; \
if (PCI_##size##_BAD) \
return -EINVAL; \
raw_spin_lock_irq(&pci_lock); \
@@ -179,9 +177,7 @@ int pci_user_write_config_##size \
ret = dev->bus->ops->write(dev->bus, dev->devfn, \
pos, sizeof(type), val); \
raw_spin_unlock_irq(&pci_lock); \
- if (ret > 0) \
- ret = -EINVAL; \
- return ret; \
+ return pcibios_err_to_errno(ret); \
} \
EXPORT_SYMBOL_GPL(pci_user_write_config_##size);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..1682cb1 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -518,7 +518,7 @@ static inline int pcibios_err_to_errno(int err)
case PCIBIOS_FUNC_NOT_SUPPORTED:
return -ENOENT;
case PCIBIOS_BAD_VENDOR_ID:
- return -EINVAL;
+ return -ENOTTY;
case PCIBIOS_DEVICE_NOT_FOUND:
return -ENODEV;
case PCIBIOS_BAD_REGISTER_NUMBER:
@@ -527,9 +527,11 @@ static inline int pcibios_err_to_errno(int err)
return -EIO;
case PCIBIOS_BUFFER_TOO_SMALL:
return -ENOSPC;
+ default:
+ return -err;
}
- return -ENOTTY;
+ return -ERANGE;
}
/* Low-level architecture-dependent routines */
--
1.8.3.2
^ permalink raw reply related
* [PATCH 23/25] powerpc/powernv: pci_domain_nr() not reliable
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
If the PE contains single PCI function, "pe->pbus" would be NULL.
It's not reliable to be used by pci_domain_nr(). We just grab the
PCI domain number from the PCI host controller (struct pci_controller)
instance.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 1934327..9807341 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -673,7 +673,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
TCE_PCI_SWINV_PAIR);
}
iommu_init_table(tbl, phb->hose->node);
- iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
+ iommu_register_group(tbl, phb->hose->global_number, pe->pe_number);
if (pe->pdev)
set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
@@ -801,7 +801,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
tbl->it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
}
iommu_init_table(tbl, phb->hose->node);
- iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
+ iommu_register_group(tbl, phb->hose->global_number, pe->pe_number);
if (pe->pdev)
set_iommu_table_base_and_group(&pe->pdev->dev, tbl);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 22/25] powerpc/powernv: Missed IOMMU table type
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
In function pnv_pci_ioda2_setup_dma_pe(), the IOMMU table type is
set to (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE) unconditionally.
It was just set to TCE_PCI by pnv_pci_setup_iommu_table(). So the
primary IOMMU table type (TCE_PCI) is lost. The patch fixes it.
Also, pnv_pci_setup_iommu_table() already set "tbl->it_busno" to
zero and we needn't do it again. The patch removes the redundant
assignment.
The patch also fixes similar issues in pnv_pci_ioda_setup_dma_pe().
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/pci-ioda.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 6a2cb37..1934327 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -665,12 +665,12 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb *phb,
* errors, and on the first pass the data will be a relative
* bus number, print that out instead.
*/
- tbl->it_busno = 0;
pe->tce_inval_reg_phys = be64_to_cpup(swinvp);
tbl->it_index = (unsigned long)ioremap(pe->tce_inval_reg_phys,
8);
- tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE |
- TCE_PCI_SWINV_PAIR;
+ tbl->it_type |= (TCE_PCI_SWINV_CREATE |
+ TCE_PCI_SWINV_FREE |
+ TCE_PCI_SWINV_PAIR);
}
iommu_init_table(tbl, phb->hose->node);
iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
@@ -795,11 +795,10 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
* errors, and on the first pass the data will be a relative
* bus number, print that out instead.
*/
- tbl->it_busno = 0;
pe->tce_inval_reg_phys = be64_to_cpup(swinvp);
tbl->it_index = (unsigned long)ioremap(pe->tce_inval_reg_phys,
8);
- tbl->it_type = TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE;
+ tbl->it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
}
iommu_init_table(tbl, phb->hose->node);
iommu_register_group(tbl, pci_domain_nr(pe->pbus), pe->pe_number);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 25/25] powerpc/prom: Stop scanning dev-tree for fdump early
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
Function early_init_dt_scan_fw_dump() is called to scan the device
tree for fdump properties under node "rtas". Any one of them is
invalid, we can stop scanning the device tree early by returning
"1". It would save a bit time during boot.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/kernel/fadump.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 2230fd0..0266774 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -69,7 +69,7 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
*/
token = of_get_flat_dt_prop(node, "ibm,configure-kernel-dump", NULL);
if (!token)
- return 0;
+ return 1;
fw_dump.fadump_supported = 1;
fw_dump.ibm_configure_kernel_dump = *token;
@@ -92,7 +92,7 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
&size);
if (!sections)
- return 0;
+ return 1;
num_sections = size / (3 * sizeof(u32));
@@ -110,6 +110,7 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
break;
}
}
+
return 1;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 16/25] powerpc/powernv: Reset root port in firmware
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan, linux-stable
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
Resetting root port has more stuff to do than that for PCIe switch
ports and we should have resetting root port done in firmware instead
of the kernel itself. The problem was introduced by commit 5b2e198e
("powerpc/powernv: Rework EEH reset").
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 3a755b5..0844e00 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -510,12 +510,10 @@ static int ioda_eeh_reset(struct eeh_pe *pe, int option)
int ret;
/*
- * The rules applied to reset, either fundamental or hot reset:
- *
- * We always reset the direct upstream bridge of the PE. If the
- * direct upstream bridge isn't root bridge, we always take hot
- * reset no matter what option (fundamental or hot) is. Otherwise,
- * we should do the reset according to the required option.
+ * For PHB reset, we always have complete reset. For those PEs whose
+ * primary bus derived from root complex (root bus) or root port
+ * (usually bus#1), we apply hot or fundamental reset on the root port.
+ * For other PEs, we always have hot reset on the PE primary bus.
*
* Here, we have different design to pHyp, which always clear the
* frozen state during PE reset. However, the good idea here from
@@ -529,7 +527,8 @@ static int ioda_eeh_reset(struct eeh_pe *pe, int option)
ret = ioda_eeh_phb_reset(hose, option);
} else {
bus = eeh_pe_bus_get(pe);
- if (pci_is_root_bus(bus))
+ if (pci_is_root_bus(bus) ||
+ pci_is_root_bus(bus->parent))
ret = ioda_eeh_root_reset(hose, option);
else
ret = ioda_eeh_bridge_reset(bus->self, option);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 20/25] powerpc/eeh: Can't recover from non-PE-reset case
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
When PCI_ERS_RESULT_CAN_RECOVER returned from device drivers, the
EEH core should enable I/O and DMA for the affected PE. However,
it was missed to have DMA enabled in eeh_handle_normal_event().
Besides, the frozen state of the affected PE should be cleared
after successful recovery, but we didn't.
The patch fixes both of the issues as above.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh_driver.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
index f99ba9b..7100a5b 100644
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -640,7 +640,6 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
result = PCI_ERS_RESULT_NEED_RESET;
} else {
pr_info("EEH: Notify device drivers to resume I/O\n");
- result = PCI_ERS_RESULT_NONE;
eeh_pe_dev_traverse(pe, eeh_report_mmio_enabled, &result);
}
}
@@ -652,10 +651,17 @@ static void eeh_handle_normal_event(struct eeh_pe *pe)
if (rc < 0)
goto hard_fail;
- if (rc)
+ if (rc) {
result = PCI_ERS_RESULT_NEED_RESET;
- else
+ } else {
+ /*
+ * We didn't do PE reset for the case. The PE
+ * is still in frozen state. Clear it before
+ * resuming the PE.
+ */
+ eeh_pe_state_clear(pe, EEH_PE_ISOLATED);
result = PCI_ERS_RESULT_RECOVERED;
+ }
}
/* If any device has a hard failure, then shut off everything. */
--
1.8.3.2
^ permalink raw reply related
* [PATCH 19/25] powrpc/powernv: Reset PHB in kdump kernel
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
In the kdump scenario, the first kerenl doesn't shutdown PCI devices
and the kdump kerenl clean PHB IODA table at the early probe time.
That means the kdump kerenl can't support PCI transactions piled
by the first kerenl. Otherwise, lots of EEH errors and frozen PEs
will be detected.
In order to avoid the EEH errors, the PHB is resetted to drop all
PCI transaction from the first kerenl.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 15 +++++++++++----
arch/powerpc/platforms/powernv/pci-ioda.c | 12 ++++++++++++
arch/powerpc/platforms/powernv/pci.h | 1 +
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 58ef809..753f08e 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -388,13 +388,16 @@ static s64 ioda_eeh_phb_poll(struct pnv_phb *phb)
if (rc <= 0)
break;
- msleep(rc);
+ if (system_state < SYSTEM_RUNNING)
+ udelay(1000 * rc);
+ else
+ msleep(rc);
}
return rc;
}
-static int ioda_eeh_phb_reset(struct pci_controller *hose, int option)
+int ioda_eeh_phb_reset(struct pci_controller *hose, int option)
{
struct pnv_phb *phb = hose->private_data;
s64 rc = OPAL_HARDWARE;
@@ -422,8 +425,12 @@ static int ioda_eeh_phb_reset(struct pci_controller *hose, int option)
* need the PCI bus settlement delay.
*/
rc = ioda_eeh_phb_poll(phb);
- if (option == EEH_RESET_DEACTIVATE)
- msleep(EEH_PE_RST_SETTLE_TIME);
+ if (option == EEH_RESET_DEACTIVATE) {
+ if (system_state < SYSTEM_RUNNING)
+ udelay(1000 * EEH_PE_RST_SETTLE_TIME);
+ else
+ msleep(EEH_PE_RST_SETTLE_TIME);
+ }
out:
if (rc != OPAL_SUCCESS)
return -EIO;
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 0bfc4d1..6a2cb37 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -13,6 +13,7 @@
#include <linux/kernel.h>
#include <linux/pci.h>
+#include <linux/crash_dump.h>
#include <linux/debugfs.h>
#include <linux/delay.h>
#include <linux/string.h>
@@ -1394,6 +1395,17 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
rc = opal_pci_reset(phb_id, OPAL_PCI_IODA_TABLE_RESET, OPAL_ASSERT_RESET);
if (rc)
pr_warning(" OPAL Error %ld performing IODA table reset !\n", rc);
+
+ /* If we're running in kdump kerenl, the previous kerenl never
+ * shutdown PCI devices correctly. We already got IODA table
+ * cleaned out. So we have to issue PHB reset to stop all PCI
+ * transactions from previous kerenl.
+ */
+ if (is_kdump_kernel()) {
+ pr_info(" Issue PHB reset ...\n");
+ ioda_eeh_phb_reset(hose, EEH_RESET_FUNDAMENTAL);
+ ioda_eeh_phb_reset(hose, OPAL_DEASSERT_RESET);
+ }
}
void __init pnv_pci_init_ioda2_phb(struct device_node *np)
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 34a0974..676232c 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -205,5 +205,6 @@ extern void pnv_pci_init_ioda2_phb(struct device_node *np);
extern void pnv_pci_ioda_tce_invalidate(struct iommu_table *tbl,
__be64 *startp, __be64 *endp, bool rm);
extern void pnv_pci_reset_secondary_bus(struct pci_dev *dev);
+extern int ioda_eeh_phb_reset(struct pci_controller *hose, int option);
#endif /* __POWERNV_PCI_H */
--
1.8.3.2
^ permalink raw reply related
* [PATCH 17/25] powerpc/eeh: Make the delay for PE reset unified
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
Basically, we have 3 types of resets to fulfil PE reset: fundamental,
hot and PHB reset. For the later 2 cases, we need PCI bus reset hold
and settlement delay as specified by PCI spec. PowerNV and pSeries
platforms are running on top of different firmware and some of the
delays have been covered by underly firmware (PowerNV).
The patch makes the delays unified to be done in backend, instead of
EEH core.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 10 ++++++++++
arch/powerpc/kernel/eeh.c | 13 -------------
arch/powerpc/platforms/powernv/eeh-ioda.c | 12 +++++++++++-
arch/powerpc/platforms/pseries/eeh_pseries.c | 10 +++++++++-
4 files changed, 30 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index 2841eca..b76f58c 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -39,6 +39,16 @@ struct device_node;
#define EEH_PROBE_MODE_DEVTREE 0x8 /* From device tree */
/*
+ * Delay for PE reset, all in ms
+ *
+ * PCI specification has reset hold time of 100 milliseconds.
+ * We have 250 milliseconds here. The PCI bus settlement time
+ * is specified as 1.5 seconds and we have 1.8 seconds.
+ */
+#define EEH_PE_RST_HOLD_TIME 250
+#define EEH_PE_RST_SETTLE_TIME 1800
+
+/*
* The struct is used to trace PE related EEH functionality.
* In theory, there will have one instance of the struct to
* be created against particular PE. In nature, PEs corelate
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 1e409a2..3764fb7 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -639,20 +639,7 @@ static void eeh_reset_pe_once(struct eeh_pe *pe)
else
eeh_ops->reset(pe, EEH_RESET_HOT);
- /* The PCI bus requires that the reset be held high for at least
- * a 100 milliseconds. We wait a bit longer 'just in case'.
- */
-#define PCI_BUS_RST_HOLD_TIME_MSEC 250
- msleep(PCI_BUS_RST_HOLD_TIME_MSEC);
-
eeh_ops->reset(pe, EEH_RESET_DEACTIVATE);
-
- /* After a PCI slot has been reset, the PCI Express spec requires
- * a 1.5 second idle time for the bus to stabilize, before starting
- * up traffic.
- */
-#define PCI_BUS_SETTLE_TIME_MSEC 1800
- msleep(PCI_BUS_SETTLE_TIME_MSEC);
}
/**
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 0844e00..268cd46 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -417,9 +417,13 @@ static int ioda_eeh_phb_reset(struct pci_controller *hose, int option)
/*
* Poll state of the PHB until the request is done
- * successfully.
+ * successfully. The PHB reset is usually PHB complete
+ * reset followed by hot reset on root bus. So we also
+ * need the PCI bus settlement delay.
*/
rc = ioda_eeh_phb_poll(phb);
+ if (option == EEH_RESET_DEACTIVATE)
+ msleep(EEH_PE_RST_SETTLE_TIME);
out:
if (rc != OPAL_SUCCESS)
return -EIO;
@@ -457,6 +461,8 @@ static int ioda_eeh_root_reset(struct pci_controller *hose, int option)
/* Poll state of the PHB until the request is done */
rc = ioda_eeh_phb_poll(phb);
+ if (option == EEH_RESET_DEACTIVATE)
+ msleep(EEH_PE_RST_SETTLE_TIME);
out:
if (rc != OPAL_SUCCESS)
return -EIO;
@@ -480,11 +486,15 @@ static int ioda_eeh_bridge_reset(struct pci_dev *dev, int option)
eeh_ops->read_config(dn, PCI_BRIDGE_CONTROL, 2, &ctrl);
ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
eeh_ops->write_config(dn, PCI_BRIDGE_CONTROL, 2, ctrl);
+
+ msleep(EEH_PE_RST_HOLD_TIME);
break;
case EEH_RESET_DEACTIVATE:
eeh_ops->read_config(dn, PCI_BRIDGE_CONTROL, 2, &ctrl);
ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
eeh_ops->write_config(dn, PCI_BRIDGE_CONTROL, 2, ctrl);
+
+ msleep(EEH_PE_RST_SETTLE_TIME);
break;
}
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
index 2f1ba64..0bec0c0 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -532,11 +532,19 @@ static int pseries_eeh_reset(struct eeh_pe *pe, int option)
/* If fundamental-reset not supported, try hot-reset */
if (option == EEH_RESET_FUNDAMENTAL &&
ret == -8) {
+ option = EEH_RESET_HOT;
ret = rtas_call(ibm_set_slot_reset, 4, 1, NULL,
config_addr, BUID_HI(pe->phb->buid),
- BUID_LO(pe->phb->buid), EEH_RESET_HOT);
+ BUID_LO(pe->phb->buid), option);
}
+ /* We need reset hold or settlement delay */
+ if (option == EEH_RESET_FUNDAMENTAL ||
+ option == EEH_RESET_HOT)
+ msleep(EEH_PE_RST_HOLD_TIME);
+ else
+ msleep(EEH_PE_RST_SETTLE_TIME);
+
return ret;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 21/25] powerpc/powernv: Fundamental reset on PLX ports
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
The patch intends to support fundamental reset on PLX downstream
ports. If the PCI device matches any one of the internal table,
which includes PLX vendor ID, bridge device ID, register offset
for fundamental reset and bit, fundamental reset will be done
accordingly. Otherwise, it will fail back to hot reset.
Additional flag (EEH_DEV_FRESET) is introduced to record the last
reset type on the PCI bridge.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 1 +
arch/powerpc/platforms/powernv/eeh-ioda.c | 110 +++++++++++++++++++++++++-----
2 files changed, 95 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index b76f58c..d12529f 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -109,6 +109,7 @@ struct eeh_pe {
#define EEH_DEV_NO_HANDLER (1 << 8) /* No error handler */
#define EEH_DEV_SYSFS (1 << 9) /* Sysfs created */
#define EEH_DEV_REMOVED (1 << 10) /* Removed permanently */
+#define EEH_DEV_FRESET (1 << 11) /* Fundamental reset */
struct eeh_dev {
int mode; /* EEH mode */
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 753f08e..79d0cdf 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -477,49 +477,127 @@ out:
return 0;
}
+static bool ioda_eeh_is_plx_dnport(struct pci_dev *dev, int *reg,
+ int *mask, int *len)
+{
+ unsigned short *pid;
+ unsigned short ids[] = {
+ 0x10b5, 0x8748, 0x0080, 0x0400, /* PLX#8748 */
+ 0x0000, 0x0000, 0x0000, 0x0000, /* End flag */
+ };
+
+ if (!pci_is_pcie(dev))
+ return false;
+ if (pci_pcie_type(dev) != PCI_EXP_TYPE_DOWNSTREAM)
+ return false;
+
+ pid = &ids[0];
+ while (!reg) {
+ if (pid[0] == 0x0)
+ break;
+
+ if (dev->vendor == pid[0] &&
+ dev->device == pid[1]) {
+ *reg = pid[2];
+ *mask = pid[3];
+ *len = 2;
+ return true;
+ }
+ }
+
+ *reg = PCI_BRIDGE_CONTROL;
+ *mask = PCI_BRIDGE_CTL_BUS_RESET;
+ *len = 2;
+ return false;
+}
+
static int ioda_eeh_bridge_reset(struct pci_dev *dev, int option)
{
struct device_node *dn = pci_device_to_OF_node(dev);
struct eeh_dev *edev = of_node_to_eeh_dev(dn);
int aer = edev ? edev->aer_cap : 0;
- u32 ctrl;
+ int reg, mask, val, len;
+ bool is_plx_dnport;
pr_debug("%s: Reset PCI bus %04x:%02x with option %d\n",
__func__, pci_domain_nr(dev->bus),
dev->bus->number, option);
+
+ is_plx_dnport = ioda_eeh_is_plx_dnport(dev, ®, &mask, &len);
+ if (option == EEH_RESET_FUNDAMENTAL)
+ if (!is_plx_dnport || !edev)
+ option = EEH_RESET_HOT;
+
+ if (option == EEH_RESET_HOT) {
+ reg = PCI_BRIDGE_CONTROL;
+ mask = PCI_BRIDGE_CTL_BUS_RESET;
+ len = 2;
+ }
+
+ if (option == EEH_RESET_DEACTIVATE) {
+ if (!is_plx_dnport || !edev ||
+ !(edev->mode & EEH_DEV_FRESET)) {
+ reg = PCI_BRIDGE_CONTROL;
+ mask = PCI_BRIDGE_CTL_BUS_RESET;
+ len = 2;
+ }
+ }
+
switch (option) {
case EEH_RESET_FUNDAMENTAL:
+ edev->mode |= EEH_DEV_FRESET;
+ /* Fall through */
case EEH_RESET_HOT:
- /* Don't report linkDown event */
if (aer) {
+ /* Mask receiver error */
+ eeh_ops->read_config(dn, aer + PCI_ERR_COR_MASK,
+ 4, &val);
+ val |= PCI_ERR_COR_RCVR;
+ eeh_ops->write_config(dn, aer + PCI_ERR_COR_MASK,
+ 4, val);
+
+ /* Mask linkDown */
eeh_ops->read_config(dn, aer + PCI_ERR_UNCOR_MASK,
- 4, &ctrl);
- ctrl |= PCI_ERR_UNC_SURPDN;
+ 4, &val);
+ val |= PCI_ERR_UNC_SURPDN;
eeh_ops->write_config(dn, aer + PCI_ERR_UNCOR_MASK,
- 4, ctrl);
- }
+ 4, val);
+ }
- eeh_ops->read_config(dn, PCI_BRIDGE_CONTROL, 2, &ctrl);
- ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
- eeh_ops->write_config(dn, PCI_BRIDGE_CONTROL, 2, ctrl);
+ eeh_ops->read_config(dn, reg, len, &val);
+ val |= mask;
+ eeh_ops->write_config(dn, reg, len, val);
msleep(EEH_PE_RST_HOLD_TIME);
break;
case EEH_RESET_DEACTIVATE:
- eeh_ops->read_config(dn, PCI_BRIDGE_CONTROL, 2, &ctrl);
- ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
- eeh_ops->write_config(dn, PCI_BRIDGE_CONTROL, 2, ctrl);
+ eeh_ops->read_config(dn, reg, len, &val);
+ val &= ~mask;
+ eeh_ops->write_config(dn, reg, len, val);
msleep(EEH_PE_RST_SETTLE_TIME);
- /* Continue reporting linkDown event */
+ if (edev)
+ edev->mode &= ~EEH_DEV_FRESET;
if (aer) {
+ /* Clear receive error and enable it */
+ eeh_ops->write_config(dn, aer + PCI_ERR_COR_STATUS,
+ 4, PCI_ERR_COR_RCVR);
+ eeh_ops->read_config(dn, aer + PCI_ERR_COR_MASK,
+ 4, &val);
+ val &= ~PCI_ERR_COR_RCVR;
+ eeh_ops->write_config(dn, aer + PCI_ERR_COR_MASK,
+ 4, val);
+
+ /* Clear linkDown and enable it */
+ eeh_ops->write_config(dn, aer + PCI_ERR_UNCOR_STATUS,
+ 4, PCI_ERR_UNC_SURPDN);
eeh_ops->read_config(dn, aer + PCI_ERR_UNCOR_MASK,
- 4, &ctrl);
- ctrl &= ~PCI_ERR_UNC_SURPDN;
+ 4, &val);
+ val &= ~PCI_ERR_UNC_SURPDN;
eeh_ops->write_config(dn, aer + PCI_ERR_UNCOR_MASK,
- 4, ctrl);
+ 4, val);
}
break;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 18/25] powerpc/pci: Mask linkDown on resetting PCI bus
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
The problem was initially reported by Wendy who tried pass through
IPR adapter, which was connected to PHB root port directly, to KVM
based guest. When doing that, pci_reset_bridge_secondary_bus() was
called by VFIO driver and linkDown was detected by the root port.
That caused all PEs to be frozen.
The patch fixes the issue by routing the reset for the secondary bus
of root port to underly firmware. For that, one more weak function
pci_reset_secondary_bus() is introduced so that the individual platforms
can override that and do specific reset for bridge's secondary bus.
Reported-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/machdep.h | 3 +++
arch/powerpc/kernel/pci-common.c | 20 ++++++++++++++++
arch/powerpc/platforms/powernv/eeh-ioda.c | 38 +++++++++++++++++++++++++++++--
arch/powerpc/platforms/powernv/pci-ioda.c | 1 +
arch/powerpc/platforms/powernv/pci.h | 1 +
drivers/pci/pci.c | 21 ++++++++++-------
6 files changed, 74 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index 5b6c03f..240b137 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -241,6 +241,9 @@ struct machdep_calls {
/* Called during PCI resource reassignment */
resource_size_t (*pcibios_window_alignment)(struct pci_bus *, unsigned long type);
+ /* Reset the secondary bus of bridge */
+ void (*pcibios_reset_secondary_bus)(struct pci_dev *dev);
+
/* Called to shutdown machine specific hardware not already controlled
* by other drivers.
*/
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index d9476c1..f9ca509 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -21,6 +21,7 @@
#include <linux/string.h>
#include <linux/init.h>
#include <linux/bootmem.h>
+#include <linux/delay.h>
#include <linux/export.h>
#include <linux/of_address.h>
#include <linux/of_pci.h>
@@ -120,6 +121,25 @@ resource_size_t pcibios_window_alignment(struct pci_bus *bus,
return 1;
}
+void pcibios_reset_secondary_bus(struct pci_dev *dev)
+{
+ u16 ctrl;
+
+ if (ppc_md.pcibios_reset_secondary_bus) {
+ ppc_md.pcibios_reset_secondary_bus(dev);
+ return;
+ }
+
+ pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &ctrl);
+ ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
+ pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
+ msleep(2);
+
+ ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
+ pci_write_config_word(dev, PCI_BRIDGE_CONTROL, ctrl);
+ ssleep(1);
+}
+
static resource_size_t pcibios_io_size(const struct pci_controller *hose)
{
#ifdef CONFIG_PPC64
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 268cd46..58ef809 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -474,6 +474,8 @@ static int ioda_eeh_bridge_reset(struct pci_dev *dev, int option)
{
struct device_node *dn = pci_device_to_OF_node(dev);
+ struct eeh_dev *edev = of_node_to_eeh_dev(dn);
+ int aer = edev ? edev->aer_cap : 0;
u32 ctrl;
pr_debug("%s: Reset PCI bus %04x:%02x with option %d\n",
@@ -483,24 +485,56 @@ static int ioda_eeh_bridge_reset(struct pci_dev *dev, int option)
switch (option) {
case EEH_RESET_FUNDAMENTAL:
case EEH_RESET_HOT:
+ /* Don't report linkDown event */
+ if (aer) {
+ eeh_ops->read_config(dn, aer + PCI_ERR_UNCOR_MASK,
+ 4, &ctrl);
+ ctrl |= PCI_ERR_UNC_SURPDN;
+ eeh_ops->write_config(dn, aer + PCI_ERR_UNCOR_MASK,
+ 4, ctrl);
+ }
+
eeh_ops->read_config(dn, PCI_BRIDGE_CONTROL, 2, &ctrl);
ctrl |= PCI_BRIDGE_CTL_BUS_RESET;
eeh_ops->write_config(dn, PCI_BRIDGE_CONTROL, 2, ctrl);
-
msleep(EEH_PE_RST_HOLD_TIME);
+
break;
case EEH_RESET_DEACTIVATE:
eeh_ops->read_config(dn, PCI_BRIDGE_CONTROL, 2, &ctrl);
ctrl &= ~PCI_BRIDGE_CTL_BUS_RESET;
eeh_ops->write_config(dn, PCI_BRIDGE_CONTROL, 2, ctrl);
-
msleep(EEH_PE_RST_SETTLE_TIME);
+
+ /* Continue reporting linkDown event */
+ if (aer) {
+ eeh_ops->read_config(dn, aer + PCI_ERR_UNCOR_MASK,
+ 4, &ctrl);
+ ctrl &= ~PCI_ERR_UNC_SURPDN;
+ eeh_ops->write_config(dn, aer + PCI_ERR_UNCOR_MASK,
+ 4, ctrl);
+ }
+
break;
}
return 0;
}
+void pnv_pci_reset_secondary_bus(struct pci_dev *dev)
+{
+ struct pci_controller *hose;
+
+ if (pci_is_root_bus(dev->bus)) {
+ hose = pci_bus_to_host(dev->bus);
+ ioda_eeh_root_reset(hose, EEH_RESET_HOT);
+ ioda_eeh_root_reset(hose, EEH_RESET_DEACTIVATE);
+ } else {
+ ioda_eeh_bridge_reset(dev, EEH_RESET_HOT);
+ ioda_eeh_bridge_reset(dev, EEH_RESET_DEACTIVATE);
+ }
+}
+
/**
* ioda_eeh_reset - Reset the indicated PE
* @pe: EEH PE
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
index 3b2b4fb..0bfc4d1 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1387,6 +1387,7 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;
ppc_md.pcibios_enable_device_hook = pnv_pci_enable_device_hook;
ppc_md.pcibios_window_alignment = pnv_pci_window_alignment;
+ ppc_md.pcibios_reset_secondary_bus = pnv_pci_reset_secondary_bus;
pci_add_flags(PCI_REASSIGN_ALL_RSRC);
/* Reset IODA tables to a clean state */
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 39ec697..34a0974 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -204,5 +204,6 @@ extern void pnv_pci_init_ioda_hub(struct device_node *np);
extern void pnv_pci_init_ioda2_phb(struct device_node *np);
extern void pnv_pci_ioda_tce_invalidate(struct iommu_table *tbl,
__be64 *startp, __be64 *endp, bool rm);
+extern void pnv_pci_reset_secondary_bus(struct pci_dev *dev);
#endif /* __POWERNV_PCI_H */
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7325d43..633382d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3167,14 +3167,7 @@ static int pci_pm_reset(struct pci_dev *dev, int probe)
return 0;
}
-/**
- * pci_reset_bridge_secondary_bus - Reset the secondary bus on a PCI bridge.
- * @dev: Bridge device
- *
- * Use the bridge control register to assert reset on the secondary bus.
- * Devices on the secondary bus are left in power-on state.
- */
-void pci_reset_bridge_secondary_bus(struct pci_dev *dev)
+void __weak pcibios_reset_secondary_bus(struct pci_dev *dev)
{
u16 ctrl;
@@ -3199,6 +3192,18 @@ void pci_reset_bridge_secondary_bus(struct pci_dev *dev)
*/
ssleep(1);
}
+
+/**
+ * pci_reset_bridge_secondary_bus - Reset the secondary bus on a PCI bridge.
+ * @dev: Bridge device
+ *
+ * Use the bridge control register to assert reset on the secondary bus.
+ * Devices on the secondary bus are left in power-on state.
+ */
+void pci_reset_bridge_secondary_bus(struct pci_dev *dev)
+{
+ pcibios_reset_secondary_bus(dev);
+}
EXPORT_SYMBOL_GPL(pci_reset_bridge_secondary_bus);
static int pci_parent_bus_reset(struct pci_dev *dev, int probe)
--
1.8.3.2
^ permalink raw reply related
* [PATCH 12/25] powerpc/eeh: Allow to disable EEH
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
The patch introduces bootarg "eeh=off" to disable EEH functinality.
Also, it creates /sys/kerenl/debug/powerpc/eeh_enable to disable
or enable EEH functionality. By default, we have the functionality
enabled.
For PowerNV platform, we will restore to have the conventional
mechanism of clearing frozen PE during PCI config access if we're
going to disable EEH functionality. Conversely, we will rely on
EEH for error recovery.
The patch also fixes the issue that we missed to cover the case
of disabled EEH functionality in function ioda_eeh_event(). Those
events driven by interrupt should be cleared to avoid endless
reporting.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/kernel/eeh.c | 47 ++++++++++++++++++++++++++++++-
arch/powerpc/platforms/powernv/eeh-ioda.c | 29 +++++++++++++++----
arch/powerpc/platforms/powernv/pci.h | 1 +
3 files changed, 70 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 06d2b7c..1e409a2 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -22,6 +22,7 @@
*/
#include <linux/delay.h>
+#include <linux/debugfs.h>
#include <linux/sched.h>
#include <linux/init.h>
#include <linux/list.h>
@@ -132,6 +133,15 @@ static struct eeh_stats eeh_stats;
#define IS_BRIDGE(class_code) (((class_code)<<16) == PCI_BASE_CLASS_BRIDGE)
+static int __init eeh_setup(char *str)
+{
+ if (!strcmp(str, "off"))
+ eeh_subsystem_flags |= EEH_FORCE_DISABLED;
+
+ return 1;
+}
+__setup("eeh=", eeh_setup);
+
/**
* eeh_gather_pci_data - Copy assorted PCI config space registers to buff
* @edev: device to report data for
@@ -1117,10 +1127,45 @@ static const struct file_operations proc_eeh_operations = {
.release = single_release,
};
+#ifdef CONFIG_DEBUG_FS
+static int eeh_enable_dbgfs_set(void *data, u64 val)
+{
+ if (val)
+ eeh_subsystem_flags &= ~EEH_FORCE_DISABLED;
+ else
+ eeh_subsystem_flags |= EEH_FORCE_DISABLED;
+
+ /* Notify the backend */
+ if (eeh_ops->post_init)
+ eeh_ops->post_init();
+
+ return 0;
+}
+
+static int eeh_enable_dbgfs_get(void *data, u64 *val)
+{
+ if (eeh_enabled())
+ *val = 0x1ul;
+ else
+ *val = 0x0ul;
+ return 0;
+}
+
+DEFINE_SIMPLE_ATTRIBUTE(eeh_enable_dbgfs_ops, eeh_enable_dbgfs_get,
+ eeh_enable_dbgfs_set, "0x%llx\n");
+#endif
+
static int __init eeh_init_proc(void)
{
- if (machine_is(pseries) || machine_is(powernv))
+ if (machine_is(pseries) || machine_is(powernv)) {
proc_create("powerpc/eeh", 0, NULL, &proc_eeh_operations);
+#ifdef CONFIG_DEBUG_FS
+ debugfs_create_file("eeh_enable", 0600,
+ powerpc_debugfs_root, NULL,
+ &eeh_enable_dbgfs_ops);
+#endif
+ }
+
return 0;
}
__initcall(eeh_init_proc);
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 6bdae8d..35ec394 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -42,11 +42,19 @@ static int ioda_eeh_event(struct notifier_block *nb,
{
uint64_t changed_evts = (uint64_t)change;
- /* We simply send special EEH event */
- if ((changed_evts & OPAL_EVENT_PCI_ERROR) &&
- (events & OPAL_EVENT_PCI_ERROR) &&
- eeh_enabled())
+ /*
+ * We simply send special EEH event if EEH has
+ * been enabled, or clear pending events in
+ * case that we enable EEH soon
+ */
+ if (!(changed_evts & OPAL_EVENT_PCI_ERROR) ||
+ !(events & OPAL_EVENT_PCI_ERROR))
+ return 0;
+
+ if (eeh_enabled())
eeh_send_failure_event(NULL);
+ else
+ opal_notifier_update_evt(OPAL_EVENT_PCI_ERROR, 0x0ul);
return 0;
}
@@ -141,7 +149,9 @@ static int ioda_eeh_post_init(struct pci_controller *hose)
}
#ifdef CONFIG_DEBUG_FS
- if (phb->dbgfs) {
+ if (!phb->has_dbgfs && phb->dbgfs) {
+ phb->has_dbgfs = 1;
+
debugfs_create_file("err_injct_outbound", 0600,
phb->dbgfs, hose,
&ioda_eeh_outb_dbgfs_ops);
@@ -154,7 +164,14 @@ static int ioda_eeh_post_init(struct pci_controller *hose)
}
#endif
- phb->flags |= PNV_PHB_FLAG_EEH;
+ /* If EEH is enabled, we're going to rely on that.
+ * Otherwise, we restore to conventional mechanism
+ * to clear frozen PE during PCI config access.
+ */
+ if (eeh_enabled())
+ phb->flags |= PNV_PHB_FLAG_EEH;
+ else
+ phb->flags &= ~PNV_PHB_FLAG_EEH;
return 0;
}
diff --git a/arch/powerpc/platforms/powernv/pci.h b/arch/powerpc/platforms/powernv/pci.h
index 94e3495..39ec697 100644
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -101,6 +101,7 @@ struct pnv_phb {
#endif
#ifdef CONFIG_DEBUG_FS
+ int has_dbgfs;
struct dentry *dbgfs;
#endif
--
1.8.3.2
^ permalink raw reply related
* [PATCH 11/25] powerpc/eeh: Cleanup EEH subsystem variables
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
There're 2 EEH subsystem variables: eeh_subsystem_enabled and
eeh_probe_mode. We needn't maintain 2 variables and we can just
have one variable and introduce different flags. The patch also
introduces additional flag EEH_FORCE_DISABLE, which will be used
to disable EEH subsystem via boot parameter ("eeh=off") in future.
Besides, the patch also introduces flag EEH_ENABLED, which is
changed to disable or enable EEH functionality on the fly through
debugfs entry in future.
With the patch applied, the creteria to check the enabled EEH
functionality is changed to:
!EEH_FORCE_DISABLED && EEH_ENABLED : Enabled
Other cases : Disabled
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/eeh.h | 29 +++++++++++++++++++----------
arch/powerpc/kernel/eeh.c | 31 +++++++++++++++----------------
2 files changed, 34 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/include/asm/eeh.h b/arch/powerpc/include/asm/eeh.h
index f0183e3..f4a9321 100644
--- a/arch/powerpc/include/asm/eeh.h
+++ b/arch/powerpc/include/asm/eeh.h
@@ -32,6 +32,12 @@ struct device_node;
#ifdef CONFIG_EEH
+/* EEH subsystem flags */
+#define EEH_ENABLED 0x1 /* EEH enabled */
+#define EEH_FORCE_DISABLED 0x2 /* EEH disabled */
+#define EEH_PROBE_MODE_DEV 0x4 /* From PCI device */
+#define EEH_PROBE_MODE_DEVTREE 0x8 /* From device tree */
+
/*
* The struct is used to trace PE related EEH functionality.
* In theory, there will have one instance of the struct to
@@ -173,37 +179,40 @@ struct eeh_ops {
int (*restore_config)(struct device_node *dn);
};
+extern int eeh_subsystem_flags;
extern struct eeh_ops *eeh_ops;
-extern bool eeh_subsystem_enabled;
extern raw_spinlock_t confirm_error_lock;
-extern int eeh_probe_mode;
static inline bool eeh_enabled(void)
{
- return eeh_subsystem_enabled;
+ if ((eeh_subsystem_flags & EEH_FORCE_DISABLED) ||
+ !(eeh_subsystem_flags & EEH_ENABLED))
+ return false;
+
+ return true;
}
static inline void eeh_set_enable(bool mode)
{
- eeh_subsystem_enabled = mode;
+ if (mode)
+ eeh_subsystem_flags |= EEH_ENABLED;
+ else
+ eeh_subsystem_flags &= ~EEH_ENABLED;
}
-#define EEH_PROBE_MODE_DEV (1<<0) /* From PCI device */
-#define EEH_PROBE_MODE_DEVTREE (1<<1) /* From device tree */
-
static inline void eeh_probe_mode_set(int flag)
{
- eeh_probe_mode = flag;
+ eeh_subsystem_flags |= flag;
}
static inline int eeh_probe_mode_devtree(void)
{
- return (eeh_probe_mode == EEH_PROBE_MODE_DEVTREE);
+ return (eeh_subsystem_flags & EEH_PROBE_MODE_DEVTREE);
}
static inline int eeh_probe_mode_dev(void)
{
- return (eeh_probe_mode == EEH_PROBE_MODE_DEV);
+ return (eeh_subsystem_flags & EEH_PROBE_MODE_DEV);
}
static inline void eeh_serialize_lock(unsigned long *flags)
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index 69df898..06d2b7c 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -87,22 +87,21 @@
/* Time to wait for a PCI slot to report status, in milliseconds */
#define PCI_BUS_RESET_WAIT_MSEC (5*60*1000)
-/* Platform dependent EEH operations */
-struct eeh_ops *eeh_ops = NULL;
-
-bool eeh_subsystem_enabled = false;
-EXPORT_SYMBOL(eeh_subsystem_enabled);
-
/*
- * EEH probe mode support. The intention is to support multiple
- * platforms for EEH. Some platforms like pSeries do PCI emunation
- * based on device tree. However, other platforms like powernv probe
- * PCI devices from hardware. The flag is used to distinguish that.
- * In addition, struct eeh_ops::probe would be invoked for particular
- * OF node or PCI device so that the corresponding PE would be created
- * there.
+ * EEH probe mode support, which is part of the flags,
+ * is to support multiple platforms for EEH. Some platforms
+ * like pSeries do PCI emunation based on device tree.
+ * However, other platforms like powernv probe PCI devices
+ * from hardware. The flag is used to distinguish that.
+ * In addition, struct eeh_ops::probe would be invoked for
+ * particular OF node or PCI device so that the corresponding
+ * PE would be created there.
*/
-int eeh_probe_mode;
+int eeh_subsystem_flags;
+EXPORT_SYMBOL(eeh_subsystem_flags);
+
+/* Platform dependent EEH operations */
+struct eeh_ops *eeh_ops = NULL;
/* Lock to avoid races due to multiple reports of an error */
DEFINE_RAW_SPINLOCK(confirm_error_lock);
@@ -842,8 +841,8 @@ int eeh_init(void)
&hose_list, list_node)
pci_walk_bus(hose->bus, eeh_ops->dev_probe, NULL);
} else {
- pr_warning("%s: Invalid probe mode %d\n",
- __func__, eeh_probe_mode);
+ pr_warn("%s: Invalid probe mode %x",
+ __func__, eeh_subsystem_flags);
return -EINVAL;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 14/25] powerpc/powernv: Fix endless reporting frozen PE
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
Once one specific PE has been marked as EEH_PE_ISOLATED, it's in
the middile of recovery or removed permenently. We needn't report
the frozen PE again. Otherwise, we will have endless reporting
same frozen PE.
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 35ec394..3a755b5 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -745,6 +745,11 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
* If we can't find the corresponding PE, the
* PEEV / PEST would be messy. So we force an
* fenced PHB so that it can be recovered.
+ *
+ * If the PE has been marked as isolated, that
+ * should have been removed permanently or in
+ * progress with recovery. We needn't report
+ * it again.
*/
if (ioda_eeh_get_pe(hose, frozen_pe_no, pe)) {
*pe = phb_pe;
@@ -753,6 +758,8 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
hose->global_number,
frozen_pe_no);
ret = EEH_NEXT_ERR_FENCED_PHB;
+ } else if ((*pe)->state & EEH_PE_ISOLATED) {
+ ret = EEH_NEXT_ERR_NONE;
} else {
pr_err("EEH: Frozen PE#%x on PHB#%x detected\n",
(*pe)->addr, (*pe)->phb->global_number);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 15/25] powerpc/pseries: Fix overwritten PE state
From: Gavin Shan @ 2014-04-24 8:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Gavin Shan, linux-stable
In-Reply-To: <1398326431-24305-1-git-send-email-gwshan@linux.vnet.ibm.com>
In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always
overwritten by EEH_STATE_NOT_SUPPORT because of the missed
"break" there. The patch fixes the issue.
Reported-by: Joe Perches <joe@perches.com>
Cc: linux-stable <stable@vger.kernel.org>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/eeh_pseries.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/eeh_pseries.c b/arch/powerpc/platforms/pseries/eeh_pseries.c
index 9d58a53..2f1ba64 100644
--- a/arch/powerpc/platforms/pseries/eeh_pseries.c
+++ b/arch/powerpc/platforms/pseries/eeh_pseries.c
@@ -496,6 +496,7 @@ static int pseries_eeh_get_state(struct eeh_pe *pe, int *state)
} else {
result = EEH_STATE_NOT_SUPPORT;
}
+ break;
default:
result = EEH_STATE_NOT_SUPPORT;
}
--
1.8.3.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox