* [PATCH v2 0/3] POWER8 PMU bugfixes
From: Joel Stanley @ 2014-07-08 6:38 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev
These three patches are required for correct operation of perf counters on
POWER8 boxes when running KVM guests. There were two bugs; not clearing MMCR2
and writing over the saved value when entering a guest. However the first
obscured the second.
Thanks to who mpe helped diagnose the issue and pointed out the fix.
V2:
Add comment from mpe
Joel Stanley (3):
powerpc/kvm: Remove redundant save of SIER AND MMCR2
powerpc/perf: Add PPMU_ARCH_207S define
powerpc/perf: Clear MMCR2 when enabling PMU
arch/powerpc/include/asm/perf_event_server.h | 3 +--
arch/powerpc/kvm/book3s_hv_interrupts.S | 5 -----
arch/powerpc/perf/core-book3s.c | 9 ++++++---
arch/powerpc/perf/power8-pmu.c | 2 +-
4 files changed, 8 insertions(+), 11 deletions(-)
--
2.0.0
^ permalink raw reply
* Re: powerpc allyesconfig fix
From: Stephen Rothwell @ 2014-07-08 6:04 UTC (permalink / raw)
To: Nicholas Krause
Cc: agraf, linux-kernel, michael, paulus, anton, mahesh, linuxppc-dev,
Guenter Roeck
In-Reply-To: <1404795849-25609-1-git-send-email-xerofoify@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 548 bytes --]
Hi Nicholas,
On Tue, 8 Jul 2014 01:04:09 -0400 Nicholas Krause <xerofoify@gmail.com> wrote:
>
> powerpc:allmodconfig has been failing for some time with the following
> error.
This patch has already bee submitted directly by Guenter, however for
future reference: when you submit someone else's patch, you should
include a From line as the first line of the email body containing their
email address and you should include a Signed-off-by line from yourself.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH v11 4/7] powerpc: add pmd_[dirty|mkclean] for THP
From: Minchan Kim @ 2014-07-08 6:03 UTC (permalink / raw)
To: Andrew Morton
Cc: Jason Evans, Rik van Riel, Minchan Kim, Aneesh Kumar K.V,
Linux API, Hugh Dickins, linux-kernel, linux-mm, Zhang Yanfei,
Michael Kerrisk, KOSAKI Motohiro, Johannes Weiner,
Kirill A. Shutemov, linuxppc-dev, Paul Mackerras, Mel Gorman
In-Reply-To: <1404799424-1120-1-git-send-email-minchan@kernel.org>
MADV_FREE needs pmd_dirty and pmd_mkclean for detecting recent
overwrite of the contents since MADV_FREE syscall is called for
THP page.
This patch adds pmd_dirty and pmd_mkclean for THP page MADV_FREE
support.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index eb9261024f51..c9a4bbe8e179 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -468,9 +468,11 @@ static inline pte_t *pmdp_ptep(pmd_t *pmd)
#define pmd_pfn(pmd) pte_pfn(pmd_pte(pmd))
#define pmd_young(pmd) pte_young(pmd_pte(pmd))
+#define pmd_dirty(pmd) pte_dirty(pmd_pte(pmd))
#define pmd_mkold(pmd) pte_pmd(pte_mkold(pmd_pte(pmd)))
#define pmd_wrprotect(pmd) pte_pmd(pte_wrprotect(pmd_pte(pmd)))
#define pmd_mkdirty(pmd) pte_pmd(pte_mkdirty(pmd_pte(pmd)))
+#define pmd_mkclean(pmd) pte_pmd(pte_mkclean(pmd_pte(pmd)))
#define pmd_mkyoung(pmd) pte_pmd(pte_mkyoung(pmd_pte(pmd)))
#define pmd_mkwrite(pmd) pte_pmd(pte_mkwrite(pmd_pte(pmd)))
--
2.0.0
^ permalink raw reply related
* [PATCH] powerpc/cell: Fix compilation with CONFIG_COREDUMP=n
From: Michael Ellerman @ 2014-07-08 6:00 UTC (permalink / raw)
To: linuxppc-dev
Commit 046d662f4818 "coredump: make core dump functionality optional"
made the coredump optional, but didn't update the spufs code that
depends on it. That leads to build errors such as:
arch/powerpc/platforms/built-in.o: In function `.spufs_arch_write_note':
coredump.c:(.text+0x22cd4): undefined reference to `.dump_emit'
coredump.c:(.text+0x22cf4): undefined reference to `.dump_emit'
coredump.c:(.text+0x22d0c): undefined reference to `.dump_align'
coredump.c:(.text+0x22d48): undefined reference to `.dump_emit'
coredump.c:(.text+0x22e7c): undefined reference to `.dump_skip'
Fix it by adding some ifdefs in the cell code.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
arch/powerpc/platforms/cell/spu_syscalls.c | 2 ++
arch/powerpc/platforms/cell/spufs/Makefile | 3 ++-
arch/powerpc/platforms/cell/spufs/syscalls.c | 6 ++++--
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spu_syscalls.c b/arch/powerpc/platforms/cell/spu_syscalls.c
index 38e0a1a5cec3..5e6e0bad6db6 100644
--- a/arch/powerpc/platforms/cell/spu_syscalls.c
+++ b/arch/powerpc/platforms/cell/spu_syscalls.c
@@ -111,6 +111,7 @@ asmlinkage long sys_spu_run(int fd, __u32 __user *unpc, __u32 __user *ustatus)
return ret;
}
+#ifdef CONFIG_COREDUMP
int elf_coredump_extra_notes_size(void)
{
struct spufs_calls *calls;
@@ -142,6 +143,7 @@ int elf_coredump_extra_notes_write(struct coredump_params *cprm)
return ret;
}
+#endif
void notify_spus_active(void)
{
diff --git a/arch/powerpc/platforms/cell/spufs/Makefile b/arch/powerpc/platforms/cell/spufs/Makefile
index b9d5d678aa44..52a7d2596d30 100644
--- a/arch/powerpc/platforms/cell/spufs/Makefile
+++ b/arch/powerpc/platforms/cell/spufs/Makefile
@@ -1,8 +1,9 @@
obj-$(CONFIG_SPU_FS) += spufs.o
-spufs-y += inode.o file.o context.o syscalls.o coredump.o
+spufs-y += inode.o file.o context.o syscalls.o
spufs-y += sched.o backing_ops.o hw_ops.o run.o gang.o
spufs-y += switch.o fault.o lscsa_alloc.o
+spufs-$(CONFIG_COREDUMP) += coredump.o
# magic for the trace events
CFLAGS_sched.o := -I$(src)
diff --git a/arch/powerpc/platforms/cell/spufs/syscalls.c b/arch/powerpc/platforms/cell/spufs/syscalls.c
index b045fdda4845..a87200a535fa 100644
--- a/arch/powerpc/platforms/cell/spufs/syscalls.c
+++ b/arch/powerpc/platforms/cell/spufs/syscalls.c
@@ -79,8 +79,10 @@ static long do_spu_create(const char __user *pathname, unsigned int flags,
struct spufs_calls spufs_calls = {
.create_thread = do_spu_create,
.spu_run = do_spu_run,
- .coredump_extra_notes_size = spufs_coredump_extra_notes_size,
- .coredump_extra_notes_write = spufs_coredump_extra_notes_write,
.notify_spus_active = do_notify_spus_active,
.owner = THIS_MODULE,
+#ifdef CONFIG_COREDUMP
+ .coredump_extra_notes_size = spufs_coredump_extra_notes_size,
+ .coredump_extra_notes_write = spufs_coredump_extra_notes_write,
+#endif
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2] Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8
From: Stewart Smith @ 2014-07-08 5:06 UTC (permalink / raw)
To: linuxppc-dev, paulus, kvm-ppc; +Cc: Stewart Smith
In-Reply-To: <1404437035-4336-1-git-send-email-stewart@linux.vnet.ibm.com>
The POWER8 processor has a Micro Partition Prefetch Engine, which is
a fancy way of saying "has way to store and load contents of L2 or
L2+MRU way of L3 cache". We initiate the storing of the log (list of
addresses) using the logmpp instruction and start restore by writing
to a SPR.
The logmpp instruction takes parameters in a single 64bit register:
- starting address of the table to store log of L2/L2+L3 cache contents
- 32kb for L2
- 128kb for L2+L3
- Aligned relative to maximum size of the table (32kb or 128kb)
- Log control (no-op, L2 only, L2 and L3, abort logout)
We should abort any ongoing logging before initiating one.
To initiate restore, we write to the MPPR SPR. The format of what to write
to the SPR is similar to the logmpp instruction parameter:
- starting address of the table to read from (same alignment requirements)
- table size (no data, until end of table)
- prefetch rate (from fastest possible to slower. about every 8, 16, 24 or
32 cycles)
The idea behind loading and storing the contents of L2/L3 cache is to
reduce memory latency in a system that is frequently swapping vcores on
a physical CPU.
The best case scenario for doing this is when some vcores are doing very
cache heavy workloads. The worst case is when they have about 0 cache hits,
so we just generate needless memory operations.
This implementation just does L2 store/load. In my benchmarks this proves
to be useful.
Benchmark 1:
- 16 core POWER8
- 3x Ubuntu 14.04LTS guests (LE) with 8 VCPUs each
- No split core/SMT
- two guests running sysbench memory test.
sysbench --test=memory --num-threads=8 run
- one guest running apache bench (of default HTML page)
ab -n 490000 -c 400 http://localhost/
This benchmark aims to measure performance of real world application (apache)
where other guests are cache hot with their own workloads. The sysbench memory
benchmark does pointer sized writes to a (small) memory buffer in a loop.
In this benchmark with this patch I can see an improvement both in requests
per second (~5%) and in mean and median response times (again, about 5%).
The spread of minimum and maximum response times were largely unchanged.
benchmark 2:
- Same VM config as benchmark 1
- all three guests running sysbench memory benchmark
This benchmark aims to see if there is a positive or negative affect to this
cache heavy benchmark. Although due to the nature of the benchmark (stores) we
may not see a difference in performance, but rather hopefully an improvement
in consistency of performance (when vcore switched in, don't have to wait
many times for cachelines to be pulled in)
The results of this benchmark are improvements in consistency of performance
rather than performance itself. With this patch, the few outliers in duration
go away and we get more consistent performance in each guest.
benchmark 3:
- same 3 guests and CPU configuration as benchmark 1 and 2.
- two idle guests
- 1 guest running STREAM benchmark
This scenario also saw performance improvement with this patch. On Copy and
Scale workloads from STREAM, I got 5-6% improvement with this patch. For
Add and triad, it was around 10% (or more).
benchmark 4:
- same 3 guests as previous benchmarks
- two guests running sysbench --memory, distinctly different cache heavy
workload
- one guest running STREAM benchmark.
Similar improvements to benchmark 3.
benchmark 5:
- 1 guest, 8 VCPUs, Ubuntu 14.04
- Host configured with split core (SMT8, subcores-per-core=4)
- STREAM benchmark
In this benchmark, we see a 10-20% performance improvement across the board
of STREAM benchmark results with this patch.
Based on preliminary investigation and microbenchmarks
by Prerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
--
changes since v1:
- s/mppe/mpp_buffer/
- add MPP_BUFFER_ORDER define.
---
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/include/asm/ppc-opcode.h | 10 ++++++
arch/powerpc/include/asm/reg.h | 1 +
arch/powerpc/kvm/book3s_hv.c | 54 ++++++++++++++++++++++++++++++++-
4 files changed, 65 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index 1eaea2d..83ed249 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -305,6 +305,7 @@ struct kvmppc_vcore {
u32 arch_compat;
ulong pcr;
ulong dpdes; /* doorbell state (POWER8) */
+ unsigned long mpp_buffer; /* Micro Partition Prefetch buffer */
};
#define VCORE_ENTRY_COUNT(vc) ((vc)->entry_exit_count & 0xff)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 3132bb9..6201440 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -139,6 +139,7 @@
#define PPC_INST_ISEL 0x7c00001e
#define PPC_INST_ISEL_MASK 0xfc00003e
#define PPC_INST_LDARX 0x7c0000a8
+#define PPC_INST_LOGMPP 0x7c0007e4
#define PPC_INST_LSWI 0x7c0004aa
#define PPC_INST_LSWX 0x7c00042a
#define PPC_INST_LWARX 0x7c000028
@@ -275,6 +276,13 @@
#define __PPC_EH(eh) 0
#endif
+/* POWER8 Micro Partition Prefetch parameters */
+#define PPC_MPPE_ADDRESS_MASK 0xffffffffc000
+#define PPC_MPPE_WHOLE_TABLE (0x2ULL << 60)
+#define PPC_MPPE_LOG_L2 (0x02ULL << 54)
+#define PPC_MPPE_LOG_L2L3 (0x01ULL << 54)
+#define PPC_MPPE_LOG_ABORT (0x03ULL << 54)
+
/* Deal with instructions that older assemblers aren't aware of */
#define PPC_DCBAL(a, b) stringify_in_c(.long PPC_INST_DCBAL | \
__PPC_RA(a) | __PPC_RB(b))
@@ -283,6 +291,8 @@
#define PPC_LDARX(t, a, b, eh) stringify_in_c(.long PPC_INST_LDARX | \
___PPC_RT(t) | ___PPC_RA(a) | \
___PPC_RB(b) | __PPC_EH(eh))
+#define PPC_LOGMPP(b) stringify_in_c(.long PPC_INST_LOGMPP | \
+ __PPC_RB(b))
#define PPC_LWARX(t, a, b, eh) stringify_in_c(.long PPC_INST_LWARX | \
___PPC_RT(t) | ___PPC_RA(a) | \
___PPC_RB(b) | __PPC_EH(eh))
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index e5d2e0b..5164beb 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -224,6 +224,7 @@
#define CTRL_TE 0x00c00000 /* thread enable */
#define CTRL_RUNLATCH 0x1
#define SPRN_DAWR 0xB4
+#define SPRN_MPPR 0xB8 /* Micro Partition Prefetch Register */
#define SPRN_CIABR 0xBB
#define CIABR_PRIV 0x3
#define CIABR_PRIV_USER 1
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 8227dba..41dab67 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -67,6 +67,13 @@
/* Used as a "null" value for timebase values */
#define TB_NIL (~(u64)0)
+#if defined(CONFIG_PPC_64K_PAGES)
+#define MPP_BUFFER_ORDER 0
+#elif defined(CONFIG_PPC_4K_PAGES)
+#define MPP_BUFFER_ORDER 4
+#endif
+
+
static void kvmppc_end_cede(struct kvm_vcpu *vcpu);
static int kvmppc_hv_setup_htab_rma(struct kvm_vcpu *vcpu);
@@ -1528,6 +1535,7 @@ static void kvmppc_run_core(struct kvmppc_vcore *vc)
int i, need_vpa_update;
int srcu_idx;
struct kvm_vcpu *vcpus_to_update[threads_per_core];
+ phys_addr_t phy_addr, tmp;
/* don't start if any threads have a signal pending */
need_vpa_update = 0;
@@ -1590,9 +1598,48 @@ static void kvmppc_run_core(struct kvmppc_vcore *vc)
srcu_idx = srcu_read_lock(&vc->kvm->srcu);
+ /* If we have a saved list of L2/L3, restore it */
+ if (cpu_has_feature(CPU_FTR_ARCH_207S) && vc->mpp_buffer) {
+ phy_addr = virt_to_phys((void *)vc->mpp_buffer);
+#if defined(CONFIG_PPC_4K_PAGES)
+ phy_addr = (phy_addr + 8*4096) & ~(8*4096);
+#endif
+ tmp = phy_addr & PPC_MPPE_ADDRESS_MASK;
+ tmp = tmp | PPC_MPPE_WHOLE_TABLE;
+
+ /* For sanity, abort any 'save' requests in progress */
+ asm volatile(PPC_LOGMPP(R1) : : "r" (tmp));
+
+ /* Inititate a cache-load request */
+ mtspr(SPRN_MPPR, tmp);
+ }
+
+ /* Allocate memory before switching out of guest so we don't
+ trash L2/L3 with memory allocation stuff */
+ if (cpu_has_feature(CPU_FTR_ARCH_207S) && !vc->mpp_buffer) {
+ vc->mpp_buffer = __get_free_pages(GFP_KERNEL|__GFP_ZERO,
+ MPP_BUFFER_ORDER);
+ }
+
__kvmppc_vcore_entry();
spin_lock(&vc->lock);
+
+ if (cpu_has_feature(CPU_FTR_ARCH_207S) && vc->mpp_buffer) {
+ phy_addr = (phys_addr_t)virt_to_phys((void *)vc->mpp_buffer);
+#if defined(CONFIG_PPC_4K_PAGES)
+ phy_addr = (phy_addr + 8*4096) & ~(8*4096);
+#endif
+ tmp = PPC_MPPE_ADDRESS_MASK & phy_addr;
+ tmp = tmp | PPC_MPPE_LOG_L2;
+
+ /* Abort any existing 'fetch' operations for this core */
+ mtspr(SPRN_MPPR, tmp&0x0fffffffffffffff);
+
+ /* Finally, issue logmpp to save cache contents for L2 */
+ asm volatile(PPC_LOGMPP(R1) : : "r" (tmp));
+ }
+
/* disable sending of IPIs on virtual external irqs */
list_for_each_entry(vcpu, &vc->runnable_threads, arch.run_list)
vcpu->cpu = -1;
@@ -2329,8 +2376,13 @@ static void kvmppc_free_vcores(struct kvm *kvm)
{
long int i;
- for (i = 0; i < KVM_MAX_VCORES; ++i)
+ for (i = 0; i < KVM_MAX_VCORES; ++i) {
+ if (kvm->arch.vcores[i] && kvm->arch.vcores[i]->mpp_buffer) {
+ free_pages(kvm->arch.vcores[i]->mpp_buffer,
+ MPP_BUFFER_ORDER);
+ }
kfree(kvm->arch.vcores[i]);
+ }
kvm->arch.online_vcores = 0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH][v2]devicetree/binding/powerpc/fsl: Add binding for CPLD
From: Priyanka Jain @ 2014-07-08 5:06 UTC (permalink / raw)
To: scottwood, devicetree, linuxppc-dev; +Cc: Priyanka Jain
Some Freescale boards like T1040RDB have on board CPLD connected on
the IFC bus. Add binding for this in board.txt file
Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
---
Changes for v2: Incorporated Scott's comments
.../devicetree/bindings/powerpc/fsl/board.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 700dec4..67ef6a4 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -84,3 +84,19 @@ Example:
compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
reg = <0x66>;
};
+
+* Freescale on-board CPLD
+
+Some Freescale boards like T1040RDB have on board CPLD connected.
+
+Required properties:
+- compatible: Should be a board-specific string like "fsl,<board>-cpld"
+ Example:
+ "fsl,T1040RDB-cpld", "fsl,T1042RDB-cpld", "fsl,T1042RDB_PI-cpld"
+- reg: should describe CPLD registers
+
+Example:
+ cpld@3,0 {
+ compatible = "fsl,T1040RDB-cpld";
+ reg = <3 0 0x300>;
+ };
--
1.7.4.1
^ permalink raw reply related
* powerpc allyesconfig fix
From: Nicholas Krause @ 2014-07-08 5:04 UTC (permalink / raw)
To: benh
Cc: mahesh, agraf, linux-kernel, michael, paulus, anton, linuxppc-dev,
Guenter Roeck
powerpc:allmodconfig has been failing for some time with the following
error.
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
A number of attempts to fix the problem by moving around code have been
unsuccessful and resulted in failed builds for some configurations and
the discovery of toolchain bugs.
Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead.
While this is less than perfect, it avoids substantial code changes
which would otherwise be necessary just to make COMPILE_TEST builds
happy and might have undesired side effects.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
arch/powerpc/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index bd6dd6e..fefe7c8 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -414,7 +414,7 @@ config KEXEC
config CRASH_DUMP
bool "Build a kdump crash kernel"
depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP)
- select RELOCATABLE if PPC64 || 44x || FSL_BOOKE
+ select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE
help
Build a kernel suitable for use as a kdump capture kernel.
The same kernel binary can be used as production kernel and dump
@@ -1017,6 +1017,7 @@ endmenu
if PPC64
config RELOCATABLE
bool "Build a relocatable kernel"
+ depends on !COMPILE_TEST
select NONSTATIC_KERNEL
help
This builds a kernel image that is capable of running anywhere
--
1.9.1
^ permalink raw reply related
* Fwd: Fwd: Allyesconfig for powerpc still Failing
From: Nick Krause @ 2014-07-08 4:57 UTC (permalink / raw)
To: linux; +Cc: linuxppc-dev, linux-kernel@vger.kernel.org, paulus
In-Reply-To: <53BB6C2D.60209@roeck-us.net>
From: Guenter Roeck on Mon, Jul 7, 2014 at 11:57 PM wrote
Subject: Re: Fwd: Allyesconfig for powerpc still Failing
To: Nick Krause <xerofoify@gmail.com>, "linux-kernel@vger.kernel.org"
<linux-kernel@vger.kernel.org>, "linuxppc-dev@lists.ozlabs.org"
<linuxppc-dev@lists.ozlabs.org>
On 07/07/2014 08:38 PM, Nick Krause wrote:
>
> On 07/07/2014 07:45 PM, Nick Krause wrote:
>>
>>
>> Today I tested the allyesconfig for powerpc and it seems to be still
>> failing according to my tests.
>> Below are the error messages I get before the jobs finish and exit
>> failing the build.
>> Cheers Nick
>> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
>> arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards
>> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
>> make: *** [arch/powerpc/kernel] Error 2
>> make: *** Waiting for unfinished jobs....
>
>
> Guenter Roeck wrote on Mon, Jul 7, 2014 at 11:07 PM
> I submitted a patch to work around this problem a couple of weeks ago [1].
> Unfortunately, with this patch applied, allyesconfig still fails with
> relocation errors, but at least the above message is gone, and
> allmodconfig passes.
>
> Maybe we can convince Ben to accept the patch ...
>
> Thanks,
> Guenter
>
> ---
> [1] https://lkml.org/lkml/2014/6/30/607
>
> Hey Guenter,
> Would you mind sending me the patch that fixes these errors.
> I would like to test it before sending in to Ben.
> Cheers Nick
>
Hi Nick,
Just follow the link above, select 'forward', and follow the directions.
You'll get the patch per e-mail.
Alternative:
wget "http://download.gmane.org/gmane.linux.kernel/1736036/1736037"
The patch will be in a file named '1736037'.
I copied the list for others, in case the 'how to download a patch'
question comes up again.
Guenter
Guenter,
Your patch works for me in building the powerpc allyesconfig.
This is one news, I am going to send this patch to Ben.
Cheers Nick
^ permalink raw reply
* RE: [PATCH] devicetree/bindings: Add binding for micron n25q512a memory
From: Priyanka Jain @ 2014-07-08 4:41 UTC (permalink / raw)
To: Scott Wood
Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-mtd@lists.infradead.org, linux-spi@vger.kernel.org
In-Reply-To: <1404768354.21434.191.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAxNCAyOjU2IEFNDQo+IFRvOiBKYWluIFBy
aXlhbmthLUIzMjE2Nw0KPiBDYzogZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBj
LWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC0NCj4gc3BpQHZnZXIua2VybmVsLm9yZzsgbGlu
dXgtbXRkQGxpc3RzLmluZnJhZGVhZC5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSF0gZGV2aWNl
dHJlZS9iaW5kaW5nczogQWRkIGJpbmRpbmcgZm9yIG1pY3JvbiBuMjVxNTEyYQ0KPiBtZW1vcnkN
Cj4gDQo+IE9uIFRodSwgMjAxNC0wNy0wMyBhdCAyMzowOCAtMDUwMCwgSmFpbiBQcml5YW5rYS1C
MzIxNjcgd3JvdGU6DQo+ID4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g
PiBGcm9tOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiA+ID4gU2VudDogRnJpZGF5LCBKdWx5IDA0LCAy
MDE0IDM6NDAgQU0NCj4gPiA+IFRvOiBKYWluIFByaXlhbmthLUIzMjE2Nw0KPiA+ID4gQ2M6IGRl
dmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsN
Cj4gPiA+IGxpbnV4LSBzcGlAdmdlci5rZXJuZWwub3JnOyBsaW51eC1tdGRAbGlzdHMuaW5mcmFk
ZWFkLm9yZw0KPiA+ID4gU3ViamVjdDogUmU6IFtQQVRDSF0gZGV2aWNldHJlZS9iaW5kaW5nczog
QWRkIGJpbmRpbmcgZm9yIG1pY3Jvbg0KPiA+ID4gbjI1cTUxMmEgbWVtb3J5DQo+ID4gPg0KPiA+
ID4gT24gVGh1LCAyMDE0LTA3LTAzIGF0IDE1OjQyICswNTMwLCBQcml5YW5rYSBKYWluIHdyb3Rl
Og0KPiA+ID4gPiAtTWljcm9uIG4yNXE1MTJhIG1lbW9yeSBpcyBzdXBwb3J0ZWQgYnkgbTI1cDgw
IGRyaXZlci4NCj4gPiA+ID4gIEFkZCBjb21wYXRpYmxlIGZpZWxkIHJlcXVpcmVkIHRvIHN1cHBv
cnQgbjI1cTUxMmEgaW4gbTI1cDgwLnR4dA0KPiA+ID4gPiAtQWRkIG1pY3JvbiB0byB0aGUgdmVu
ZG9yLXByZWZpeGVzLnR4dCBmaWxlDQo+ID4gPiA+DQo+ID4gPiA+IFNpZ25lZC1vZmYtYnk6IFBy
aXlhbmthIEphaW4gPFByaXlhbmthLkphaW5AZnJlZXNjYWxlLmNvbT4NCj4gPiA+ID4gLS0tDQo+
ID4gPiA+ICBEb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvbXRkL20yNXA4MC50eHQg
ICB8ICAgIDEgKw0KPiA+ID4gPiAgLi4uL2RldmljZXRyZWUvYmluZGluZ3MvdmVuZG9yLXByZWZp
eGVzLnR4dCAgICAgICAgfCAgICAxICsNCj4gPiA+ID4gIDIgZmlsZXMgY2hhbmdlZCwgMiBpbnNl
cnRpb25zKCspLCAwIGRlbGV0aW9ucygtKQ0KPiA+ID4NCj4gPiA+IFdoeSBkaWQgeW91IHNlbmQg
dGhpcyB0byB0aGUgcHBjIGxpc3QgYnV0IG5vdCB0aGUgc3BpIG9yIG10ZCBsaXN0cz8NCj4gPiA+
DQo+ID4gW0phaW4gUHJpeWFua2EtQjMyMTY3XSBTb3JyeSwgSSBtaXNzZWQgdGhhdA0KPiA+ID4g
SSdtIGhhdmluZyBhIGhhcmQgdGltZSBmb2xsb3dpbmcgdGhlIGZsb3cgb2YgaG93IHRoZXNlIFNQ
SSBkZXZpY2VzDQo+ID4gPiBnZXQgYm91bmQgLS0gaXMgdGhlIGNvbXBhdGlibGUgaW52b2x2ZWQg
YXQgYWxsPyAgSSBkb24ndCBzZWUgdGhpcw0KPiA+ID4gc3RyaW5nICh3aXRoIHZlbmRvciBwcmVm
aXggaW5jbHVkZWQpIGluIHRoZSBkcml2ZXIuICBJIGRvIHNlZSBhDQo+ID4gPiB0YWJsZSB0aGF0
IGNvbnRhaW5zIHdoYXQgbG9va3MgbGlrZSBkZXZpY2UgSURzLiAgSWYgdGhlIGRldmljZSBjYW4N
Cj4gPiA+IHJlcG9ydCBpdHMgaWQsIHNob3VsZG4ndCB3ZSByZWx5IG9uIHRoYXQgcmF0aGVyIHRo
YW4gZGV2aWNlIHRyZWUNCj4gY29tcGF0aWJsZT8NCj4gPiA+DQo+ID4gPiAtU2NvdHQNCj4gPiBb
SmFpbiBQcml5YW5rYS1CMzIxNjddDQo+ID4gU3BpIGRyaXZlciBoYXMgYSBjaGVjayB0byBkZXZp
Y2UgbmFtZSBjb3JyZXNwb25kaW5nIHRvIGRldmljZS1pZCBhbmQNCj4gY29tcGFyZSB0byB3aGF0
IGlzIHBhc3NlZCBpbiBkdHMgc3RyaW5nLg0KPiANCj4gUGxlYXNlIGdvIGludG8gbW9yZSBkZXRh
aWwuICBJIGRvbid0IHNlZSB3aGVyZSB0aGUgc3RyaW5nDQo+ICJtaWNyb24sbjI1cTUxMmEiIGFw
cGVhcnMgaW4gdGhlIGN1cnJlbnQga2VybmVsLiAgSSBkbyBzZWUgIm4yNXE1MTJhIiwNCj4gYnV0
IGhvdyBkb2VzIHRoYXQgY29tcGFyZSBzdWNjZXNzZnVsbHkgd2l0aCB0aGUgdmVyc2lvbiBvZiB0
aGUgc3RyaW5nDQo+IHRoYXQgaGFzIGEgdmVuZG9yIGNvbXBhdGlibGU/DQo+IA0KPiBBZ2Fpbiwg
aXMgdGhlcmUgYSBkZXZpY2UgSUQgdGhhdCBjYW4gYmUgcmVhZCBhdCBydW50aW1lPyAgSXMgdGhl
cmUgYQ0KPiBjb21wYXRpYmxlIHN0cmluZyB0aGF0IHJlcHJlc2VudHMgYSBjb21tb24gcHJvZ3Jh
bW1pbmcgaW50ZXJmYWNlPw0KW0phaW4gUHJpeWFua2EtQjMyMTY3XSANClNwaSBkcml2ZXIgKG9m
X3JlZ2lzdGVyX3NwaV9kZXZpY2VzKCkpIHNlYXJjaCBmb3IgY29tcGF0aWJsZSBzdHJpbmcgaW4g
ZGV2aWNlLXRyZWUuIEl0IHNlbGVjdHMgdGhlIGZsYXNoIGRldmljZSBkcml2ZXIgYmFzZWQgb24g
dGhlIGNvbXBhdGlibGUgc3RyaW5nIChuMjVxNTEyYSkuIFRoaXMgY29tcGF0aWJsZSBzdHJpbmcg
aXMgZXNzZW50aWFsLCBlbHNlIGRldmljZSBwcm9iZSB3b250IGNvbnRpbnVlLiAgVGhlbiBEZXZp
Y2UtaWQgb2YgZmxhc2ggaXMgcmVhZCBhdCBydW50aW1lIGluIHByb2JlIGFuZCBjb21wYXJlZCB3
aXRoIHRoZSBjb3JyZXNwb25kaW5nIGRldmljZS1pZCBvZiBmbGFzaCAobjI1cTUxMmEpLiBEZXZp
Y2UtaWQgKG1haW50YWluZWQgYXMgZmlyc3QgZWxlbWVudCBpbiBJTkZPIHN0cmluZyBpbiBzcGlf
bm9yX2lkc1tdIGluIGRyaXZlcnMvbXRkL3NwaS1ub3Ivc3BpLW5vci5jIGZpbGUpDQpPbmx5IGlm
IGJvdGggZGV2aWNlLWlkcyBtYXRjaCwgdGhlIGRldmljZSBpcyB0YWtlbiBhcyBzdWNjZXNzZnVs
bHkgZGV0ZWN0ZWQuDQpSZWdhcmRpbmcgdmVuZG9yICJtaWNyb24iLCB5b3UgYXJlIHJpZ2h0IGN1
cnJlbnRseSB0aGUgdmVuZG9yIGluZm9ybWF0aW9uIGlzIG5vdCBtYWludGFpbmVkIGFzIHN1Y2gg
aW4gZGV2aWNlLWlkLCBidXQgdGhlIGNvbnZlbnRpb24gdGhhdCBpcyBmb2xsb3dlZCBmb3IgY29t
cGF0aWJsZSBzdHJpbmcgaXMgInZlbmRvci1pZCwgZGV2aWNlLWlkIg0KPiANCj4gPiBOZXcgY2hl
Y2twYXRjaCBzY3JpcHQgc2VhcmNoIGZvciBleGFjdCBzdHJpbmcgbWF0Y2ggaW4gYmluZGluZyBm
b2xkZXIuDQo+IFNvLCBJIGhhdmUgYWRkZWQgdGhpcyBpbiBleGFtcGxlLg0KPiANCj4gVGhhdCBj
aGVjayBoYXMgYSBsb3Qgb2YgZmFsc2UgcG9zaXRpdmVzIHdoZW4gaXQgY29tZXMgdG8gY29tcGF0
aWJsZQ0KPiBzdHJpbmdzIGZvciBzcGVjaWZpYyBjaGlwcyB0aGF0IGRvbid0IG5lZWQgdG8gYmUg
c3BlY2lmaWNhbGx5IG1lbnRpb25lZA0KPiBpbiBhIG1vcmUgZ2VuZXJpYyBiaW5kaW5nLg0KPiAN
Cj4gLVNjb3R0DQo+IA0KW0phaW4gUHJpeWFua2EtQjMyMTY3XSBFdmVuIHRob3VnaCAibWljcm9u
LG4yNXE1MTJhIiBpcyBpbiBzeW5jIHdpdGggYmluZGluZyBtZW50aW9uZWQgaW4gIiBEb2N1bWVu
dGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvbXRkL20yNXA4MC50eHQgICAiLCBJIGhhdmUgdG8g
YWRkIHRoaXMgYXMgYW4gYSBleGFtcGxlLCBqdXN0IHRvIGF2b2lkIGNoZWNrcGF0Y2ggZXJyb3Iu
IFdoYXQgc2hvdWxkIGJlIHRoZSBhcHByb2FjaCBnb2luZyBmb3J3YXJkOiBTaG91bGQgc3VjaCBj
aGVja3BhdGNoIHdhcm5pbmdzIGJlIGlnbm9yZWQ/DQoNCg0KDQoNCg==
^ permalink raw reply
* Re: [PATCH 1/3] PCI/MSI: Add pci_enable_msi_partial()
From: Michael Ellerman @ 2014-07-08 4:01 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: linux-mips, linux-s390, linux-doc, linux-pci, x86, linux-kernel,
linux-ide, iommu, Alexander Gordeev, xen-devel, linuxppc-dev
In-Reply-To: <20140702202201.GA28852@google.com>
On Wed, 2014-07-02 at 14:22 -0600, Bjorn Helgaas wrote:
> On Tue, Jun 10, 2014 at 03:10:30PM +0200, Alexander Gordeev wrote:
> > There are PCI devices that require a particular value written
> > to the Multiple Message Enable (MME) register while aligned on
> > power of 2 boundary value of actually used MSI vectors 'nvec'
> > is a lesser of that MME value:
> >
> > roundup_pow_of_two(nvec) < 'Multiple Message Enable'
> >
> > However the existing pci_enable_msi_block() interface is not
> > able to configure such devices, since the value written to the
> > MME register is calculated from the number of requested MSIs
> > 'nvec':
> >
> > 'Multiple Message Enable' = roundup_pow_of_two(nvec)
>
> For MSI, software learns how many vectors a device requests by reading
> the Multiple Message Capable (MMC) field. This field is encoded, so a
> device can only request 1, 2, 4, 8, etc., vectors. It's impossible
> for a device to request 3 vectors; it would have to round up that up
> to a power of two and request 4 vectors.
>
> Software writes similarly encoded values to MME to tell the device how
> many vectors have been allocated for its use. For example, it's
> impossible to tell the device that it can use 3 vectors; the OS has to
> round that up and tell the device it can use 4 vectors.
>
> So if I understand correctly, the point of this series is to take
> advantage of device-specific knowledge, e.g., the device requests 4
> vectors via MMC, but we "know" the device is only capable of using 3.
> Moreover, we tell the device via MME that 4 vectors are available, but
> we've only actually set up 3 of them.
>
> This makes me uneasy because we're lying to the device, and the device
> is perfectly within spec to use all 4 of those vectors. If anything
> changes the number of vectors the device uses (new device revision,
> firmware upgrade, etc.), this is liable to break.
It also adds more complexity into the already complex MSI API, across all
architectures, all so a single Intel chipset can save a couple of MSIs. That
seems like the wrong trade off to me.
cheers
^ permalink raw reply
* Re: Fwd: Allyesconfig for powerpc still Failing
From: Guenter Roeck @ 2014-07-08 3:57 UTC (permalink / raw)
To: Nick Krause, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAPDOMVgeUWGtMC2yssh3zz6y208mHW5WCduDCwr+J09d7LF+CQ@mail.gmail.com>
On 07/07/2014 08:38 PM, Nick Krause wrote:
> On 07/07/2014 07:45 PM, Nick Krause wrote:
>>
>> Today I tested the allyesconfig for powerpc and it seems to be still
>> failing according to my tests.
>> Below are the error messages I get before the jobs finish and exit
>> failing the build.
>> Cheers Nick
>> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
>> arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards
>> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
>> make: *** [arch/powerpc/kernel] Error 2
>> make: *** Waiting for unfinished jobs....
>
> Guenter Roeck wrote on Mon, Jul 7, 2014 at 11:07 PM
> I submitted a patch to work around this problem a couple of weeks ago [1].
> Unfortunately, with this patch applied, allyesconfig still fails with
> relocation errors, but at least the above message is gone, and
> allmodconfig passes.
>
> Maybe we can convince Ben to accept the patch ...
>
> Thanks,
> Guenter
>
> ---
> [1] https://lkml.org/lkml/2014/6/30/607
>
> Hey Guenter,
> Would you mind sending me the patch that fixes these errors.
> I would like to test it before sending in to Ben.
> Cheers Nick
>
Hi Nick,
Just follow the link above, select 'forward', and follow the directions.
You'll get the patch per e-mail.
Alternative:
wget "http://download.gmane.org/gmane.linux.kernel/1736036/1736037"
The patch will be in a file named '1736037'.
I copied the list for others, in case the 'how to download a patch'
question comes up again.
Guenter
^ permalink raw reply
* RE: [PATCH] devicetree/bindings/powerpc/fsl: Add binding for board
From: Priyanka Jain @ 2014-07-08 3:56 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1404768624.21434.196.camel@snotra.buserror.net>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29vZCBTY290dC1CMDc0
MjENCj4gU2VudDogVHVlc2RheSwgSnVseSAwOCwgMjAxNCAzOjAwIEFNDQo+IFRvOiBKYWluIFBy
aXlhbmthLUIzMjE2Nw0KPiBDYzogZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBj
LWRldkBsaXN0cy5vemxhYnMub3JnDQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0hdIGRldmljZXRyZWUv
YmluZGluZ3MvcG93ZXJwYy9mc2w6IEFkZCBiaW5kaW5nIGZvcg0KPiBib2FyZA0KPiANCj4gT24g
TW9uLCAyMDE0LTA3LTA3IGF0IDE0OjA2ICswNTMwLCBQcml5YW5rYSBKYWluIHdyb3RlOg0KPiA+
IFNpZ25lZC1vZmYtYnk6IFByaXlhbmthIEphaW4gPFByaXlhbmthLkphaW5AZnJlZXNjYWxlLmNv
bT4NCj4gPiAtLS0NCj4gPiAgLi4uL2RldmljZXRyZWUvYmluZGluZ3MvcG93ZXJwYy9mc2wvYm9h
cmQudHh0ICAgICAgfCAgIDE3DQo+ICsrKysrKysrKysrKysrKystDQo+ID4gIDEgZmlsZXMgY2hh
bmdlZCwgMTYgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1n
aXQgYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcG93ZXJwYy9mc2wvYm9hcmQu
dHh0DQo+ID4gYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcG93ZXJwYy9mc2wv
Ym9hcmQudHh0DQo+ID4gaW5kZXggZjM1ZjI5NS4uNzgwMDcyOSAxMDA2NDQNCj4gPiAtLS0gYS9E
b2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvcG93ZXJwYy9mc2wvYm9hcmQudHh0DQo+
ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdzL3Bvd2VycGMvZnNsL2Jv
YXJkLnR4dA0KPiA+IEBAIC0xLDggKzEsMjMgQEANCj4gPiAgRnJlZXNjYWxlIFJlZmVyZW5jZSBC
b2FyZCBCaW5kaW5ncw0KPiA+DQo+ID4gLVRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGRldmljZSB0
cmVlIGJpbmRpbmdzIGZvciB2YXJpb3VzIGRldmljZXMgdGhhdA0KPiA+ICtUaGlzIGRvY3VtZW50
IGRlc2NyaWJlcyBkZXZpY2UgdHJlZSBiaW5kaW5ncyBmb3IgYm9hcmQgYW5kICB2YXJpb3VzDQo+
ID4gK2RldmljZXMgdGhhdA0KPiA+ICBleGlzdCBvbiBzb21lIEZyZWVzY2FsZSByZWZlcmVuY2Ug
Ym9hcmRzLg0KPiA+DQo+ID4gKyogQm9hcmQgbm9kZQ0KPiA+ICtSZXF1aXJlZCBwcm9wZXJ0aWVz
Og0KPiA+ICsNCj4gPiArIC0gbW9kZWwgOiBTaG91bGQgYmUgImZzbCw8Ym9hcmQ+Ig0KPiA+ICsg
LSBjb21wYXRpYmxlIDogU2hvdWxkIGJlICJmc2wsPGJvYXJkPiINCj4gPiArCWV4YW1wbGU6ICJm
c2wsVDEwNDBSREIiLCAiZnNsLFQxMDQyUkRCIiwgImZzbCxUMTA0MlJEQl9QSSINCj4gPiArCQkg
ImZzbCxUMTA0MFFEUyIsICJmc2wsVDEwNDJRRFMiDQo+ID4gKw0KPiA+ICtFeGFtcGxlOg0KPiA+
ICsNCj4gPiArLyB7DQo+ID4gKwltb2RlbCA9ICJmc2wsVDEwNDBSREIiOw0KPiA+ICsJY29tcGF0
aWJsZSA9ICJmc2wsVDEwNDBSREIiOw0KPiA+ICt9Ow0KPiANCj4gV2UgcmVhbGx5IGRvbid0IG5l
ZWQgdG8gZG8gdGhpcyBmb3IgZXZlcnkgYm9hcmQganVzdCB0byBzYXRpc2Z5DQo+IGNoZWNrcGF0
Y2guDQo+IA0KPiAtU2NvdHQNCj4gDQpbSmFpbiBQcml5YW5rYS1CMzIxNjddIElzIGl0IE9LIHRv
IHN1Ym1pdCBhIHBhdGNoIHdpdGggYm9hcmQgY2hlY2twYXRjaCB3YXJuaW5nIGZvciB0aGlzIGNh
c2UgPw0K
^ permalink raw reply
* Re: [RFC PATCH 3/4] KVM: PPC: e500: TLB emulation for IND entries
From: Scott Wood @ 2014-07-08 3:25 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1404398727-12844-4-git-send-email-mihai.caraman@freescale.com>
On Thu, 2014-07-03 at 17:45 +0300, Mihai Caraman wrote:
> Handle indirect entries (IND) in TLB emulation code. Translation size of IND
> entries differ from the size of referred Page Tables (Linux guests now use IND
> of 2MB for 4KB PTs) and this require careful tweak of the existing logic.
>
> TLB search emulation requires additional search in HW TLB0 (since these entries
> are directly added by HTW) and found entries shoud be presented to the guest with
> RPN changed from PFN to GFN. There might be more GFNs pointing to the same PFN so
> the only way to get the corresponding GFN is to search it in guest's PTE. If IND
> entry for the corresponding PT is not available just invalidate guest's ea and
> report a tlbsx miss. This patch only implements the invalidation and let a TODO
> note for searching HW TLB0.
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/include/asm/mmu-book3e.h | 2 +
> arch/powerpc/kvm/e500.h | 81 ++++++++++++++++++++++++++++-------
> arch/powerpc/kvm/e500_mmu.c | 78 +++++++++++++++++++++++++++------
> arch/powerpc/kvm/e500_mmu_host.c | 31 ++++++++++++--
> arch/powerpc/kvm/e500mc.c | 53 +++++++++++++++++++++--
> 5 files changed, 211 insertions(+), 34 deletions(-)
Please look at erratum A-008139. A patch to work around it for the main
Linux tablewalk code is forthcoming. You need to make sure to never
overwrite an indirect entry with tlbwe -- always use tlbilx.
> @@ -286,6 +336,22 @@ void kvmppc_e500_tlbil_one(struct kvmppc_vcpu_e500 *vcpu_e500,
> void kvmppc_e500_tlbil_all(struct kvmppc_vcpu_e500 *vcpu_e500);
>
> #ifdef CONFIG_KVM_BOOKE_HV
> +void inval_tlb_on_host(struct kvm_vcpu *vcpu, int type, int pid);
> +
> +void inval_ea_on_host(struct kvm_vcpu *vcpu, gva_t ea, int pid, int sas,
> + int sind);
> +#else
> +/* TLB is fully virtualized */
> +static inline void inval_tlb_on_host(struct kvm_vcpu *vcpu,
> + int type, int pid)
> +{}
> +
> +static inline void inval_ea_on_host(struct kvm_vcpu *vcpu, gva_t ea, int pid,
> + int sas, int sind)
> +{}
> +#endif
Document exactly what these do, and explain why it's conceptually a
separate API from kvmppc_e500_tlbil_all/one(), and why "TLB is fully
virtualized" explains why we never need to do this on non-HV.
> @@ -290,21 +298,32 @@ static void tlbilx_all(struct kvmppc_vcpu_e500 *vcpu_e500, int tlbsel,
> kvmppc_e500_gtlbe_invalidate(vcpu_e500, tlbsel, esel);
> }
> }
> +
> + /* Invalidate enties added by HTW */
> + if (has_feature(&vcpu_e500->vcpu, VCPU_FTR_MMU_V2) && (!sind))
Unnecessary parens.
> @@ -368,6 +388,23 @@ int kvmppc_e500_emul_tlbsx(struct kvm_vcpu *vcpu, gva_t ea)
> } else {
> int victim;
>
> + if (has_feature(vcpu, VCPU_FTR_MMU_V2) &&
> + get_cur_sind(vcpu) != 1) {
> + /*
Never align the continuation line of an if or loop with the indentation
of the if/loop body.
get_cur_sind(vcpu) == 0 would be more natural, and probably slightly
faster.
> + * TLB0 entries are not cached in KVM being written
> + * directly by HTW. TLB0 entry found in HW TLB0 needs
> + * to be presented to the guest with RPN changed from
> + * PFN to GFN. There might be more GFNs pointing to the
> + * same PFN so the only way to get the corresponding GFN
> + * is to search it in guest's PTE. If IND entry for the
> + * corresponding PT is not available just invalidate
> + * guest's ea and report a tlbsx miss.
> + *
> + * TODO: search ea in HW TLB0
> + */
> + inval_ea_on_host(vcpu, ea, pid, as, 0);
What if the guest is in a loop where it does an access followed by a
tlbsx, looping back if the tlbsx reports no entry (e.g. an exception
handler that wants to emulate retrying the faulting instruction on a
tlbsx miss)? The architecture allows hypervisors to invalidate at
arbitrary times, but we should avoid doing this in ways that can block
forward progress.
How likely is it really that we have multiple GFNs per PFN? How bad is
it really if we return an arbitrary matching GFN in such a case?
> @@ -516,12 +527,17 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
>
> tsize = (gtlbe->mas1 & MAS1_TSIZE_MASK) >>
> MAS1_TSIZE_SHIFT;
> + if (ind)
> + tsize -= BOOK3E_PAGESZ_4K + 7;
>
> /*
> * e500 doesn't implement the lowest tsize bit,
> * or 1K pages.
> */
> - tsize = max(BOOK3E_PAGESZ_4K, tsize & ~1);
> + if (!has_feature(&vcpu_e500->vcpu, VCPU_FTR_MMU_V2))
> + tsize &= ~1;
This looks like general e6500 support rathen than IND entry support.
Shouldn't there be a corresponding change to the "for (; tsize >
BOOK3E_PAGESZ_4K; tsize -= 2)" loop?
> -void kvmppc_e500_tlbil_all(struct kvmppc_vcpu_e500 *vcpu_e500)
> +void inval_ea_on_host(struct kvm_vcpu *vcpu, gva_t ea, int pid, int sas,
> + int sind)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + mtspr(SPRN_MAS5, MAS5_SGS | vcpu->kvm->arch.lpid);
> + mtspr(SPRN_MAS6, (pid << MAS6_SPID_SHIFT) |
> + sas | (sind << MAS6_SIND_SHIFT));
> + asm volatile("tlbilx 3, 0, %[ea]\n" : : [ea] "r" (ea));
> + mtspr(SPRN_MAS5, 0);
> + isync();
> +
> + local_irq_restore(flags);
> +}
s/tlbilx 3/tlbilxva/
> +void inval_tlb_on_host(struct kvm_vcpu *vcpu, int type, int pid)
> +{
> + if (type == 0)
> + kvmppc_e500_tlbil_lpid(vcpu);
> + else
> + kvmppc_e500_tlbil_pid(vcpu, pid);
> +}
If type stays then please make it an enum, but why not have the caller
call kvmppc_e500_tlbil_lpid() or kvmppc_e500_tlbil_pid() directly?
-Scott
^ permalink raw reply
* Fwd: Allyesconfig for powerpc still Failing
From: Nick Krause @ 2014-07-08 3:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: mahesh, Alexander Graf, linux-kernel@vger.kernel.org,
Michael Ellerman, paulus, Anton Blanchard, linuxppc-dev
In-Reply-To: <1404788634.16156.38.camel@pasglop>
On Mon, Jul 7, 2014 at 11:03 PM wrote Benjamin Herrenschmidt
On Mon, 2014-07-07 at 22:45 -0400, Nick Krause wrote:
> Today I tested the allyesconfig for powerpc and it seems to be still
> failing according to my tests.
> Below are the error messages I get before the jobs finish and exit
> failing the build.
> Cheers Nick
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards
> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
> make: *** Waiting for unfinished jobs....
Yes, it's a trainwreck and I don't know how to fix it yet ... I tried
various more or less invasive approaches and none of them worked
properly so far. I need to spend more time on this.
Cheers,
Ben.
If you need any help with these issues please let me known.
Cheers Nick :)
^ permalink raw reply
* Re: [PATCH] powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
From: Benjamin Herrenschmidt @ 2014-07-08 3:10 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Nick
In-Reply-To: <53BB5F9A.2060105@roeck-us.net>
On Mon, 2014-07-07 at 20:03 -0700, Guenter Roeck wrote:
> ping ...
>
> Ben, I know this is not perfect, but on the other side it is simple
> and would be easy to backport. With this in place, a complete/clean
> fix would not be as urgent. Any chance to get it applied ?
Yes, that definitely helps, I'll include it as a band aid.
Cheers,
Ben.
> Nick, this doesn't fix the allyesconfig build - it still fails with
> relocation errors. But it does fix the allmodconfig build.
>
> Thanks,
> Guenter
>
> On 06/30/2014 11:45 AM, Guenter Roeck wrote:
> > powerpc:allmodconfig has been failing for some time with the following
> > error.
> >
> > arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> > arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
> > make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> >
> > A number of attempts to fix the problem by moving around code have been
> > unsuccessful and resulted in failed builds for some configurations and
> > the discovery of toolchain bugs.
> >
> > Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead.
> > While this is less than perfect, it avoids substantial code changes
> > which would otherwise be necessary just to make COMPILE_TEST builds
> > happy and might have undesired side effects.
> >
> > Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> > ---
> > arch/powerpc/Kconfig | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> > index bd6dd6e..fefe7c8 100644
> > --- a/arch/powerpc/Kconfig
> > +++ b/arch/powerpc/Kconfig
> > @@ -414,7 +414,7 @@ config KEXEC
> > config CRASH_DUMP
> > bool "Build a kdump crash kernel"
> > depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP)
> > - select RELOCATABLE if PPC64 || 44x || FSL_BOOKE
> > + select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE
> > help
> > Build a kernel suitable for use as a kdump capture kernel.
> > The same kernel binary can be used as production kernel and dump
> > @@ -1017,6 +1017,7 @@ endmenu
> > if PPC64
> > config RELOCATABLE
> > bool "Build a relocatable kernel"
> > + depends on !COMPILE_TEST
> > select NONSTATIC_KERNEL
> > help
> > This builds a kernel image that is capable of running anywhere
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Allyesconfig for powerpc still Failing
From: Nick Krause @ 2014-07-08 3:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: mahesh, agraf, linux-kernel@vger.kernel.org, michael, paulus,
anton, linuxppc-dev
In-Reply-To: <1404788634.16156.38.camel@pasglop>
Just hoped this log may help you in your issues with the train wreck.
If you need any help with the issues here please let me know.
Cheers Nick :)
On Mon, Jul 7, 2014 at 11:03 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Mon, 2014-07-07 at 22:45 -0400, Nick Krause wrote:
>> Today I tested the allyesconfig for powerpc and it seems to be still
>> failing according to my tests.
>> Below are the error messages I get before the jobs finish and exit
>> failing the build.
>> Cheers Nick
>> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
>> arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards
>> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
>> make: *** [arch/powerpc/kernel] Error 2
>> make: *** Waiting for unfinished jobs....
>
> Yes, it's a trainwreck and I don't know how to fix it yet ... I tried
> various more or less invasive approaches and none of them worked
> properly so far. I need to spend more time on this.
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: Allyesconfig for powerpc still Failing
From: Guenter Roeck @ 2014-07-08 3:07 UTC (permalink / raw)
To: Nick Krause, benh
Cc: mahesh, agraf, linux-kernel@vger.kernel.org, michael, paulus,
anton, linuxppc-dev
In-Reply-To: <CAPDOMVi5ptjaKzT+Exd3XtKcy7W7nNZYUD+MEwN8LmhPrQTZBQ@mail.gmail.com>
On 07/07/2014 07:45 PM, Nick Krause wrote:
> Today I tested the allyesconfig for powerpc and it seems to be still
> failing according to my tests.
> Below are the error messages I get before the jobs finish and exit
> failing the build.
> Cheers Nick
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards
> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
> make: *** Waiting for unfinished jobs....
I submitted a patch to work around this problem a couple of weeks ago [1].
Unfortunately, with this patch applied, allyesconfig still fails with
relocation errors, but at least the above message is gone, and
allmodconfig passes.
Maybe we can convince Ben to accept the patch ...
Thanks,
Guenter
---
[1] https://lkml.org/lkml/2014/6/30/607
^ permalink raw reply
* Re: Allyesconfig for powerpc still Failing
From: Benjamin Herrenschmidt @ 2014-07-08 3:03 UTC (permalink / raw)
To: Nick Krause
Cc: mahesh, agraf, linux-kernel@vger.kernel.org, michael, paulus,
anton, linuxppc-dev
In-Reply-To: <CAPDOMVi5ptjaKzT+Exd3XtKcy7W7nNZYUD+MEwN8LmhPrQTZBQ@mail.gmail.com>
On Mon, 2014-07-07 at 22:45 -0400, Nick Krause wrote:
> Today I tested the allyesconfig for powerpc and it seems to be still
> failing according to my tests.
> Below are the error messages I get before the jobs finish and exit
> failing the build.
> Cheers Nick
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards
> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
> make: *** [arch/powerpc/kernel] Error 2
> make: *** Waiting for unfinished jobs....
Yes, it's a trainwreck and I don't know how to fix it yet ... I tried
various more or less invasive approaches and none of them worked
properly so far. I need to spend more time on this.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: Disable RELOCATABLE for COMPILE_TEST with PPC64
From: Guenter Roeck @ 2014-07-08 3:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel, Nick
In-Reply-To: <1404153930-26568-1-git-send-email-linux@roeck-us.net>
ping ...
Ben, I know this is not perfect, but on the other side it is simple
and would be easy to backport. With this in place, a complete/clean
fix would not be as urgent. Any chance to get it applied ?
Nick, this doesn't fix the allyesconfig build - it still fails with
relocation errors. But it does fix the allmodconfig build.
Thanks,
Guenter
On 06/30/2014 11:45 AM, Guenter Roeck wrote:
> powerpc:allmodconfig has been failing for some time with the following
> error.
>
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
>
> A number of attempts to fix the problem by moving around code have been
> unsuccessful and resulted in failed builds for some configurations and
> the discovery of toolchain bugs.
>
> Fix the problem by disabling RELOCATABLE for COMPILE_TEST builds instead.
> While this is less than perfect, it avoids substantial code changes
> which would otherwise be necessary just to make COMPILE_TEST builds
> happy and might have undesired side effects.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> arch/powerpc/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index bd6dd6e..fefe7c8 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -414,7 +414,7 @@ config KEXEC
> config CRASH_DUMP
> bool "Build a kdump crash kernel"
> depends on PPC64 || 6xx || FSL_BOOKE || (44x && !SMP)
> - select RELOCATABLE if PPC64 || 44x || FSL_BOOKE
> + select RELOCATABLE if (PPC64 && !COMPILE_TEST) || 44x || FSL_BOOKE
> help
> Build a kernel suitable for use as a kdump capture kernel.
> The same kernel binary can be used as production kernel and dump
> @@ -1017,6 +1017,7 @@ endmenu
> if PPC64
> config RELOCATABLE
> bool "Build a relocatable kernel"
> + depends on !COMPILE_TEST
> select NONSTATIC_KERNEL
> help
> This builds a kernel image that is capable of running anywhere
>
^ permalink raw reply
* Allyesconfig for powerpc still Failing
From: Nick Krause @ 2014-07-08 2:45 UTC (permalink / raw)
To: benh
Cc: mahesh, agraf, linux-kernel@vger.kernel.org, michael, paulus,
anton, linuxppc-dev
Today I tested the allyesconfig for powerpc and it seems to be still
failing according to my tests.
Below are the error messages I get before the jobs finish and exit
failing the build.
Cheers Nick
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1331: Error: attempt to move .org backwards
make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
make: *** [arch/powerpc/kernel] Error 2
make: *** Waiting for unfinished jobs....
^ permalink raw reply
* Re: [RFC PATCH 2/4] KVM: PPC: Book3E: Handle LRAT error exception
From: Scott Wood @ 2014-07-08 1:53 UTC (permalink / raw)
To: Alexander Graf; +Cc: Mihai Caraman, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <53B6628B.6020001@suse.de>
On Fri, 2014-07-04 at 10:15 +0200, Alexander Graf wrote:
> On 03.07.14 16:45, Mihai Caraman wrote:
> > diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
> > index a192975..ab1077f 100644
> > --- a/arch/powerpc/kvm/booke.c
> > +++ b/arch/powerpc/kvm/booke.c
> > @@ -1286,6 +1286,46 @@ int kvmppc_handle_exit(struct kvm_run *run, struct kvm_vcpu *vcpu,
> > break;
> > }
> >
> > +#ifdef CONFIG_KVM_BOOKE_HV
> > + case BOOKE_INTERRUPT_LRAT_ERROR:
> > + {
> > + gfn_t gfn;
> > +
> > + /*
> > + * Guest TLB management instructions (EPCR.DGTMI == 0) is not
> > + * supported for now
> > + */
> > + if (!(vcpu->arch.fault_esr & ESR_PT)) {
> > + WARN(1, "%s: Guest TLB management instructions not supported!\n", __func__);
>
> Wouldn't this allow a guest to flood the host's kernel log?
It shouldn't be possible for this to happen, since the host will never
set EPCR[DGTMI] -- but yes, it should be WARN_ONCE or ratelimited.
> > +{
> > + int this, next;
> > +
> > + this = local_paca->tcd.lrat_next;
> > + next = (this + 1) % local_paca->tcd.lrat_max;
>
> Can we assume that lrat_max is always a power of 2? IIRC modulo
> functions with variables can be quite expensive. So if we can instead do
>
> next = (this + 1) & local_paca->tcd.lrat_mask;
>
> we should be faster and not rely on division helpers.
Architecturally we can't assume that, though it's true on the only
existing implementation.
Why not do something similar to what is done for tlb1:
unsigned int sesel = vcpu_e500->host_tlb1_nv++;
if (unlikely(vcpu_e500->host_tlb1_nv >= tlb1_max_shadow_size()))
vcpu_e500->host_tlb1_nv = 0;
...and while we're at it, use local_paca->tcd for tlb1 as well (except
on 32-bit).
Also, please use get_paca() rather than local_paca so that the
preemption-disabled check is retained.
> > +void write_host_lrate(int tsize, gfn_t gfn, unsigned long pfn, uint32_t lpid,
> > + int valid, int lrat_entry)
> > +{
> > + struct kvm_book3e_206_tlb_entry stlbe;
> > + int esel = lrat_entry;
> > + unsigned long flags;
> > +
> > + stlbe.mas1 = (valid ? MAS1_VALID : 0) | MAS1_TSIZE(tsize);
> > + stlbe.mas2 = ((u64)gfn << PAGE_SHIFT);
> > + stlbe.mas7_3 = ((u64)pfn << PAGE_SHIFT);
> > + stlbe.mas8 = MAS8_TGS | lpid;
> > +
> > + local_irq_save(flags);
> > + /* book3e_tlb_lock(); */
>
> Hm?
Indeed.
> > +
> > + if (esel == -1)
> > + esel = lrat_next();
> > + __write_host_tlbe(&stlbe, MAS0_ATSEL | MAS0_ESEL(esel));
Where do you call this function with lrat_entry != -1? Why rename it to
esel at function entry?
> > + down_read(¤t->mm->mmap_sem);
> > + vma = find_vma(current->mm, hva);
> > + if (vma && (hva >= vma->vm_start)) {
> > + psize = vma_kernel_pagesize(vma);
> > + } else {
> > + pr_err_ratelimited("%s: couldn't find virtual memory address for gfn %lx!\n", __func__, (long)gfn);
While output strings should not be linewrapped, the arguments that come
after the long string should be.
-Scott
^ permalink raw reply
* Re: Kernel build issues after yesterdays merge by Linus
From: Anton Blanchard @ 2014-07-08 1:06 UTC (permalink / raw)
To: Tony Breeds, grant.likely
Cc: Rusty Russell, linuxppc-dev, Christoph Lameter, Brian Hart
In-Reply-To: <20140613051559.GC19628@thor.bakeyournoodle.com>
Hi Tony,
> > Shows how much we use make install :) Below is a quick hack to get
> > you going but we should look at either fixing the Ubuntu
> > installkernel to handle extra optional args, or stop passing them
> > from the ppc64 kernel install.sh script.
>
> It seems like passign the zImage files is probably wrong. How about:
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index ccc25ed..146d898 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -390,7 +390,7 @@ $(obj)/zImage.initrd: $(addprefix $(obj)/, $(initrd-y))
@rm -f $@; ln $< $@
install: $(CONFIGURE) $(addprefix $(obj)/, $(image-y))
- sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)" $^
+ sh -x $(srctree)/$(src)/install.sh "$(KERNELRELEASE)" vmlinux System.map "$(INSTALL_PATH)"
# anything not in $(targets)
clean-files += $(image-) $(initrd-) cuImage.* dtbImage.* treeImage.* \
Looks reasonable to me. Grant added this back in commit 29f1aff2 (powerpc:
Copy bootable images in the default install script) but the other archs have
gone in a different direction and created make zinstall targets.
Anton
^ permalink raw reply related
* Re: [PATCH] ibmvfc: fix little endian issues
From: Brian King @ 2014-07-07 23:21 UTC (permalink / raw)
To: Tyrel Datwyler, linux-scsi; +Cc: linuxppc-dev, linux-kernel, jbottomley
In-Reply-To: <1403827435-29522-1-git-send-email-tyreld@linux.vnet.ibm.com>
On 06/26/2014 07:03 PM, Tyrel Datwyler wrote:
> Added big endian annotations to relevant data structure fields, and necessary
> byte swappings to support little endian builds.
Acked-by: Brian King <brking@linux.vnet.ibm.com>
Thanks,
Brian
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [3/3,v4] powerpc/t2080rdb: Add T2080RDB board support
From: Scott Wood @ 2014-07-07 22:16 UTC (permalink / raw)
To: Liu Shengzhou-B36685; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <8f75541b111b44e3a26e2f6f4dc9df77@DM2PR03MB398.namprd03.prod.outlook.com>
On Mon, 2014-07-07 at 05:26 -0500, Liu Shengzhou-B36685 wrote:
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Thursday, June 26, 2014 7:35 AM
> > To: Liu Shengzhou-B36685
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [3/3,v4] powerpc/t2080rdb: Add T2080RDB board support
> >
> > On Wed, Jun 11, 2014 at 06:10:06PM +0800, Shengzhou Liu wrote:
> > > + i2c@0 {
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + reg = <0x0>;
> > > +
> > > + sfp@50 {
> > > + compatible = "optics,sfp";
> > > + reg = <0x50>;
> > > + };
> > > + };
> >
> > What is "sfp"? Please use generic node names when possible.
> >
> > I'm not able to easily find what chip this is referring to by googling
> > "optics sfp". I suspect this compatible is too vague -- what is the
> > actual part number? Could you provide a URL to a description of the chip?
> >
> > If "optics" is the correct vendor name, it needs to go into vendor-prefixes.txt.
> >
> > -Scott
>
> [Shengzhou] SFP is "Small Form-factor Pluggable transceiver" for 10Gpbs
> optics module. Actually, there is no a specific vendor for this case,
> it is a general sfp cage to which we can plug in different optics
> module from different vendors. And there is no need to configure it by
> SW.
Do not put arbitrary things in the vendor prefix.
What is the programming interface that is made available on i2c port
0x50? If it can change based on user configuration, then perhaps it
should just be left out.
-Scott
^ permalink raw reply
* Re: [PATCH] devicetree/bindings/powerpc/fsl: Add binding for board
From: Scott Wood @ 2014-07-07 21:30 UTC (permalink / raw)
To: Priyanka Jain; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1404722194-8103-1-git-send-email-Priyanka.Jain@freescale.com>
On Mon, 2014-07-07 at 14:06 +0530, Priyanka Jain wrote:
> Signed-off-by: Priyanka Jain <Priyanka.Jain@freescale.com>
> ---
> .../devicetree/bindings/powerpc/fsl/board.txt | 17 ++++++++++++++++-
> 1 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> index f35f295..7800729 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
> @@ -1,8 +1,23 @@
> Freescale Reference Board Bindings
>
> -This document describes device tree bindings for various devices that
> +This document describes device tree bindings for board and various devices that
> exist on some Freescale reference boards.
>
> +* Board node
> +Required properties:
> +
> + - model : Should be "fsl,<board>"
> + - compatible : Should be "fsl,<board>"
> + example: "fsl,T1040RDB", "fsl,T1042RDB", "fsl,T1042RDB_PI"
> + "fsl,T1040QDS", "fsl,T1042QDS"
> +
> +Example:
> +
> +/ {
> + model = "fsl,T1040RDB";
> + compatible = "fsl,T1040RDB";
> +};
We really don't need to do this for every board just to satisfy
checkpatch.
-Scott
^ 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