* [PATCH] KVM: PPC: BOOK3S: HV: Don't try to allocate from kernel page allocator for hash page table.
From: Aneesh Kumar K.V @ 2014-05-04 17:25 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
We reserve 5% of total ram for CMA allocation and not using that can
result in us running out of numa node memory with specific
configuration. One caveat is we may not have node local hpt with pinned
vcpu configuration. But currently libvirt also pins the vcpu to cpuset
after creating hash page table.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_64_mmu_hv.c | 23 ++++++-----------------
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index fb25ebc0af0c..f32896ffd784 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -52,7 +52,7 @@ static void kvmppc_rmap_reset(struct kvm *kvm);
long kvmppc_alloc_hpt(struct kvm *kvm, u32 *htab_orderp)
{
- unsigned long hpt;
+ unsigned long hpt = 0;
struct revmap_entry *rev;
struct page *page = NULL;
long order = KVM_DEFAULT_HPT_ORDER;
@@ -64,22 +64,11 @@ long kvmppc_alloc_hpt(struct kvm *kvm, u32 *htab_orderp)
}
kvm->arch.hpt_cma_alloc = 0;
- /*
- * try first to allocate it from the kernel page allocator.
- * We keep the CMA reserved for failed allocation.
- */
- hpt = __get_free_pages(GFP_KERNEL | __GFP_ZERO | __GFP_REPEAT |
- __GFP_NOWARN, order - PAGE_SHIFT);
-
- /* Next try to allocate from the preallocated pool */
- if (!hpt) {
- VM_BUG_ON(order < KVM_CMA_CHUNK_ORDER);
- page = kvm_alloc_hpt(1 << (order - PAGE_SHIFT));
- if (page) {
- hpt = (unsigned long)pfn_to_kaddr(page_to_pfn(page));
- kvm->arch.hpt_cma_alloc = 1;
- } else
- --order;
+ VM_BUG_ON(order < KVM_CMA_CHUNK_ORDER);
+ page = kvm_alloc_hpt(1 << (order - PAGE_SHIFT));
+ if (page) {
+ hpt = (unsigned long)pfn_to_kaddr(page_to_pfn(page));
+ kvm->arch.hpt_cma_alloc = 1;
}
/* Lastly try successively smaller sizes from the page allocator */
--
1.9.1
^ permalink raw reply related
* [PATCH V4] POWERPC: BOOK3S: KVM: Use the saved dar value and generic make_dsisr
From: Aneesh Kumar K.V @ 2014-05-04 17:21 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
Although it's optional IBM POWER cpus always had DAR value set on
alignment interrupt. So don't try to compute these values.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
Changes from V3:
* Use make_dsisr instead of checking feature flag to decide whether to use
saved dsisr or not
arch/powerpc/include/asm/disassemble.h | 34 +++++++++++++++++++++++++++
arch/powerpc/kernel/align.c | 34 +--------------------------
arch/powerpc/kvm/book3s_emulate.c | 43 ++++------------------------------
3 files changed, 40 insertions(+), 71 deletions(-)
diff --git a/arch/powerpc/include/asm/disassemble.h b/arch/powerpc/include/asm/disassemble.h
index 856f8deb557a..6330a61b875a 100644
--- a/arch/powerpc/include/asm/disassemble.h
+++ b/arch/powerpc/include/asm/disassemble.h
@@ -81,4 +81,38 @@ static inline unsigned int get_oc(u32 inst)
{
return (inst >> 11) & 0x7fff;
}
+
+#define IS_XFORM(inst) (get_op(inst) == 31)
+#define IS_DSFORM(inst) (get_op(inst) >= 56)
+
+/*
+ * Create a DSISR value from the instruction
+ */
+static inline unsigned make_dsisr(unsigned instr)
+{
+ unsigned dsisr;
+
+
+ /* bits 6:15 --> 22:31 */
+ dsisr = (instr & 0x03ff0000) >> 16;
+
+ if (IS_XFORM(instr)) {
+ /* bits 29:30 --> 15:16 */
+ dsisr |= (instr & 0x00000006) << 14;
+ /* bit 25 --> 17 */
+ dsisr |= (instr & 0x00000040) << 8;
+ /* bits 21:24 --> 18:21 */
+ dsisr |= (instr & 0x00000780) << 3;
+ } else {
+ /* bit 5 --> 17 */
+ dsisr |= (instr & 0x04000000) >> 12;
+ /* bits 1: 4 --> 18:21 */
+ dsisr |= (instr & 0x78000000) >> 17;
+ /* bits 30:31 --> 12:13 */
+ if (IS_DSFORM(instr))
+ dsisr |= (instr & 0x00000003) << 18;
+ }
+
+ return dsisr;
+}
#endif /* __ASM_PPC_DISASSEMBLE_H__ */
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index 94908af308d8..34f55524d456 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -25,14 +25,13 @@
#include <asm/cputable.h>
#include <asm/emulated_ops.h>
#include <asm/switch_to.h>
+#include <asm/disassemble.h>
struct aligninfo {
unsigned char len;
unsigned char flags;
};
-#define IS_XFORM(inst) (((inst) >> 26) == 31)
-#define IS_DSFORM(inst) (((inst) >> 26) >= 56)
#define INVALID { 0, 0 }
@@ -192,37 +191,6 @@ static struct aligninfo aligninfo[128] = {
};
/*
- * Create a DSISR value from the instruction
- */
-static inline unsigned make_dsisr(unsigned instr)
-{
- unsigned dsisr;
-
-
- /* bits 6:15 --> 22:31 */
- dsisr = (instr & 0x03ff0000) >> 16;
-
- if (IS_XFORM(instr)) {
- /* bits 29:30 --> 15:16 */
- dsisr |= (instr & 0x00000006) << 14;
- /* bit 25 --> 17 */
- dsisr |= (instr & 0x00000040) << 8;
- /* bits 21:24 --> 18:21 */
- dsisr |= (instr & 0x00000780) << 3;
- } else {
- /* bit 5 --> 17 */
- dsisr |= (instr & 0x04000000) >> 12;
- /* bits 1: 4 --> 18:21 */
- dsisr |= (instr & 0x78000000) >> 17;
- /* bits 30:31 --> 12:13 */
- if (IS_DSFORM(instr))
- dsisr |= (instr & 0x00000003) << 18;
- }
-
- return dsisr;
-}
-
-/*
* The dcbz (data cache block zero) instruction
* gives an alignment fault if used on non-cacheable
* memory. We handle the fault mainly for the
diff --git a/arch/powerpc/kvm/book3s_emulate.c b/arch/powerpc/kvm/book3s_emulate.c
index 99d40f8977e8..04c38f049dfd 100644
--- a/arch/powerpc/kvm/book3s_emulate.c
+++ b/arch/powerpc/kvm/book3s_emulate.c
@@ -569,48 +569,14 @@ unprivileged:
u32 kvmppc_alignment_dsisr(struct kvm_vcpu *vcpu, unsigned int inst)
{
- u32 dsisr = 0;
-
- /*
- * This is what the spec says about DSISR bits (not mentioned = 0):
- *
- * 12:13 [DS] Set to bits 30:31
- * 15:16 [X] Set to bits 29:30
- * 17 [X] Set to bit 25
- * [D/DS] Set to bit 5
- * 18:21 [X] Set to bits 21:24
- * [D/DS] Set to bits 1:4
- * 22:26 Set to bits 6:10 (RT/RS/FRT/FRS)
- * 27:31 Set to bits 11:15 (RA)
- */
-
- switch (get_op(inst)) {
- /* D-form */
- case OP_LFS:
- case OP_LFD:
- case OP_STFD:
- case OP_STFS:
- dsisr |= (inst >> 12) & 0x4000; /* bit 17 */
- dsisr |= (inst >> 17) & 0x3c00; /* bits 18:21 */
- break;
- /* X-form */
- case 31:
- dsisr |= (inst << 14) & 0x18000; /* bits 15:16 */
- dsisr |= (inst << 8) & 0x04000; /* bit 17 */
- dsisr |= (inst << 3) & 0x03c00; /* bits 18:21 */
- break;
- default:
- printk(KERN_INFO "KVM: Unaligned instruction 0x%x\n", inst);
- break;
- }
-
- dsisr |= (inst >> 16) & 0x03ff; /* bits 22:31 */
-
- return dsisr;
+ return make_dsisr(inst);
}
ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
{
+#ifdef CONFIG_PPC_BOOK3S_64
+ return vcpu->arch.fault_dar;
+#else
ulong dar = 0;
ulong ra = get_ra(inst);
ulong rb = get_rb(inst);
@@ -635,4 +601,5 @@ ulong kvmppc_alignment_dar(struct kvm_vcpu *vcpu, unsigned int inst)
}
return dar;
+#endif
}
--
1.9.1
^ permalink raw reply related
* [PATCH V4] KVM: PPC: BOOK3S: PR: Enable Little Endian PR guest
From: Aneesh Kumar K.V @ 2014-05-04 17:18 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
This patch make sure we inherit the LE bit correctly in different case
so that we can run Little Endian distro in PR mode
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
Changes from V3:
* Address review comments.
* rebase to new kernel so that intr_msr is moved instead of adding a new variable
* Drop the lock since we are single threaded for PR KVM
arch/powerpc/include/asm/kvm_host.h | 2 +-
arch/powerpc/kernel/asm-offsets.c | 2 +-
arch/powerpc/kvm/book3s_64_mmu.c | 2 +-
arch/powerpc/kvm/book3s_pr.c | 29 ++++++++++++++++++++++++++++-
4 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 1eaea2dea174..d342f8efc843 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -562,6 +562,7 @@ struct kvm_vcpu_arch {
#ifdef CONFIG_PPC_BOOK3S
ulong fault_dar;
u32 fault_dsisr;
+ unsigned long intr_msr;
#endif
#ifdef CONFIG_BOOKE
@@ -654,7 +655,6 @@ struct kvm_vcpu_arch {
spinlock_t tbacct_lock;
u64 busy_stolen;
u64 busy_preempt;
- unsigned long intr_msr;
#endif
};
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index dba8140ebc20..6a4b77d197f3 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -493,7 +493,6 @@ int main(void)
DEFINE(VCPU_DAR, offsetof(struct kvm_vcpu, arch.shregs.dar));
DEFINE(VCPU_VPA, offsetof(struct kvm_vcpu, arch.vpa.pinned_addr));
DEFINE(VCPU_VPA_DIRTY, offsetof(struct kvm_vcpu, arch.vpa.dirty));
- DEFINE(VCPU_INTR_MSR, offsetof(struct kvm_vcpu, arch.intr_msr));
#endif
#ifdef CONFIG_PPC_BOOK3S
DEFINE(VCPU_VCPUID, offsetof(struct kvm_vcpu, vcpu_id));
@@ -528,6 +527,7 @@ int main(void)
DEFINE(VCPU_SLB_NR, offsetof(struct kvm_vcpu, arch.slb_nr));
DEFINE(VCPU_FAULT_DSISR, offsetof(struct kvm_vcpu, arch.fault_dsisr));
DEFINE(VCPU_FAULT_DAR, offsetof(struct kvm_vcpu, arch.fault_dar));
+ DEFINE(VCPU_INTR_MSR, offsetof(struct kvm_vcpu, arch.intr_msr));
DEFINE(VCPU_LAST_INST, offsetof(struct kvm_vcpu, arch.last_inst));
DEFINE(VCPU_TRAP, offsetof(struct kvm_vcpu, arch.trap));
DEFINE(VCPU_CFAR, offsetof(struct kvm_vcpu, arch.cfar));
diff --git a/arch/powerpc/kvm/book3s_64_mmu.c b/arch/powerpc/kvm/book3s_64_mmu.c
index 83da1f868fd5..8231b83c493b 100644
--- a/arch/powerpc/kvm/book3s_64_mmu.c
+++ b/arch/powerpc/kvm/book3s_64_mmu.c
@@ -38,7 +38,7 @@
static void kvmppc_mmu_book3s_64_reset_msr(struct kvm_vcpu *vcpu)
{
- kvmppc_set_msr(vcpu, MSR_SF);
+ kvmppc_set_msr(vcpu, vcpu->arch.intr_msr);
}
static struct kvmppc_slb *kvmppc_mmu_book3s_64_find_slbe(
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index f30cdfee800d..466273aca58b 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -249,7 +249,7 @@ static void kvmppc_recalc_shadow_msr(struct kvm_vcpu *vcpu)
ulong smsr = vcpu->arch.shared->msr;
/* Guest MSR values */
- smsr &= MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE;
+ smsr &= MSR_FE0 | MSR_FE1 | MSR_SF | MSR_SE | MSR_BE | MSR_LE;
/* Process MSR values */
smsr |= MSR_ME | MSR_RI | MSR_IR | MSR_DR | MSR_PR | MSR_EE;
/* External providers the guest reserved */
@@ -1118,6 +1118,15 @@ static int kvmppc_get_one_reg_pr(struct kvm_vcpu *vcpu, u64 id,
case KVM_REG_PPC_HIOR:
*val = get_reg_val(id, to_book3s(vcpu)->hior);
break;
+ case KVM_REG_PPC_LPCR:
+ /*
+ * We are only interested in the LPCR_ILE bit
+ */
+ if (vcpu->arch.intr_msr & MSR_LE)
+ *val = get_reg_val(id, LPCR_ILE);
+ else
+ *val = get_reg_val(id, 0);
+ break;
default:
r = -EINVAL;
break;
@@ -1126,6 +1135,20 @@ static int kvmppc_get_one_reg_pr(struct kvm_vcpu *vcpu, u64 id,
return r;
}
+static void kvmppc_set_lpcr_pr(struct kvm_vcpu *vcpu, u64 new_lpcr)
+{
+ /*
+ * If ILE (interrupt little-endian) has changed, update the
+ * MSR_LE bit in the intr_msr for each vcpu in this vcore.
+ */
+ if ((new_lpcr & LPCR_ILE) != (vcpu->arch.intr_msr & MSR_LE)) {
+ if (new_lpcr & LPCR_ILE)
+ vcpu->arch.intr_msr |= MSR_LE;
+ else
+ vcpu->arch.intr_msr &= ~MSR_LE;
+ }
+}
+
static int kvmppc_set_one_reg_pr(struct kvm_vcpu *vcpu, u64 id,
union kvmppc_one_reg *val)
{
@@ -1136,6 +1159,9 @@ static int kvmppc_set_one_reg_pr(struct kvm_vcpu *vcpu, u64 id,
to_book3s(vcpu)->hior = set_reg_val(id, *val);
to_book3s(vcpu)->hior_explicit = true;
break;
+ case KVM_REG_PPC_LPCR:
+ kvmppc_set_lpcr_pr(vcpu, set_reg_val(id, *val));
+ break;
default:
r = -EINVAL;
break;
@@ -1188,6 +1214,7 @@ static struct kvm_vcpu *kvmppc_core_vcpu_create_pr(struct kvm *kvm,
vcpu->arch.pvr = 0x3C0301;
if (mmu_has_feature(MMU_FTR_1T_SEGMENT))
vcpu->arch.pvr = mfspr(SPRN_PVR);
+ vcpu->arch.intr_msr = MSR_SF;
#else
/* default to book3s_32 (750) */
vcpu->arch.pvr = 0x84202;
--
1.9.1
^ permalink raw reply related
* Boot problems with a PA6T board
From: Christian Zigotzky @ 2014-05-04 16:02 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
The RC 1, 2, and 3 of the kernel 3.15 don't boot on my PA6T board with a
Radeon HD 6870 graphics card.
Screenshot:
http://forum.hyperion-entertainment.biz/download/file.php?id=1060&mode=view
The kernel 3.14 starts without any problems. Has anyone a tip for me,
please?
Cheers,
Christian
^ permalink raw reply
* Re: [PATCH 5/6] powerpc/corenet: Add DPAA FMan support to the SoC device tree(s)
From: Emil Medve @ 2014-05-04 10:59 UTC (permalink / raw)
To: Scott Wood, Kanetkar Shruti-B44454, devicetree,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1398118442.1694.190.camel__272.432543761347$1398129129$gmane$org@snotra.buserror.net>
Hello Scott,
On 04/21/2014 05:14 PM, Scott Wood wrote:
> On Fri, 2014-04-18 at 07:21 -0500, Shruti Kanetkar wrote:
>> FMan 1 Gb/s MACs (dTSEC and mEMAC) have support for SGMII PHYs.
>> Add support for the internal SerDes TBI PHYs
>>
>> Based on prior work by Andy Fleming <afleming@gmail.com>
>>
>> Signed-off-by: Shruti Kanetkar <Shruti@Freescale.com>
>> ---
>> arch/powerpc/boot/dts/fsl/b4860si-post.dtsi | 28 +++++
>> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 51 +++++++++
>> arch/powerpc/boot/dts/fsl/p1023si-post.dtsi | 14 +++
>> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 64 ++++++++++++
>> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 64 ++++++++++++
>> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 104 +++++++++++++++++++
>> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 64 ++++++++++++
>> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 128 +++++++++++++++++++++++
>> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 154 ++++++++++++++++++++++++++++
>> 9 files changed, 671 insertions(+)
>>
>> diff --git a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
>> index cbc354b..45b0ff5 100644
>> --- a/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
>> +++ b/arch/powerpc/boot/dts/fsl/b4860si-post.dtsi
>> @@ -172,6 +172,34 @@
>> compatible = "fsl,b4860-rcpm", "fsl,qoriq-rcpm-2.0";
>> };
>>
>> +/include/ "qoriq-fman3-0-1g-4.dtsi"
>> +/include/ "qoriq-fman3-0-1g-5.dtsi"
>> +/include/ "qoriq-fman3-0-10g-0.dtsi"
>> +/include/ "qoriq-fman3-0-10g-1.dtsi"
>> + fman@400000 {
>> + ethernet@e8000 {
>> + tbi-handle = <&tbi4>;
>> + };
>
> Binding needed
>
> Where is the "reg" for these unit addresses?
As I said, the bulk of the FMan work comes from another team. Here we
need just enough to hook up the MDIO and PHY nodes. I'd really like to
be able to make progress on this without waiting for that moment in time
we can get the entire FMan binding in place
>> + mdio@e9000 {
>> + tbi4: tbi-phy@8 {
>> + reg = <0x8>;
>> + device_type = "tbi-phy";
>> + };
>> + };
>
> Binding needed for tbi-phy device_type
I guess that's fair (BTW, you accepted tbi-phy nodes/device-type before
without a binding)
> Why are we using device_type at all for this?
That's what the upstream driver is looking for. Anyway, most days PHYs
can be discovered so they don't use/need compatible properties. That's I
guess part of the reason we don't have bindings for them PHY nodes
However, what you can't discover is how they are wired to the MAC(s) so
we still need some nodes in the device tree to convey that. Also, when
looking for a specific kind of PHY, such as TBI, device_type works
easier then parsing compatibles from various vendors or so
Cheers,
^ permalink raw reply
* Re: [PATCH v4 8/8] DMA: Freescale: add suspend resume functions for DMA driver
From: Hongbo Zhang @ 2014-05-04 10:22 UTC (permalink / raw)
To: Vinod Koul
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <20140502164604.GB32284@intel.com>
On 05/03/2014 12:46 AM, Vinod Koul wrote:
> On Fri, Apr 18, 2014 at 04:17:51PM +0800, hongbo.zhang@freescale.com wrote:
>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>
>> This patch adds suspend resume functions for Freescale DMA driver.
>> .prepare callback is used to stop further descriptors from being added into the
>> pending queue, and also issue pending queues into execution if there is any.
>> .suspend callback makes sure all the pending jobs are cleaned up and all the
>> channels are idle, and save the mode registers.
>> .resume callback re-initializes the channels by restore the mode registers.
>>
>> +
>> +static const struct dev_pm_ops fsldma_pm_ops = {
>> + .prepare = fsldma_prepare,
>> + .suspend = fsldma_suspend,
>> + .resume = fsldma_resume,
>> +};
> I think this is not correct. We discussed this sometime back on list. The
> DMAengine drivers should use late resume and early suspend to ensure they get
> suspended after clients (who should use normal ones) and resume before them
>
OK, will update it like this:
use .suspend to take place of current .prepare
use .suspend_late to take place of current .suspend
use .resume_early to take place of current .resume
^ permalink raw reply
* Re: [PATCH v4 7/8] DMA: Freescale: use spin_lock_bh instead of spin_lock_irqsave
From: Hongbo Zhang @ 2014-05-04 8:40 UTC (permalink / raw)
To: Vinod Koul
Cc: leo.li, vkoul, linux-kernel, scottwood, dmaengine, dan.j.williams,
linuxppc-dev
In-Reply-To: <20140502165143.GI32284@intel.com>
On 05/03/2014 12:51 AM, Vinod Koul wrote:
> On Fri, Apr 18, 2014 at 04:17:50PM +0800, hongbo.zhang@freescale.com wrote:
>> From: Hongbo Zhang <hongbo.zhang@freescale.com>
>>
>> The usage of spin_lock_irqsave() is a stronger locking mechanism than is
>> required throughout the driver. The minimum locking required should be used
>> instead. Interrupts will be turned off and context will be saved, it is
>> unnecessary to use irqsave.
>>
>> This patch changes all instances of spin_lock_irqsave() to spin_lock_bh(). All
>> manipulation of protected fields is done using tasklet context or weaker, which
>> makes spin_lock_bh() the correct choice.
>>
> This doesnt apply, perhpas due to depends on 6/8
>
So let's wait for the review result of 6/8.
^ permalink raw reply
* [PATCH v2 02/13] PCI: Introduce new pci_is_bridge() helper function
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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 | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index aab57b4..9f5f89e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -477,6 +477,19 @@ static inline bool pci_is_root_bus(struct pci_bus *pbus)
return !(pbus->parent);
}
+/**
+ * pci_is_bridge - check if the PCI device is a bridge
+ * @dev: PCI device
+ *
+ * Return true if the PCI device is bridge whether it has subordinate
+ * or not.
+ */
+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 v2 12/13] PCI, pcmcia: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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/pcmcia/cardbus.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
index 8bde619..4fe4cc4 100644
--- a/drivers/pcmcia/cardbus.c
+++ b/drivers/pcmcia/cardbus.c
@@ -78,8 +78,7 @@ int __ref cb_alloc(struct pcmcia_socket *s)
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);
/*
--
1.7.1
^ permalink raw reply related
* [PATCH v2 13/13] PCI, pciehp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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/pciehp_pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/pciehp_pci.c b/drivers/pci/hotplug/pciehp_pci.c
index 1b53306..b6cb1df 100644
--- a/drivers/pci/hotplug/pciehp_pci.c
+++ b/drivers/pci/hotplug/pciehp_pci.c
@@ -62,8 +62,7 @@ int pciehp_configure_device(struct slot *p_slot)
}
list_for_each_entry(dev, &parent->devices, bus_list)
- 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);
pci_assign_unassigned_bridge_resources(bridge);
--
1.7.1
^ permalink raw reply related
* [PATCH v2 07/13] sparc/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
arch/sparc/kernel/pci.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 1555bbc..857ad77 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -543,8 +543,7 @@ static void pci_of_scan_bus(struct pci_pbm_info *pbm,
printk("PCI: dev header type: %x\n",
dev->hdr_type);
- if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
- dev->hdr_type == PCI_HEADER_TYPE_CARDBUS)
+ if (pci_is_bridge(dev))
of_scan_pci_bridge(pbm, child, dev);
}
}
--
1.7.1
^ permalink raw reply related
* [PATCH v2 03/13] PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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/pci-acpi.c | 8 +-------
drivers/pci/probe.c | 3 +--
drivers/pci/setup-bus.c | 4 +---
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index f49abef..ca4927b 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -309,13 +309,7 @@ static struct acpi_device *acpi_pci_find_companion(struct device *dev)
bool check_children;
u64 addr;
- /*
- * pci_is_bridge() is not suitable here, because pci_dev->subordinate
- * is set only after acpi_pci_find_device() has been called for the
- * given device.
- */
- check_children = pci_dev->hdr_type == PCI_HEADER_TYPE_BRIDGE
- || pci_dev->hdr_type == PCI_HEADER_TYPE_CARDBUS;
+ check_children = pci_is_bridge(pci_dev);
/* Please ref to ACPI spec for the syntax of _ADR */
addr = (PCI_SLOT(pci_dev->devfn) << 16) | PCI_FUNC(pci_dev->devfn);
return acpi_find_child_device(ACPI_COMPANION(dev->parent), addr,
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef09f5f..f831dd8 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1670,8 +1670,7 @@ unsigned int pci_scan_child_bus(struct pci_bus *bus)
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/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 138bdd6..e399d00 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1629,9 +1629,7 @@ void pci_assign_unassigned_bus_resources(struct pci_bus *bus)
down_read(&pci_bus_sem);
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 (dev->subordinate)
+ if (pci_is_bridge(dev) && pci_has_subordinate(dev))
__pci_bus_size_bridges(dev->subordinate,
&add_list);
up_read(&pci_bus_sem);
--
1.7.1
^ permalink raw reply related
* [PATCH v2 10/13] PCI, cpcihp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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 v2 04/13] x86/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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 v2 06/13] powerpc/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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 v2 11/13] PCI, acpiphp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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 v2 09/13] PCI, shpchp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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 v2 05/13] IA64/PCI: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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
* [PATCH v2 00/13] Refactor pci_is_brdige() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
v1->v2: Add comments for new pci_is_bridge().
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. PCI Spec define the pci
device is a bridge by the dev->hdr_type = 0x01 || 0x02.
There is no guarantee that a PCI bridge must attached a subordinate bus.
When PCI bridge is created but before the scan child bus, it has no
subordinate bus. Also users can remove the pci bus using
interface pci_remove_bus() in remove.c.
So use new pci_is_bridge() check if the PCI device is bridge is better
choice. If user want check PCI bridge whether has a subordinate bus,
pci_has_subordinate() is a candidate.
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 | 13 +++++++++++++
17 files changed, 32 insertions(+), 41 deletions(-)
^ permalink raw reply
* [PATCH v2 08/13] PCI, rpaphp: Use new pci_is_bridge() to simplify code
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-1-git-send-email-wangyijing@huawei.com>
Now we can use new pci_is_bridge() helper function
to simplify code.
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
---
drivers/pci/hotplug/rpadlpar_core.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/rpadlpar_core.c b/drivers/pci/hotplug/rpadlpar_core.c
index 4fcdeed..7660232 100644
--- a/drivers/pci/hotplug/rpadlpar_core.c
+++ b/drivers/pci/hotplug/rpadlpar_core.c
@@ -157,8 +157,7 @@ static void dlpar_pci_add_bus(struct device_node *dn)
}
/* Scan below the new bridge */
- 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);
/* Map IO space for child bus, which may or may not succeed */
--
1.7.1
^ permalink raw reply related
* [PATCH v2 01/13] PCI: rename pci_is_bridge() to pci_has_subordinate()
From: Yijing Wang @ 2014-05-04 4:23 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64, x86, Yijing Wang, linux-pci, sparclinux,
Thomas Gleixner, linuxppc-dev, David S. Miller
In-Reply-To: <1399177428-3784-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
* Re: [PATCH 00/13] Refactor pci_is_brdige() to simplify code
From: Yijing Wang @ 2014-05-04 4:16 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Tony Luck, linux-ia64@vger.kernel.org, x86@kernel.org,
linux-kernel@vger.kernel.org, sparclinux, Thomas Gleixner,
linuxppc-dev, David S. Miller
In-Reply-To: <CAErSpo4fa=fmajhxGA7PRm42S1fS2wV_7w+EWaVh_qiawRAQxA@mail.gmail.com>
> This needs to be posted to the linux-pci list. The fact that it
> wasn't means it's not in patchwork, so it's not on my to-do list.
>
> Currently we have one interface: pci_is_bridge().
>
> After your series, we would have two interfaces: pci_is_bridge() and
> pci_has_subordinate(). Presumably, both are used, and you should
> explain how you decided which to use at each place.
>
> I assume the difference is that the old pci_is_bridge() is true for a
> bridge that has a subordinate bus. The new pci_is_bridge() is true
> for any bridge, even if there is no subordinate bus. When do we even
> have a bridge with no subordinate bus? This is the sort of stuff you
> need to explain so we know why we should apply these patches.
>
Hi Bjorn, sorry forgot to cc pci list, will resend the v2 patchset with
some new description for new pci_is_bridge().
>
>> 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(-)
>>
>>
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup"
From: Alexander Graf @ 2014-05-03 22:14 UTC (permalink / raw)
To: mihai.caraman@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <1399072472827.57968@freescale.com>
Am 03.05.2014 um 01:14 schrieb "mihai.caraman@freescale.com" <mihai.caraman@=
freescale.com>:
>> From: Alexander Graf <agraf@suse.de>
>> Sent: Friday, May 2, 2014 12:24 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-dev@lists.ozla=
bs.org
>> Subject: Re: [PATCH v2 1/4] KVM: PPC: e500mc: Revert "add load inst fixup=
"
>>=20
>>> On 05/01/2014 02:45 AM, Mihai Caraman wrote:
>>> The commit 1d628af7 "add load inst fixup" made an attempt to handle
>>> failures generated by reading the guest current instruction. The fixup
>>> code that was added works by chance hiding the real issue.
>>>=20
>>> Load external pid (lwepx) instruction, used by KVM to read guest
>>> instructions, is executed in a subsituted guest translation context
>>> (EPLC[EGS] =3D 1). In consequence lwepx's TLB error and data storage
>>> interrupts need to be handled by KVM, even though these interrupts
>>> are generated from host context (MSR[GS] =3D 0).
>>>=20
>>> Currently, KVM hooks only interrupts generated from guest context
>>> (MSR[GS] =3D 1), doing minimal checks on the fast path to avoid host
>>> performance degradation. As a result, the host kernel handles lwepx
>>> faults searching the faulting guest data address (loaded in DEAR) in
>>> its own Logical Partition ID (LPID) 0 context. In case a host translatio=
n
>>> is found the execution returns to the lwepx instruction instead of the
>>> fixup, the host ending up in an infinite loop.
>>>=20
>>> Revert the commit "add load inst fixup". lwepx issue will be addressed
>>> in a subsequent patch without needing fixup code.
>>>=20
>>> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
>>=20
>> Just a random idea: Could we just switch IVOR2 during the critical lwepx
>> phase? In fact, we could even do that later when we're already in C code
>> and try to recover the last instruction. The code IVOR2 would point to
>> would simply set the register we're trying to read to as LAST_INST_FAIL
>> and rfi.
>=20
> This was the first idea that sprang to my mind inspired from how DO_KVM
> is hooked on PR. I actually did a simple POC for e500mc/e5500, but this wi=
ll
> not work on e6500 which has shared IVORs between HW threads.
What if we combine the ideas? On read we flip the IVOR to a separate handler=
that checks for a field in the PACA. Only if that field is set, we treat th=
e fault as kvm fault, otherwise we jump into the normal handler.
I suppose we'd have to also take a lock to make sure we don't race with the o=
ther thread when it wants to also read a guest instruction, but you get the i=
dea.
I have no idea whether this would be any faster, it's more of a brainstormin=
g thing really. But regardless this patch set would be a move into the right=
direction.
Btw, do we have any guarantees that we don't get scheduled away before we ru=
n kvmppc_get_last_inst()? If we run on a different core we can't read the in=
st anymore. Hrm.
Alex
^ permalink raw reply
* RE: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
From: curieux.khetan @ 2014-05-03 16:40 UTC (permalink / raw)
To: sanjeev sharma
Cc: scottwood@freescale.com, linuxppc-dev@lists.ozlabs.org,
Valdis Kletnieks, kernelnewbies
[-- Attachment #1: Type: text/plain, Size: 6685 bytes --]
hi thanks for your reply. the problem is still there. At 800MHZ core its working fine but for 1Ghz its still happening.
Any suggestion or check point I can monitor.
From: sanjeev sharma
Sent: 02 May 2014 09:22
To: Ashish
CC: Valdis Kletnieks; scottwood@freescale.com; linuxppc-dev@lists.ozlabs.org; kernelnewbies
Subject: Re: MPC8641 based custom board Kernel stuck at 1000Mhz core clock
Hello Ashish,
is this issue resolved and is this always happening when you are changing core to 1Ghz because i am confused here with sometime Keyword.
Regards
Sanjeev Sharma
On Fri, Apr 4, 2014 at 1:12 PM, Ashish <curieux.khetan@gmail.com> wrote:
On Thursday 03 April 2014 08:55 AM, sanjeev sharma wrote:
Are you able to capture kernel logs ?
Regards
Sanjeev Sharma
On Thu, Mar 27, 2014 at 10:01 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 27 Mar 2014 16:04:37 +0530, Ashish said:
> Hi,
>
> I am using MPC8641-HPCN based custom board and able to boot linux at
> MPX clock 400Mhz and core clock 800mhz. When I am increasing core
> frequency ie MPX clock at 400Mhz and core at 1Ghz, kernel stuck.
Step 0: Prove to us that your core actually runs reliable and stably at 1Ghz.
Step 1: Figure out *where* it gets stuck. If you have earlyprintk working on
your board, adding 'initcall_debug ignore_loglevel' to the kernel cmdline often
helps track down where a kernel hangs during boot.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi,
Does kernel logs means debugging information that kernel prints while booting using printk or it is something else?
Here is kernel boot logs that kernel printed while booting...
U-Boot 2013.04 (Jan 27 2014 - 11:21:21)
Unicore software on multiprocessor system!!
To enable mutlticore build define CONFIG_MP
CPU: 8641, Version: 2.1, (0x80900021)
Core: E600 Core 0, Version: 2.2, (0x80040202)
Clock Configuration:
CPU:1000 MHz, MPX:400 MHz
DDR:200 MHz (400 MT/s data rate), LBC:25 MHz
L1: D-cache 32 KB enabled
I-cache 32 KB enabled
L2: 512 KB enabled
Board: MPC8641-HPCN
I2C: ready
DRAM: 512 MiB
SDRAM test phase 1:
SDRAM test phase 2:
SDRAM test passed.
Flash: 16 MiB
EEPROM: NXID v1
In: serial
Out: serial
Err: serial
Net: eTSEC1, eTSEC2, eTSEC3, eTSEC4 [PRIME]
Hit any key to stop autoboot:
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uRamdisk'.
Load address: 0x600000
Loading: * #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
##################################################
13.1 MiB/s
done
Bytes transferred = 22680188 (15a127c hex)
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'uImage'.
Load address: 0x16000000
Loading: * #################################################################
#################################################################
#######################################
14 MiB/s
done
Bytes transferred = 2476304 (25c910 hex)
Speed: 1000, full duplex
Using eTSEC4 device
TFTP from server 192.168.10.1; our IP address is 192.168.10.2
Filename 'mpc8641_hpcn.dtb'.
Load address: 0x14000000
Loading: * #
2.6 MiB/s
done
Bytes transferred = 5540 (15a4 hex)
## Booting kernel from Legacy Image at 16000000 ...
Image Name: Linux-3.13.6
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 2476240 Bytes = 2.4 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00600000 ...
Image Name: rootfs
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 22680124 Bytes = 21.6 MiB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
## Flattened Device Tree blob at 14000000
Booting using the fdt blob at 0x14000000
Uncompressing Kernel Image ... OK
Loading Ramdisk to 1e923000, end 1fec423c ... OK
Loading Device Tree to 007fb000, end 007ff5a3 ... OK (some times it stucking here)
Using MPC86xx HPCN machine description
Total memory = 512MB; using 1024kB for hash table (at cff00000)
Linux version 3.13.6 (ashish@ashish-VirtualBox) (gcc version 4.7.2 (GCC) ) #8 Sat Mar 29 10:31:58 IST 2014
Found initrd at 0xde923000:0xdfec423c
bootconsole [udbg0] enabled
setup_arch: bootmem
mpc86xx_hpcn_setup_arch()
MPC86xx HPCN board from Freescale Semiconductor
arch: exit
Zone ranges:
DMA [mem 0x00000000-0x1fffffff]
Normal empty
HighMem empty
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x00000000-0x1fffffff] (some times here)
[-- Attachment #2: Type: text/html, Size: 10983 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] powerpc/corenet: Create the dts components for the DPAA FMan
From: Emil Medve @ 2014-05-03 10:02 UTC (permalink / raw)
To: Scott Wood, Shruti Kanetkar, devicetree,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1398118262.1694.188.camel__8135.6513932862$1398128944$gmane$org@snotra.buserror.net>
Hello Scott,
On 04/21/2014 05:11 PM, Scott Wood wrote:
> On Fri, 2014-04-18 at 07:21 -0500, Shruti Kanetkar wrote:
>> +fman@400000 {
>> + mdio@f1000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,fman-xmdio";
>> + reg = <0xf1000 0x1000>;
>> + };
>> +};
>
> I'd like to see a complete fman binding before we start adding pieces.
The driver for the FMan 10 Gb/s MDIO has upstreamed a couple of years
ago: '9f35a73 net/fsl: introduce Freescale 10G MDIO driver', granted
without a binding writeup. This patch series should probably include a
binding blurb. However, let's not gate this patchset on a complete
binding for the FMan
As you know we don't own the FMan work and the FMan work is... not ready
for upstreaming. In an attempt to make some sort of progress we've
decided to upstream the pieces that are less controversial and MDIO is
an obvious candidate
>> +fman@400000 {
>> + mdio0: mdio@e1120 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "fsl,fman-mdio";
>> + reg = <0xe1120 0xee0>;
>> + };
>> +};
>
> What is the difference between "fsl,fman-mdio" and "fsl,fman-xmdio"? I
> don't see the latter on the list of compatibles in patch 3/6.
'fsl,fman-mdio' is the 1 Gb/s MDIO (Clause 22 only). 'fsl,fman-xmdio' is
the 10 Gb/s MDIO (Clause 45 only). We can respin this patch wi
I believe 'fsl,fman-mdio' (and others on that list) was added
gratuitously as the FMan MDIO is completely compatible with the
eTSEC/gianfar MDIO driver, but we can deal with that later
> Within each category, is the exact fman version discoverable from the
> mdio registers?
No, but that's irrelevant as that's not the difference between the two
compatibles
>> diff --git a/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi
>> new file mode 100644
>> index 0000000..ced5786
>> --- /dev/null
>> +++ b/arch/powerpc/boot/dts/fsl/qoriq-fman3-1.dtsi
>> @@ -0,0 +1,52 @@
>> +/*
>> + * QorIQ FMan v3 device tree stub [ controller @ offset 0x500000 ]
>> + *
>> + * Copyright 2012 Freescale Semiconductor Inc.
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions are met:
>> + * * Redistributions of source code must retain the above copyright
>> + * notice, this list of conditions and the following disclaimer.
>> + * * Redistributions in binary form must reproduce the above copyright
>> + * notice, this list of conditions and the following disclaimer in the
>> + * documentation and/or other materials provided with the distribution.
>> + * * Neither the name of Freescale Semiconductor nor the
>> + * names of its contributors may be used to endorse or promote products
>> + * derived from this software without specific prior written permission.
>> + *
>> + *
>> + * ALTERNATIVELY, this software may be distributed under the terms of the
>> + * GNU General Public License ("GPL") as published by the Free Software
>> + * Foundation, either version 2 of that License or (at your option) any
>> + * later version.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
>> + * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
>> + * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
>> + * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
>> + * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
>> + * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
>> + * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
>> + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>> + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
>> + * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> +*/
>> +
>> +fman@500000 {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "simple-bus";
>
> Why is this simple-bus?
Because that's the translation type for the FMan sub-nodes. We need it
now to get the MDIO nodes probed and we'll needed later to probe other
nodes/devices that will have standalone drivers: MAC, MURAM. etc. I
don't think we need to add another entry into the platform probe list
(which is already quite long) as a simple synonym
>> +
>> + /* mdio nodes for fman v3 @ 0x500000 */
>> + mdio@fc000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0xfc000 0x1000>;
>> + };
>> +
>> + mdio@fd000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + reg = <0xfd000 0x1000>;
>> + };
>> +};
>
> Where's the compatible? Why is this file different from all the others?
The FMan v3 MDIO block (supports both Clause 22/45) is compatible with
the FMan v2 10 Gb/s MDIO (the xgmac-mdio driver). However, the driver
needs a small clean-up patch (still in internal review) that will get it
working for FMan v3 MDIO. With that patch will add the compatible to
these nodes. However, we need these nodes now for the board level MDIO
bus muxing support (included in this patchset)
Cheers,
^ permalink raw reply
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