* [PATCH 10/13] PCI, cpcihp: 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/cpci_hotplug_pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/cpci_hotplug_pci.c b/drivers/pci/hotplug/cpci_hotplug_pci.c
index 8c14648..9843371 100644
--- a/drivers/pci/hotplug/cpci_hotplug_pci.c
+++ b/drivers/pci/hotplug/cpci_hotplug_pci.c
@@ -289,8 +289,7 @@ int __ref cpci_configure_slot(struct slot *slot)
list_for_each_entry(dev, &parent->devices, bus_list)
if (PCI_SLOT(dev->devfn) != PCI_SLOT(slot->devfn))
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 02/13] PCI: Introduce new pci_is_bridge() helper function
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>
PCIe Spec define the PCI bridge is the PCI device
which header type(bit 0 through 6) is 0x1(PCI bridge)
or 0x2(CardBus bridge).
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
include/linux/pci.h | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..827077a 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -477,6 +477,12 @@ static inline bool pci_is_root_bus(struct pci_bus *pbus)
return !(pbus->parent);
}
+static inline bool pci_is_bridge(struct pci_dev *dev)
+{
+ return dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
+ dev->hdr_type == PCI_HEADER_TYPE_CARDBUS;
+}
+
static inline struct pci_dev *pci_upstream_bridge(struct pci_dev *dev)
{
dev = pci_physfn(dev);
--
1.7.1
^ permalink raw reply related
* [PATCH 00/13] Refactor pci_is_brdige() 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
This patchset rename the current pci_is_bridge() to pci_has_subordinate(),
and introduce a new pci_is_bridge() which determine pci bridge by check
dev->hdr_type. The new one is more accurate. PCIe Spec define the pci
device is a bridge by the dev->hdr_type = 0x01 || 0x02.
Yijing Wang (13):
PCI: rename pci_is_bridge() to pci_has_subordinate()
PCI: Introduce new pci_is_bridge() helper function
PCI: Use new pci_is_bridge() to simplify code
x86/PCI: Use new pci_is_bridge() to simplify code
IA64/PCI: Use new pci_is_bridge() to simplify code
powerpc/PCI: Use new pci_is_bridge() to simplify code
sparc/PCI: Use new pci_is_bridge() to simplify code
PCI, rpaphp: Use new pci_is_bridge() to simplify code
PCI, shpchp: Use new pci_is_bridge() to simplify code
PCI, cpcihp: Use new pci_is_bridge() to simplify code
PCI, acpiphp: Use new pci_is_bridge() to simplify code
PCI, pcmcia: Use new pci_is_bridge() to simplify code
PCI, pciehp: Use new pci_is_bridge() to simplify code
arch/ia64/pci/fixup.c | 4 +---
arch/powerpc/kernel/pci-hotplug.c | 3 +--
arch/powerpc/kernel/pci_of_scan.c | 3 +--
arch/sparc/kernel/pci.c | 3 +--
arch/x86/pci/fixup.c | 4 +---
drivers/pci/hotplug/acpiphp_glue.c | 3 +--
drivers/pci/hotplug/cpci_hotplug_pci.c | 3 +--
drivers/pci/hotplug/pciehp_pci.c | 3 +--
drivers/pci/hotplug/rpadlpar_core.c | 3 +--
drivers/pci/hotplug/shpchp_pci.c | 3 +--
drivers/pci/pci-acpi.c | 8 +-------
drivers/pci/pci-driver.c | 8 ++++----
drivers/pci/pci.h | 2 +-
drivers/pci/probe.c | 3 +--
drivers/pci/setup-bus.c | 4 +---
drivers/pcmcia/cardbus.c | 3 +--
include/linux/pci.h | 6 ++++++
17 files changed, 25 insertions(+), 41 deletions(-)
^ permalink raw reply
* [PATCH 04/13] x86/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/x86/pci/fixup.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 94ae9ae..e5f000c 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -337,9 +337,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
* [PATCH 01/13] PCI: rename pci_is_bridge() to pci_has_subordinate()
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>
pci_is_bridge() which seems to determine whether device is a bridge,
returns true only when the subordinate bus exists. This confuses
people. PCI device is a bridge means its header type(bit 0 through 6)
is 0x1(PCI bridge) or 0x2(CardBus bridge). Rename the current
pci_is_bridge() helper function to pci_has_subordinate().
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/pci-driver.c | 8 ++++----
drivers/pci/pci.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index d911e0c..b7850cb 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -580,14 +580,14 @@ static void pci_pm_default_resume(struct pci_dev *pci_dev)
{
pci_fixup_device(pci_fixup_resume, pci_dev);
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_enable_wake(pci_dev, PCI_D0, false);
}
static void pci_pm_default_suspend(struct pci_dev *pci_dev)
{
/* Disable non-bridge devices without PM support */
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_disable_enabled_device(pci_dev);
}
@@ -717,7 +717,7 @@ static int pci_pm_suspend_noirq(struct device *dev)
if (!pci_dev->state_saved) {
pci_save_state(pci_dev);
- if (!pci_is_bridge(pci_dev))
+ if (!pci_has_subordinate(pci_dev))
pci_prepare_to_sleep(pci_dev);
}
@@ -971,7 +971,7 @@ static int pci_pm_poweroff_noirq(struct device *dev)
return error;
}
- if (!pci_dev->state_saved && !pci_is_bridge(pci_dev))
+ if (!pci_dev->state_saved && !pci_has_subordinate(pci_dev))
pci_prepare_to_sleep(pci_dev);
/*
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 6bd0822..65108fc 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -77,7 +77,7 @@ static inline void pci_wakeup_event(struct pci_dev *dev)
pm_wakeup_event(&dev->dev, 100);
}
-static inline bool pci_is_bridge(struct pci_dev *pci_dev)
+static inline bool pci_has_subordinate(struct pci_dev *pci_dev)
{
return !!(pci_dev->subordinate);
}
--
1.7.1
^ permalink raw reply related
* [PATCH 06/13] powerpc/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/powerpc/kernel/pci-hotplug.c | 3 +--
arch/powerpc/kernel/pci_of_scan.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/pci-hotplug.c b/arch/powerpc/kernel/pci-hotplug.c
index c1e17ae..5b78917 100644
--- a/arch/powerpc/kernel/pci-hotplug.c
+++ b/arch/powerpc/kernel/pci-hotplug.c
@@ -98,8 +98,7 @@ void pcibios_add_pci_devices(struct pci_bus * bus)
max = bus->busn_res.start;
for (pass = 0; pass < 2; pass++) {
list_for_each_entry(dev, &bus->devices, bus_list) {
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
max = pci_scan_bridge(bus, dev,
max, pass);
}
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index 83c26d8..059e244 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -362,8 +362,7 @@ static void __of_scan_bus(struct device_node *node, struct pci_bus *bus,
/* Now scan child busses */
list_for_each_entry(dev, &bus->devices, bus_list) {
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
+ if (pci_is_bridge(dev)) {
of_scan_pci_bridge(dev);
}
}
--
1.7.1
^ permalink raw reply related
* [PATCH 11/13] PCI, acpiphp: 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/acpiphp_glue.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c b/drivers/pci/hotplug/acpiphp_glue.c
index bccc27e..f1f9bd1 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -516,8 +516,7 @@ static void __ref enable_slot(struct acpiphp_slot *slot)
if (PCI_SLOT(dev->devfn) != slot->device)
continue;
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS) {
+ if (pci_is_bridge(dev)) {
max = pci_scan_bridge(bus, dev, max, pass);
if (pass && dev->subordinate) {
check_hotplug_bridge(slot, dev);
--
1.7.1
^ permalink raw reply related
* [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
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