Re: [PATCH] PowerPC: kernel: need return the related error code when failure occurs.
On Tue, May 21, 2013 at 01:48:58PM +0800, Chen Gang wrote: When error occurs, need return the related error code to let upper caller know about it. ppc_md.nvram_size() can return the error code (e.g. core99_nvram_size() in 'arch/powerpc/platforms/powermac/nvram.c'). And when '*ppos = size', need return -ESPIPE (Illegal seek) Why? When *ppos = size, it should return 0 (end of file) in my opinion. ESPIPE means that any seek would be ineffective, not that a particular seek went out of bounds. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] PowerPC: kernel: need return the related error code when failure occurs.
On 05/21/2013 04:10 PM, Paul Mackerras wrote: On Tue, May 21, 2013 at 01:48:58PM +0800, Chen Gang wrote: When error occurs, need return the related error code to let upper caller know about it. ppc_md.nvram_size() can return the error code (e.g. core99_nvram_size() in 'arch/powerpc/platforms/powermac/nvram.c'). And when '*ppos = size', need return -ESPIPE (Illegal seek) Why? When *ppos = size, it should return 0 (end of file) in my opinion. ESPIPE means that any seek would be ineffective, not that a particular seek went out of bounds. OK, thanks, I will send patch v2. :-) Thanks. -- Chen Gang Asianux Corporation ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v1 0/2] powerpc/mpc512x: improve common platform code
Hi Gerhard, On Tue, 14 May 2013 16:40:52 +0200 Gerhard Sittig g...@denx.de wrote: ... Gerhard Sittig (2): powerpc/mpc512x: move common code to the shared.c file powerpc/mpc512x: initialize board restart earlier Applied both patches for -next. Thanks! Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] PowerPC: kernel: need return the related error code when failure occurs
When error occurs, need return the related error code to let upper
caller know about it.
ppc_md.nvram_size() can return the error code (e.g. core99_nvram_size()
in 'arch/powerpc/platforms/powermac/nvram.c').
Also set ret value when only need it, so can save structions for normal
cases.
The original related patch: f9ce299 [PATCH] powerpc: fix large nvram
access.
Signed-off-by: Chen Gang gang.c...@asianux.com
---
arch/powerpc/kernel/nvram_64.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/nvram_64.c b/arch/powerpc/kernel/nvram_64.c
index 48fbc2b..8213ee1 100644
--- a/arch/powerpc/kernel/nvram_64.c
+++ b/arch/powerpc/kernel/nvram_64.c
@@ -84,22 +84,30 @@ static ssize_t dev_nvram_read(struct file *file, char
__user *buf,
char *tmp = NULL;
ssize_t size;
- ret = -ENODEV;
- if (!ppc_md.nvram_size)
+ if (!ppc_md.nvram_size) {
+ ret = -ENODEV;
goto out;
+ }
- ret = 0;
size = ppc_md.nvram_size();
- if (*ppos = size || size 0)
+ if (size 0) {
+ ret = size;
+ goto out;
+ }
+
+ if (*ppos = size) {
+ ret = 0;
goto out;
+ }
count = min_t(size_t, count, size - *ppos);
count = min(count, PAGE_SIZE);
- ret = -ENOMEM;
tmp = kmalloc(count, GFP_KERNEL);
- if (!tmp)
+ if (!tmp) {
+ ret = -ENOMEM;
goto out;
+ }
ret = ppc_md.nvram_read(tmp, count, ppos);
if (ret = 0)
--
1.7.7.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
The function pci_devs_phb_init is invoked more earlier than we really
probe the pci controller, so it does nothing at all. And we also don't
need the pci_dn stuff for the fsl powerpc64 boards, just remove it.
It also seems that we don't support ISA on all the current corenet ds
boards. So picking a primary bus seems useless, remove that function
too.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/platforms/85xx/corenet_ds.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/corenet_ds.c
b/arch/powerpc/platforms/85xx/corenet_ds.c
index c59c617..aa3690b 100644
--- a/arch/powerpc/platforms/85xx/corenet_ds.c
+++ b/arch/powerpc/platforms/85xx/corenet_ds.c
@@ -53,12 +53,6 @@ void __init corenet_ds_setup_arch(void)
{
mpc85xx_smp_init();
-#if defined(CONFIG_PCI) defined(CONFIG_PPC64)
- pci_devs_phb_init();
-#endif
-
- fsl_pci_assign_primary();
-
swiotlb_detect_4g();
pr_info(%s board from Freescale Semiconductor\n, ppc_md.name);
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/3] powerpc/fsl-pci: fix the unreachable warning message
The (1ull mem_log) is never greater than mem unless mem_log++;
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/sysdev/fsl_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..3833c8f 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -305,10 +305,10 @@ static void setup_pci_atmu(struct pci_controller *hose)
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
/* Size window to exact size if power-of-two or one size up */
if ((1ull mem_log) != mem) {
+ mem_log++;
if ((1ull mem_log) mem)
pr_info(%s: Setting PCI inbound window
greater than memory size\n, name);
- mem_log++;
}
piwar |= ((mem_log - 1) PIWAR_SZ_MASK);
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/3] several cleanup patches for fsl pci
These patches are against Linus's tree and passed the boot test on T4240qds board. Kevin Hao (3): powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board powerpc/fsl-pci: fix the unreachable warning message powerpc/fsl-pci: enable SWIOTLB in function setup_pci_atmu arch/powerpc/platforms/85xx/corenet_ds.c | 6 -- arch/powerpc/sysdev/fsl_pci.c| 24 2 files changed, 4 insertions(+), 26 deletions(-) -- 1.8.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/3] powerpc/fsl-pci: enable SWIOTLB in function setup_pci_atmu
This function contains all the stuff we need to check if SWIOTLB
should be enabled or not. So it is more convenient to enable
the SWIOTLB here than later.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/sysdev/fsl_pci.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 3833c8f..793e64d 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -381,7 +381,9 @@ static void setup_pci_atmu(struct pci_controller *hose)
}
if (hose-dma_window_size mem) {
-#ifndef CONFIG_SWIOTLB
+#ifdef CONFIG_SWIOTLB
+ ppc_swiotlb_enable = 1;
+#else
pr_err(%s: ERROR: Memory size exceeds PCI ATMU ability to
map - enable CONFIG_SWIOTLB to avoid dma errors.\n,
name);
@@ -934,28 +936,10 @@ static int fsl_pci_probe(struct platform_device *pdev)
{
int ret;
struct device_node *node;
-#ifdef CONFIG_SWIOTLB
- struct pci_controller *hose;
-#endif
node = pdev-dev.of_node;
ret = fsl_add_bridge(pdev, fsl_pci_primary == node);
-#ifdef CONFIG_SWIOTLB
- if (ret == 0) {
- hose = pci_find_hose_for_OF_device(pdev-dev.of_node);
-
- /*
-* if we couldn't map all of DRAM via the dma windows
-* we need SWIOTLB to handle buffers located outside of
-* dma capable memory region
-*/
- if (memblock_end_of_DRAM() - 1 hose-dma_window_base_cur +
- hose-dma_window_size)
- ppc_swiotlb_enable = 1;
- }
-#endif
-
mpc85xx_pci_err_probe(pdev);
return 0;
--
1.8.1.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/pci: fix PCI-e check link issue
On Friday 17 May 2013 15:35:29 Yuanquan Chen wrote:
For Freescale powerpc platform, the PCI-e bus number uses the reassign mode
by default. It means the second PCI-e controller's hose-first_busno is the
first controller's last bus number adding 1. For some hotpluged device(or
controlled by FPGA), the device is linked to PCI-e slot at linux runtime.
It needs rescan for the system to add it and driver it to work. It successes
to rescan the device linked to the first PCI-e controller's slot, but fails
to rescan the device linked to the second PCI-e controller's slot. The
cause is that the bus-number is reset to 0, which isn't equal to the
hose-first_busno for the second controller checking PCI-e link. So it
doesn't really check the PCI-e link status, the link status is always
no_link. The device won't be really rescaned. Reset the bus-number to
hose-first_busno in the function fsl_pcie_check_link(), it will do the
real checking PCI-e link status for the second controller, the device will
be rescaned.
Signed-off-by: Yuanquan Chen yuanquan.c...@freescale.com
Tested-by: Rojhalat Ibrahim i...@rtschenk.de
---
arch/powerpc/sysdev/fsl_pci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
index 028ac1f..534597a 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -64,7 +64,7 @@ static int fsl_pcie_check_link(struct pci_controller
*hose) if (hose-indirect_type PPC_INDIRECT_TYPE_FSL_CFG_REG_LINK) {
if (hose-ops-read == fsl_indirect_read_config) {
struct pci_bus bus;
- bus.number = 0;
+ bus.number = hose-first_busno;
bus.sysdata = hose;
bus.ops = hose-ops;
indirect_read_config(bus, 0, PCIE_LTSSM, 4, val);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
On Sun, May 19, 2013 at 07:40:09PM +0300, Michael S. Tsirkin wrote:
OK I get it. So let me correct myself. The simple code
that does something like this under a spinlock:
preempt_disable
pagefault_disable
error = copy_to_user
pagefault_enable
preempt_enable
is not doing anything wrong and should not get a warning,
as long as error is handled correctly later.
Right?
Indeed, but I don't get the point of the preempt_{disable,enable}()
here. Why does it have to disable preemption explicitly here? I thought
all you wanted was to avoid the pagefault handler and make it do the
exception table thing; for that pagefault_disable() is sufficient.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
On Sun, May 19, 2013 at 12:35:26PM +0300, Michael S. Tsirkin wrote:
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -198,7 +198,6 @@ void might_fault(void);
#else
static inline void might_fault(void)
{
- might_sleep();
This removes potential resched points for PREEMPT_VOLUNTARY -- was that
intentional?
No it's a bug. Thanks for pointing this out.
OK so I guess it should be might_sleep_if(!in_atomic())
and this means might_fault would have to move from linux/kernel.h to
linux/uaccess.h, since in_atomic() is in linux/hardirq.h
Makes sense?
So the only difference between PROVE_LOCKING and not should be the
might_lock_read() thing; so how about something like this?
---
include/linux/kernel.h | 7 ++-
include/linux/uaccess.h | 26 ++
mm/memory.c | 14 ++
3 files changed, 30 insertions(+), 17 deletions(-)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index e96329c..70812f4 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -194,12 +194,9 @@ extern int _cond_resched(void);
})
#ifdef CONFIG_PROVE_LOCKING
-void might_fault(void);
+void might_fault_lockdep(void);
#else
-static inline void might_fault(void)
-{
- might_sleep();
-}
+static inline void might_fault_lockdep(void) { }
#endif
extern struct atomic_notifier_head panic_notifier_list;
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index 5ca0951..50a2cc9 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -38,6 +38,32 @@ static inline void pagefault_enable(void)
preempt_check_resched();
}
+static inline bool __can_fault(void)
+{
+ /*
+* Some code (nfs/sunrpc) uses socket ops on kernel memory while
+* holding the mmap_sem, this is safe because kernel memory doesn't
+* get paged out, therefore we'll never actually fault, and the
+* below annotations will generate false positives.
+*/
+ if (segment_eq(get_fs(), KERNEL_DS))
+ return false;
+
+ if (in_atomic() /* || pagefault_disabled() */)
+ return false;
+
+ return true;
+}
+
+static inline void might_fault(void)
+{
+ if (!__can_fault())
+ return;
+
+ might_sleep();
+ might_fault_lockdep();
+}
+
#ifndef ARCH_HAS_NOCACHE_UACCESS
static inline unsigned long __copy_from_user_inatomic_nocache(void *to,
diff --git a/mm/memory.c b/mm/memory.c
index 6dc1882..266610c 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4211,19 +4211,9 @@ void print_vma_addr(char *prefix, unsigned long ip)
}
#ifdef CONFIG_PROVE_LOCKING
-void might_fault(void)
+void might_fault_lockdep(void)
{
/*
-* Some code (nfs/sunrpc) uses socket ops on kernel memory while
-* holding the mmap_sem, this is safe because kernel memory doesn't
-* get paged out, therefore we'll never actually fault, and the
-* below annotations will generate false positives.
-*/
- if (segment_eq(get_fs(), KERNEL_DS))
- return;
-
- might_sleep();
- /*
* it would be nicer only to annotate paths which are not under
* pagefault_disable, however that requires a larger audit and
* providing helpers like get_user_atomic.
@@ -4231,7 +4221,7 @@ void might_fault(void)
if (!in_atomic() current-mm)
might_lock_read(current-mm-mmap_sem);
}
-EXPORT_SYMBOL(might_fault);
+EXPORT_SYMBOL(might_fault_lockdep);
#endif
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_HUGETLBFS)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 10/10] kernel: might_fault does not imply might_sleep
On Sun, May 19, 2013 at 12:35:26PM +0300, Michael S. Tsirkin wrote: On Thu, May 16, 2013 at 08:40:41PM +0200, Peter Zijlstra wrote: On Thu, May 16, 2013 at 02:16:10PM +0300, Michael S. Tsirkin wrote: There are several ways to make sure might_fault calling function does not sleep. One is to use it on kernel or otherwise locked memory - apparently nfs/sunrpc does this. As noted by Ingo, this is handled by the migh_fault() implementation in mm/memory.c but not the one in linux/kernel.h so in the current code might_fault() schedules differently depending on CONFIG_PROVE_LOCKING, which is an undesired semantical side effect. Another is to call pagefault_disable: in this case the page fault handler will go to fixups processing and we get an error instead of sleeping, so the might_sleep annotation is a false positive. vhost driver wants to do this now in order to reuse socket ops under a spinlock (and fall back on slower thread handler on error). Are you using the assumption that spin_lock() implies preempt_disable() implies pagefault_disable()? Note that this assumption isn't valid for -rt where the spinlock becomes preemptible but we'll not disable pagefaults. No, I was not assuming that. What I'm trying to say is that a caller that does something like this under a spinlock: preempt_disable pagefault_disable error = copy_to_user pagefault_enable preempt_enable_no_resched is not doing anything wrong and should not get a warning, as long as error is handled correctly later. Right? Aside from the no_resched() thing which Steven already explained and my previous email asking why you need the preempt_disable() at all, that should indeed work. The reason I was asking was that I wasn't sure you weren't doing: spin_lock(my_lock); error = copy_to_user(); spin_unlock(my_lock); and expecting the copy_to_user() to always take the exception table route. This works on mainline (since spin_lock implies a preempt disable and preempt_disable is the same as pagefault_disable). However as should be clear by now, it doesn't quite work that way for -rt. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
On Tue, May 21, 2013 at 03:41:35PM +1000, Michael Neuling wrote: Peter Zijlstra pet...@infradead.org wrote: Can we add your signed-off-by on this? We are cleaning up our series for conditional branches and would like to add this as part of the post. Sure, but its completely untested.. I was hoping Stephane would say somnething about it since he wrote all that magic ;-) But yeah, feel free to add my SoB. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
On Tue, May 21, 2013 at 10:50 AM, Peter Zijlstra pet...@infradead.org wrote: On Tue, May 21, 2013 at 03:41:35PM +1000, Michael Neuling wrote: Peter Zijlstra pet...@infradead.org wrote: Can we add your signed-off-by on this? We are cleaning up our series for conditional branches and would like to add this as part of the post. Sure, but its completely untested.. I was hoping Stephane would say somnething about it since he wrote all that magic ;-) Let me take a look at it. But yeah, feel free to add my SoB. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/3] perf, x86, lbr: Demand proper privileges for PERF_SAMPLE_BRANCH_KERNEL
On Thu, May 16, 2013 at 12:15 PM, Michael Neuling mi...@neuling.org wrote:
Peter Zijlstra pet...@infradead.org wrote:
On Wed, May 15, 2013 at 03:37:22PM +0200, Stephane Eranian wrote:
On Fri, May 3, 2013 at 2:11 PM, Peter Zijlstra a.p.zijls...@chello.nl
wrote:
We should always have proper privileges when requesting kernel data.
Cc: Andi Kleen a...@linux.intel.com
Cc: eran...@google.com
Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl
Link:
http://lkml.kernel.org/n/tip-v0x9ky3ahzr6nm3c6ilwr...@git.kernel.org
---
arch/x86/kernel/cpu/perf_event_intel_lbr.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/arch/x86/kernel/cpu/perf_event_intel_lbr.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_lbr.c
@@ -318,8 +318,11 @@ static void intel_pmu_setup_sw_lbr_filte
if (br_type PERF_SAMPLE_BRANCH_USER)
mask |= X86_BR_USER;
- if (br_type PERF_SAMPLE_BRANCH_KERNEL)
+ if (br_type PERF_SAMPLE_BRANCH_KERNEL) {
+ if (perf_paranoid_kernel() !capable(CAP_SYS_ADMIN))
+ return -EACCES;
mask |= X86_BR_KERNEL;
+ }
This will prevent regular users from capturing kernel - kernel branches.
But it won't prevent users from getting kernel - user branches. Thus
some kernel address will still be captured. I guess they could be
eliminated
by the sw_filter.
When using LBR priv level filtering, the filter applies to the branch
target
only.
How about something like the below? It also adds the branch flags
Mikey wanted for PowerPC.
Peter,
BTW PowerPC also has the ability to filter on conditional branches. Any
chance we could add something like the follow to perf also?
Mikey
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index fb104e5..891c769 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -157,8 +157,9 @@ enum perf_branch_sample_type {
PERF_SAMPLE_BRANCH_ANY_CALL = 1U 4, /* any call branch */
PERF_SAMPLE_BRANCH_ANY_RETURN = 1U 5, /* any return branch */
PERF_SAMPLE_BRANCH_IND_CALL = 1U 6, /* indirect calls */
+ PERF_SAMPLE_BRANCH_CONDITIONAL = 1U 7, /* conditional branches */
I would use PERF_SAMPLE_BRANCH_COND here.
- PERF_SAMPLE_BRANCH_MAX = 1U 7, /* non-ABI */
+ PERF_SAMPLE_BRANCH_MAX = 1U 8, /* non-ABI */
};
#define PERF_SAMPLE_BRANCH_PLM_ALL \
diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
index cdf58ec..5b0b89d 100644
--- a/tools/perf/builtin-record.c
+++ b/tools/perf/builtin-record.c
@@ -676,6 +676,7 @@ static const struct branch_mode branch_modes[] = {
BRANCH_OPT(any_call, PERF_SAMPLE_BRANCH_ANY_CALL),
BRANCH_OPT(any_ret, PERF_SAMPLE_BRANCH_ANY_RETURN),
BRANCH_OPT(ind_call, PERF_SAMPLE_BRANCH_IND_CALL),
+ BRANCH_OPT(cnd, PERF_SAMPLE_BRANCH_CONDITIONAL),
use cond
BRANCH_END
};
And if you do this, you also need to update the x86
perf_event_intel_lbr.c mapping
tables to fill out the entries for PERF_SAMPLE_BRANCH_COND:
[PERF_SAMPLE_BRANCH_COND] = LBR_JCC,
And you also need to update intel_pmu_setup_sw_lbr_filter()
to handle the conversion to x86 instructions:
if (br_type PERF_SAMPLE_BRANCH_COND)
mask |= X86_BR_JCC;
You also need to update the perf-record.txt documentation to list cond
as a possible
branch filter.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] Enable multiple MSI feature in pSeries
On Tue, Jan 15, 2013 at 03:38:53PM +0800, Mike Qiu wrote: The test results is shown by 'cat /proc/interrups': CPU0 CPU1 CPU2 CPU3 16: 240458 261601 226310 200425 XICS Level IPI 17: 0 0 0 0 XICS Level RAS_EPOW 18: 10 0 3 2 XICS Level hvc_console 19: 122182 28481 28527 28864 XICS Level ibmvscsi 20:5067388226108118 XICS Level eth0 21: 6 5 5 5 XICS Level host1-0 22:817814816813 XICS Level host1-1 Hi Mike, I am curious if pSeries firmware allows changing affinity masks independently for multiple MSIs? I.e. in your example, would it be possible to assign IRQ21 and IRQ22 to different CPUs? Thanks! LOC: 398077 316725 231882 203049 Local timer interrupts SPU: 1659919961903 Spurious interrupts CNT: 0 0 0 0 Performance monitoring interrupts MCE: 0 0 0 0 Machine check exceptions -- Regards, Alexander Gordeev agord...@redhat.com ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 01/12] net: mv643xx_eth: use phy_disconnect instead of phy_detach
Using a separated mdio bus driver with mvmdio, phy_detach on network device removal will not stop the phy and finally lead to NULL pointer dereference in mvmdio due to non-existent network device. Use phy_disconnect instead to properly stop phy device from accessing network device prior removal of the network device. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Note: I observed this behavior when removing a modular mv643xx_eth driver after attaching it to a phy handled by (also modular) mvmdio. The mvmdio conversion has been done in commit c3a07134e6aa5b93a37f72ffa3d11fadf72bf757 (mv643xx_eth: convert to use the Marvell Orion MDIO driver) and should go back any -stable version with that commit (propably only 3.9) @David: I am not sure if the above description is sufficient for a -stable patch, if you need more, like actual kernel failure, I am sure I can reproduce it. Cc: David Miller da...@davemloft.net Cc: Lennert Buytenhek buyt...@wantstofly.org Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- drivers/net/ethernet/marvell/mv643xx_eth.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c index d0afeea..ef3454c 100644 --- a/drivers/net/ethernet/marvell/mv643xx_eth.c +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c @@ -2805,7 +2805,7 @@ static int mv643xx_eth_remove(struct platform_device *pdev) unregister_netdev(mp-dev); if (mp-phy != NULL) - phy_detach(mp-phy); + phy_disconnect(mp-phy); cancel_work_sync(mp-tx_timeout_task); if (!IS_ERR(mp-clk)) -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 02/12] net: mv643xx_eth: use managed devm_ioremap for port registers
Make use of managed devm_ioremap and remove corresponding iounmap.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index ef3454c..e658ebd 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -2470,7 +2470,7 @@ static int mv643xx_eth_shared_probe(struct
platform_device *pdev)
if (msp == NULL)
return -ENOMEM;
- msp-base = ioremap(res-start, resource_size(res));
+ msp-base = devm_ioremap(pdev-dev, res-start, resource_size(res));
if (msp-base == NULL)
return -ENOMEM;
@@ -2498,7 +2498,6 @@ static int mv643xx_eth_shared_remove(struct
platform_device *pdev)
{
struct mv643xx_eth_shared_private *msp = platform_get_drvdata(pdev);
- iounmap(msp-base);
if (!IS_ERR(msp-clk))
clk_disable_unprepare(msp-clk);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 03/12] net: mv643xx_eth: add phy_node to platform_data struct
This adds a struct device_node pointer for a phy passed by phandle
to mv643xx_eth node.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
include/linux/mv643xx_eth.h |2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
index 141d395..6e8215b 100644
--- a/include/linux/mv643xx_eth.h
+++ b/include/linux/mv643xx_eth.h
@@ -30,6 +30,7 @@ struct mv643xx_eth_shared_platform_data {
#define MV643XX_ETH_PHY_ADDR(x)(0x80 | (x))
#define MV643XX_ETH_PHY_NONE 0xff
+struct device_node;
struct mv643xx_eth_platform_data {
/*
* Pointer back to our parent instance, and our port number.
@@ -41,6 +42,7 @@ struct mv643xx_eth_platform_data {
* Whether a PHY is present, and if yes, at which address.
*/
int phy_addr;
+ struct device_node *phy_node;
/*
* Use this MAC address if it is valid, overriding the
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 00/12] net: mv643xx_eth DT support and fixes
This patch set picks up work by Florian Fainelli bringing full DT support to mv643xx_eth and Marvell SoCs using it. The current v4 patch set drops 1:1 compatibiliy with PPC binding for two reasons: (a) PPC parses DT nodes in arch/ppc/sysdev and creates non-DT platform_devices itself, (b) property and node naming for new ethernet devices is slightly different (phy vs phy-handle, marvell, prefix) Anyway, the two bindings are functionally compatible and PPC bindings can be converted if desireable. The patch set if fully bisectable and care has been taken to (a) not reparse on PPC platforms, (b) allow to use platform_device based registration even if on CONFIG_OF. Not tested is double registration issues, i.e. if DT nodes are provided but legacy registration it not yet removed. This double registration should lead to either non-DT or DT registered device fail on already claimed ressources. Also this patch set picks up the opportunity to fix some repeatedly reported issues with modular mvmdio/mv643xx_eth loading, unloading, and reloading. It has been tested on SolidRun CuBox (Dove) and Seagate Dockstar (Kirkwood) so far. Patch 1 fixes an issue introduced with switch to separate mvmdio driver, where detaching mv643xx_eth from a phy will not stop the phy state machine and finally dereference the already removed network device. Using phy_disconnect properly stops the phy state machine before detaching from it. Perhaps, this patch should go back in stable (most likely 3.9 only) if mvmdio separation patch went in there. Patch 2 makes use of managed devm_ioremap for the last remaining non-managed resource. Patches 3-4 prepare DT support for mv643xx_eth by adding a phy_node pointer to platform_data and exploiting that phy_node when attaching to a phy. Patch 5 introduces DT parsing support for mv643xx_eth by adding a match table to the shared driver and adding a platform_device for each of its child nodes. Patches 6-8 add corresponding device tree nodes to Marvell Dove, Kirkwood, and Orion5x including all boards. Where known, also the PHY compatible string has been set to what is reported in the boards boot loader. Patches 9, 10-11, and 12 finally remove all legacy platform_device based registration from Dove, Kirkwood, and Orion5x DT setup. For Kirkwood also now obsolete board specific setup is removed from common DT board setup, Kconfig, Makefile, and kirkwood_defconfig. For the patches above I suggest to take Patches 1-5 through David Miller's branch, and Patches 6-12 through Jason Cooper's when they have appeared on mainline linux. The patch set has been based on todays net-next, if I shall rebase them on any other branch please name it. Sebastian Hesselbarth (12): net: mv643xx_eth: use phy_disconnect instead of phy_detach net: mv643xx_eth: use managed devm_ioremap for port registers net: mv643xx_eth: add phy_node to platform_data struct net: mv643xx_eth: use of_phy_connect if phy_node present net: mv643xx_eth: add DT parsing support ARM: dove: add gigabit ethernet and mvmdio device tree nodes ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes ARM: orion5x: add gigabit ethernet and mvmdio device tree nodes ARM: dove: remove legacy mv643xx_eth setup ARM: kirkwood: remove legacy clk alias for mv643xx_eth ARM: kirkwood: remove redundant DT board files ARM: orion5x: remove legacy mv643xx_eth board setup .../devicetree/bindings/net/marvell-orion-net.txt | 83 + arch/arm/boot/dts/dove-cubox.dts |7 + arch/arm/boot/dts/dove.dtsi| 35 arch/arm/boot/dts/kirkwood-cloudbox.dts| 16 ++ arch/arm/boot/dts/kirkwood-dnskw.dtsi | 16 ++ arch/arm/boot/dts/kirkwood-dockstar.dts| 17 ++ arch/arm/boot/dts/kirkwood-dreamplug.dts | 28 +++ arch/arm/boot/dts/kirkwood-goflexnet.dts | 16 ++ .../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 30 arch/arm/boot/dts/kirkwood-ib62x0.dts | 16 ++ arch/arm/boot/dts/kirkwood-iconnect.dts| 16 ++ arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 24 +++ arch/arm/boot/dts/kirkwood-is2.dts |2 + arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 16 ++ arch/arm/boot/dts/kirkwood-lsxl.dtsi | 28 +++ arch/arm/boot/dts/kirkwood-mplcec4.dts | 27 +++ .../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 16 ++ arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 16 ++ arch/arm/boot/dts/kirkwood-ns2.dts |2 + arch/arm/boot/dts/kirkwood-ns2lite.dts |2 + arch/arm/boot/dts/kirkwood-ns2max.dts |2 + arch/arm/boot/dts/kirkwood-ns2mini.dts |2 + arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 16 ++ arch/arm/boot/dts/kirkwood-topkick.dts | 16 ++ arch/arm/boot/dts/kirkwood-ts219-6281.dts |4 +-
[PATCH v4 04/12] net: mv643xx_eth: use of_phy_connect if phy_node present
This connects to a phy node passed to the port device instead of probing
the phy by phy_addr.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index e658ebd..0f5c3c2 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -60,6 +60,7 @@
#include linux/types.h
#include linux/slab.h
#include linux/clk.h
+#include linux/of_mdio.h
static char mv643xx_eth_driver_name[] = mv643xx_eth;
static char mv643xx_eth_driver_version[] = 1.4;
@@ -2715,17 +2716,27 @@ static int mv643xx_eth_probe(struct platform_device
*pdev)
netif_set_real_num_tx_queues(dev, mp-txq_count);
netif_set_real_num_rx_queues(dev, mp-rxq_count);
- if (pd-phy_addr != MV643XX_ETH_PHY_NONE) {
+ err = 0;
+ if (pd-phy_node) {
+ mp-phy = of_phy_connect(mp-dev, pd-phy_node,
+mv643xx_eth_adjust_link, 0,
+PHY_INTERFACE_MODE_GMII);
+ if (!mp-phy)
+ err = -ENODEV;
+ } else if (pd-phy_addr != MV643XX_ETH_PHY_NONE) {
mp-phy = phy_scan(mp, pd-phy_addr);
- if (IS_ERR(mp-phy)) {
+ if (IS_ERR(mp-phy))
err = PTR_ERR(mp-phy);
- if (err == -ENODEV)
- err = -EPROBE_DEFER;
- goto out;
- }
- phy_init(mp, pd-speed, pd-duplex);
+ else
+ phy_init(mp, pd-speed, pd-duplex);
}
+ if (err == -ENODEV) {
+ err = -EPROBE_DEFER;
+ goto out;
+ }
+ if (err)
+ goto out;
SET_ETHTOOL_OPS(dev, mv643xx_eth_ethtool_ops);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
This patch adds orion-eth and mvmdio device tree nodes for DT enabled
Dove boards. As there is only one ethernet controller on Dove, a default
phy node is also added with a note to set its reg property on a per-board
basis.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v3-v4:
- convert to new device tree binding
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/dove-cubox.dts |7 +++
arch/arm/boot/dts/dove.dtsi | 35 +++
2 files changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dts
index 7e3065a..02618fa 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -49,6 +49,13 @@
uart0 { status = okay; };
sata0 { status = okay; };
i2c0 { status = okay; };
+mdio { status = okay; };
+eth { status = okay; };
+
+ethphy {
+ compatible = marvell,88e1310;
+ reg = 1;
+};
sdio0 {
status = okay;
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 6cab468..8612658 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -258,5 +258,40 @@
dmacap,xor;
};
};
+
+ mdio: mdio-bus@72004 {
+ compatible = marvell,orion-mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x72004 0x84;
+ interrupts = 30;
+ clocks = gate_clk 2;
+ status = disabled;
+
+ ethphy: ethernet-phy {
+ device-type = ethernet-phy;
+ /* set phy address in board file */
+ };
+ };
+
+ eth: ethernet-controller@72000 {
+ compatible = marvell,orion-eth;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x72000 0x4000;
+ clocks = gate_clk 2;
+ marvell,tx-checksum-limit = 1600;
+ status = disabled;
+
+ ethernet-port@0 {
+ device_type = network;
+ compatible = marvell,orion-eth-port;
+ reg = 0;
+ interrupts = 29;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ phy-handle = ethphy;
+ };
+ };
};
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 05/12] net: mv643xx_eth: add DT parsing support
This adds device tree parsing support for the shared driver of mv643xx_eth.
As the bindings are slightly different from current PPC bindings new binding
documentation is also added. Following PPC-style device setup, the shared
driver now also adds port platform_devices and sets up port platform_data.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Note: Although different, device tree bindings are compatible with PPC
bindings. As I do not have access to any PPC platform using mv643xx_eth,
I leave conversion (phy vs phy-handle) and compatible string name
up to PPC guys.
Due to hang reports for modular built mvmdio and mv643xx_eth, I have
tested module loading/unloading/reloading on CuBox (Dove) and Dockstar
(Kirkwood) without any issues for the whole patch set.
Changelog:
v3-v4:
- separation of independent patches (phy, of_mdio, devm)
- stand-alone device tree binding compatible to existing mv64x60 binding
- device node match for shared driver only
- device node registration for port drivers
- properly return -EPROBE_DEFER on missing of phy (Reported by Simon Baatz)
v2-v3:
- rebase on top of mv643xx_eth clean-ups
- do not reparse existing platform_data
- use managed devm_kzalloc for parsed platform_data
- use of_property_read_u32 where applicable
- add phy_node to platform_data
- use of_connect_phy if DT phy node was found
v1-v2:
- properly ifdef of_platform_bus_probe with CONFIG_OF
- handle of_platform_bus_probe errors and cleanup accordingly
- use of_property_read_u32 where applicable
- parse duplex and speed property in PHY-less configuration
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
.../devicetree/bindings/net/marvell-orion-net.txt | 83 +++
drivers/net/ethernet/marvell/mv643xx_eth.c | 152 +++-
2 files changed, 231 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/marvell-orion-net.txt
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt
b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
new file mode 100644
index 000..23ffd57
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -0,0 +1,83 @@
+Marvell Orion/Discovery ethernet controller
+=
+
+The Marvell Discovery ethernet controller can be found on Marvell Orion SoCs
+(Kirkwood, Dove, Orion5x, and Discovery Innovation) and as part of Marvell
+Discovery system controller chips (mv64[345]60).
+
+The Discovery ethernet controller is described with two levels of nodes. The
+first level describes the ethernet controller itself and the second level
+describes up to 3 ethernet port nodes within that controller. The reason for
+the multiple levels is that the port registers are interleaved within a single
+set of controller registers. Each port node describes port-specific properties.
+
+Note: The above separation is only true for Discovery system controllers.
+For Orion SoCs we stick to the separation, although there each controller has
+only one port associated. Multiple ports are implemented as multiple
single-port
+controllers.
+
+* Ethernet controller node
+
+Required controller properties:
+ - #address-cells: shall be 1.
+ - #size-cells: shall be 0.
+ - compatible: shall be marvell,orion-eth.
+ - reg: address and length of the controller registers.
+
+Optional controller properties:
+ - clocks: phandle reference to the controller clock.
+ - marvell,tx-checksum-limit: max tx packet size for hardware checksum.
+
+* Ethernet port node
+
+Required port properties:
+ - device_type: shall be network.
+ - compatible: shall be marvell,orion-eth-port.
+ - reg: port number relative to ethernet controller, shall be 0, 1, or 2.
+ - interrupts: port interrupt.
+ - local-mac-address: 6 bytes MAC address.
+
+Optional port properties:
+ - marvell,tx-queue-size: size of the transmit ring buffer.
+ - marvell,tx-sram-addr: address of transmit descriptor buffer located in SRAM.
+ - marvell,tx-sram-size: size of transmit descriptor buffer located in SRAM.
+ - marvell,rx-queue-size: size of the receive ring buffer.
+ - marvell,rx-sram-addr: address of receive descriptor buffer located in SRAM.
+ - marvell,rx-sram-size: size of receive descriptor buffer located in SRAM.
+
+and
+
+ - phy-handle: phandle reference to ethernet PHY.
+
+or
+
+ - speed: port speed if no PHY connected.
+ - duplex: port mode if no PHY connected.
+
+* Node example:
+
+mdio-bus {
+ ...
+ ethphy: ethernet-phy@8 {
+ device_type = ethernet-phy;
+ ...
+ };
+};
+
+eth: ethernet-controller@72000 {
+ compatible = marvell,orion-eth;
+
[PATCH v4 07/12] ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Kirkwood boards. Phy nodes are also added with reg property set on a
per-board basis.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v3-v4:
- convert to new device tree binding
- fix phy addr of kirkwood-ts219-6282.dts (Reported by Andrew Lunn)
- fix mvmdio interrupt (Reported by Simon Baatz)
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/kirkwood-cloudbox.dts| 16 ++
arch/arm/boot/dts/kirkwood-dnskw.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-dockstar.dts| 17 +++
arch/arm/boot/dts/kirkwood-dreamplug.dts | 28 +++
arch/arm/boot/dts/kirkwood-goflexnet.dts | 16 ++
.../arm/boot/dts/kirkwood-guruplug-server-plus.dts | 30 +++
arch/arm/boot/dts/kirkwood-ib62x0.dts | 16 ++
arch/arm/boot/dts/kirkwood-iconnect.dts| 16 ++
arch/arm/boot/dts/kirkwood-iomega_ix2_200.dts | 24 +
arch/arm/boot/dts/kirkwood-is2.dts |2 +
arch/arm/boot/dts/kirkwood-km_kirkwood.dts | 16 ++
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 28 +++
arch/arm/boot/dts/kirkwood-mplcec4.dts | 27 ++
.../boot/dts/kirkwood-netgear_readynas_duo_v2.dts | 16 ++
arch/arm/boot/dts/kirkwood-ns2-common.dtsi | 16 ++
arch/arm/boot/dts/kirkwood-ns2.dts |2 +
arch/arm/boot/dts/kirkwood-ns2lite.dts |2 +
arch/arm/boot/dts/kirkwood-ns2max.dts |2 +
arch/arm/boot/dts/kirkwood-ns2mini.dts |2 +
arch/arm/boot/dts/kirkwood-openblocks_a6.dts | 16 ++
arch/arm/boot/dts/kirkwood-topkick.dts | 16 ++
arch/arm/boot/dts/kirkwood-ts219-6281.dts |4 +-
arch/arm/boot/dts/kirkwood-ts219-6282.dts |4 +-
arch/arm/boot/dts/kirkwood-ts219.dtsi | 16 ++
arch/arm/boot/dts/kirkwood.dtsi| 52
25 files changed, 398 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-cloudbox.dts
b/arch/arm/boot/dts/kirkwood-cloudbox.dts
index 5f21d4e..03e1b68 100644
--- a/arch/arm/boot/dts/kirkwood-cloudbox.dts
+++ b/arch/arm/boot/dts/kirkwood-cloudbox.dts
@@ -87,3 +87,19 @@
gpios = gpio0 17 0;
};
};
+
+mdio {
+ status = okay;
+
+ ethphy0: ethernet-phy@0 {
+ device_type = ethernet-phy;
+ reg = 0;
+ };
+};
+
+eth0 {
+ status = okay;
+ ethernet0-port@0 {
+ phy-handle = ethphy0;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
index 6875ac0..7c8bc17 100644
--- a/arch/arm/boot/dts/kirkwood-dnskw.dtsi
+++ b/arch/arm/boot/dts/kirkwood-dnskw.dtsi
@@ -217,3 +217,19 @@
};
};
};
+
+mdio {
+ status = okay;
+
+ ethphy0: ethernet-phy@8 {
+ device_type = ethernet-phy;
+ reg = 8;
+ };
+};
+
+eth0 {
+ status = okay;
+ ethernet0-port@0 {
+ phy-handle = ethphy0;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dockstar.dts
b/arch/arm/boot/dts/kirkwood-dockstar.dts
index 0196cf6..b5aebbc 100644
--- a/arch/arm/boot/dts/kirkwood-dockstar.dts
+++ b/arch/arm/boot/dts/kirkwood-dockstar.dts
@@ -91,3 +91,20 @@
};
};
};
+
+mdio {
+ status = okay;
+
+ ethphy0: ethernet-phy@0 {
+ device_type = ethernet-phy;
+ compatible = marvell,88e1116;
+ reg = 0;
+ };
+};
+
+eth0 {
+ status = okay;
+ ethernet0-port@0 {
+ phy-handle = ethphy0;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-dreamplug.dts
b/arch/arm/boot/dts/kirkwood-dreamplug.dts
index 289e51d..e0c93d4 100644
--- a/arch/arm/boot/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/boot/dts/kirkwood-dreamplug.dts
@@ -99,3 +99,31 @@
};
};
};
+
+mdio {
+ status = okay;
+
+ ethphy0: ethernet-phy@0 {
+ device_type = ethernet-phy;
+ reg = 0;
+ };
+
+ ethphy1: ethernet-phy@1 {
+ device_type = ethernet-phy;
+ reg = 1;
+ };
+};
+
+eth0 {
+ status = okay;
+ ethernet0-port@0 {
+ phy-handle = ethphy0;
+ };
+};
+
+eth1 {
+ status = okay;
+ ethernet1-port@0 {
+ phy-handle = ethphy1;
+ };
+};
diff --git a/arch/arm/boot/dts/kirkwood-goflexnet.dts
b/arch/arm/boot/dts/kirkwood-goflexnet.dts
index
[PATCH v4 08/12] ARM: orion5x: add gigabit ethernet and mvmdio device tree nodes
This patch adds mv643xx_eth and mvmdio device tree nodes for DT enabled
Orion5x boards. Phy nodes are also added with reg property set on a
per-board basis.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v3-v4:
- convert to new device tree binding
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
.../dts/orion5x-lacie-ethernet-disk-mini-v2.dts| 17
arch/arm/boot/dts/orion5x.dtsi | 29
2 files changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
index 0077fc8..c7e2efd 100644
--- a/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
+++ b/arch/arm/boot/dts/orion5x-lacie-ethernet-disk-mini-v2.dts
@@ -53,3 +53,20 @@
};
};
};
+
+mdio {
+ status = okay;
+
+ ethphy: ethernet-phy {
+ device-type = ethernet-phy;
+ reg = 8;
+ };
+};
+
+eth {
+ status = okay;
+
+ ethernet-port@0 {
+ phy-handle = ethphy;
+ };
+};
diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index 892c64e..6fe45d5 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -132,5 +132,34 @@
interrupts = 28;
status = okay;
};
+
+ mdio: mdio-bus@72004 {
+ compatible = marvell,orion-mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x72004 0x84;
+ interrupts = 22;
+ status = disabled;
+
+ /* add phy nodes in board file */
+ };
+
+ eth: ethernet-controller@72000 {
+ compatible = marvell,orion-eth;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x72000 0x4000;
+ marvell,tx-checksum-limit = 1600;
+ status = disabled;
+
+ ethernet-port@0 {
+ device_type = network;
+ compatible = marvell,orion-eth-port;
+ reg = 0;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
+ /* set phy-handle property in board file */
+ };
+ };
};
};
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 09/12] ARM: dove: remove legacy mv643xx_eth setup
With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards anymore.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/mach-dove/board-dt.c |9 -
1 file changed, 9 deletions(-)
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-dove/board-dt.c
index 0b14280..048e942 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-dove/board-dt.c
@@ -34,10 +34,6 @@ static void __init dove_legacy_clk_init(void)
clkspec.np = np;
clkspec.args_count = 1;
- clkspec.args[0] = CLOCK_GATING_BIT_GBE;
- orion_clkdev_add(NULL, mv643xx_eth_port.0,
-of_clk_get_from_provider(clkspec));
-
clkspec.args[0] = CLOCK_GATING_BIT_PCIE0;
orion_clkdev_add(0, pcie,
of_clk_get_from_provider(clkspec));
@@ -53,10 +49,6 @@ static void __init dove_of_clk_init(void)
dove_legacy_clk_init();
}
-static struct mv643xx_eth_platform_data dove_dt_ge00_data = {
- .phy_addr = MV643XX_ETH_PHY_ADDR_DEFAULT,
-};
-
static void __init dove_dt_init(void)
{
pr_info(Dove 88AP510 SoC\n);
@@ -70,7 +62,6 @@ static void __init dove_dt_init(void)
dove_of_clk_init();
/* Internal devices not ported to DT yet */
- dove_ge00_init(dove_dt_ge00_data);
dove_pcie_init(1, 1);
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 10/12] ARM: kirkwood: remove legacy clk alias for mv643xx_eth
With all boards converted to DT enabled mv643xx_eth we can now remove the clock alias for gbe clocks. The workaround for ge0/ge1 clock gates is not removed, as Kirkwood ethernet controllers loose MAC address stored in internal registers on gated ge0/ge1 clocks. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Note: I confirm that the above workaround is still required, i.e. when booting DT kernel with non-DT boot loader (no local-mac-address property) MAC address registers looses its content on clock gating. Cc: David Miller da...@davemloft.net Cc: Lennert Buytenhek buyt...@wantstofly.org Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- arch/arm/mach-kirkwood/board-dt.c |2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c index e9647b8..8db388a 100644 --- a/arch/arm/mach-kirkwood/board-dt.c +++ b/arch/arm/mach-kirkwood/board-dt.c @@ -66,12 +66,10 @@ static void __init kirkwood_legacy_clk_init(void) */ clkspec.args[0] = CGC_BIT_GE0; clk = of_clk_get_from_provider(clkspec); - orion_clkdev_add(NULL, mv643xx_eth_port.0, clk); clk_prepare_enable(clk); clkspec.args[0] = CGC_BIT_GE1; clk = of_clk_get_from_provider(clkspec); - orion_clkdev_add(NULL, mv643xx_eth_port.1, clk); clk_prepare_enable(clk); } -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 11/12] ARM: kirkwood: remove redundant DT board files
With DT support for mv643xx_eth, board specific init for some boards now is unneccessary. Remove those board files, Kconfig entries, and corresponding entries in kirkwood_defconfig. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Note: board-km_kirkwood.c is also removed, as Valentin Longchamp confirmed the lock-up is not caused by accessing clock gating registers but rather non-existent device registers. This will be addressed by dtsi separation for kirkwood and bobcat SoC variants. Changelog: v3-v4: - remove more boards that don't require board specific setup Cc: David Miller da...@davemloft.net Cc: Lennert Buytenhek buyt...@wantstofly.org Cc: Jason Cooper ja...@lakedaemon.net Cc: Andrew Lunn and...@lunn.ch Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: net...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ker...@vger.kernel.org --- arch/arm/configs/kirkwood_defconfig | 16 arch/arm/mach-kirkwood/Kconfig| 117 - arch/arm/mach-kirkwood/Makefile | 16 arch/arm/mach-kirkwood/board-dnskw.c |7 -- arch/arm/mach-kirkwood/board-dockstar.c | 32 --- arch/arm/mach-kirkwood/board-dreamplug.c | 35 arch/arm/mach-kirkwood/board-dt.c | 38 arch/arm/mach-kirkwood/board-goflexnet.c | 34 --- arch/arm/mach-kirkwood/board-guruplug.c | 33 --- arch/arm/mach-kirkwood/board-ib62x0.c | 29 -- arch/arm/mach-kirkwood/board-iconnect.c | 10 --- arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 34 --- arch/arm/mach-kirkwood/board-km_kirkwood.c| 44 -- arch/arm/mach-kirkwood/board-lsxl.c | 16 arch/arm/mach-kirkwood/board-mplcec4.c| 14 --- arch/arm/mach-kirkwood/board-ns2.c| 35 arch/arm/mach-kirkwood/board-openblocks_a6.c | 26 -- arch/arm/mach-kirkwood/board-readynas.c |6 -- arch/arm/mach-kirkwood/board-ts219.c | 13 --- arch/arm/mach-kirkwood/board-usi_topkick.c| 29 -- 20 files changed, 584 deletions(-) delete mode 100644 arch/arm/mach-kirkwood/board-dockstar.c delete mode 100644 arch/arm/mach-kirkwood/board-dreamplug.c delete mode 100644 arch/arm/mach-kirkwood/board-goflexnet.c delete mode 100644 arch/arm/mach-kirkwood/board-guruplug.c delete mode 100644 arch/arm/mach-kirkwood/board-ib62x0.c delete mode 100644 arch/arm/mach-kirkwood/board-iomega_ix2_200.c delete mode 100644 arch/arm/mach-kirkwood/board-km_kirkwood.c delete mode 100644 arch/arm/mach-kirkwood/board-ns2.c delete mode 100644 arch/arm/mach-kirkwood/board-openblocks_a6.c delete mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig index a1d8252..540ca51 100644 --- a/arch/arm/configs/kirkwood_defconfig +++ b/arch/arm/configs/kirkwood_defconfig @@ -30,27 +30,11 @@ CONFIG_MACH_SHEEVAPLUG=y CONFIG_MACH_T5325=y CONFIG_MACH_TS219=y CONFIG_MACH_TS41X=y -CONFIG_MACH_CLOUDBOX_DT=y CONFIG_MACH_DLINK_KIRKWOOD_DT=y -CONFIG_MACH_DOCKSTAR_DT=y -CONFIG_MACH_DREAMPLUG_DT=y -CONFIG_MACH_GOFLEXNET_DT=y -CONFIG_MACH_GURUPLUG_DT=y -CONFIG_MACH_IB62X0_DT=y -CONFIG_MACH_ICONNECT_DT=y -CONFIG_MACH_INETSPACE_V2_DT=y -CONFIG_MACH_IOMEGA_IX2_200_DT=y -CONFIG_MACH_KM_KIRKWOOD_DT=y CONFIG_MACH_LSXL_DT=y CONFIG_MACH_MPLCEC4_DT=y -CONFIG_MACH_NETSPACE_LITE_V2_DT=y -CONFIG_MACH_NETSPACE_MAX_V2_DT=y -CONFIG_MACH_NETSPACE_MINI_V2_DT=y -CONFIG_MACH_NETSPACE_V2_DT=y CONFIG_MACH_NSA310_DT=y -CONFIG_MACH_OPENBLOCKS_A6_DT=y CONFIG_MACH_READYNAS_DT=y -CONFIG_MACH_TOPKICK_DT=y CONFIG_MACH_TS219_DT=y # CONFIG_CPU_FEROCEON_OLD_ID is not set CONFIG_PREEMPT=y diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig index 7509a89..c2fd30b 100644 --- a/arch/arm/mach-kirkwood/Kconfig +++ b/arch/arm/mach-kirkwood/Kconfig @@ -146,13 +146,6 @@ config ARCH_KIRKWOOD_DT Say 'Y' here if you want your kernel to support the Marvell Kirkwood using flattened device tree. -config MACH_CLOUDBOX_DT - bool LaCie CloudBox NAS (Flattened Device Tree) - select ARCH_KIRKWOOD_DT - help - Say 'Y' here if you want your kernel to support the LaCie - CloudBox NAS, using Flattened Device Tree. - config MACH_DLINK_KIRKWOOD_DT bool D-Link Kirkwood-based NAS (Flattened Device Tree) select ARCH_KIRKWOOD_DT @@ -161,69 +154,6 @@ config MACH_DLINK_KIRKWOOD_DT Kirkwood-based D-Link NASes such as DNS-320 DNS-325, using Flattened Device Tree. -config MACH_DOCKSTAR_DT - bool Seagate FreeAgent Dockstar (Flattened Device Tree) - select ARCH_KIRKWOOD_DT - help - Say 'Y' here if you want your kernel to support the - Seagate FreeAgent Dockstar (Flattened Device Tree). - -config MACH_DREAMPLUG_DT - bool
[PATCH v4 12/12] ARM: orion5x: remove legacy mv643xx_eth board setup
With DT support for mv643xx_eth we do not need legacy platform_data
based setup for DT enabled boards. This patch removes eth setup
for all orion5x DT board files.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/mach-orion5x/edmini_v2-setup.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/arch/arm/mach-orion5x/edmini_v2-setup.c
b/arch/arm/mach-orion5x/edmini_v2-setup.c
index 1476155..d9de926 100644
--- a/arch/arm/mach-orion5x/edmini_v2-setup.c
+++ b/arch/arm/mach-orion5x/edmini_v2-setup.c
@@ -24,7 +24,6 @@
#include linux/pci.h
#include linux/irq.h
#include linux/mtd/physmap.h
-#include linux/mv643xx_eth.h
#include linux/leds.h
#include linux/gpio_keys.h
#include linux/input.h
@@ -96,14 +95,6 @@ static struct platform_device edmini_v2_nor_flash = {
};
/*
- * Ethernet
- /
-
-static struct mv643xx_eth_platform_data edmini_v2_eth_data = {
- .phy_addr = 8,
-};
-
-/*
* RTC 5C372a on I2C bus
/
@@ -152,7 +143,6 @@ void __init edmini_v2_init(void)
* Configure peripherals.
*/
orion5x_ehci0_init();
- orion5x_eth_init(edmini_v2_eth_data);
mvebu_mbus_add_window(devbus-boot, EDMINI_V2_NOR_BOOT_BASE,
EDMINI_V2_NOR_BOOT_SIZE);
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] drivers/macintosh: Remove obsolete cleanup for clientdata
A few new i2c-drivers came into the kernel which clear the clientdata-pointer on exit or error. This is obsolete meanwhile, the core will do it. Signed-off-by: Wolfram Sang w...@the-dreams.de --- drivers/macintosh/windfarm_smu_sat.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/macintosh/windfarm_smu_sat.c b/drivers/macintosh/windfarm_smu_sat.c index d87f5ee..ad6223e 100644 --- a/drivers/macintosh/windfarm_smu_sat.c +++ b/drivers/macintosh/windfarm_smu_sat.c @@ -343,7 +343,6 @@ static int wf_sat_remove(struct i2c_client *client) wf_unregister_sensor(sens-sens); } sat-i2c = NULL; - i2c_set_clientdata(client, NULL); kref_put(sat-ref, wf_sat_release); return 0; -- 1.7.10.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Build failure with 3.9.3 (Regression 3.9.2-3.9.3)
On 05/20/2013 08:44 PM, Adam Lackorzynski wrote: Hi, 3.9.3 introduced the following build failure: CC arch/powerpc/kernel/rtas.o arch/powerpc/kernel/rtas.c: In function ‘rtas_cpu_state_change_mask’: arch/powerpc/kernel/rtas.c:843:4: error: implicit declaration of function ‘cpu_down’ [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make[1]: *** [arch/powerpc/kernel/rtas.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 My kernel config has CONFIG_HOTPLUG_CPU off, that's why cpu_down is not defined. Shall CONFIG_HOTPLUG_CPU just be enabled or should the code in rtas.c be adapted? I think we should just enable CONFIG_HOTPLUG_CPU. I don't see any other solution to this problem. The changelog of the below (untested) patch explains the reasoning. (BTW, I'm not sure if this is the best way to alter the Kconfig in order to enable both HOTPLUG and HOTPLUG_CPU. If there is a better way to do it, let's go for it). Also, this patch applies on current mainline. We need a separate backport for 3.9 (because current mainline has a new line - select HAVE_CONTEXT_TRACKING which is not present in 3.9, and this interferes with the patch). Regards, Srivatsa S. Bhat - From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Subject: [PATCH] powerpc: Enable CONFIG_HOTPLUG_CPU on PPC_PSERIES SMP builds Adam Lackorzynski reported the following build failure on !CONFIG_HOTPLUG_CPU configuration: CC arch/powerpc/kernel/rtas.o arch/powerpc/kernel/rtas.c: In function ‘rtas_cpu_state_change_mask’: arch/powerpc/kernel/rtas.c:843:4: error: implicit declaration of function ‘cpu_down’ [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make[1]: *** [arch/powerpc/kernel/rtas.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 The build fails because cpu_down() is defined only under CONFIG_HOTPLUG_CPU. Looking further, the mobility code in pseries is one of the call-sites which uses rtas_ibm_suspend_me(), which in turn calls rtas_cpu_state_change_mask(). And the mobility code is unconditionally compiled-in (it does not fall under any Kconfig option). And commit 120496ac (powerpc: Bring all threads online prior to migration/hibernation) which introduced this build regression is critical for the proper functioning of the migration code. So it appears that the only solution to this problem is to enable CONFIG_HOTPLUG_CPU if SMP is enabled on PPC_PSERIES platforms. So make that change in the Kconfig. Reported-by: Adam Lackorzynski a...@os.inf.tu-dresden.de Cc: sta...@vger.kernel.org Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- arch/powerpc/platforms/pseries/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index 023b288..4459eff 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -19,6 +19,8 @@ config PPC_PSERIES select ZLIB_DEFLATE select PPC_DOORBELL select HAVE_CONTEXT_TRACKING + select HOTPLUG if SMP + select HOTPLUG_CPU if SMP default y config PPC_SPLPAR ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SATA hang on 8315E triggered by heavy flash write?
On 05/15/2013 03:12:21 AM, Anthony Foiani wrote:
At this point, /dev/sda is pretty much unusable, and I have to do at
least a reboot to recover. (I don't recall if I had to do a power
cycle at this point, though.)
I suspect that it is related to errata eLBC-A001 (from MPC8315E Chip
Errata, Rev. 3, 09/2011):
eLBC-A001:
Simultaneous FCM and GPCM or UPM operation may erroneously trigger
bus monitor timeout
Description: Devices: MPC8315E, MPC8314E
When the FCM is in the middle of a long transaction, such as NAND
erase or write, another transaction on the GPCM or UPM triggers the
bus monitor to start immediately for the GPCM or UPM, even though
the GPCM or UPM is still waiting for the FCM to finish and has not
yet started its transaction. If the bus monitor timeout value is not
programmed for a sufficiently large value, the local bus monitor may
time out. This timeout corrupts the current NAND Flash operation and
terminate the GPCM or UPM operation.
Impact: Local bus monitor may time out unexpectedly and corrupt the
NAND transaction.
Workaround: Set the local bus monitor timeout value to the maximum
by setting LBCR[BMT] = 0 and LBCR[BMTPS] = 0xF.
Fix plan: No plans to fix
But it seems that erratum is already fixed:
http://patchwork.ozlabs.org/patch/96339/
(git patch d08e44570e)
Am I reading that correctly?
Yes, that erratum has been worked around.
(I'm already writing only one flash
sector at a time, but it might be that even a single 0x1-byte
sector takes long enough to trigger the issue.)
I don't think this erratum is relevant. Unlike NAND, NOR flash does
not involve holding the localbus for extended periods of time. I also
don't see how it would interact with SATA, which is separate from the
localbus. Are you seeing any errors on the localbus, or just on SATA?
I also verified that
I have the relevant property in my device tree:
localbus@e0005000 {
...
compatible = fsl,mpc8315-elbc, fsl,elbc, simple-bus;
So, my questions are:
1. Is anyone else seeing something like this?
2. Is there an obvious way for our code to detect that we're in the
middle of error recovery, so we can not write to the disk until
recovery is complete?
3. Is there any chance that the 1.5Gbps limiting code might have
exacerbated the problems?
4. Should I open a support request with Freescale, or if someone from
Freescale is already reading this, could you look to see if anyone
else has reported it?
Hopefully Shaohui (our SATA person) can answer these. If you don't get
an answer, go ahead and open an official support request.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/1] powerpc: Force 32 bit MSIs on systems lacking firmware support
Recent commit e61133dda480062d221f09e4fc18f66763f8ecd0 added support
for a new firmware feature to force an adapter to use 32 bit MSIs.
However, this firmware is not available for all systems. The hack below
allows devices needing 32 bit MSIs to work on these systems as well.
It is careful to only enable this on Gen2 slots, which should limit
this to configurations where this hack is needed and tested to work.
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
---
arch/powerpc/platforms/pseries/msi.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff -puN arch/powerpc/platforms/pseries/msi.c~powerpc_32bit_msi_hack_on_papr
arch/powerpc/platforms/pseries/msi.c
--- linux/arch/powerpc/platforms/pseries/msi.c~powerpc_32bit_msi_hack_on_papr
2013-05-15 10:44:46.0 -0500
+++ linux-bjking1/arch/powerpc/platforms/pseries/msi.c 2013-05-20
15:24:52.0 -0500
@@ -397,10 +397,11 @@ static int check_msix_entries(struct pci
static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec_in, int type)
{
struct pci_dn *pdn;
- int hwirq, virq, i, rc;
+ int hwirq, virq, i, rc = -1;
struct msi_desc *entry;
struct msi_msg msg;
int nvec = nvec_in;
+ int use_32bit_msi_hack = 0;
pdn = get_pdn(pdev);
if (!pdn)
@@ -428,15 +429,37 @@ static int rtas_setup_msi_irqs(struct pc
*/
again:
if (type == PCI_CAP_ID_MSI) {
- if (pdn-force_32bit_msi)
+ if (pdn-force_32bit_msi) {
rc = rtas_change_msi(pdn, RTAS_CHANGE_32MSI_FN, nvec);
- else
+ if (rc 0) {
+ /* We only want to run the 32 bit MSI hack
below if
+the max bus speed is Gen2 speed. */
+ if (pdev-bus-max_bus_speed !=
PCIE_SPEED_5_0GT)
+ return rc;
+
+ use_32bit_msi_hack = 1;
+ }
+ }
+
+ if (rc 0)
rc = rtas_change_msi(pdn, RTAS_CHANGE_MSI_FN, nvec);
- if (rc 0 !pdn-force_32bit_msi) {
+ if (rc 0) {
pr_debug(rtas_msi: trying the old firmware call.\n);
rc = rtas_change_msi(pdn, RTAS_CHANGE_FN, nvec);
}
+
+ if (use_32bit_msi_hack rc 0) {
+ int pos;
+ u32 addr_hi, addr_lo;
+
+ dev_info(pdev-dev, rtas_msi: No 32 bit MSI firmware
support, forcing 32 bit MSI\n);
+ pos = pci_find_capability(pdev, PCI_CAP_ID_MSI);
+ pci_read_config_dword(pdev, pos + PCI_MSI_ADDRESS_HI,
addr_hi);
+ addr_lo = 0x | ((addr_hi (48 - 32)) 4);
+ pci_write_config_dword(pdev, pos + PCI_MSI_ADDRESS_LO,
addr_lo);
+ pci_write_config_dword(pdev, pos + PCI_MSI_ADDRESS_HI,
0);
+ }
} else
rc = rtas_change_msi(pdn, RTAS_CHANGE_MSIX_FN, nvec);
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 06/12] ARM: dove: add gigabit ethernet and mvmdio device tree nodes
On Tue, May 21, 2013 at 06:41:44PM +0200, Sebastian Hesselbarth wrote:
This patch adds orion-eth and mvmdio device tree nodes for DT enabled
Dove boards. As there is only one ethernet controller on Dove, a default
phy node is also added with a note to set its reg property on a per-board
basis.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v3-v4:
- convert to new device tree binding
Cc: David Miller da...@davemloft.net
Cc: Lennert Buytenhek buyt...@wantstofly.org
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: net...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
---
arch/arm/boot/dts/dove-cubox.dts |7 +++
arch/arm/boot/dts/dove.dtsi | 35 +++
2 files changed, 42 insertions(+)
diff --git a/arch/arm/boot/dts/dove-cubox.dts
b/arch/arm/boot/dts/dove-cubox.dts
index 7e3065a..02618fa 100644
--- a/arch/arm/boot/dts/dove-cubox.dts
+++ b/arch/arm/boot/dts/dove-cubox.dts
@@ -49,6 +49,13 @@
uart0 { status = okay; };
sata0 { status = okay; };
i2c0 { status = okay; };
+mdio { status = okay; };
+eth { status = okay; };
+
+ethphy {
+ compatible = marvell,88e1310;
+ reg = 1;
+};
sdio0 {
status = okay;
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 6cab468..8612658 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -258,5 +258,40 @@
dmacap,xor;
};
};
+
+ mdio: mdio-bus@72004 {
+ compatible = marvell,orion-mdio;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x72004 0x84;
+ interrupts = 30;
+ clocks = gate_clk 2;
+ status = disabled;
+
+ ethphy: ethernet-phy {
+ device-type = ethernet-phy;
+ /* set phy address in board file */
+ };
+ };
+
+ eth: ethernet-controller@72000 {
+ compatible = marvell,orion-eth;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x72000 0x4000;
+ clocks = gate_clk 2;
+ marvell,tx-checksum-limit = 1600;
+ status = disabled;
+
+ ethernet-port@0 {
+ device_type = network;
+ compatible = marvell,orion-eth-port;
+ reg = 0;
+ interrupts = 29;
+ /* overwrite MAC address in bootloader */
+ local-mac-address = [00 00 00 00 00 00];
Hi Sebastian
Its probably a good idea to set the local administration bit in this
MAC address. i.e. first byte is 02.
Andrew
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] Enable multiple MSI feature in pSeries
On Tue, 2013-05-21 at 16:45 +0200, Alexander Gordeev wrote: On Tue, Jan 15, 2013 at 03:38:53PM +0800, Mike Qiu wrote: The test results is shown by 'cat /proc/interrups': CPU0 CPU1 CPU2 CPU3 16: 240458 261601 226310 200425 XICS Level IPI 17: 0 0 0 0 XICS Level RAS_EPOW 18: 10 0 3 2 XICS Level hvc_console 19: 122182 28481 28527 28864 XICS Level ibmvscsi 20:5067388226108118 XICS Level eth0 21: 6 5 5 5 XICS Level host1-0 22:817814816813 XICS Level host1-1 Hi Mike, I am curious if pSeries firmware allows changing affinity masks independently for multiple MSIs? I.e. in your example, would it be possible to assign IRQ21 and IRQ22 to different CPUs? Yes. Each interrupt has its own affinity, whether it's an MSI or not, the affinity is not driven by the address. Cheers, Ben. Thanks! LOC: 398077 316725 231882 203049 Local timer interrupts SPU: 1659919961903 Spurious interrupts CNT: 0 0 0 0 Performance monitoring interrupts MCE: 0 0 0 0 Machine check exceptions ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Context switch more PMU related SPRs
In commit 9353374 Context switch the new EBB SPRs we added support for
context switching some new EBB SPRs. However despite four of us signing
off on that patch we missed some. To be fair these are not actually new
SPRs, but they are now potentially user accessible so need to be context
switched.
Signed-off-by: Michael Ellerman mich...@ellerman.id.au
---
arch/powerpc/include/asm/processor.h |6 ++
arch/powerpc/kernel/asm-offsets.c|6 ++
arch/powerpc/kernel/entry_64.S | 28
3 files changed, 40 insertions(+)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index d7e67ca..594db6b 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -284,6 +284,12 @@ struct thread_struct {
unsigned long ebbrr;
unsigned long ebbhr;
unsigned long bescr;
+ unsigned long siar;
+ unsigned long sdar;
+ unsigned long sier;
+ unsigned long mmcr0;
+ unsigned long mmcr2;
+ unsigned long mmcra;
#endif
};
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index b51a97c..6f16ffa 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -127,6 +127,12 @@ int main(void)
DEFINE(THREAD_BESCR, offsetof(struct thread_struct, bescr));
DEFINE(THREAD_EBBHR, offsetof(struct thread_struct, ebbhr));
DEFINE(THREAD_EBBRR, offsetof(struct thread_struct, ebbrr));
+ DEFINE(THREAD_SIAR, offsetof(struct thread_struct, siar));
+ DEFINE(THREAD_SDAR, offsetof(struct thread_struct, sdar));
+ DEFINE(THREAD_SIER, offsetof(struct thread_struct, sier));
+ DEFINE(THREAD_MMCR0, offsetof(struct thread_struct, mmcr0));
+ DEFINE(THREAD_MMCR2, offsetof(struct thread_struct, mmcr2));
+ DEFINE(THREAD_MMCRA, offsetof(struct thread_struct, mmcra));
#endif
#ifdef CONFIG_PPC_TRANSACTIONAL_MEM
DEFINE(PACATMSCRATCH, offsetof(struct paca_struct, tm_scratch));
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 51cfb8f..0e9095e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -465,6 +465,20 @@ BEGIN_FTR_SECTION
std r0, THREAD_EBBHR(r3)
mfspr r0, SPRN_EBBRR
std r0, THREAD_EBBRR(r3)
+
+ /* PMU registers made user read/(write) by EBB */
+ mfspr r0, SPRN_SIAR
+ std r0, THREAD_SIAR(r3)
+ mfspr r0, SPRN_SDAR
+ std r0, THREAD_SDAR(r3)
+ mfspr r0, SPRN_SIER
+ std r0, THREAD_SIER(r3)
+ mfspr r0, SPRN_MMCR0
+ std r0, THREAD_MMCR0(r3)
+ mfspr r0, SPRN_MMCR2
+ std r0, THREAD_MMCR2(r3)
+ mfspr r0, SPRN_MMCRA
+ std r0, THREAD_MMCRA(r3)
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
#endif
@@ -560,6 +574,20 @@ BEGIN_FTR_SECTION
ld r0, THREAD_EBBRR(r4)
mtspr SPRN_EBBRR, r0
+ /* PMU registers made user read/(write) by EBB */
+ ld r0, THREAD_SIAR(r4)
+ mtspr SPRN_SIAR, r0
+ ld r0, THREAD_SDAR(r4)
+ mtspr SPRN_SDAR, r0
+ ld r0, THREAD_SIER(r4)
+ mtspr SPRN_SIER, r0
+ ld r0, THREAD_MMCR0(r4)
+ mtspr SPRN_MMCR0, r0
+ ld r0, THREAD_MMCR2(r4)
+ mtspr SPRN_MMCR2, r0
+ ld r0, THREAD_MMCRA(r4)
+ mtspr SPRN_MMCRA, r0
+
ld r0,THREAD_TAR(r4)
mtspr SPRN_TAR,r0
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
--
1.7.10.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PROBLEM: Only 2 of 4 cores used on IBM Cell blades and no threads shown in spufs
On Fri, May 17, 2013 at 05:46:52PM +0200, Dennis Schridde wrote: Hello! Am Dienstag, 23. April 2013, 19:12:47 schrieb Michael Ellerman: For me it is fixed by applying the following patch, it should be in v3.10: http://patchwork.ozlabs.org/patch/230103/ Can you please also backport this to 3.8? It is still missing in 3.8.12. It's in 3.8.13. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2 v3] powerpc: Make ptrace work reliably
From: Bharat Bhushan bharat.bhus...@freescale.com v2-v3 - Load PACACURRENT immediately after _MSR(r1), and load DBCR0 just after beq resume_kernel - Added lat_sysycal results before and after the patch v1-v2 - Subject line was missing 0/2, 1/2, 2/2 Bharat Bhushan (2): powerpc: debug control and status registers are 32bit = This patch makes debug control and status registers as 32bit as they are. This does not fix anything powerpc: restore dbcr0 on user space exit = This patch fixes the ptrace reliability issue. The description is the patch describes one of the case where it does not work reliably arch/powerpc/include/asm/processor.h |8 arch/powerpc/kernel/asm-offsets.c|1 + arch/powerpc/kernel/entry_64.S | 28 3 files changed, 29 insertions(+), 8 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2 v3] powerpc: debug control and status registers are 32bit
Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v2-v3
- No change
v1-v2
- Subject line was not having 1/2
arch/powerpc/include/asm/processor.h |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index d7e67ca..5213577 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -168,10 +168,10 @@ struct thread_struct {
* The following help to manage the use of Debug Control Registers
* om the BookE platforms.
*/
- unsigned long dbcr0;
- unsigned long dbcr1;
+ uint32_tdbcr0;
+ uint32_tdbcr1;
#ifdef CONFIG_BOOKE
- unsigned long dbcr2;
+ uint32_tdbcr2;
#endif
/*
* The stored value of the DBSR register will be the value at the
@@ -179,7 +179,7 @@ struct thread_struct {
* user (will never be written to) and has value while helping to
* describe the reason for the last debug trap. Torez
*/
- unsigned long dbsr;
+ uint32_tdbsr;
/*
* The following will contain addresses used by debug applications
* to help trace and trap on particular address locations.
--
1.7.0.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2 v3] powerpc: restore dbcr0 on user space exit
On BookE (Branch taken + Single Step) is as same as Branch Taken on BookS and in Linux we simulate BookS behavior for BookE as well. When doing so, in Branch taken handling we want to set DBCR0_IC but we update the current-thread-dbcr0 and not DBCR0. Now on 64bit the current-thread.dbcr0 (and other debug registers) is synchronized ONLY on context switch flow. But after handling Branch taken in debug exception if we return back to user space without context switch then single stepping change (DBCR0_ICMP) does not get written in h/w DBCR0 and Instruction Complete exception does not happen. This fixes using ptrace reliably on BookE-PowerPC lmbench latency test (lat_syscall) Results are (they varies a little on each run) 1) ./lat_syscall action /dev/shm/uImage action: Openreadwrite statfstat null Before: 3.8618 0.2017 0.2851 1.6789 0.2256 0.0856 After: 3.8580 0.2017 0.2851 1.6955 0.2255 0.0856 1) ./lat_syscall -P 2 -N 10 action /dev/shm/uImage action: Openreadwrite statfstat null Before: 4.1388 0.2238 0.3066 1.7106 0.2256 0.0856 After: 4.1413 0.2236 0.3062 1.7107 0.2256 0.0856 Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com --- v2-v3 - Load PACACURRENT immediately after _MSR(r1), and load DBCR0 just after beq resume_kernel - Added lat_sysycal results before and after the patch v1-v2 - Subject line was not having 1/2 arch/powerpc/kernel/asm-offsets.c |1 + arch/powerpc/kernel/entry_64.S| 28 2 files changed, 25 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index b51a97c..1e2f450 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -103,6 +103,7 @@ int main(void) #endif /* CONFIG_VSX */ #ifdef CONFIG_PPC64 DEFINE(KSP_VSID, offsetof(struct thread_struct, ksp_vsid)); + DEFINE(THREAD_DBCR0, offsetof(struct thread_struct, dbcr0)); #else /* CONFIG_PPC64 */ DEFINE(PGDIR, offsetof(struct thread_struct, pgdir)); #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE) diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S index 794889b..5b91d27 100644 --- a/arch/powerpc/kernel/entry_64.S +++ b/arch/powerpc/kernel/entry_64.S @@ -622,21 +622,41 @@ _GLOBAL(ret_from_except_lite) CURRENT_THREAD_INFO(r9, r1) ld r3,_MSR(r1) +#ifdef CONFIG_PPC_BOOK3E + ld r10,PACACURRENT(r13) +#endif /* CONFIG_PPC_BOOK3E */ ld r4,TI_FLAGS(r9) andi. r3,r3,MSR_PR beq resume_kernel +#ifdef CONFIG_PPC_BOOK3E + lwz r3,(THREAD+THREAD_DBCR0)(r10) +#endif /* CONFIG_PPC_BOOK3E */ /* Check current_thread_info()-flags */ andi. r0,r4,_TIF_USER_WORK_MASK + bne 1f +#ifdef CONFIG_PPC_BOOK3E + /* +* Check to see if the dbcr0 register is set up to debug. +* Use the internal debug mode bit to do this. +*/ + andis. r0,r3,DBCR0_IDM@h beq restore - - andi. r0,r4,_TIF_NEED_RESCHED - beq 1f + mfmsr r0 + rlwinm r0,r0,0,~MSR_DE /* Clear MSR.DE */ + mtmsr r0 + mtspr SPRN_DBCR0,r3 + li r10, -1 + mtspr SPRN_DBSR,r10 + b restore +#endif +1: andi. r0,r4,_TIF_NEED_RESCHED + beq 2f bl .restore_interrupts SCHEDULE_USER b .ret_from_except_lite -1: bl .save_nvgprs +2: bl .save_nvgprs bl .restore_interrupts addir3,r1,STACK_FRAME_OVERHEAD bl .do_notify_resume -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SATA hang on 8315E triggered by heavy flash write?
Scott --
Scott Wood scottw...@freescale.com writes:
On 05/15/2013 03:12:21 AM, Anthony Foiani wrote:
At this point, /dev/sda is pretty much unusable, and I have to do
at least a reboot to recover. (I don't recall if I had to do a
power cycle at this point, though.)
For whatever it's worth, a hard boot (full power cycle) is indeed
necessary at this point.
I suspect that it is related to errata eLBC-A001 (from MPC8315E
Chip Errata, Rev. 3, 09/2011):
...
But it seems that erratum is already fixed:
http://patchwork.ozlabs.org/patch/96339/
(git patch d08e44570e)
Am I reading that correctly?
Yes, that erratum has been worked around.
Ok, thanks for the confirmation.
(I'm already writing only one flash sector at a time, but it might
be that even a single 0x1-byte sector takes long enough to
trigger the issue.)
I don't think this erratum is relevant. Unlike NAND, NOR flash does
not involve holding the localbus for extended periods of time.
I wasn't sure about the mechanism of the erratum, and it seemed
awfully close, so I thought I'd go fishing. Guess I missed. :(
It is NOR writes, btw; I do both in my application, but the initial
error always seems to occur during a NOR write. (In this device,
kernel + devtree go into NOR flash, ramdisk goes into NAND flash, and
data goes to SSD... stop laughing.)
Here's the most recent hang. First, to compare the application log
timestamps with the kernel log timestamps:
# mix of kernel and application log, note that kernel is about +12s.
+0.537506 main.0 [0]: rc: fork took 9.376ms
[ 12.892323] PHY: mdio@e0024520:01 - Link is Up - 100/Full
+1.603034 main.0 [0]: schs: ctor: done
The console output is:
# console log
[318334.294126] ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xe
frozen
[318334.301515] ata2.00: PHY RDY changed
[318334.305301] ata2.00: failed command: WRITE DMA
[318334.309991] ata2.00: cmd ca/00:08:b0:00:18/00:00:00:00:00/e1 tag 0 dma
4096 out
[318334.310015] res 50/00:00:08:61:25/00:00:00:00:00/e1 Emask 0x10
(ATA bus error)
[318334.325689] ata2.00: status: { DRDY }
[318334.329717] ata2: hard resetting link
[318334.836038] ata2: Hardreset failed, not off-lined 0
[318334.848407] ata2: setting speed (in hard reset)
[318344.456050] ata2: No Signature Update
[318344.631916] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[318344.638354] ata2.00: link online but device misclassified
[318349.643897] ata2.00: qc timeout (cmd 0xec)
[318349.648268] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[318349.654562] ata2.00: revalidation failed (errno=-5)
[318349.659667] ata2: hard resetting link
[318350.163864] ata2: Hardreset failed, not off-lined 0
[318350.175869] ata2: setting speed (in hard reset)
[318359.771956] ata2: No Signature Update
[318359.947901] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[318359.954342] ata2.00: link online but device misclassified
[318369.959921] ata2.00: qc timeout (cmd 0xec)
[318369.964279] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[318369.970567] ata2.00: revalidation failed (errno=-5)
[318369.975658] ata2: hard resetting link
[318370.479933] ata2: Hardreset failed, not off-lined 0
[318370.491880] ata2: setting speed (in hard reset)
[318380.083892] ata2: No Signature Update
And my application log:
# application log
+318320.957019 sw-upd.0 [29]: fm: nor0: write: writing 0x1 @0x18 from
buf[0x8]; attempt 1/3
+318322.498346 sw-upd.0 [29]: fm: nor0: write: writing 0x1 @0x19 from
buf[0x9]; attempt 1/3
+318323.849995 sw-upd.0 [29]: fm: nor0: write: writing 0x1 @0x1a from
buf[0xa]; attempt 1/3
+318325.262559 sw-upd.0 [29]: fm: nor0: write: writing 0x1 @0x1b from
buf[0xb]; attempt 1/3
+318326.703213 sw-upd.0 [29]: fm: nor0: write: writing 0x1 @0x1c from
buf[0xc]; attempt 1/3
I also don't see how it would interact with SATA, which is separate
from the localbus.
No idea. Is there some other shared resource that might be taxed by
this type of load?
I do get a few other errors, usually just once or twice per boot:
[ 4231.619368] NOHZ: local_softirq_pending 100
[ 4232.249935] NOHZ: local_softirq_pending 100
[ 4232.312241] NOHZ: local_softirq_pending 100
[ 4232.424523] NOHZ: local_softirq_pending 100
[ 4233.139146] NOHZ: local_softirq_pending 100
[ 4233.328540] NOHZ: local_softirq_pending 100
[ 4233.655909] NOHZ: local_softirq_pending 100
[ 4234.106578] NOHZ: local_softirq_pending 100
[ 4234.853966] NOHZ: local_softirq_pending 100
[ 4235.375208] NOHZ: local_softirq_pending 100
[11072.027818] hrtimer: interrupt took 126210 ns
They seem harmless, though, and (as the timestamps indicate) the
machine happily ran for 3-4 days after those issues.
Are you seeing any errors on the localbus, or just on SATA?
I'm not seeing any errors in the console log -- but I'm not using the
LBC
Re: [PATCH 1/1] powerpc: Force 32 bit MSIs on systems lacking firmware support
On Tue, May 21, 2013 at 04:54:04PM -0500, Brian King wrote:
Recent commit e61133dda480062d221f09e4fc18f66763f8ecd0 added support
for a new firmware feature to force an adapter to use 32 bit MSIs.
However, this firmware is not available for all systems. The hack below
allows devices needing 32 bit MSIs to work on these systems as well.
It is careful to only enable this on Gen2 slots, which should limit
this to configurations where this hack is needed and tested to work.
Sorry I know you've already sent this to me once, but I didn't get time
to reply.
diff -puN arch/powerpc/platforms/pseries/msi.c~powerpc_32bit_msi_hack_on_papr
arch/powerpc/platforms/pseries/msi.c
--- linux/arch/powerpc/platforms/pseries/msi.c~powerpc_32bit_msi_hack_on_papr
2013-05-15 10:44:46.0 -0500
+++ linux-bjking1/arch/powerpc/platforms/pseries/msi.c2013-05-20
15:24:52.0 -0500
@@ -397,10 +397,11 @@ static int check_msix_entries(struct pci
static int rtas_setup_msi_irqs(struct pci_dev *pdev, int nvec_in, int type)
{
struct pci_dn *pdn;
- int hwirq, virq, i, rc;
+ int hwirq, virq, i, rc = -1;
I'd rather you didn't do a catch-all initialisation like this, it's too
easy to miss a return path.
struct msi_desc *entry;
struct msi_msg msg;
int nvec = nvec_in;
+ int use_32bit_msi_hack = 0;
pdn = get_pdn(pdev);
if (!pdn)
@@ -428,15 +429,37 @@ static int rtas_setup_msi_irqs(struct pc
*/
again:
if (type == PCI_CAP_ID_MSI) {
- if (pdn-force_32bit_msi)
+ if (pdn-force_32bit_msi) {
rc = rtas_change_msi(pdn, RTAS_CHANGE_32MSI_FN, nvec);
- else
+ if (rc 0) {
+ /* We only want to run the 32 bit MSI hack
below if
+ the max bus speed is Gen2 speed. */
+ if (pdev-bus-max_bus_speed !=
PCIE_SPEED_5_0GT)
+ return rc;
+
+ use_32bit_msi_hack = 1;
+ }
+ }
+
+ if (rc 0)
rc = rtas_change_msi(pdn, RTAS_CHANGE_MSI_FN, nvec);
- if (rc 0 !pdn-force_32bit_msi) {
+ if (rc 0) {
pr_debug(rtas_msi: trying the old firmware call.\n);
rc = rtas_change_msi(pdn, RTAS_CHANGE_FN, nvec);
}
+
+ if (use_32bit_msi_hack rc 0) {
+ int pos;
+ u32 addr_hi, addr_lo;
+
+ dev_info(pdev-dev, rtas_msi: No 32 bit MSI firmware
support, forcing 32 bit MSI\n);
+ pos = pci_find_capability(pdev, PCI_CAP_ID_MSI);
+ pci_read_config_dword(pdev, pos + PCI_MSI_ADDRESS_HI,
addr_hi);
+ addr_lo = 0x | ((addr_hi (48 - 32)) 4);
+ pci_write_config_dword(pdev, pos + PCI_MSI_ADDRESS_LO,
addr_lo);
+ pci_write_config_dword(pdev, pos + PCI_MSI_ADDRESS_HI,
0);
This is basically baking knowledge of phyp's address layout into the
kernel right? Which is OK, but it needs a big fat comment describing
exactly what it's doing and why it's safe.
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/cell: Only iterate over online nodes in cbe_init_pm_irq()
On Fri, May 17, 2013 at 05:45:05PM +0200, Dennis Schridde wrote: Hello! Just wanted to remind you: The patchto fix cbe_init_pm_irq() that Michael and Grant sent me is still not included in Linux 3.8.12. I didn't push that one to stable because it just fixes a warning. If you want it you'll have to grab it yourself. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] powerpc: Force 32 bit MSIs on systems lacking firmware support
On Wed, 2013-05-22 at 14:36 +1000, Michael Ellerman wrote: This is basically baking knowledge of phyp's address layout into the kernel right? Which is OK, but it needs a big fat comment describing exactly what it's doing and why it's safe. Not pHyp really but the HW, basically this should work with any IODA1 host bridge (P7IOC, Torrent, ...). The assumption here is that RTAS MSI + PCIe Gen2 == IODA1 :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/2] Improvement and fixes for BHRB
(1) The first patch fixes a situation like this Before patch:- ./perf record -j any -e branch-misses:k ls Error: The sys_perf_event_open() syscall returned with 95 (Operation not supported) for event (branch-misses:k). /bin/dmesg may provide additional information. No CONFIG_PERF_EVENTS=y kernel support configured? Here 'perf record' actually copies over ':k' filter request into BHRB privilege state filter config and our previous check in kernel would fail that. After patch:- - /perf record -j any -e branch-misses:k ls perf perf.data perf.data.old test-mmap-ring [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.002 MB perf.data (~102 samples) ] (2) The second patch fixes context migration for BHRB filter configuration Anshuman Khandual (2): powerpc, perf: Ignore separate BHRB privilege state filter request powerpc, perf: BHRB filter configuration should follow the task arch/powerpc/perf/core-book3s.c | 5 - arch/powerpc/perf/power8-pmu.c | 17 + 2 files changed, 13 insertions(+), 9 deletions(-) -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc, perf: BHRB filter configuration should follow the task
When the task moves around the system, the corresponding cpuhw
per cpu strcuture should be popullated with the BHRB filter
request value so that PMU could be configured appropriately with
that during the next call into power_pmu_enable().
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/core-book3s.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 426180b..48c68a8 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -1122,8 +1122,11 @@ nocheck:
ret = 0;
out:
- if (has_branch_stack(event))
+ if (has_branch_stack(event)) {
power_pmu_bhrb_enable(event);
+ cpuhw-bhrb_filter = ppmu-bhrb_filter_map(
+ event-attr.branch_sample_type);
+ }
perf_pmu_enable(event-pmu);
local_irq_restore(flags);
--
1.7.11.7
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] powerpc, perf: Ignore separate BHRB privilege state filter request
Completely ignore BHRB privilege state filter request as we are already configuring MMCRA register with privilege state filtering attribute for the accompanying PMU event. This would help achieve cleaner user space interaction for BHRB. Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com --- arch/powerpc/perf/power8-pmu.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c index f7d1c4f..8ed323d 100644 --- a/arch/powerpc/perf/power8-pmu.c +++ b/arch/powerpc/perf/power8-pmu.c @@ -525,16 +525,17 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type) u64 pmu_bhrb_filter = 0; u64 br_privilege = branch_sample_type ONLY_PLM; - /* BHRB and regular PMU events share the same prvillege state + /* BHRB and regular PMU events share the same prvilege state * filter configuration. BHRB is always recorded along with a -* regular PMU event. So privilege state filter criteria for BHRB -* and the companion PMU events has to be the same. As a default -* perf record tool sets all privillege bits ON when no filter -* criteria is provided in the command line. So as along as all -* privillege bits are ON or they are OFF, we are good to go. +* regular PMU event. So privilege state filter criteria for +* the BHRB and the companion PMU events has to be the same. +* Separate BHRB privillege state filter requests would be +* ignored. */ - if ((br_privilege != 7) (br_privilege != 0)) - return -1; + + if (br_privilege) + pr_info(BHRB privilege state filter request %llx ignored\n, + br_privilege); /* No branch filter requested */ if (branch_sample_type PERF_SAMPLE_BRANCH_ANY) -- 1.7.11.7 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 0/3] Enable multiple MSI feature in pSeries
于 2013/5/21 22:45, Alexander Gordeev 写道: On Tue, Jan 15, 2013 at 03:38:53PM +0800, Mike Qiu wrote: The test results is shown by 'cat /proc/interrups': CPU0 CPU1 CPU2 CPU3 16: 240458 261601 226310 200425 XICS Level IPI 17: 0 0 0 0 XICS Level RAS_EPOW 18: 10 0 3 2 XICS Level hvc_console 19: 122182 28481 28527 28864 XICS Level ibmvscsi 20:5067388226108118 XICS Level eth0 21: 6 5 5 5 XICS Level host1-0 22:817814816813 XICS Level host1-1 Hi Mike, I am curious if pSeries firmware allows changing affinity masks independently for multiple MSIs? I.e. in your example, would it be possible to assign IRQ21 and IRQ22 to different CPUs? Yes, as Ben says, this is very different from other firmware :) Thanks Mike Thanks! LOC: 398077 316725 231882 203049 Local timer interrupts SPU: 1659919961903 Spurious interrupts CNT: 0 0 0 0 Performance monitoring interrupts MCE: 0 0 0 0 Machine check exceptions ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
