* Re: [PATCH] ASoC: fsl_ssi: Fix printing return code on clk error
From: Mark Brown @ 2014-01-06 13:20 UTC (permalink / raw)
To: Alexander Shiyan
Cc: alsa-devel, Liam Girdwood, Takashi Iwai, Timur Tabi,
Jaroslav Kysela, linuxppc-dev
In-Reply-To: <1388902876-29964-1-git-send-email-shc_work@mail.ru>
[-- Attachment #1: Type: text/plain, Size: 137 bytes --]
On Sun, Jan 05, 2014 at 10:21:16AM +0400, Alexander Shiyan wrote:
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Applied, thanks.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC] linux/pci: move pci_platform_pm_ops to linux/pci.h
From: Rafael J. Wysocki @ 2014-01-06 12:13 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Linux PM list, roy.zang, Dongsheng Wang,
linux-pci@vger.kernel.org, Scott Wood, linuxppc-dev
In-Reply-To: <CAErSpo7+8sLZVi24fi+xxTEW2_DTJ2_zUrW+vobMGsvCEFwY_Q@mail.gmail.com>
On Friday, December 20, 2013 09:42:59 AM Bjorn Helgaas wrote:
> On Fri, Dec 20, 2013 at 3:03 AM, Dongsheng Wang
> <dongsheng.wang@freescale.com> wrote:
> > From: Wang Dongsheng <dongsheng.wang@freescale.com>
> >
> > make Freescale platform use pci_platform_pm_ops struct.
>
> This changelog doesn't say anything about what the patch does.
>
> I infer that you want to use pci_platform_pm_ops from some Freescale
> code. This patch should be posted along with the patches that add
> that Freescale code, so we can see how you intend to use it.
>
> The existing use is in drivers/pci/pci-acpi.c, so it's possible that
> your new use should be added in the same way, in drivers/pci, so we
> don't have to make pci_platform_pm_ops part of the public PCI
> interface in include/linux/pci.h.
>
> That said, if Raphael thinks this makes sense, it's OK with me.
Well, I'd like to know why exactly the change is needed in the first place.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH v2 0/9] cpuidle: rework device state count handling
From: Rafael J. Wysocki @ 2014-01-06 12:12 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-samsung-soc, linux-pm, daniel.lezcano, linux-kernel,
kyungmin.park, linuxppc-dev, lenb
In-Reply-To: <1387565251-7051-1-git-send-email-b.zolnierkie@samsung.com>
On Friday, December 20, 2013 07:47:22 PM Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> Some cpuidle drivers assume that cpuidle core will handle cases where
> device->state_count is smaller than driver->state_count, unfortunately
> currently this is untrue (device->state_count is used only for handling
> cpuidle state sysfs entries and driver->state_count is used for all
> other cases) and will not be fixed in the future as device->state_count
> is planned to be removed [1].
>
> This patchset fixes such drivers (ARM EXYNOS cpuidle driver and ACPI
> cpuidle driver), removes superflous device->state_count initialization
> from drivers for which device->state_count equals driver->state_count
> (POWERPC pseries cpuidle driver and intel_idle driver) and finally
> removes state_count field from struct cpuidle_device.
>
> Additionaly (while at it) this patchset fixes C1E promotion disable
> quirk handling (in intel_idle driver) and converts cpuidle drivers code
> to use the common cpuidle_[un]register() routines (in POWERPC pseries
> cpuidle driver and intel_idle driver).
>
> [1] http://permalink.gmane.org/gmane.linux.power-management.general/36908
>
> Reference to v1:
> http://comments.gmane.org/gmane.linux.power-management.general/37390
>
> Changes since v1:
> - synced patch series with next-20131220
> - added ACKs from Daniel Lezcano
I've queued up the series for 3.14, thanks!
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
>
> Bartlomiej Zolnierkiewicz (9):
> ARM: EXYNOS: cpuidle: fix AFTR mode check
> POWERPC: pseries: cpuidle: remove superfluous dev->state_count
> initialization
> POWERPC: pseries: cpuidle: use the common cpuidle_[un]register()
> routines
> ACPI / cpuidle: fix max idle state handling with hotplug CPU support
> ACPI / cpuidle: remove dev->state_count setting
> intel_idle: do C1E promotion disable quirk for hotplugged CPUs
> intel_idle: remove superfluous dev->state_count initialization
> intel_idle: use the common cpuidle_[un]register() routines
> cpuidle: remove state_count field from struct cpuidle_device
>
> arch/arm/mach-exynos/cpuidle.c | 8 +-
> arch/powerpc/platforms/pseries/processor_idle.c | 59 +---------
> drivers/acpi/processor_idle.c | 29 +++--
> drivers/cpuidle/cpuidle.c | 3 -
> drivers/cpuidle/sysfs.c | 5 +-
> drivers/idle/intel_idle.c | 140 +++++-------------------
> include/linux/cpuidle.h | 1 -
> 7 files changed, 51 insertions(+), 194 deletions(-)
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* linux-next: build failure after merge of the final tree
From: Stephen Rothwell @ 2014-01-06 9:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Cc: Mahesh Salgaonkar, linux-next, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:1312: Error: attempt to move .org backwards
The last time I got this error, I needed to apply patch "powerpc: Fix
"attempt to move .org backwards" error", but that has been included in
the powerpc tree now, so I guess something else has added code in a
critical place. :-(
I have just left this broken for today.
--
Cheers,
Stephen Rothwell <sfr@canb.auug.org.au>
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Build regressions/improvements in v3.13-rc7
From: Geert Uytterhoeven @ 2014-01-06 9:05 UTC (permalink / raw)
To: linux-kernel@vger.kernel.org
Cc: the arch/x86 maintainers, linuxppc-dev@lists.ozlabs.org,
Linux-sh list
In-Reply-To: <1388998868-31448-1-git-send-email-geert@linux-m68k.org>
On Mon, Jan 6, 2014 at 10:01 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> JFYI, when comparing v3.13-rc7[1] to v3.13-rc6[3], the summaries are:
> - build errors: +14/-4
+ /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error:
'cached_to_uncached' undeclared (first use in this function): =>
99:17
+ /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error: implicit
declaration of function 'cpu_context'
[-Werror=implicit-function-declaration]: => 192:2
+ /scratch/kisskb/src/drivers/mtd/maps/vmu-flash.c: error: (near
initialization for 'vmu_flash_driver.drv'): => 805:3, 803:3, 804:3
+ /scratch/kisskb/src/drivers/mtd/maps/vmu-flash.c: error: expected
declaration specifiers or '...' before string constant: => 824:20,
822:16, 823:15
+ /scratch/kisskb/src/drivers/mtd/maps/vmu-flash.c: error: field
name not in record or union initializer: => 805:3, 803:3, 804:3
+ /scratch/kisskb/src/include/linux/maple.h: error: field 'dev' has
incomplete type: => 80:16
+ /scratch/kisskb/src/include/linux/maple.h: error: field 'drv' has
incomplete type: => 85:23
sh-randconfig
+ /scratch/kisskb/src/drivers/tty/serial/nwpserial.c: error:
implicit declaration of function 'udelay'
[-Werror=implicit-function-declaration]: => 53:3
+ error: No rule to make target drivers/scsi/aic7xxx/aicasm/*.[chyl]: => N/A
powerpc-randconfig
+ error: No rule to make target /etc/sound/msndinit.bin: => N/A
+ error: No rule to make target /etc/sound/msndperm.bin: => N/A
+ error: No rule to make target /etc/sound/pndsperm.bin: => N/A
+ error: No rule to make target /etc/sound/pndspini.bin: => N/A
i386-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/7037/ (119 out of 120 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7026/ (119 out of 120 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH -V3 1/2] powerpc: mm: Move ppc64 page table range definitions to separate header
From: Aneesh Kumar K.V @ 2014-01-06 9:03 UTC (permalink / raw)
To: benh, paulus, aarcange, kirill.shutemov
Cc: linux-mm, linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
This avoid mmu-hash64.h including pagetable-ppc64.h. That inclusion
cause issues like
CC arch/powerpc/kernel/asm-offsets.s
In file included from /home/aneesh/linus/arch/powerpc/include/asm/mmu-hash64.h:23:0,
from /home/aneesh/linus/arch/powerpc/include/asm/mmu.h:196,
from /home/aneesh/linus/arch/powerpc/include/asm/lppaca.h:36,
from /home/aneesh/linus/arch/powerpc/include/asm/paca.h:21,
from /home/aneesh/linus/arch/powerpc/include/asm/hw_irq.h:41,
from /home/aneesh/linus/arch/powerpc/include/asm/irqflags.h:11,
from include/linux/irqflags.h:15,
from include/linux/spinlock.h:53,
from include/linux/seqlock.h:35,
from include/linux/time.h:5,
from include/uapi/linux/timex.h:56,
from include/linux/timex.h:56,
from include/linux/sched.h:17,
from arch/powerpc/kernel/asm-offsets.c:17:
/home/aneesh/linus/arch/powerpc/include/asm/pgtable-ppc64.h:563:42: error: unknown type name ‘spinlock_t’
static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
NOTE: We can either do this or stuck a typdef struct spinlock spinlock_t; in pgtable-ppc64.h
arch/powerpc/include/asm/mmu-hash64.h | 2 +-
arch/powerpc/include/asm/pgtable-ppc64-range.h | 101 +++++++++++++++++++++++++
arch/powerpc/include/asm/pgtable-ppc64.h | 101 +------------------------
3 files changed, 103 insertions(+), 101 deletions(-)
create mode 100644 arch/powerpc/include/asm/pgtable-ppc64-range.h
diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
index 807014dde821..895b4df31fec 100644
--- a/arch/powerpc/include/asm/mmu-hash64.h
+++ b/arch/powerpc/include/asm/mmu-hash64.h
@@ -20,7 +20,7 @@
* need for various slices related matters. Note that this isn't the
* complete pgtable.h but only a portion of it.
*/
-#include <asm/pgtable-ppc64.h>
+#include <asm/pgtable-ppc64-range.h>
#include <asm/bug.h>
/*
diff --git a/arch/powerpc/include/asm/pgtable-ppc64-range.h b/arch/powerpc/include/asm/pgtable-ppc64-range.h
new file mode 100644
index 000000000000..b48b089fb209
--- /dev/null
+++ b/arch/powerpc/include/asm/pgtable-ppc64-range.h
@@ -0,0 +1,101 @@
+#ifndef _ASM_POWERPC_PGTABLE_PPC64_RANGE_H_
+#define _ASM_POWERPC_PGTABLE_PPC64_RANGE_H_
+/*
+ * This file contains the functions and defines necessary to modify and use
+ * the ppc64 hashed page table.
+ */
+
+#ifdef CONFIG_PPC_64K_PAGES
+#include <asm/pgtable-ppc64-64k.h>
+#else
+#include <asm/pgtable-ppc64-4k.h>
+#endif
+#include <asm/barrier.h>
+
+#define FIRST_USER_ADDRESS 0
+
+/*
+ * Size of EA range mapped by our pagetables.
+ */
+#define PGTABLE_EADDR_SIZE (PTE_INDEX_SIZE + PMD_INDEX_SIZE + \
+ PUD_INDEX_SIZE + PGD_INDEX_SIZE + PAGE_SHIFT)
+#define PGTABLE_RANGE (ASM_CONST(1) << PGTABLE_EADDR_SIZE)
+
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+#define PMD_CACHE_INDEX (PMD_INDEX_SIZE + 1)
+#else
+#define PMD_CACHE_INDEX PMD_INDEX_SIZE
+#endif
+/*
+ * Define the address range of the kernel non-linear virtual area
+ */
+
+#ifdef CONFIG_PPC_BOOK3E
+#define KERN_VIRT_START ASM_CONST(0x8000000000000000)
+#else
+#define KERN_VIRT_START ASM_CONST(0xD000000000000000)
+#endif
+#define KERN_VIRT_SIZE ASM_CONST(0x0000100000000000)
+
+/*
+ * The vmalloc space starts at the beginning of that region, and
+ * occupies half of it on hash CPUs and a quarter of it on Book3E
+ * (we keep a quarter for the virtual memmap)
+ */
+#define VMALLOC_START KERN_VIRT_START
+#ifdef CONFIG_PPC_BOOK3E
+#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 2)
+#else
+#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
+#endif
+#define VMALLOC_END (VMALLOC_START + VMALLOC_SIZE)
+
+/*
+ * The second half of the kernel virtual space is used for IO mappings,
+ * it's itself carved into the PIO region (ISA and PHB IO space) and
+ * the ioremap space
+ *
+ * ISA_IO_BASE = KERN_IO_START, 64K reserved area
+ * PHB_IO_BASE = ISA_IO_BASE + 64K to ISA_IO_BASE + 2G, PHB IO spaces
+ * IOREMAP_BASE = ISA_IO_BASE + 2G to VMALLOC_START + PGTABLE_RANGE
+ */
+#define KERN_IO_START (KERN_VIRT_START + (KERN_VIRT_SIZE >> 1))
+#define FULL_IO_SIZE 0x80000000ul
+#define ISA_IO_BASE (KERN_IO_START)
+#define ISA_IO_END (KERN_IO_START + 0x10000ul)
+#define PHB_IO_BASE (ISA_IO_END)
+#define PHB_IO_END (KERN_IO_START + FULL_IO_SIZE)
+#define IOREMAP_BASE (PHB_IO_END)
+#define IOREMAP_END (KERN_VIRT_START + KERN_VIRT_SIZE)
+
+
+/*
+ * Region IDs
+ */
+#define REGION_SHIFT 60UL
+#define REGION_MASK (0xfUL << REGION_SHIFT)
+#define REGION_ID(ea) (((unsigned long)(ea)) >> REGION_SHIFT)
+
+#define VMALLOC_REGION_ID (REGION_ID(VMALLOC_START))
+#define KERNEL_REGION_ID (REGION_ID(PAGE_OFFSET))
+#define VMEMMAP_REGION_ID (0xfUL) /* Server only */
+#define USER_REGION_ID (0UL)
+
+/*
+ * Defines the address of the vmemap area, in its own region on
+ * hash table CPUs and after the vmalloc space on Book3E
+ */
+#ifdef CONFIG_PPC_BOOK3E
+#define VMEMMAP_BASE VMALLOC_END
+#define VMEMMAP_END KERN_IO_START
+#else
+#define VMEMMAP_BASE (VMEMMAP_REGION_ID << REGION_SHIFT)
+#endif
+#define vmemmap ((struct page *)VMEMMAP_BASE)
+
+#ifdef CONFIG_PPC_MM_SLICES
+#define HAVE_ARCH_UNMAPPED_AREA
+#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
+#endif /* CONFIG_PPC_MM_SLICES */
+
+#endif
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index 4a191c472867..9935e9b79524 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -1,102 +1,8 @@
#ifndef _ASM_POWERPC_PGTABLE_PPC64_H_
#define _ASM_POWERPC_PGTABLE_PPC64_H_
-/*
- * This file contains the functions and defines necessary to modify and use
- * the ppc64 hashed page table.
- */
-
-#ifdef CONFIG_PPC_64K_PAGES
-#include <asm/pgtable-ppc64-64k.h>
-#else
-#include <asm/pgtable-ppc64-4k.h>
-#endif
-#include <asm/barrier.h>
-
-#define FIRST_USER_ADDRESS 0
-
-/*
- * Size of EA range mapped by our pagetables.
- */
-#define PGTABLE_EADDR_SIZE (PTE_INDEX_SIZE + PMD_INDEX_SIZE + \
- PUD_INDEX_SIZE + PGD_INDEX_SIZE + PAGE_SHIFT)
-#define PGTABLE_RANGE (ASM_CONST(1) << PGTABLE_EADDR_SIZE)
-
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
-#define PMD_CACHE_INDEX (PMD_INDEX_SIZE + 1)
-#else
-#define PMD_CACHE_INDEX PMD_INDEX_SIZE
-#endif
-/*
- * Define the address range of the kernel non-linear virtual area
- */
-
-#ifdef CONFIG_PPC_BOOK3E
-#define KERN_VIRT_START ASM_CONST(0x8000000000000000)
-#else
-#define KERN_VIRT_START ASM_CONST(0xD000000000000000)
-#endif
-#define KERN_VIRT_SIZE ASM_CONST(0x0000100000000000)
-
-/*
- * The vmalloc space starts at the beginning of that region, and
- * occupies half of it on hash CPUs and a quarter of it on Book3E
- * (we keep a quarter for the virtual memmap)
- */
-#define VMALLOC_START KERN_VIRT_START
-#ifdef CONFIG_PPC_BOOK3E
-#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 2)
-#else
-#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
-#endif
-#define VMALLOC_END (VMALLOC_START + VMALLOC_SIZE)
-
-/*
- * The second half of the kernel virtual space is used for IO mappings,
- * it's itself carved into the PIO region (ISA and PHB IO space) and
- * the ioremap space
- *
- * ISA_IO_BASE = KERN_IO_START, 64K reserved area
- * PHB_IO_BASE = ISA_IO_BASE + 64K to ISA_IO_BASE + 2G, PHB IO spaces
- * IOREMAP_BASE = ISA_IO_BASE + 2G to VMALLOC_START + PGTABLE_RANGE
- */
-#define KERN_IO_START (KERN_VIRT_START + (KERN_VIRT_SIZE >> 1))
-#define FULL_IO_SIZE 0x80000000ul
-#define ISA_IO_BASE (KERN_IO_START)
-#define ISA_IO_END (KERN_IO_START + 0x10000ul)
-#define PHB_IO_BASE (ISA_IO_END)
-#define PHB_IO_END (KERN_IO_START + FULL_IO_SIZE)
-#define IOREMAP_BASE (PHB_IO_END)
-#define IOREMAP_END (KERN_VIRT_START + KERN_VIRT_SIZE)
-
-
-/*
- * Region IDs
- */
-#define REGION_SHIFT 60UL
-#define REGION_MASK (0xfUL << REGION_SHIFT)
-#define REGION_ID(ea) (((unsigned long)(ea)) >> REGION_SHIFT)
-
-#define VMALLOC_REGION_ID (REGION_ID(VMALLOC_START))
-#define KERNEL_REGION_ID (REGION_ID(PAGE_OFFSET))
-#define VMEMMAP_REGION_ID (0xfUL) /* Server only */
-#define USER_REGION_ID (0UL)
-
-/*
- * Defines the address of the vmemap area, in its own region on
- * hash table CPUs and after the vmalloc space on Book3E
- */
-#ifdef CONFIG_PPC_BOOK3E
-#define VMEMMAP_BASE VMALLOC_END
-#define VMEMMAP_END KERN_IO_START
-#else
-#define VMEMMAP_BASE (VMEMMAP_REGION_ID << REGION_SHIFT)
-#endif
-#define vmemmap ((struct page *)VMEMMAP_BASE)
+#include <asm/pgtable-ppc64-range.h>
-/*
- * Include the PTE bits definitions
- */
#ifdef CONFIG_PPC_BOOK3S
#include <asm/pte-hash64.h>
#else
@@ -104,11 +10,6 @@
#endif
#include <asm/pte-common.h>
-#ifdef CONFIG_PPC_MM_SLICES
-#define HAVE_ARCH_UNMAPPED_AREA
-#define HAVE_ARCH_UNMAPPED_AREA_TOPDOWN
-#endif /* CONFIG_PPC_MM_SLICES */
-
#ifndef __ASSEMBLY__
/*
--
1.8.3.2
^ permalink raw reply related
* [PATCH -V3 2/2] powerpc: thp: Fix crash on mremap
From: Aneesh Kumar K.V @ 2014-01-06 9:03 UTC (permalink / raw)
To: benh, paulus, aarcange, kirill.shutemov
Cc: linux-mm, linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <1388999012-14424-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
This patch fix the below crash
NIP [c00000000004cee4] .__hash_page_thp+0x2a4/0x440
LR [c0000000000439ac] .hash_page+0x18c/0x5e0
...
Call Trace:
[c000000736103c40] [00001ffffb000000] 0x1ffffb000000(unreliable)
[437908.479693] [c000000736103d50] [c0000000000439ac] .hash_page+0x18c/0x5e0
[437908.479699] [c000000736103e30] [c00000000000924c] .do_hash_page+0x4c/0x58
On ppc64 we use the pgtable for storing the hpte slot information and
store address to the pgtable at a constant offset (PTRS_PER_PMD) from
pmd. On mremap, when we switch the pmd, we need to withdraw and deposit
the pgtable again, so that we find the pgtable at PTRS_PER_PMD offset
from new pmd.
We also want to move the withdraw and deposit before the set_pmd so
that, when page fault find the pmd as trans huge we can be sure that
pgtable can be located at the offset.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/pgtable-ppc64.h | 14 ++++++++++++++
include/asm-generic/pgtable.h | 12 ++++++++++++
mm/huge_memory.c | 14 +++++---------
3 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index 9935e9b79524..ff3afce40f3b 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -12,6 +12,7 @@
#ifndef __ASSEMBLY__
+#include <linux/spinlock.h>
/*
* This is the default implementation of various PTE accessors, it's
* used in all cases except Book3S with 64K pages where we have a
@@ -459,5 +460,18 @@ extern pgtable_t pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t *pmdp);
#define __HAVE_ARCH_PMDP_INVALIDATE
extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
pmd_t *pmdp);
+
+#define pmd_move_must_withdraw pmd_move_must_withdraw
+static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
+ spinlock_t *old_pmd_ptl)
+{
+ /*
+ * Archs like ppc64 use pgtable to store per pmd
+ * specific information. So when we switch the pmd,
+ * we should also withdraw and deposit the pgtable
+ */
+ return true;
+}
+
#endif /* __ASSEMBLY__ */
#endif /* _ASM_POWERPC_PGTABLE_PPC64_H_ */
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index db0923458940..8e4f41d9af4d 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -558,6 +558,18 @@ static inline pmd_t pmd_read_atomic(pmd_t *pmdp)
}
#endif
+#ifndef pmd_move_must_withdraw
+static inline int pmd_move_must_withdraw(spinlock_t *new_pmd_ptl,
+ spinlock_t *old_pmd_ptl)
+{
+ /*
+ * With split pmd lock we also need to move preallocated
+ * PTE page table if new_pmd is on different PMD page table.
+ */
+ return new_pmd_ptl != old_pmd_ptl;
+}
+#endif
+
/*
* This function is meant to be used by sites walking pagetables with
* the mmap_sem hold in read mode to protect against MADV_DONTNEED and
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 9c0b17295ba0..b77bb5df4db9 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1502,19 +1502,15 @@ int move_huge_pmd(struct vm_area_struct *vma, struct vm_area_struct *new_vma,
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
pmd = pmdp_get_and_clear(mm, old_addr, old_pmd);
VM_BUG_ON(!pmd_none(*new_pmd));
- set_pmd_at(mm, new_addr, new_pmd, pmd_mksoft_dirty(pmd));
- if (new_ptl != old_ptl) {
- pgtable_t pgtable;
- /*
- * Move preallocated PTE page table if new_pmd is on
- * different PMD page table.
- */
+ if (pmd_move_must_withdraw(new_ptl, old_ptl)) {
+ pgtable_t pgtable;
pgtable = pgtable_trans_huge_withdraw(mm, old_pmd);
pgtable_trans_huge_deposit(mm, new_pmd, pgtable);
-
- spin_unlock(new_ptl);
}
+ set_pmd_at(mm, new_addr, new_pmd, pmd_mksoft_dirty(pmd));
+ if (new_ptl != old_ptl)
+ spin_unlock(new_ptl);
spin_unlock(old_ptl);
}
out:
--
1.8.3.2
^ permalink raw reply related
* [PATCH] mtd: m25p80: Make the name of mtd_info fixed
From: Hou Zhiqiang @ 2014-01-06 6:34 UTC (permalink / raw)
To: linux-mtd, linuxppc-dev
Cc: scottwood, Hou Zhiqiang, mingkai.hu, computersforpeace
To give spi flash layout using "mtdparts=..." in cmdline, we must
give mtd_info a fixed name,because the cmdlinepart's parser will
match the name given in cmdline with the mtd_info.
Now, if use OF node, mtd_info's name will be spi->dev->name. It
consists of spi_master->bus_num, and the spi_master->bus_num maybe
dynamically fetched.
So, give the mtd_info a new fiexd name "name.cs", "name" is name of
spi_device_id and "cs" is chip-select in spi_dev.
Signed-off-by: Hou Zhiqiang <b48286@freescale.com>
---
drivers/mtd/devices/m25p80.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index eb558e8..d1ed480 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -1012,7 +1012,8 @@ static int m25p_probe(struct spi_device *spi)
if (data && data->name)
flash->mtd.name = data->name;
else
- flash->mtd.name = dev_name(&spi->dev);
+ flash->mtd.name = kasprintf(GFP_KERNEL, "%s.%d",
+ id->name, spi->chip_select);
flash->mtd.type = MTD_NORFLASH;
flash->mtd.writesize = 1;
--
1.8.4.1
^ permalink raw reply related
* RE: [PATCH] mtd: m25p80: Add Power Management support
From: B48286 @ 2014-01-06 7:32 UTC (permalink / raw)
To: 'Brian Norris'
Cc: Scott Wood, linuxppc-dev@ozlabs.org, Mingkai.Hu@freescale.com,
linux-mtd@lists.infradead.org, dwmw2@infradead.org
In-Reply-To: <20140103190049.GG5631@ld-irv-0074>
>On Wed, Dec 11, 2013 at 04:19:30PM +0800, Hou Zhiqiang wrote:
>> Add PM support using callback function suspend and resume in .driver=20
>> of spi_driver.
>>=20
>> Signed-off-by: Hou Zhiqiang <b48286@freescale.com>
>> ---
>> drivers/mtd/devices/m25p80.c | 37=20
>> +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>>=20
>> diff --git a/drivers/mtd/devices/m25p80.c=20
>> b/drivers/mtd/devices/m25p80.c index 7eda71d..b0c2b8c 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -66,6 +66,8 @@
>> =20
>> /* Used for Spansion flashes only. */
>> #define OPCODE_BRWR 0x17 /* Bank register write */
>> +#define OPCODE_DP 0xb9 /* Enter deep power down mode */
>> +#define OPCODE_RES 0xab /* Exit deep power down mode */
>
>Where did you get these opcodes from? They are not in the Spansion datashe=
ets I'm reading. And in fact, they are overloaded as RES (Read Electronic S=
ignature, 0xab) and Bank Register Access (0xb9) in the datasheet I'm lookin=
g at. So this patch is wrong.
>
In datasheet S25FL128P, Deep Power Down command is b9h and Release from Dee=
p Power Down command is abh. In S25FL-A to S25FL-P Migration Guide those co=
mmands are the same.
>Also, can you describe the purpose of these "deep power down" modes?
>I've never seen PM states where the *flash* needs to be put into a lower p=
ower mode. Typically the flash is pretty low-power when idle, and it may ev=
en be powered off completely when the system enters a lower-power state. An=
yway, please describe why this patch is needed.
>
In standby mode, the MAX currunt consumption is 200mA, and in Deep Power Do=
wn mode, the MAX is 20mA. In actually the typically value of currunt consum=
ption is 3mA, so it save power consumption significantly I think.
>> =20
>> /* Status Register bits. */
>> #define SR_WIP 1 /* Write in progress */
>> @@ -1128,11 +1130,46 @@ static int m25p_remove(struct spi_device *spi)
>> return mtd_device_unregister(&flash->mtd);
>> }
>> =20
>> +#ifdef CONFIG_PM
>> +static int m25p_suspend(struct device *dev, pm_message_t mesg) {
>> + struct m25p *flash =3D dev_get_drvdata(dev);
>> + int ret;
>> +
>> + flash->command[0] =3D OPCODE_DP;
>
>As mentioned above, this opcode is not recognized by many flash supported =
in this driver. So we might want one or more of the following:
>
> (1) to assign different suspend/resume opcodes for use in
> m25p_suspend/resume
> (2) to provide over-loadable callbacks so that different flash could
> use different suspend/resume routines
>
>And of course, we need to avoid sending these commands at all to unsupport=
ed flash.
>
Yeah, in m25p_probe we can get spi flash specified PM commands from somewhe=
re, but where can we set the PM commands, in struct spi_device_id?
Do you have some good suggestion?
>> + mutex_lock(&flash->lock);
>> + /* Wait until finished previous write/erase command. */
>> + ret =3D wait_till_ready(flash);
>> + if (ret) {
>> + mutex_unlock(&flash->lock);
>> + return ret;
>> + }
>> + ret =3D spi_write(flash->spi, flash->command, 1);
>> + mutex_unlock(&flash->lock);
>> +
>> + return ret;
>> +}
>> +
>> +static int m25p_resume(struct device *dev) {
>> + struct m25p *flash =3D dev_get_drvdata(dev);
>> + int ret;
>> +
>> + flash->command[0] =3D OPCODE_RES;
>> + ret =3D spi_write(flash->spi, flash->command, 1);
>> +
>> + return ret;
>> +}
>> +#endif /* CONFIG_PM */
>> =20
>> static struct spi_driver m25p80_driver =3D {
>> .driver =3D {
>> .name =3D "m25p80",
>> .owner =3D THIS_MODULE,
>> +#ifdef CONFIG_PM
>> + .suspend =3D m25p_suspend,
>> + .resume =3D m25p_resume,
>> +#endif
>> },
>> .id_table =3D m25p_ids,
>> .probe =3D m25p_probe,
>
>Brian
Zhiqiang Hou
^ permalink raw reply
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
From: wyang @ 2014-01-06 6:42 UTC (permalink / raw)
To: Gavin Hu; +Cc: Linuxppc-dev
In-Reply-To: <CABiPGEeoHCRk_8=yKWnxLAnvh+xg8G-q2r-VbdjtFXudtBS9Hw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]
On 01/06/2014 02:24 PM, Gavin Hu wrote:
> So, these primitive funcitons like atomic_add() and so on also can't
> prevent processes schedule switch on local CPU core? right?
You are right!
BR
Wei
>
> Thanks!
>
>
> BR
> Gvain. Hu
>
>
> On Mon, Jan 6, 2014 at 1:27 PM, wyang <w90p710@gmail.com
> <mailto:w90p710@gmail.com>> wrote:
>
>
> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>> Thanks your response. :)
>> But that means that these optimitive operations like atomic_add()
>> aren't optimitive actully in PPC architecture, right? Becuase
>> they can be interrupted by loacl HW interrupts. Theoretically,
>> the ISR also can access the atomic gloable variable.
>
> Nope, my understand is that if you wanna sync kernel primitive
> code with ISR, you have responsibility to disable local
> interrupts. atomic_add does not guarantee to handle such case.
>
> Thanks
> Wei
>
>
>>
>>
>> The following codes are complete atomic_inc() copied from arch/
>> static __inline__ void atomic_add(int a, atomic_t *v)
>> {
>> int t;
>>
>> __asm__ __volatile__(
>> "1: lwarx %0,0,%3 # atomic_add\n\
>> add %0,%2,%0\n"
>> PPC405_ERR77(0,%3)
>> " stwcx. %0,0,%3 \n\
>> bne- 1b"
>> : "=&r" (t), "+m" (v->counter)
>> : "r" (a), "r" (&v->counter)
>> : "cc");
>> }
>>
>>
>> BR
>> Gavin. Hu
>>
>>
>> On Mon, Dec 30, 2013 at 9:54 AM, wyang <w90p710@gmail.com
>> <mailto:w90p710@gmail.com>> wrote:
>>
>> On 12/28/2013 01:41 PM, Gavin Hu wrote:
>>> Hi
>>>
>>> I notice that there is a pair ppc instructions lwarx and
>>> stwcx used to atomtic operation for instance,
>>> atomic_inc/atomic_dec.
>>>
>>> In some ppc manuals, they more emphasize its mechanism is
>>> that lwarx can reseve the target memory address preventing
>>> other CORE from modifying it.
>>>
>>> I assume that there is atomtic operation executing on the
>>> CORE0 in a multicore system. In this situation, does the
>>> CORE0 disable the local HW interrupt?
>>> Can the executing process from the beginning of lwarx and
>>> end of stwcx be interrupted by HW interruptions/exceptions?
>>> Anyway, they are two assembly instructions.
>>
>> It should just like other arch, the processor should response
>> any interrupt after the execution of a instruction, so the
>> local HW interrupt is not disabled.
>>
>> Thanks
>> Wei
>>>
>>> Thanks a lot!
>>>
>>> "1: lwarx %0,0,%2 # atomic_inc\n\
>>> addic %0,%0,1\n"
>>> " stwcx. %0,0,%2 \n\
>>>
>>>
>>> BR
>>> Gavin. Hu
>>>
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org <mailto:Linuxppc-dev@lists.ozlabs.org>
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>
>
[-- Attachment #2: Type: text/html, Size: 9361 bytes --]
^ permalink raw reply
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
From: Gavin Hu @ 2014-01-06 6:24 UTC (permalink / raw)
To: wyang; +Cc: Linuxppc-dev
In-Reply-To: <52CA3ED7.2020407@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2484 bytes --]
So, these primitive funcitons like atomic_add() and so on also can't
prevent processes schedule switch on local CPU core? right?
Thanks!
BR
Gvain. Hu
On Mon, Jan 6, 2014 at 1:27 PM, wyang <w90p710@gmail.com> wrote:
>
> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>
> Thanks your response. :)
> But that means that these optimitive operations like atomic_add() aren't
> optimitive actully in PPC architecture, right? Becuase they can be
> interrupted by loacl HW interrupts. Theoretically, the ISR also can access
> the atomic gloable variable.
>
>
> Nope, my understand is that if you wanna sync kernel primitive code with
> ISR, you have responsibility to disable local interrupts. atomic_add does
> not guarantee to handle such case.
>
> Thanks
> Wei
>
>
>
>
> The following codes are complete atomic_inc() copied from arch/
> static __inline__ void atomic_add(int a, atomic_t *v)
> {
> int t;
>
> __asm__ __volatile__(
> "1: lwarx %0,0,%3 # atomic_add\n\
> add %0,%2,%0\n"
> PPC405_ERR77(0,%3)
> " stwcx. %0,0,%3 \n\
> bne- 1b"
> : "=&r" (t), "+m" (v->counter)
> : "r" (a), "r" (&v->counter)
> : "cc");
> }
>
>
> BR
> Gavin. Hu
>
>
> On Mon, Dec 30, 2013 at 9:54 AM, wyang <w90p710@gmail.com> wrote:
>
>> On 12/28/2013 01:41 PM, Gavin Hu wrote:
>>
>> Hi
>>
>> I notice that there is a pair ppc instructions lwarx and stwcx used to
>> atomtic operation for instance, atomic_inc/atomic_dec.
>>
>> In some ppc manuals, they more emphasize its mechanism is that lwarx
>> can reseve the target memory address preventing other CORE from modifying
>> it.
>>
>> I assume that there is atomtic operation executing on the CORE0 in a
>> multicore system. In this situation, does the CORE0 disable the local HW
>> interrupt?
>> Can the executing process from the beginning of lwarx and end of stwcx
>> be interrupted by HW interruptions/exceptions? Anyway, they are two
>> assembly instructions.
>>
>>
>> It should just like other arch, the processor should response any
>> interrupt after the execution of a instruction, so the local HW interrupt
>> is not disabled.
>>
>> Thanks
>> Wei
>>
>>
>> Thanks a lot!
>>
>> "1: lwarx %0,0,%2 # atomic_inc\n\
>> addic %0,%0,1\n"
>> " stwcx. %0,0,%2 \n\
>>
>>
>> BR
>> Gavin. Hu
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>
>
>
[-- Attachment #2: Type: text/html, Size: 5930 bytes --]
^ permalink raw reply
* Re: [02/12,v3] pci: fsl: add structure fsl_pci
From: Lian Minghuan-b31939 @ 2014-01-06 6:10 UTC (permalink / raw)
To: Scott Wood, Minghuan Lian
Cc: Bjorn Helgaas, linux-pci, linuxppc-dev, Zang Roy-R61911
In-Reply-To: <20140103221923.GB22546@home.buserror.net>
On 01/04/2014 06:19 AM, Scott Wood wrote:
> On Wed, Oct 23, 2013 at 06:41:24PM +0800, Minghuan Lian wrote:
>> PowerPC uses structure pci_controller to describe PCI controller,
>> but ARM uses structure pci_sys_data. In order to support PowerPC
>> and ARM simultaneously, the patch adds a structure fsl_pci that
>> contains most of the members of the pci_controller and pci_sys_data.
>> Meanwhile, it defines a interface fsl_arch_sys_to_pci() which should
>> be implemented in architecture-specific PCI controller driver to
>> convert pci_controller or pci_sys_data to fsl_pci.
>>
>> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
>>
>> ---
>> change log:
>> v1-v3:
>> Derived from http://patchwork.ozlabs.org/patch/278965/
>>
>> Based on upstream master.
>> Based on the discussion of RFC version here
>> http://patchwork.ozlabs.org/patch/274487/
>>
>> include/linux/fsl/pci-common.h | 41 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>>
>> diff --git a/include/linux/fsl/pci-common.h b/include/linux/fsl/pci-common.h
>> index 5e4f683..e56a040 100644
>> --- a/include/linux/fsl/pci-common.h
>> +++ b/include/linux/fsl/pci-common.h
>> @@ -102,5 +102,46 @@ struct ccsr_pci {
>>
>> };
>>
>> +/*
>> + * Structure of a PCI controller (host bridge)
>> + */
>> +struct fsl_pci {
>> + struct list_head node;
>> + bool is_pcie;
>> + struct device_node *dn;
>> + struct device *dev;
>> +
>> + int first_busno;
>> + int last_busno;
>> + int self_busno;
>> + struct resource busn;
>> +
>> + struct pci_ops *ops;
>> + struct ccsr_pci __iomem *regs;
>> +
>> + u32 indirect_type;
>> +
>> + struct resource io_resource;
>> + resource_size_t io_base_phys;
>> + resource_size_t pci_io_size;
>> +
>> + struct resource mem_resources[3];
>> + resource_size_t mem_offset[3];
>> +
>> + int global_number; /* PCI domain number */
>> +
>> + resource_size_t dma_window_base_cur;
>> + resource_size_t dma_window_size;
>> +
>> + void *sys;
>> +};
> I don't like the extent to which this duplicates (not moves) PPC's struct
> pci_controller. Also this leaves some fields like "indirect_type"
> unexplained (PPC_INDIRECT_TYPE_xxx is only in the PPC header).
>
> Does the arch-independent part of the driver really need all this? Given
> how closely this tracks the PPC code, how would this work on ARM?
[Minghuan] I added the duplicate fields because PPC's struct
pci_controller need them.
The common PCI driver gets the related information and pass to PowerPC
driver.
And I do hope PowerPC driver to parse dts or access controller to get
the information again.
please see the following code for PowerPC:
int fsl_arch_pci_sys_register(struct fsl_pci *pci)
+{
+ struct pci_controller *hose;
+ hose = pcibios_alloc_controller(pci->dn);
+
+ hose->private_data = pci;
+ hose->parent = pci->dev;
+ hose->first_busno = pci->first_busno;
+ hose->last_busno = pci->last_busno;
+ hose->ops = pci->ops;
+
+ hose->io_base_virt = ioremap(pci->io_base_phys +
pci->io_resource.start,
+ pci->pci_io_size);
+ hose->pci_io_size = pci->io_resource.start + pci->pci_io_size;
+ hose->io_base_phys = pci->io_base_phys;
+ hose->io_resource = pci->io_resource;
+
+ memcpy(hose->mem_offset, pci->mem_offset, sizeof(hose->mem_offset));
+ memcpy(hose->mem_resources, pci->mem_resources,
+ sizeof(hose->mem_resources));
+ hose->dma_window_base_cur = pci->dma_window_base_cur;
+ hose->dma_window_size = pci->dma_window_size;
+ pci->sys = hose;
+....
+ return 0;
+}
The following is for ARM, I will submit them after verification:
+
+static inline struct fsl_pcie *sys_to_pcie(struct pci_sys_data *sys)
+{
+ return sys->private_data;
+}
+
+static int fsl_pcie_setup(int nr, struct pci_sys_data *sys)
+{
+ struct fsl_pcie *pcie;
+
+ pcie = sys_to_pcie(sys);
+
+ if (!pcie)
+ return 0;
+
+ pcie->sys = sys;
+
+ sys->io_offset = pcie->io_base_phys;
+ pci_ioremap_io(sys->io_offset, pcie->io_resource.start);
+ pci_add_resource_offset(&sys->resources, &pcie->io_resource,
+ sys->io_offset);
+
+ sys->mem_offset = pcie->mem_offset;
+ pci_add_resource_offset(&sys->resources, &pcie->mem_resource,
+ sys->mem_offset);
+
+ return 1;
+}
+
+static struct pci_bus *
+fsl_pcie_scan_bus(int nr, struct pci_sys_data *sys)
+{
+ struct pci_bus *bus;
+ struct fsl_pcie *pcie = sys_to_pcie(sys);
+
+ bus = pci_create_root_bus(pcie->dev, sys->busnr,
+ pcie->ops, sys, &sys->resources);
+ if (!bus)
+ return NULL;
+
+ pci_scan_child_bus(bus);
+
+ return bus;
+}
+
+static int fsl_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
+{
+ struct of_irq oirq;
+ int ret;
+
+ ret = of_irq_map_pci(dev, &oirq);
+ if (ret)
+ return ret;
+
+ return irq_create_of_mapping(oirq.controller, oirq.specifier,
+ oirq.size);
+}
+
+static struct hw_pci fsl_hw_pcie = {
+ .ops = &fsl_indirect_pci_ops;
+ .setup = fsl_pcie_setup,
+ .scan = fsl_pcie_scan_bus,
+ .map_irq = fsl_pcie_map_irq,
+};
+static struct pci_bus *
+fake_pci_bus(struct fsl_pcie *pcie, int busnr)
+{
+ static struct pci_bus bus;
+ static struct pci_sys_data sys;
+
+ bus.number = busnr;
+ bus.sysdata = &sys;
+ sys.private_data = pcie;
+ bus.ops = pcie->ops;
+ return &bus;
+}
+
+static int fsl_pcie_register(struct fsl_pcie *pcie)
+{
+ pcie->controller = fsl_hw_pcie.nr_controllers;
+ fsl_hw_pcie.nr_controllers = 1;
+ fsl_hw_pcie.private_data = (void **)&pcie;
+
+ pci_common_init(&fsl_hw_pcie);
+ pci_assign_unassigned_resources();
+#ifdef CONFIG_PCI_DOMAINS
+ fsl_hw_pcie.domain++;
+#endif
+}
>
> -Scott
^ permalink raw reply
* RE: [PATCH] powerpc/fsl-booke: Use SPRN_SPRGn rather than mfsprg/mtsprg
From: Dongsheng.Wang @ 2014-01-06 6:05 UTC (permalink / raw)
To: Scott Wood, Benjamin Herrenschmidt
Cc: anton@enomsg.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <a79e5eb1cf444a3782c9af9952efe69b@BN1PR03MB188.namprd03.prod.outlook.com>
Reviewed-by: Wang Dongsheng <dongsheng.wang@freescale.com>
Tested-by: Wang Dongsheng <dongsheng.wang@freescale.com>
Works well. :)
-Dongsheng
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+b40534=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
> Dongsheng.Wang@freescale.com
> Sent: Friday, January 03, 2014 6:33 PM
> To: Wood Scott-B07421; Benjamin Herrenschmidt
> Cc: Anton Vorontsov; linuxppc-dev@lists.ozlabs.org
> Subject: RE: [PATCH] powerpc/fsl-booke: Use SPRN_SPRGn rather than mfsprg=
/mtsprg
>=20
> Looks good. I will test it as soon as possible.
>=20
> BTW, there is only SPRG3 need to save.
> 32bit: SPRG0-SPRG1, SPRG2-SPRG7, SPRG9 be use to deal with exception,
> those register not need to save.(SPRG8 not be used) Only SPRG3 be used
> to save current thread_info pointer.
>=20
> -Dongsheng
>=20
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Friday, January 03, 2014 6:38 AM
> > To: Benjamin Herrenschmidt
> > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421; Wang Dongsheng-B4=
0534;
> > Anton Vorontsov
> > Subject: [PATCH] powerpc/fsl-booke: Use SPRN_SPRGn rather than mfsprg/m=
tsprg
> >
> > This fixes a build break that was probably introduced with the removal
> > of -Wa,-me500 (commit f49596a4cf4753d13951608f24f939a59fdcc653), where
> > the assembler refuses to recognize SPRG4-7 with a generic PPC target.
> >
> > Signed-off-by: Scott Wood <scottwood@freescale.com>
> > Cc: Dongsheng Wang <dongsheng.wang@freescale.com>
> > Cc: Anton Vorontsov <avorontsov@mvista.com>
> > ---
> > Dongsheng, please test.
> > ---
> > arch/powerpc/kernel/swsusp_booke.S | 32 ++++++++++++++++--------------=
--
> > 1 file changed, 16 insertions(+), 16 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/swsusp_booke.S
> > b/arch/powerpc/kernel/swsusp_booke.S
> > index 0f20405..553c140 100644
> > --- a/arch/powerpc/kernel/swsusp_booke.S
> > +++ b/arch/powerpc/kernel/swsusp_booke.S
> > @@ -74,21 +74,21 @@ _GLOBAL(swsusp_arch_suspend)
> > bne 1b
> >
> > /* Save SPRGs */
> > - mfsprg r4,0
> > + mfspr r4,SPRN_SPRG0
> > stw r4,SL_SPRG0(r11)
> > - mfsprg r4,1
> > + mfspr r4,SPRN_SPRG1
> > stw r4,SL_SPRG1(r11)
> > - mfsprg r4,2
> > + mfspr r4,SPRN_SPRG2
> > stw r4,SL_SPRG2(r11)
> > - mfsprg r4,3
> > + mfspr r4,SPRN_SPRG3
> > stw r4,SL_SPRG3(r11)
> > - mfsprg r4,4
> > + mfspr r4,SPRN_SPRG4
> > stw r4,SL_SPRG4(r11)
> > - mfsprg r4,5
> > + mfspr r4,SPRN_SPRG5
> > stw r4,SL_SPRG5(r11)
> > - mfsprg r4,6
> > + mfspr r4,SPRN_SPRG6
> > stw r4,SL_SPRG6(r11)
> > - mfsprg r4,7
> > + mfspr r4,SPRN_SPRG7
> > stw r4,SL_SPRG7(r11)
> >
> > /* Call the low level suspend stuff (we should probably have made
> > @@ -150,21 +150,21 @@ _GLOBAL(swsusp_arch_resume)
> > bl _tlbil_all
> >
> > lwz r4,SL_SPRG0(r11)
> > - mtsprg 0,r4
> > + mtspr SPRN_SPRG0,r4
> > lwz r4,SL_SPRG1(r11)
> > - mtsprg 1,r4
> > + mtspr SPRN_SPRG1,r4
> > lwz r4,SL_SPRG2(r11)
> > - mtsprg 2,r4
> > + mtspr SPRN_SPRG2,r4
> > lwz r4,SL_SPRG3(r11)
> > - mtsprg 3,r4
> > + mtspr SPRN_SPRG3,r4
> > lwz r4,SL_SPRG4(r11)
> > - mtsprg 4,r4
> > + mtspr SPRN_SPRG4,r4
> > lwz r4,SL_SPRG5(r11)
> > - mtsprg 5,r4
> > + mtspr SPRN_SPRG5,r4
> > lwz r4,SL_SPRG6(r11)
> > - mtsprg 6,r4
> > + mtspr SPRN_SPRG6,r4
> > lwz r4,SL_SPRG7(r11)
> > - mtsprg 7,r4
> > + mtspr SPRN_SPRG7,r4
> >
> > /* restore the MSR */
> > lwz r3,SL_MSR(r11)
> > --
> > 1.8.3.2
>=20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>=20
^ permalink raw reply
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
From: Gavin Hu @ 2014-01-06 5:51 UTC (permalink / raw)
To: wyang; +Cc: Linuxppc-dev
In-Reply-To: <52CA3ED7.2020407@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]
Get it. Thanks! :)
BR
Gavin. Hu
On Mon, Jan 6, 2014 at 1:27 PM, wyang <w90p710@gmail.com> wrote:
>
> On 01/06/2014 11:41 AM, Gavin Hu wrote:
>
> Thanks your response. :)
> But that means that these optimitive operations like atomic_add() aren't
> optimitive actully in PPC architecture, right? Becuase they can be
> interrupted by loacl HW interrupts. Theoretically, the ISR also can access
> the atomic gloable variable.
>
>
> Nope, my understand is that if you wanna sync kernel primitive code with
> ISR, you have responsibility to disable local interrupts. atomic_add does
> not guarantee to handle such case.
>
> Thanks
> Wei
>
>
>
>
> The following codes are complete atomic_inc() copied from arch/
> static __inline__ void atomic_add(int a, atomic_t *v)
> {
> int t;
>
> __asm__ __volatile__(
> "1: lwarx %0,0,%3 # atomic_add\n\
> add %0,%2,%0\n"
> PPC405_ERR77(0,%3)
> " stwcx. %0,0,%3 \n\
> bne- 1b"
> : "=&r" (t), "+m" (v->counter)
> : "r" (a), "r" (&v->counter)
> : "cc");
> }
>
>
> BR
> Gavin. Hu
>
>
> On Mon, Dec 30, 2013 at 9:54 AM, wyang <w90p710@gmail.com> wrote:
>
>> On 12/28/2013 01:41 PM, Gavin Hu wrote:
>>
>> Hi
>>
>> I notice that there is a pair ppc instructions lwarx and stwcx used to
>> atomtic operation for instance, atomic_inc/atomic_dec.
>>
>> In some ppc manuals, they more emphasize its mechanism is that lwarx
>> can reseve the target memory address preventing other CORE from modifying
>> it.
>>
>> I assume that there is atomtic operation executing on the CORE0 in a
>> multicore system. In this situation, does the CORE0 disable the local HW
>> interrupt?
>> Can the executing process from the beginning of lwarx and end of stwcx
>> be interrupted by HW interruptions/exceptions? Anyway, they are two
>> assembly instructions.
>>
>>
>> It should just like other arch, the processor should response any
>> interrupt after the execution of a instruction, so the local HW interrupt
>> is not disabled.
>>
>> Thanks
>> Wei
>>
>>
>> Thanks a lot!
>>
>> "1: lwarx %0,0,%2 # atomic_inc\n\
>> addic %0,%0,1\n"
>> " stwcx. %0,0,%2 \n\
>>
>>
>> BR
>> Gavin. Hu
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>
>>
>
>
[-- Attachment #2: Type: text/html, Size: 5799 bytes --]
^ permalink raw reply
* Re: [03/12,v3] pci: fsl: add PCI indirect access support
From: Lian Minghuan-b31939 @ 2014-01-06 5:36 UTC (permalink / raw)
To: Scott Wood, Minghuan Lian
Cc: Bjorn Helgaas, linux-pci, linuxppc-dev, Zang Roy-R61911
In-Reply-To: <20140103223306.GC22546@home.buserror.net>
HI Scott,
please see my comments inline.
On 01/04/2014 06:33 AM, Scott Wood wrote:
> On Wed, Oct 23, 2013 at 06:41:25PM +0800, Minghuan Lian wrote:
>> The patch adds PCI indirect read/write functions. The main code
>> is ported from arch/powerpc/sysdev/indirect_pci.c. We use general
>> IO API iowrite32be/ioread32be instead of out_be32/in_be32, and
>> use structure fsl_Pci instead of PowerPC's pci_controller.
>> The patch also provides fsl_pcie_check_link() to check PCI link.
>> The weak function fsl_arch_pci_exclude_device() is provided to
>> call ppc_md.pci_exclude_device() for PowerPC architecture.
>>
>> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
>>
>> ---
>> change log:
>> v1-v3:
>> Derived from http://patchwork.ozlabs.org/patch/278965/
>>
>> Based on upstream master.
>> Based on the discussion of RFC version here
>> http://patchwork.ozlabs.org/patch/274487/
>>
>> drivers/pci/host/pci-fsl-common.c | 169 ++++++++++++++++++++++++++++++++------
>> include/linux/fsl/pci-common.h | 6 ++
>> 2 files changed, 151 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/pci/host/pci-fsl-common.c b/drivers/pci/host/pci-fsl-common.c
>> index 69d338b..8bc9a64 100644
>> --- a/drivers/pci/host/pci-fsl-common.c
>> +++ b/drivers/pci/host/pci-fsl-common.c
>> @@ -35,52 +35,173 @@
>> #include <sysdev/fsl_soc.h>
>> #include <sysdev/fsl_pci.h>
>>
>> -static int fsl_pcie_check_link(struct pci_controller *hose)
>> +/* Indirect type */
>> +#define INDIRECT_TYPE_EXT_REG 0x00000002
>> +#define INDIRECT_TYPE_SURPRESS_PRIMARY_BUS 0x00000004
>> +#define INDIRECT_TYPE_NO_PCIE_LINK 0x00000008
>> +#define INDIRECT_TYPE_BIG_ENDIAN 0x00000010
>> +#define INDIRECT_TYPE_FSL_CFG_REG_LINK 0x00000040
> Why are these here rather than in the header, given that you have
> indirect_type in the struct in the header?
[Minghuan] It's better to define the type in the header file. I will fix it.
>
>> +int __weak fsl_arch_pci_exclude_device(struct fsl_pci *pci, u8 bus, u8 devfn)
>> +{
>> + return PCIBIOS_SUCCESSFUL;
>> +}
>> +
>> +static int fsl_pci_read_config(struct fsl_pci *pci, int bus, int devfn,
>> + int offset, int len, u32 *val)
>> +{
>> + u32 bus_no, reg, data;
>> +
>> + if (pci->indirect_type & INDIRECT_TYPE_NO_PCIE_LINK) {
>> + if (bus != pci->first_busno)
>> + return PCIBIOS_DEVICE_NOT_FOUND;
>> + if (devfn != 0)
>> + return PCIBIOS_DEVICE_NOT_FOUND;
>> + }
> A lot of this seems duplicated from arch/powerpc/sysdev/indirect_pci.c.
>
> How generally applicable is that file to non-PPC implementations? At a
> minimum I see a similar file in arch/microblaze. It should probably
> eventually be moved to common code, rather than duplicated again. A
> prerequisite for that would be making common the dependencies it has on
> the rest of what is currently arch PCI infrastructure; until then, it's
> probably better to just have the common fsl-pci code know how to
> interface with the appropriate PPC/ARM code rather than trying to copy
> the infrastructure as well.
[Minghuan] Yes, This is a duplicate except it uses struct fsl_pci. But
it is hard to be move to common code.
because every indirect read/write functions use different PCI controller
structure which is very basic structure and ARM has no this structure.
If we can not establish a unified pci controller structure, we can only
abstract out a simple structure which includes indirect access related
fields,
and need a callback function to get the pointer like this:
((powerpc/microblaze/mips/ pci_controller
*)(pci_bus->sysdata))->indirect_struct.
Should we provide the common code for indirect access API or wait for
the common PCI controller structure?
> -Scott
^ permalink raw reply
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
From: wyang @ 2014-01-06 5:27 UTC (permalink / raw)
To: Gavin Hu; +Cc: Linuxppc-dev
In-Reply-To: <CABiPGEcHxgmuLMcMN1ByutJC22RJPHSZf3n5gF9BgenbfQTJvA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]
On 01/06/2014 11:41 AM, Gavin Hu wrote:
> Thanks your response. :)
> But that means that these optimitive operations like atomic_add()
> aren't optimitive actully in PPC architecture, right? Becuase they can
> be interrupted by loacl HW interrupts. Theoretically, the ISR also can
> access the atomic gloable variable.
Nope, my understand is that if you wanna sync kernel primitive code with
ISR, you have responsibility to disable local interrupts. atomic_add
does not guarantee to handle such case.
Thanks
Wei
>
>
> The following codes are complete atomic_inc() copied from arch/
> static __inline__ void atomic_add(int a, atomic_t *v)
> {
> int t;
>
> __asm__ __volatile__(
> "1: lwarx %0,0,%3 # atomic_add\n\
> add %0,%2,%0\n"
> PPC405_ERR77(0,%3)
> " stwcx. %0,0,%3 \n\
> bne- 1b"
> : "=&r" (t), "+m" (v->counter)
> : "r" (a), "r" (&v->counter)
> : "cc");
> }
>
>
> BR
> Gavin. Hu
>
>
> On Mon, Dec 30, 2013 at 9:54 AM, wyang <w90p710@gmail.com
> <mailto:w90p710@gmail.com>> wrote:
>
> On 12/28/2013 01:41 PM, Gavin Hu wrote:
>> Hi
>>
>> I notice that there is a pair ppc instructions lwarx and stwcx
>> used to atomtic operation for instance, atomic_inc/atomic_dec.
>>
>> In some ppc manuals, they more emphasize its mechanism is that
>> lwarx can reseve the target memory address preventing other CORE
>> from modifying it.
>>
>> I assume that there is atomtic operation executing on the CORE0
>> in a multicore system. In this situation, does the CORE0 disable
>> the local HW interrupt?
>> Can the executing process from the beginning of lwarx and end of
>> stwcx be interrupted by HW interruptions/exceptions? Anyway,
>> they are two assembly instructions.
>
> It should just like other arch, the processor should response any
> interrupt after the execution of a instruction, so the local HW
> interrupt is not disabled.
>
> Thanks
> Wei
>>
>> Thanks a lot!
>>
>> "1: lwarx %0,0,%2 # atomic_inc\n\
>> addic %0,%0,1\n"
>> " stwcx. %0,0,%2 \n\
>>
>>
>> BR
>> Gavin. Hu
>>
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org <mailto:Linuxppc-dev@lists.ozlabs.org>
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
[-- Attachment #2: Type: text/html, Size: 5868 bytes --]
^ permalink raw reply
* [PATCH v2 2/2] powerpc/mpic_timer: fix convert ticks to time subtraction overflow
From: Dongsheng Wang @ 2014-01-06 5:23 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev, Wang Dongsheng
In-Reply-To: <1388985811-32495-1-git-send-email-dongsheng.wang@freescale.com>
From: Wang Dongsheng <dongsheng.wang@freescale.com>
In some cases tmp_sec may be greater than ticks, because in the process
of calculation ticks and tmp_sec will be rounded.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
v2:
Add the new patch in v2.
diff --git a/arch/powerpc/sysdev/mpic_timer.c b/arch/powerpc/sysdev/mpic_timer.c
index 70dcf9c..9d9b062 100644
--- a/arch/powerpc/sysdev/mpic_timer.c
+++ b/arch/powerpc/sysdev/mpic_timer.c
@@ -97,8 +97,11 @@ static void convert_ticks_to_time(struct timer_group_priv *priv,
time->tv_sec = (__kernel_time_t)div_u64(ticks, priv->timerfreq);
tmp_sec = (u64)time->tv_sec * (u64)priv->timerfreq;
- time->tv_usec = (__kernel_suseconds_t)
- div_u64((ticks - tmp_sec) * 1000000, priv->timerfreq);
+ time->tv_usec = 0;
+
+ if (tmp_sec <= ticks)
+ time->tv_usec = (__kernel_suseconds_t)
+ div_u64((ticks - tmp_sec) * 1000000, priv->timerfreq);
return;
}
--
1.8.5
^ permalink raw reply related
* [PATCH v2 1/2] powerpc/mpic_timer: fix the time is not accurate caused by GTCRR toggle bit
From: Dongsheng Wang @ 2014-01-06 5:23 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev, Wang Dongsheng
From: Wang Dongsheng <dongsheng.wang@freescale.com>
When the timer GTCCR toggle bit is inverted, we calculated the rest
of the time is not accurate. So we need to ignore this bit.
Signed-off-by: Wang Dongsheng <dongsheng.wang@freescale.com>
---
v2:
No change.
diff --git a/arch/powerpc/sysdev/mpic_timer.c b/arch/powerpc/sysdev/mpic_timer.c
index 22d7d57..70dcf9c 100644
--- a/arch/powerpc/sysdev/mpic_timer.c
+++ b/arch/powerpc/sysdev/mpic_timer.c
@@ -41,6 +41,7 @@
#define MPIC_TIMER_TCR_ROVR_OFFSET 24
#define TIMER_STOP 0x80000000
+#define GTCCR_TOG 0x80000000
#define TIMERS_PER_GROUP 4
#define MAX_TICKS (~0U >> 1)
#define MAX_TICKS_CASCADE (~0U)
@@ -327,11 +328,13 @@ void mpic_get_remain_time(struct mpic_timer *handle, struct timeval *time)
casc_priv = priv->timer[handle->num].cascade_handle;
if (casc_priv) {
tmp_ticks = in_be32(&priv->regs[handle->num].gtccr);
+ tmp_ticks &= ~GTCCR_TOG;
ticks = ((u64)tmp_ticks & UINT_MAX) * (u64)MAX_TICKS_CASCADE;
tmp_ticks = in_be32(&priv->regs[handle->num - 1].gtccr);
ticks += tmp_ticks;
} else {
ticks = in_be32(&priv->regs[handle->num].gtccr);
+ ticks &= ~GTCCR_TOG;
}
convert_ticks_to_time(priv, ticks, time);
--
1.8.5
^ permalink raw reply related
* Re: [11/12,v3] pci: fsl: update PCI EDAC driver
From: Lian Minghuan-b31939 @ 2014-01-06 3:57 UTC (permalink / raw)
To: Scott Wood, Minghuan Lian
Cc: Bjorn Helgaas, linux-pci, linuxppc-dev, Zang Roy-R61911
In-Reply-To: <20140103221603.GA22546@home.buserror.net>
Hi Scott,
I think we should reverse this commit
0f1741c74aa6794b1c7fbdd19f26a4f2377a11c6.
PCI controller driver is a platform driver supports probe and remove,
when removing the driver we should call mpc85xx_pci_err_remove() to free EDAC PCI resource.
Thanks,
Minghuan
On 01/04/2014 06:16 AM, Scott Wood wrote:
> On Wed, Oct 23, 2013 at 06:41:33PM +0800, Minghuan Lian wrote:
>> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
>> index 40d2e1d..4a03e1a 100644
>> --- a/arch/powerpc/sysdev/fsl_pci.c
>> +++ b/arch/powerpc/sysdev/fsl_pci.c
>> @@ -236,6 +236,7 @@ void fsl_arch_pci_sys_remove(struct fsl_pci *pci)
>> if (!hose)
>> return;
>>
>> + mpc85xx_pci_err_remove(to_platform_device(pci->dev));
>> pcibios_free_controller(hose);
> This causes a linker error if the EDAC driver is enabled, due to commit
> 0f1741c74aa6794b1c7fbdd19f26a4f2377a11c6 ("edac/85xx: Remove
> mpc85xx_pci_err_remove").
>
> -Scott
^ permalink raw reply
* Re: [question] Can the execution of the atomtic operation instruction pair lwarx/stwcx be interrrupted by local HW interruptions?
From: Gavin Hu @ 2014-01-06 3:41 UTC (permalink / raw)
To: wyang; +Cc: Linuxppc-dev
In-Reply-To: <52C0D251.2000400@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]
Thanks your response. :)
But that means that these optimitive operations like atomic_add() aren't
optimitive actully in PPC architecture, right? Becuase they can be
interrupted by loacl HW interrupts. Theoretically, the ISR also can access
the atomic gloable variable.
The following codes are complete atomic_inc() copied from arch/
static __inline__ void atomic_add(int a, atomic_t *v)
{
int t;
__asm__ __volatile__(
"1: lwarx %0,0,%3 # atomic_add\n\
add %0,%2,%0\n"
PPC405_ERR77(0,%3)
" stwcx. %0,0,%3 \n\
bne- 1b"
: "=&r" (t), "+m" (v->counter)
: "r" (a), "r" (&v->counter)
: "cc");
}
BR
Gavin. Hu
On Mon, Dec 30, 2013 at 9:54 AM, wyang <w90p710@gmail.com> wrote:
> On 12/28/2013 01:41 PM, Gavin Hu wrote:
>
> Hi
>
> I notice that there is a pair ppc instructions lwarx and stwcx used to
> atomtic operation for instance, atomic_inc/atomic_dec.
>
> In some ppc manuals, they more emphasize its mechanism is that lwarx can
> reseve the target memory address preventing other CORE from modifying it.
>
> I assume that there is atomtic operation executing on the CORE0 in a
> multicore system. In this situation, does the CORE0 disable the local HW
> interrupt?
> Can the executing process from the beginning of lwarx and end of stwcx
> be interrupted by HW interruptions/exceptions? Anyway, they are two
> assembly instructions.
>
>
> It should just like other arch, the processor should response any
> interrupt after the execution of a instruction, so the local HW interrupt
> is not disabled.
>
> Thanks
> Wei
>
>
> Thanks a lot!
>
> "1: lwarx %0,0,%2 # atomic_inc\n\
> addic %0,%0,1\n"
> " stwcx. %0,0,%2 \n\
>
>
> BR
> Gavin. Hu
>
>
> _______________________________________________
> Linuxppc-dev mailing listLinuxppc-dev@lists.ozlabs.orghttps://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>
[-- Attachment #2: Type: text/html, Size: 3427 bytes --]
^ permalink raw reply
* [PATCH v5 1/1] powerpc/embedded6xx: Add support for Motorola/Emerson MVME5100
From: Stephen Chivers @ 2014-01-06 1:23 UTC (permalink / raw)
To: benh, scottwood; +Cc: schivers, linuxppc-dev
Add support for the Motorola/Emerson MVME5100 Single Board Computer.
The MVME5100 is a 6U form factor VME64 computer with:
- A single MPC7410 or MPC750 CPU
- A HAWK Processor Host Bridge (CPU to PCI) and
MultiProcessor Interrupt Controller (MPIC)
- Up to 500Mb of onboard memory
- A M48T37 Real Time Clock (RTC) and Non-Volatile Memory chip
- Two 16550 compatible UARTS
- Two Intel E100 Fast Ethernets
- Two PCI Mezzanine Card (PMC) Slots
- PPCBug Firmware
The HAWK PHB/MPIC is compatible with the MPC10x devices.
There is no onboard disk support. This is usually provided by installing a PMC
in first PMC slot.
This patch revives the board support, it was present in early 2.6
series kernels. The board support in those days was by Matt Porter of
MontaVista Software.
CSC Australia has around 31 of these boards in service. The kernel in use
for the boards is based on 2.6.31. The boards are operated without disks
from a file server.
This patch is based on linux-3.13-rc2 and has been boot tested.
Only boards with 512 Mb of memory are known to work.
V1->V2:
Address comments by Kumar Gala and Scott Wood.
Minor adjustment to platforms/embedded6xx/Kconfig to ensure
correct indentation where possible.
V2->V3:
Address comments by Scott Wood and Ben Herrenschmidt.
Address errors reported by checkpatch.
V3->V4:
Address comment by Geert Uytterhoeven
Add tested by Alessio Bogani.
V4->V5:
Correct horrible typo in patch history.
Kular Gama is Kumar Gala.
Signed-off-by: Stephen Chivers <schivers@csc.com>
Tested-by: Alessio Igor Bogani <alessio.bogani@elettra.eu>
---
arch/powerpc/boot/Makefile | 3 +-
arch/powerpc/boot/dts/mvme5100.dts | 185 +++++++++++++++++++++
arch/powerpc/boot/mvme5100.c | 27 +++
arch/powerpc/boot/wrapper | 4 +
arch/powerpc/configs/mvme5100_defconfig | 144 ++++++++++++++++
arch/powerpc/platforms/embedded6xx/Kconfig | 13 ++-
arch/powerpc/platforms/embedded6xx/Makefile | 1 +
arch/powerpc/platforms/embedded6xx/mvme5100.c | 221 +++++++++++++++++++++++++
8 files changed, 596 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index ca7f08c..cd9ea99 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -95,7 +95,7 @@ src-plat-$(CONFIG_FSL_SOC_BOOKE) += cuboot-85xx.c cuboot-85xx-cpm2.c
src-plat-$(CONFIG_EMBEDDED6xx) += cuboot-pq2.c cuboot-mpc7448hpc2.c \
cuboot-c2k.c gamecube-head.S \
gamecube.c wii-head.S wii.c holly.c \
- prpmc2800.c
+ prpmc2800.c fixed-head.S mvme5100.c
src-plat-$(CONFIG_AMIGAONE) += cuboot-amigaone.c
src-plat-$(CONFIG_PPC_PS3) += ps3-head.S ps3-hvcall.S ps3.c
src-plat-$(CONFIG_EPAPR_BOOT) += epapr.c epapr-wrapper.c
@@ -286,6 +286,7 @@ image-$(CONFIG_MPC7448HPC2) += cuImage.mpc7448hpc2
image-$(CONFIG_PPC_C2K) += cuImage.c2k
image-$(CONFIG_GAMECUBE) += dtbImage.gamecube
image-$(CONFIG_WII) += dtbImage.wii
+image-$(CONFIG_MVME5100) += dtbImage.mvme5100
# Board port in arch/powerpc/platform/amigaone/Kconfig
image-$(CONFIG_AMIGAONE) += cuImage.amigaone
diff --git a/arch/powerpc/boot/dts/mvme5100.dts b/arch/powerpc/boot/dts/mvme5100.dts
new file mode 100644
index 0000000..1ecb341
--- /dev/null
+++ b/arch/powerpc/boot/dts/mvme5100.dts
@@ -0,0 +1,185 @@
+/*
+ * Device Tree Source for Motorola/Emerson MVME5100.
+ *
+ * Copyright 2013 CSC Australia Pty. Ltd.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ model = "MVME5100";
+ compatible = "MVME5100";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ serial0 = &serial0;
+ pci0 = &pci0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,7410 {
+ device_type = "cpu";
+ reg = <0x0>;
+ /* Following required by dtc but not used */
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ timebase-frequency = <25000000>;
+ clock-frequency = <500000000>;
+ bus-frequency = <100000000>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x20000000>;
+ };
+
+ hawk@fef80000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "hawk-bridge", "simple-bus";
+ ranges = <0x0 0xfef80000 0x10000>;
+ reg = <0xfef80000 0x10000>;
+
+ serial0: serial@8000 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x8000 0x80>;
+ reg-shift = <4>;
+ clock-frequency = <1843200>;
+ current-speed = <9600>;
+ interrupts = <1 1>; // IRQ1 Level Active Low.
+ interrupt-parent = <&mpic>;
+ };
+
+ serial1: serial@8200 {
+ device_type = "serial";
+ compatible = "ns16550";
+ reg = <0x8200 0x80>;
+ reg-shift = <4>;
+ clock-frequency = <1843200>;
+ current-speed = <9600>;
+ interrupts = <1 1>; // IRQ1 Level Active Low.
+ interrupt-parent = <&mpic>;
+ };
+
+ mpic: interrupt-controller@f3f80000 {
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ device_type = "open-pic";
+ compatible = "chrp,open-pic";
+ interrupt-controller;
+ reg = <0xf3f80000 0x40000>;
+ };
+ };
+
+ pci0: pci@feff0000 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ device_type = "pci";
+ compatible = "hawk-pci";
+ reg = <0xfec00000 0x400000>;
+ 8259-interrupt-acknowledge = <0xfeff0030>;
+ ranges = <0x1000000 0x0 0x0 0xfe000000 0x0 0x800000
+ 0x2000000 0x0 0x80000000 0x80000000 0x0 0x74000000>;
+ bus-range = <0 255>;
+ clock-frequency = <33333333>;
+ interrupt-parent = <&mpic>;
+ interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
+ interrupt-map = <
+
+ /*
+ * This definition (IDSEL 11) duplicates the
+ * interrupts definition in the i8259
+ * interrupt controller below.
+ *
+ * Do not change the interrupt sense/polarity from
+ * 0x2 to anything else, doing so will cause endless
+ * "spurious" i8259 interrupts to be fielded.
+ */
+ // IDSEL 11 - iPMC712 PCI/ISA Bridge
+ 0x5800 0x0 0x0 0x1 &mpic 0x0 0x2
+ 0x5800 0x0 0x0 0x2 &mpic 0x0 0x2
+ 0x5800 0x0 0x0 0x3 &mpic 0x0 0x2
+ 0x5800 0x0 0x0 0x4 &mpic 0x0 0x2
+
+ /* IDSEL 12 - Not Used */
+
+ /* IDSEL 13 - Universe VME Bridge */
+ 0x6800 0x0 0x0 0x1 &mpic 0x5 0x1
+ 0x6800 0x0 0x0 0x2 &mpic 0x6 0x1
+ 0x6800 0x0 0x0 0x3 &mpic 0x7 0x1
+ 0x6800 0x0 0x0 0x4 &mpic 0x8 0x1
+
+ /* IDSEL 14 - ENET 1 */
+ 0x7000 0x0 0x0 0x1 &mpic 0x2 0x1
+
+ /* IDSEL 15 - Not Used */
+
+ /* IDSEL 16 - PMC Slot 1 */
+ 0x8000 0x0 0x0 0x1 &mpic 0x9 0x1
+ 0x8000 0x0 0x0 0x2 &mpic 0xa 0x1
+ 0x8000 0x0 0x0 0x3 &mpic 0xb 0x1
+ 0x8000 0x0 0x0 0x4 &mpic 0xc 0x1
+
+ /* IDSEL 17 - PMC Slot 2 */
+ 0x8800 0x0 0x0 0x1 &mpic 0xc 0x1
+ 0x8800 0x0 0x0 0x2 &mpic 0x9 0x1
+ 0x8800 0x0 0x0 0x3 &mpic 0xa 0x1
+ 0x8800 0x0 0x0 0x4 &mpic 0xb 0x1
+
+ /* IDSEL 18 - Not Used */
+
+ /* IDSEL 19 - ENET 2 */
+ 0x9800 0x0 0x0 0x1 &mpic 0xd 0x1
+
+ /* IDSEL 20 - PMCSPAN (PCI-X) */
+ 0xa000 0x0 0x0 0x1 &mpic 0x9 0x1
+ 0xa000 0x0 0x0 0x2 &mpic 0xa 0x1
+ 0xa000 0x0 0x0 0x3 &mpic 0xb 0x1
+ 0xa000 0x0 0x0 0x4 &mpic 0xc 0x1
+
+ >;
+
+ isa {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ #interrupt-cells = <2>;
+ device_type = "isa";
+ compatible = "isa";
+ ranges = <0x00000001 0 0x01000000 0 0x00000000 0x00001000>;
+ interrupt-parent = <&i8259>;
+
+ i8259: interrupt-controller@20 {
+ #interrupt-cells = <2>;
+ #address-cells = <0>;
+ interrupts = <0 2>;
+ device_type = "interrupt-controller";
+ compatible = "chrp,iic";
+ interrupt-controller;
+ reg = <1 0x00000020 0x00000002
+ 1 0x000000a0 0x00000002
+ 1 0x000004d0 0x00000002>;
+ interrupt-parent = <&mpic>;
+ };
+
+ };
+
+ };
+
+ chosen {
+ linux,stdout-path = &serial0;
+ };
+
+};
diff --git a/arch/powerpc/boot/mvme5100.c b/arch/powerpc/boot/mvme5100.c
new file mode 100644
index 0000000..cb865f8
--- /dev/null
+++ b/arch/powerpc/boot/mvme5100.c
@@ -0,0 +1,27 @@
+/*
+ * Motorola/Emerson MVME5100 with PPCBug firmware.
+ *
+ * Author: Stephen Chivers <schivers@csc.com>
+ *
+ * Copyright 2013 CSC Australia Pty. Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+#include "types.h"
+#include "ops.h"
+#include "io.h"
+
+BSS_STACK(4096);
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5)
+{
+ u32 heapsize;
+
+ heapsize = 0x8000000 - (u32)_end; /* 128M */
+ simple_alloc_init(_end, heapsize, 32, 64);
+ fdt_init(_dtb_start);
+ serial_console_init();
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index 2e1af74..d27a255 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -265,6 +265,10 @@ epapr)
link_address='0x20000000'
pie=-pie
;;
+mvme5100)
+ platformo="$object/fixed-head.o $object/mvme5100.o"
+ binary=y
+ ;;
esac
vmz="$tmpdir/`basename \"$kernel\"`.$ext"
diff --git a/arch/powerpc/configs/mvme5100_defconfig b/arch/powerpc/configs/mvme5100_defconfig
new file mode 100644
index 0000000..93c7752
--- /dev/null
+++ b/arch/powerpc/configs/mvme5100_defconfig
@@ -0,0 +1,144 @@
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_UTS_NS is not set
+# CONFIG_IPC_NS is not set
+# CONFIG_PID_NS is not set
+# CONFIG_NET_NS is not set
+CONFIG_CC_OPTIMIZE_FOR_SIZE=y
+# CONFIG_COMPAT_BRK is not set
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_BLK_DEV_BSG is not set
+# CONFIG_PPC_CHRP is not set
+# CONFIG_PPC_PMAC is not set
+CONFIG_EMBEDDED6xx=y
+CONFIG_MVME5100=y
+CONFIG_KVM_GUEST=y
+CONFIG_HZ_100=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+# CONFIG_COMPACTION is not set
+CONFIG_CMDLINE_BOOL=y
+CONFIG_CMDLINE="console=ttyS0,9600 ip=dhcp root=/dev/nfs"
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+# CONFIG_INET_LRO is not set
+# CONFIG_IPV6 is not set
+CONFIG_NETFILTER=y
+CONFIG_NF_CONNTRACK=m
+CONFIG_NF_CT_PROTO_SCTP=m
+CONFIG_NF_CONNTRACK_AMANDA=m
+CONFIG_NF_CONNTRACK_FTP=m
+CONFIG_NF_CONNTRACK_H323=m
+CONFIG_NF_CONNTRACK_IRC=m
+CONFIG_NF_CONNTRACK_NETBIOS_NS=m
+CONFIG_NF_CONNTRACK_PPTP=m
+CONFIG_NF_CONNTRACK_SIP=m
+CONFIG_NF_CONNTRACK_TFTP=m
+CONFIG_NETFILTER_XT_MATCH_MAC=m
+CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
+CONFIG_NETFILTER_XT_MATCH_STATE=m
+CONFIG_NF_CONNTRACK_IPV4=m
+CONFIG_IP_NF_IPTABLES=m
+CONFIG_IP_NF_FILTER=m
+CONFIG_IP_NF_TARGET_REJECT=m
+CONFIG_IP_NF_MANGLE=m
+CONFIG_IP_NF_TARGET_ECN=m
+CONFIG_IP_NF_TARGET_TTL=m
+CONFIG_IP_NF_RAW=m
+CONFIG_IP_NF_ARPTABLES=m
+CONFIG_IP_NF_ARPFILTER=m
+CONFIG_IP_NF_ARP_MANGLE=m
+CONFIG_LAPB=m
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_COUNT=2
+CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_EEPROM_LEGACY=m
+CONFIG_NETDEVICES=y
+CONFIG_TUN=m
+# CONFIG_NET_VENDOR_3COM is not set
+CONFIG_E100=y
+# CONFIG_WLAN is not set
+# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+# CONFIG_SERIO is not set
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_NR_UARTS=10
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_HW_RANDOM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MPC=y
+# CONFIG_HWMON is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=m
+# CONFIG_VGA_CONSOLE is not set
+# CONFIG_HID is not set
+# CONFIG_USB_SUPPORT is not set
+# CONFIG_IOMMU_SUPPORT is not set
+CONFIG_VME_BUS=m
+CONFIG_VME_CA91CX42=m
+CONFIG_EXT2_FS=m
+CONFIG_EXT3_FS=m
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_XFS_FS=m
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=m
+CONFIG_VFAT_FS=m
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NFSD=m
+CONFIG_NFSD_V3=y
+CONFIG_CIFS=m
+CONFIG_NLS=y
+CONFIG_NLS_CODEPAGE_437=m
+CONFIG_NLS_CODEPAGE_932=m
+CONFIG_NLS_ISO8859_1=m
+CONFIG_NLS_UTF8=m
+CONFIG_CRC_CCITT=m
+CONFIG_CRC_T10DIF=y
+CONFIG_XZ_DEC=y
+CONFIG_XZ_DEC_X86=y
+CONFIG_XZ_DEC_IA64=y
+CONFIG_XZ_DEC_ARM=y
+CONFIG_XZ_DEC_ARMTHUMB=y
+CONFIG_XZ_DEC_SPARC=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=20
+CONFIG_CRYPTO_CBC=y
+CONFIG_CRYPTO_PCBC=m
+CONFIG_CRYPTO_MD5=y
+CONFIG_CRYPTO_MICHAEL_MIC=m
+CONFIG_CRYPTO_SHA1=m
+CONFIG_CRYPTO_BLOWFISH=m
+CONFIG_CRYPTO_DES=y
+CONFIG_CRYPTO_SERPENT=m
+CONFIG_CRYPTO_TWOFISH=m
+CONFIG_CRYPTO_DEFLATE=m
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index 302ba43..6d3c7a9 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -67,6 +67,18 @@ config PPC_C2K
This option enables support for the GE Fanuc C2K board (formerly
an SBS board).
+config MVME5100
+ bool "Motorola/Emerson MVME5100"
+ depends on EMBEDDED6xx
+ select MPIC
+ select PCI
+ select PPC_INDIRECT_PCI
+ select PPC_I8259
+ select PPC_NATIVE
+ help
+ This option enables support for the Motorola (now Emerson) MVME5100
+ board.
+
config TSI108_BRIDGE
bool
select PCI
@@ -113,4 +125,3 @@ config WII
help
Select WII if configuring for the Nintendo Wii.
More information at: <http://gc-linux.sourceforge.net/>
-
diff --git a/arch/powerpc/platforms/embedded6xx/Makefile b/arch/powerpc/platforms/embedded6xx/Makefile
index 66c23e4..cdd48d4 100644
--- a/arch/powerpc/platforms/embedded6xx/Makefile
+++ b/arch/powerpc/platforms/embedded6xx/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_USBGECKO_UDBG) += usbgecko_udbg.o
obj-$(CONFIG_GAMECUBE_COMMON) += flipper-pic.o
obj-$(CONFIG_GAMECUBE) += gamecube.o
obj-$(CONFIG_WII) += wii.o hlwd-pic.o
+obj-$(CONFIG_MVME5100) += mvme5100.o
diff --git a/arch/powerpc/platforms/embedded6xx/mvme5100.c b/arch/powerpc/platforms/embedded6xx/mvme5100.c
new file mode 100644
index 0000000..25e3bfb
--- /dev/null
+++ b/arch/powerpc/platforms/embedded6xx/mvme5100.c
@@ -0,0 +1,221 @@
+/*
+ * Board setup routines for the Motorola/Emerson MVME5100.
+ *
+ * Copyright 2013 CSC Australia Pty. Ltd.
+ *
+ * Based on earlier code by:
+ *
+ * Matt Porter, MontaVista Software Inc.
+ * Copyright 2001 MontaVista Software Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * Author: Stephen Chivers <schivers@csc.com>
+ *
+ */
+
+#include <linux/of_platform.h>
+
+#include <asm/i8259.h>
+#include <asm/pci-bridge.h>
+#include <asm/mpic.h>
+#include <asm/prom.h>
+#include <mm/mmu_decl.h>
+#include <asm/udbg.h>
+
+#define HAWK_MPIC_SIZE 0x00040000U
+#define MVME5100_PCI_MEM_OFFSET 0x00000000
+
+/* Board register addresses. */
+#define BOARD_STATUS_REG 0xfef88080
+#define BOARD_MODFAIL_REG 0xfef88090
+#define BOARD_MODRST_REG 0xfef880a0
+#define BOARD_TBEN_REG 0xfef880c0
+#define BOARD_SW_READ_REG 0xfef880e0
+#define BOARD_GEO_ADDR_REG 0xfef880e8
+#define BOARD_EXT_FEATURE1_REG 0xfef880f0
+#define BOARD_EXT_FEATURE2_REG 0xfef88100
+
+static phys_addr_t pci_membase;
+static u_char *restart;
+
+static void mvme5100_8259_cascade(unsigned int irq, struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned int cascade_irq = i8259_irq();
+
+ if (cascade_irq != NO_IRQ)
+ generic_handle_irq(cascade_irq);
+
+ chip->irq_eoi(&desc->irq_data);
+}
+
+static void __init mvme5100_pic_init(void)
+{
+ struct mpic *mpic;
+ struct device_node *np;
+ struct device_node *cp = NULL;
+ unsigned int cirq;
+ unsigned long intack = 0;
+ const u32 *prop = NULL;
+
+ np = of_find_node_by_type(NULL, "open-pic");
+ if (!np) {
+ pr_err("Could not find open-pic node\n");
+ return;
+ }
+
+ mpic = mpic_alloc(np, pci_membase, 0, 16, 256, " OpenPIC ");
+
+ BUG_ON(mpic == NULL);
+ of_node_put(np);
+
+ mpic_assign_isu(mpic, 0, pci_membase + 0x10000);
+
+ mpic_init(mpic);
+
+ cp = of_find_compatible_node(NULL, NULL, "chrp,iic");
+ if (cp == NULL) {
+ pr_warn("mvme5100_pic_init: couldn't find i8259\n");
+ return;
+ }
+
+ cirq = irq_of_parse_and_map(cp, 0);
+ if (cirq == NO_IRQ) {
+ pr_warn("mvme5100_pic_init: no cascade interrupt?\n");
+ return;
+ }
+
+ np = of_find_compatible_node(NULL, "pci", "mpc10x-pci");
+ if (np) {
+ prop = of_get_property(np, "8259-interrupt-acknowledge", NULL);
+
+ if (prop)
+ intack = prop[0];
+
+ of_node_put(np);
+ }
+
+ if (intack)
+ pr_debug("mvme5100_pic_init: PCI 8259 intack at 0x%016lx\n",
+ intack);
+
+ i8259_init(cp, intack);
+ of_node_put(cp);
+ irq_set_chained_handler(cirq, mvme5100_8259_cascade);
+}
+
+static int __init mvme5100_add_bridge(struct device_node *dev)
+{
+ const int *bus_range;
+ int len;
+ struct pci_controller *hose;
+ unsigned short devid;
+
+ pr_info("Adding PCI host bridge %s\n", dev->full_name);
+
+ bus_range = of_get_property(dev, "bus-range", &len);
+
+ hose = pcibios_alloc_controller(dev);
+ if (hose == NULL)
+ return -ENOMEM;
+
+ hose->first_busno = bus_range ? bus_range[0] : 0;
+ hose->last_busno = bus_range ? bus_range[1] : 0xff;
+
+ setup_indirect_pci(hose, 0xfe000cf8, 0xfe000cfc, 0);
+
+ pci_process_bridge_OF_ranges(hose, dev, 1);
+
+ early_read_config_word(hose, 0, 0, PCI_DEVICE_ID, &devid);
+
+ if (devid != PCI_DEVICE_ID_MOTOROLA_HAWK) {
+ pr_err("HAWK PHB not present?\n");
+ return 0;
+ }
+
+ early_read_config_dword(hose, 0, 0, PCI_BASE_ADDRESS_1, &pci_membase);
+
+ if (pci_membase == 0) {
+ pr_err("HAWK PHB mibar not correctly set?\n");
+ return 0;
+ }
+
+ pr_info("mvme5100_pic_init: pci_membase: %x\n", pci_membase);
+
+ return 0;
+}
+
+static struct of_device_id mvme5100_of_bus_ids[] __initdata = {
+ { .compatible = "hawk-bridge", },
+ {},
+};
+
+/*
+ * Setup the architecture
+ */
+static void __init mvme5100_setup_arch(void)
+{
+ struct device_node *np;
+
+ if (ppc_md.progress)
+ ppc_md.progress("mvme5100_setup_arch()", 0);
+
+ for_each_compatible_node(np, "pci", "hawk-pci")
+ mvme5100_add_bridge(np);
+
+ restart = ioremap(BOARD_MODRST_REG, 4);
+}
+
+
+static void mvme5100_show_cpuinfo(struct seq_file *m)
+{
+ seq_puts(m, "Vendor\t\t: Motorola/Emerson\n");
+ seq_puts(m, "Machine\t\t: MVME5100\n");
+}
+
+static void mvme5100_restart(char *cmd)
+{
+
+ local_irq_disable();
+ mtmsr(mfmsr() | MSR_IP);
+
+ out_8((u_char *) restart, 0x01);
+
+ while (1)
+ ;
+}
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init mvme5100_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "MVME5100");
+}
+
+static int __init probe_of_platform_devices(void)
+{
+
+ of_platform_bus_probe(NULL, mvme5100_of_bus_ids, NULL);
+ return 0;
+}
+
+machine_device_initcall(mvme5100, probe_of_platform_devices);
+
+define_machine(mvme5100) {
+ .name = "MVME5100",
+ .probe = mvme5100_probe,
+ .setup_arch = mvme5100_setup_arch,
+ .init_IRQ = mvme5100_pic_init,
+ .show_cpuinfo = mvme5100_show_cpuinfo,
+ .get_irq = mpic_get_irq,
+ .restart = mvme5100_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
^ permalink raw reply related
* [PATCHv5 2/7] ppc/cell: use get_unused_fd_flags(0) instead of get_unused_fd()
From: Yann Droneaud @ 2014-01-05 20:36 UTC (permalink / raw)
To: Jeremy Kerr, Arnd Bergmann, Benjamin Herrenschmidt,
Paul Mackerras
Cc: Yann Droneaud, cbe-oss-dev, linux-kernel, Al Viro, Andrew Morton,
linuxppc-dev
In-Reply-To: <cover.1388952061.git.ydroneaud@opteya.com>
Macro get_unused_fd() is used to allocate a file descriptor with
default flags. Those default flags (0) can be "unsafe":
O_CLOEXEC must be used by default to not leak file descriptor
across exec().
Instead of macro get_unused_fd(), function get_unused_fd_flags()
(or anon_inode_getfd()) should be used with flags given by userspace.
If not possible, flags should be set to O_CLOEXEC to provide userspace
with a default safe behavor.
In a further patch, get_unused_fd() will be removed so that new code
start using get_unused_fd_flags() (or anon_inode_getfd()) with correct
flags.
This patch replaces calls to get_unused_fd() with equivalent call to
get_unused_fd_flags(0) to preserve current behavor for existing code.
The hard coded flag value (0) should be reviewed on a per-subsystem
basis, and, if possible, set to O_CLOEXEC.
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
Link: http://lkml.kernel.org/r/cover.1388952061.git.ydroneaud@opteya.com
---
arch/powerpc/platforms/cell/spufs/inode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/cell/spufs/inode.c b/arch/powerpc/platforms/cell/spufs/inode.c
index 87ba7cf99cd7..51effcec30d8 100644
--- a/arch/powerpc/platforms/cell/spufs/inode.c
+++ b/arch/powerpc/platforms/cell/spufs/inode.c
@@ -301,7 +301,7 @@ static int spufs_context_open(struct path *path)
int ret;
struct file *filp;
- ret = get_unused_fd();
+ ret = get_unused_fd_flags(0);
if (ret < 0)
return ret;
@@ -518,7 +518,7 @@ static int spufs_gang_open(struct path *path)
int ret;
struct file *filp;
- ret = get_unused_fd();
+ ret = get_unused_fd_flags(0);
if (ret < 0)
return ret;
--
1.8.4.2
^ permalink raw reply related
* [PATCH v5 0/7] Getting rid of get_unused_fd() / enable close-on-exec
From: Yann Droneaud @ 2014-01-05 20:36 UTC (permalink / raw)
To: Tony Luck, Fenghua Yu, Al Viro, linux-ia64, Jeremy Kerr,
Arnd Bergmann, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev, cbe-oss-dev, linux-fsdevel, Eric Paris,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Andrew Morton
Cc: Yann Droneaud, Ulrich Drepper, linux-kernel
Hi,
Please find the fifth revision of my patchset to remove get_unused_fd()
macro in order to help subsystems to use get_unused_fd_flags() (or
anon_inode_getfd()) with flags either provided by the userspace or
set to O_CLOEXEC by default where appropriate.
Without get_unused_fd() macro, more subsystems are likely to use
get_unused_fd_flags() (or anon_inode_getfd()) and be teached to
provide an API that let userspace choose the opening flags
of the file descriptor.
Not allowing userspace to provide the "open" flags or not using O_CLOEXEC
by default should be considered bad practice from security point of view:
in most case O_CLOEXEC must be used to not leak file descriptor across
exec().
Not allowing userspace to atomically set close-on-exec flag and not using
O_CLOEXEC should be avoided to protect multi-threaded program
from race condition when it tried to set close-on-exec flag using
fcntl(fd, F_SETFD, FD_CLOEXEC) after opening the file descriptor.
Example:
int fd;
int ret;
fd = open(filename, O_RDONLY);
if (fd < 0) {
perror("open");
return -1;
}
/*
* window opened for another thread to call fork(),
* then the new process can call exec() at any time
* and the file descriptor would be inherited
*/
ret = fcntl(fd, F_SETFD, FD_CLOEXEC)
if (ret < 0) {
perror("fnctl()");
close(fd);
return -1;
}
vs.:
int fd;
fd = open(filaneme, O_RDONLY | O_CLOEXEC);
if (fd < 0) {
perror("open");
return -1;
}
Using O_CLOEXEC by default when flags are not (eg. cannot be) provided
by userspace is the safest bet as it allows userspace to choose, if, when
and where the file descriptor is going to be inherited across exec():
userspace is free to call fcntl() to remove FD_CLOEXEC flag in the child
process that will call exec().
Unfortunately, O_CLOEXEC cannot be made the default for most existing system
calls as it's not the default behavior for POSIX / Unix. Reader interested
in this issue could have a look at "Ghosts of Unix past, part 2: Conflated
designs" [1] article by Neil Brown.
FAQ:
- Why do one want close-on-exec ?
Setting close-on-exec flag on file descriptor ensure it won't be inherited
silently by child, child of child, etc. when executing another program.
If the file descriptor is not closed, some kernel resources can be locked
until the last process with the opened file descriptor exit.
If the file descriptor is not closed, this can lead to a security issue,
eg. making resources available to a less privileged program allowing
information leak and/or deny of service.
- Why do one need atomic close-on-exec ?
Even if it's possible to set close-on-exec flag through call to fcntl()
as shown previously, it introduces a race condition in multi-threaded
process, where a thread call fork() / exec() while another thread
is between call to open() and fcntl().
Additionally, using close-on-exec free the programmer from tracking manually
which file descriptor is to close in a child before calling exec():
in a program using multiple third-party libraries, it's difficult to know
which file descriptor must be closed.
AFAIK, while there's a atexit(), pthread_atfork(), there's no atexec()
userspace function in libc to allow libraries to register a handler in
order to close its opened file descriptor before exec().
- Why default to close-on-exec ?
Some kernel interfaces don't allow userspace to pass a O_CLOEXEC-like
flag when creating a new file descriptor.
In such cases, if possible (see below), O_CLOEXEC must be made
the default so that userspace doesn't have to call fcntl()
which, as demonstrated previously, is open to race condition in
multi-threaded program.
- How to choose between flag 0 or O_CLOEXEC in call to
get_unused_fd_flags() (or anon_inode_getfd()) ?
Short: Will it break existing application ? Will it break kernel ABI ?
If answer is no, use O_CLOEXEC.
If answer is yes, use 0.
Long: If userspace expect to retrieve a file descriptor with plain
old Unix(tm) semantics, O_CLOEXEC must not be the default, as it
could break some applications expecting that the file descriptor
will be inherited across exec().
But for some subsystems, such as InfiniBand, KVM, VFIO, it makes
no sense to have file descriptors inherited across exec() since
those are tied to resources that will vanish when a another program
will replace the current one by mean of exec(), so it's safe to use
O_CLOEXEC in such cases.
For others, like XFS, the file descriptor is retrieved by one
program and will be used by a different program, executed as a
child. In this case, setting O_CLOEXEC would break existing
application which do not expect to have to call fcntl(fd,
F_SETFD, 0) to make it available across exec().
If file descriptor created by a subsystem is not tied to the
current process resources, it's likely legal to use it in a
different process context, thus O_CLOEXEC must not be the default.
If one, as a subsystem maintainer, cannot tell for sure that
no userspace program ever rely current behavior, eg. file descriptor
being inherited across exec(), then the default flag *must*
be kept 0 to not break application.
- This subsystem cannot be turned to use O_CLOEXEC by default:
If O_CLOEXEC cannot be made the default, it would be interesting
to think to extend the API to have a (set of) function(s) taking
a flag parameter so that userspace can atomically request close-on-exec
if it need it (and it should need it).
- Background:
One might want to read "Secure File Descriptor Handling" [2] by
Ulrich Drepper who is responsible of adding O_CLOEXEC flag on open(),
and flags alike on other syscalls.
One might also want to read PEP-446 "Make newly created file descriptors
non-inheritable" [3] by Victor Stinner since it has lot more background
information on file descriptor leaking.
One also like to read "Excuse me son, but your code is leaking !!!" [4]
by Dan Walsh for advice.
[1] http://lwn.net/Articles/412131/
[2] http://udrepper.livejournal.com/20407.html
[3] http://www.python.org/dev/peps/pep-0446/
[4] http://danwalsh.livejournal.com/53603.html
- Statistics:
In linux-next tag 20131224, they're currently:
- 32 calls to fd_install()
with one call part of anon_inode_getfd()
- 24 calls to get_unused_fd_flags()
with one call part of anon_inode_getfd()
with another part of get_unused_fd() macro
- 11 calls to anon_inode_getfd()
- 8 calls to anon_inode_getfile()
with one call part of anon_inode_getfd()
- 7 calls to get_unused_fd()
Changes from patchset v4 [PATCHSETv4]:
- rewrote cover letter following discussion with perf maintainer.
Thanks to Peter Zijlstra.
- modified a bit some commit messages.
- events: use get_unused_fd_flags(0) instead of get_unused_fd()
DROPPED: replaced by following patch
- perf: introduce a flag to enable close-on-exec in perf_event_open()
NEW: instead of hard coding the flags to 0, this patch
allows userspace to specify close-on-exec flag.
- fanotify: use get_unused_fd_flags(0) instead of get_unused_fd()
DROPPED: replaced by following patch
- fanotify: enable close-on-exec on events' fd when requested in
fanotify_init()
NEW: instead of hard coding the flags to 0, this patch
enable close-on-exec if userspace request it.
Changes from patchset v3 [PATCHSETv3]:
- industrialio: use anon_inode_getfd() with O_CLOEXEC flag
DROPPED: applied upstream
Changes from patchset v2 [PATCHSETv2]:
- android/sw_sync: use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd()
DROPPED: applied upstream
- android/sync: use get_unused_fd_flags(O_CLOEXEC) instead of get_unused_fd()
DROPPED: applied upstream
- vfio: use get_unused_fd_flags(0) instead of get_unused_fd()
DROPPED: applied upstream.
Additionally subsystem maintainer applied another patch on top
to set the flags to O_CLOEXEC.
- industrialio: use anon_inode_getfd() with O_CLOEXEC flag
NEW: propose to use O_CLOEXEC as default flag.
Changes from patchset v1 [PATCHSETv1]:
- explicitly added subsystem maintainers as mail recepients.
- infiniband: use get_unused_fd_flags(0) instead of get_unused_fd()
DROPPED: subsystem maintainer applied another patch
using get_unused_fd_flags(O_CLOEXEC) as suggested.
- android/sw_sync: use get_unused_fd_flags(0) instead of get_unused_fd()
MODIFIED: use get_unused_fd_flags(O_CLOEXEC) as suggested
- android/sync: use get_unused_fd_flags(0) instead of get_unused_fd()
MODIFIED: use get_unused_fd_flags(O_CLOEXEC) as suggested
- xfs: use get_unused_fd_flags(0) instead of get_unused_fd()
DROPPED: applied asis by subsystem maintainer.
- sctp: use get_unused_fd_flags(0) instead of get_unused_fd()
DROPPED: applied asis by subsystem maintainer.
Links:
[PATCHSETv4]
http://lkml.kernel.org/r/cover.1383121137.git.ydroneaud@opteya.com
[PATCHSETv3]
http://lkml.kernel.org/r/cover.1378460926.git.ydroneaud@opteya.com
[PATCHSETv2]
http://lkml.kernel.org/r/cover.1376327678.git.ydroneaud@opteya.com
[PATCHSETv1]
http://lkml.kernel.org/r/cover.1372777600.git.ydroneaud@opteya.com
PS: Happy new (gregorian calendar's) year 2014 and best wishes ;)
Yann Droneaud (7):
ia64: use get_unused_fd_flags(0) instead of get_unused_fd()
ppc/cell: use get_unused_fd_flags(0) instead of get_unused_fd()
binfmt_misc: use get_unused_fd_flags(0) instead of get_unused_fd()
file: use get_unused_fd_flags(0) instead of get_unused_fd()
fanotify: enable close-on-exec on events' fd when requested in
fanotify_init()
perf: introduce a flag to enable close-on-exec in perf_event_open()
file: remove macro get_unused_fd()
arch/ia64/kernel/perfmon.c | 2 +-
arch/powerpc/platforms/cell/spufs/inode.c | 4 ++--
fs/binfmt_misc.c | 2 +-
fs/file.c | 2 +-
fs/notify/fanotify/fanotify_user.c | 2 +-
include/linux/file.h | 1 -
include/uapi/linux/perf_event.h | 1 +
kernel/events/core.c | 12 +++++++++---
8 files changed, 16 insertions(+), 10 deletions(-)
--
1.8.4.2
^ permalink raw reply
* [PATCH] ASoC: fsl_ssi: Fix printing return code on clk error
From: Alexander Shiyan @ 2014-01-05 6:21 UTC (permalink / raw)
To: alsa-devel
Cc: Alexander Shiyan, Liam Girdwood, Takashi Iwai, Timur Tabi,
Jaroslav Kysela, Mark Brown, linuxppc-dev
Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
---
sound/soc/fsl/fsl_ssi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 2101fc5..3d74477a 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -1192,7 +1192,8 @@ static int fsl_ssi_probe(struct platform_device *pdev)
*/
ssi_private->baudclk = devm_clk_get(&pdev->dev, "baud");
if (IS_ERR(ssi_private->baudclk))
- dev_warn(&pdev->dev, "could not get baud clock: %d\n", ret);
+ dev_warn(&pdev->dev, "could not get baud clock: %d\n",
+ PTR_ERR(ssi_private->baudclk));
else
clk_prepare_enable(ssi_private->baudclk);
--
1.8.3.2
^ permalink raw reply related
* Re: drivers/tty: ehv_bytechan fails to build as a module
From: Guenter Roeck @ 2014-01-04 19:15 UTC (permalink / raw)
To: Anton Blanchard; +Cc: gregkh, dvaleev, paulus, linuxppc-dev, timur
In-Reply-To: <20131209160310.7f81a1bc@kryten>
On Mon, Dec 09, 2013 at 04:03:10PM +1100, Anton Blanchard wrote:
> ehv_bytechan is marked tristate but fails to build as a module:
>
> drivers/tty/ehv_bytechan.c:363:1: error: type defaults to ‘int’ in declaration of ‘console_initcall’ [-Werror=implicit-int]
>
> It doesn't make much sense for a console driver to be built as
> a module, so change it to a bool.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
>
Any comments on this patch ? The problem still causes powerpc:allmodconfig to
fail.
Guenter
> ---
>
>
> Index: b/drivers/tty/Kconfig
> ===================================================================
> --- a/drivers/tty/Kconfig
> +++ b/drivers/tty/Kconfig
> @@ -366,7 +366,7 @@ config TRACE_SINK
> "Trace data router for MIPI P1149.7 cJTAG standard".
>
> config PPC_EPAPR_HV_BYTECHAN
> - tristate "ePAPR hypervisor byte channel driver"
> + bool "ePAPR hypervisor byte channel driver"
> depends on PPC
> select EPAPR_PARAVIRT
> help
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox