* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2014-04-09 7:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tejun Heo, Greg Kroah-Hartman, linuxppc-dev, Linux Kernel list
Hi Linus !
Here are a few more powerpc things for you.
So you'll find here the conversion of the two new firmware sysfs
interfaces to the new API for self-removing files that Greg and Tejun
introduced, so they can finally remove the old one.
I'm also reverting the hwmon driver for powernv. I shouldn't have merged
it, I got a bit carried away here. I hadn't realized it was never CCed
to the relevant maintainer(s) and list(s), and happens to have some
issues so I'm taking it out and it will come back via the proper
channels.
The rest is a bunch of LE fixes (argh, some of the new stuff was broken
on LE, I really need to start testing LE myself !) and various random
fixes here and there.
Finally one bit that's not strictly a fix, which is the HVC OPAL change
to "kick" the HVC thread when the firmware tells us there is new
incoming data. I don't feel like waiting for this one, it's simple
enough, and it makes a big difference in console responsiveness which is
good for my nerves.
Cheers,
Ben.
The following changes since commit 18a1a7a1d862ae0794a0179473d08a414dd49234:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2014-04-06 08:11:57 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to cc4f265ad9a37bdb1846c45eebe454c382f31d67:
powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self (2014-04-09 13:51:50 +1000)
----------------------------------------------------------------
Aneesh Kumar K.V (1):
powerpc/mm: NUMA pte should be handled via slow path in get_user_pages_fast()
Anton Blanchard (3):
powerpc/powernv: Fix endian issues with OPAL async code
powerpc/powernv: Fix endian issues with sensor code
powerpc: Add lq/stq emulation
Benjamin Herrenschmidt (8):
powerpc: Adjust CPU_FTR_SMT on all platforms
powerpc: Make boot_cpuid common between 32 and 64-bit
powerpc/prom: early_init_dt_scan_cpus() updates cpu features only once
powerpc/ppc64: Gracefully handle early interrupts
powerpc/ppc64: Do not turn AIL (reloc-on interrupts) too early
powerpc/powernv: Add opal_notifier_unregister() and export to modules
tty/hvc_opal: Kick the HVC thread on OPAL console events
Revert "powerpc/powernv: hwmon driver for power values, fan rpm and temperature"
Greg Kurz (1):
powerpc/le: Enable RTAS events support
Joe Perches (1):
powerpc: Convert last uses of __FUNCTION__ to __func__
Joel Stanley (2):
powerpc/powernv: Add OPAL message log interface
powerpc/powernv: Add invalid OPAL call
Li Zhong (1):
powerpc: Use of_node_init() for the fakenode in msi_bitmap.c
Mahesh Salgaonkar (1):
powerpc/book3s: Fix mc_recoverable_range buffer overrun issue.
Michael Neuling (3):
powerpc/tm: Disable IRQ in tm_recheckpoint
powerpc: Remove dead code in sycall entry
powerpc/opal: Add missing include
Michael Wang (1):
power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
Monam Agarwal (1):
arch/powerpc: Use RCU_INIT_POINTER(x, NULL) in platforms/cell/spu_syscalls.c
Stephen Chivers (1):
powerpc: Correct emulated mtfsf instruction
Stewart Smith (1):
powerpc/powernv Adapt opal-elog and opal-dump to new sysfs_remove_file_self
Tony Breeds (1):
powerpc/le: Avoid creatng R_PPC64_TOCSAVE relocations for modules.
arch/powerpc/Makefile | 1 +
arch/powerpc/include/asm/emulated_ops.h | 1 +
arch/powerpc/include/asm/opal.h | 19 +-
arch/powerpc/include/asm/rtas.h | 127 ++++--
arch/powerpc/kernel/align.c | 52 ++-
arch/powerpc/kernel/cpu_setup_power.S | 2 -
arch/powerpc/kernel/exceptions-64s.S | 8 -
arch/powerpc/kernel/paca.c | 3 +-
arch/powerpc/kernel/process.c | 34 +-
arch/powerpc/kernel/prom.c | 58 +--
arch/powerpc/kernel/rtas.c | 15 +-
arch/powerpc/kernel/rtasd.c | 24 +-
arch/powerpc/kernel/setup-common.c | 3 +
arch/powerpc/kernel/setup_32.c | 2 -
arch/powerpc/kernel/setup_64.c | 28 +-
arch/powerpc/kernel/signal_32.c | 2 +
arch/powerpc/kernel/signal_64.c | 2 +
arch/powerpc/kernel/tm.S | 2 +-
arch/powerpc/kernel/traps.c | 1 +
arch/powerpc/math-emu/mtfsf.c | 58 ++-
arch/powerpc/mm/gup.c | 13 +
arch/powerpc/mm/numa.c | 15 +
arch/powerpc/platforms/cell/spu_syscalls.c | 2 +-
arch/powerpc/platforms/powernv/Makefile | 1 +
arch/powerpc/platforms/powernv/opal-async.c | 7 +-
arch/powerpc/platforms/powernv/opal-dump.c | 9 +-
arch/powerpc/platforms/powernv/opal-elog.c | 9 +-
arch/powerpc/platforms/powernv/opal-msglog.c | 120 ++++++
arch/powerpc/platforms/powernv/opal-sensor.c | 6 +-
arch/powerpc/platforms/powernv/opal-sysparam.c | 4 +-
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
arch/powerpc/platforms/powernv/opal.c | 59 ++-
arch/powerpc/platforms/pseries/io_event_irq.c | 6 +-
arch/powerpc/platforms/pseries/nvram.c | 11 +-
arch/powerpc/platforms/pseries/ras.c | 17 +-
arch/powerpc/sysdev/msi_bitmap.c | 2 +-
drivers/hwmon/Kconfig | 8 -
drivers/hwmon/Makefile | 1 -
drivers/hwmon/ibmpowernv.c | 529 -------------------------
drivers/tty/hvc/hvc_opal.c | 22 +-
40 files changed, 546 insertions(+), 738 deletions(-)
create mode 100644 arch/powerpc/platforms/powernv/opal-msglog.c
delete mode 100644 drivers/hwmon/ibmpowernv.c
^ permalink raw reply
* Re: [PATCH v3 2/3] devcietree: bindings: add some MFD Keymile FPGAs
From: Valentin Longchamp @ 2014-04-09 6:39 UTC (permalink / raw)
To: Scott Wood; +Cc: devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1397004291.32034.327.camel@snotra.buserror.net>
On 04/09/2014 02:44 AM, Scott Wood wrote:
> On Tue, 2014-03-25 at 14:41 +0100, Valentin Longchamp wrote:
>> These are the bindings for 2 MFD devices used on some of the Keymile boards.
>> The first one is the chassis managmenet bfticu FPGA.
>> The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
>> These FPGAs are used in the kmcoge4 board.
>>
>> This patch also add KEYMILE to the vendor-prefixes.
>>
>> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>>
>> ---
>> Changes in v3:
>> - add a patch with the bindings for the KEYMILE FPGAs
>>
>> Changes in v2: None
>>
>> Documentation/devicetree/bindings/mfd/bfticu.txt | 26 ++++++++++++++++++++++
>> Documentation/devicetree/bindings/mfd/qriox.txt | 17 ++++++++++++++
>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>> 3 files changed, 44 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
>> create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt b/Documentation/devicetree/bindings/mfd/bfticu.txt
>> new file mode 100644
>> index 0000000..92de32e
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
>> @@ -0,0 +1,26 @@
>> +KEYMILE bfticu Chassis Management FPGA
>> +
>> +The bfticu is a multifunction device that manages the whole chassis.
>> +Its main functionality is to collect IRQs from the whole chassis and signals
>> +them to a single controller.
>> +
>> +Required properties:
>> +- compatible: "keymile,bfticu"
>> +- interrupt-controller: the bfticu FPGA is an interrupt controller
>> +- interrupts: the main IRQ line to signal the collected IRQs
>> +- #interrupt-cells : is 2
>> + - The 1st cell is the local IRQ number on the bfticu
>> + - The 2nd cell is the type of the IRQ (IRQ_TYPE_xxx)
>
> Device tree bindings should not depend on the content of Linux headers.
> One is stable ABI, and the other isn't.
>
> If you want you can make the values the same for convenience, as is done
> by IPIC, CPM PIC, etc -- but the values need to be explicitly stated in
> the binding. It'll still break if the Linux values change (so it may
> not be a good idea to try to keep the values the same), but at least the
> fix would be in Linux code rather than an ABI change.
OK. I will then explicitly give the list of the values.
>
>> diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt b/Documentation/devicetree/bindings/mfd/qriox.txt
>> new file mode 100644
>> index 0000000..f301e2d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/qriox.txt
>> @@ -0,0 +1,17 @@
>> +KEYMILE qrio Board Control CPLD
>> +
>> +The qrio is a multifunction device that controls the KEYMILE boards based on
>> +the kmp204x design.
>> +It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable
>> +GPIO blocks.
>> +
>> +Required properties:
>> +- compatible: "keymile,qriox"
>> +- reg: access on the parent local bus (chip select, offset in chip select, size)
>> +
>> +Example:
>> +
>> + board-control@1,0 {
>> + compatible = "keymile,qriox";
>> + reg = <1 0 0x80>;
>> + };
>
> If it has GPIO blocks, shouldn't it be using the GPIO binding?
>
You are right it should. But this is currently being reworked (also in HW) and
that's why I left it out completely, instead of submitting something subject to
change.
Valentin
^ permalink raw reply
* Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
From: Madhavan Srinivasan @ 2014-04-09 1:44 UTC (permalink / raw)
To: David Miller, dave.hansen
Cc: linux-arch, riel, rusty, peterz, x86, linux-kernel, linux-mm, ak,
paulus, mgorman, akpm, linuxppc-dev, mingo, kirill.shutemov
In-Reply-To: <20140404.135056.2103520199689146670.davem@davemloft.net>
On Friday 04 April 2014 11:20 PM, David Miller wrote:
> From: Dave Hansen <dave.hansen@intel.com>
> Date: Fri, 04 Apr 2014 09:18:43 -0700
>
>> On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote:
>>> This patch creates infrastructure to move the FAULT_AROUND_ORDER
>>> to arch/ using Kconfig. This will enable architecture maintainers
>>> to decide on suitable FAULT_AROUND_ORDER value based on
>>> performance data for that architecture. Patch also adds
>>> FAULT_AROUND_ORDER Kconfig element in arch/X86.
>>
>> Please don't do it this way.
>>
>> In mm/Kconfig, put
>>
>> config FAULT_AROUND_ORDER
>> int
>> default 1234 if POWERPC
>> default 4
>>
>> The way you have it now, every single architecture that needs to enable
>> this has to go put that in their Kconfig. That's madness. This way,
>> you only put it in one place, and folks only have to care if they want
>> to change the default to be something other than 4.
>
> It looks more like it's necessary only to change the default, not
> to enable it. Unless I read his patch wrong...
>
Yes. With current patch, you only need to change the default by which
you enable it.
With regards
Maddy
>
^ permalink raw reply
* Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
From: Madhavan Srinivasan @ 2014-04-09 1:32 UTC (permalink / raw)
To: Dave Hansen, linux-kernel, linuxppc-dev, linux-mm, linux-arch,
x86
Cc: riel, ak, peterz, rusty, paulus, mgorman, akpm, mingo,
kirill.shutemov
In-Reply-To: <533EDB63.8090909@intel.com>
On Friday 04 April 2014 09:48 PM, Dave Hansen wrote:
> On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote:
>> This patch creates infrastructure to move the FAULT_AROUND_ORDER
>> to arch/ using Kconfig. This will enable architecture maintainers
>> to decide on suitable FAULT_AROUND_ORDER value based on
>> performance data for that architecture. Patch also adds
>> FAULT_AROUND_ORDER Kconfig element in arch/X86.
>
> Please don't do it this way.
>
> In mm/Kconfig, put
>
> config FAULT_AROUND_ORDER
> int
> default 1234 if POWERPC
> default 4
>
> The way you have it now, every single architecture that needs to enable
> this has to go put that in their Kconfig. That's madness. This way,
I though about it and decided not to do this way because, in future,
sub platforms of the architecture may decide to change the values. Also,
adding an if line for each architecture with different sub platforms
oring to it will look messy.
With regards
Maddy
> you only put it in one place, and folks only have to care if they want
> to change the default to be something other than 4.
>
^ permalink raw reply
* Re: [PATCH V2 1/2] mm: move FAULT_AROUND_ORDER to arch/
From: Madhavan Srinivasan @ 2014-04-09 1:14 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: linux-arch, riel, rusty, peterz, x86, linux-kernel, linux-mm, ak,
paulus, mgorman, akpm, linuxppc-dev, mingo, kirill.shutemov
In-Reply-To: <20140404131747.GA23076@node.dhcp.inet.fi>
On Friday 04 April 2014 06:47 PM, Kirill A. Shutemov wrote:
> On Fri, Apr 04, 2014 at 11:57:14AM +0530, Madhavan Srinivasan wrote:
>> Kirill A. Shutemov with faultaround patchset introduced
>> vm_ops->map_pages() for mapping easy accessible pages around
>> fault address in hope to reduce number of minor page faults.
>>
>> This patch creates infrastructure to move the FAULT_AROUND_ORDER
>> to arch/ using Kconfig. This will enable architecture maintainers
>> to decide on suitable FAULT_AROUND_ORDER value based on
>> performance data for that architecture. Patch also adds
>> FAULT_AROUND_ORDER Kconfig element in arch/X86.
>>
>> Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
>> ---
>> arch/x86/Kconfig | 4 ++++
>> include/linux/mm.h | 9 +++++++++
>> mm/memory.c | 12 +++++-------
>> 3 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 9c0a657..5833f22 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1177,6 +1177,10 @@ config DIRECT_GBPAGES
>> support it. This can improve the kernel's performance a tiny bit by
>> reducing TLB pressure. If in doubt, say "Y".
>>
>> +config FAULT_AROUND_ORDER
>> + int
>> + default "4"
>> +
>> # Common NUMA Features
>> config NUMA
>> bool "Numa Memory Allocation and Scheduler Support"
>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>> index 0bd4359..b93c1c3 100644
>> --- a/include/linux/mm.h
>> +++ b/include/linux/mm.h
>> @@ -26,6 +26,15 @@ struct file_ra_state;
>> struct user_struct;
>> struct writeback_control;
>>
>> +/*
>> + * Fault around order is a control knob to decide the fault around pages.
>> + * Default value is set to 0UL (disabled), but the arch can override it as
>> + * desired.
>> + */
>> +#ifndef CONFIG_FAULT_AROUND_ORDER
>> +#define CONFIG_FAULT_AROUND_ORDER 0
>> +#endif
>> +
>
> I don't think it should be in header file: nobody except mm/memory.c cares.
> Just put it instead '#define FAULT_AROUND_ORDER'.
>
Ok. Will do this change.
>> #ifndef CONFIG_NEED_MULTIPLE_NODES /* Don't use mapnrs, do it properly */
>> extern unsigned long max_mapnr;
>>
>> diff --git a/mm/memory.c b/mm/memory.c
>> index b02c584..22a4a89 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -3358,10 +3358,8 @@ void do_set_pte(struct vm_area_struct *vma, unsigned long address,
>> update_mmu_cache(vma, address, pte);
>> }
>>
>> -#define FAULT_AROUND_ORDER 4
>> -
>> #ifdef CONFIG_DEBUG_FS
>> -static unsigned int fault_around_order = FAULT_AROUND_ORDER;
>> +static unsigned int fault_around_order = CONFIG_FAULT_AROUND_ORDER;
>>
>> static int fault_around_order_get(void *data, u64 *val)
>> {
>> @@ -3371,7 +3369,7 @@ static int fault_around_order_get(void *data, u64 *val)
>>
>> static int fault_around_order_set(void *data, u64 val)
>> {
>> - BUILD_BUG_ON((1UL << FAULT_AROUND_ORDER) > PTRS_PER_PTE);
>> + BUILD_BUG_ON((1UL << CONFIG_FAULT_AROUND_ORDER) > PTRS_PER_PTE);
>> if (1UL << val > PTRS_PER_PTE)
>> return -EINVAL;
>> fault_around_order = val;
>> @@ -3406,14 +3404,14 @@ static inline unsigned long fault_around_pages(void)
>> {
>> unsigned long nr_pages;
>>
>> - nr_pages = 1UL << FAULT_AROUND_ORDER;
>> + nr_pages = 1UL << CONFIG_FAULT_AROUND_ORDER;
>> BUILD_BUG_ON(nr_pages > PTRS_PER_PTE);
>> return nr_pages;
>> }
>>
>> static inline unsigned long fault_around_mask(void)
>> {
>> - return ~((1UL << (PAGE_SHIFT + FAULT_AROUND_ORDER)) - 1);
>> + return ~((1UL << (PAGE_SHIFT + CONFIG_FAULT_AROUND_ORDER)) - 1);
>> }
>> #endif
>>
>> @@ -3471,7 +3469,7 @@ static int do_read_fault(struct mm_struct *mm, struct vm_area_struct *vma,
>> * if page by the offset is not ready to be mapped (cold cache or
>> * something).
>> */
>> - if (vma->vm_ops->map_pages) {
>> + if ((vma->vm_ops->map_pages) && (fault_around_pages() > 1)) {
>
> if (vma->vm_ops->map_pages && fault_around_pages()) {
>
For a fault around value of 0, fault_around_pages() will return 1 and
that is reason for checking it greater than 1. Also, using debug fs,
fault around value can be zeroed.
With regards
Maddy
>> pte = pte_offset_map_lock(mm, pmd, address, &ptl);
>> do_fault_around(vma, address, pte, pgoff, flags);
>> if (!pte_same(*pte, orig_pte))
>> --
>> 1.7.10.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH] powerpc/qe: Setup clock source for TDM
From: Scott Wood @ 2014-04-09 1:05 UTC (permalink / raw)
To: Xie Xiaobo; +Cc: linuxppc-dev
In-Reply-To: <1395133745-5557-1-git-send-email-X.Xie@freescale.com>
On Tue, 2014-03-18 at 17:09 +0800, Xie Xiaobo wrote:
> diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
> index 238a07b..9a9f733 100644
> --- a/arch/powerpc/sysdev/qe_lib/qe.c
> +++ b/arch/powerpc/sysdev/qe_lib/qe.c
> @@ -1,5 +1,6 @@
> /*
> - * Copyright (C) 2006-2010 Freescale Semiconductor, Inc. All rights reserved.
> + * Copyright (C) 2006-2010, 2014 Freescale Semiconductor, Inc.
> + * All rights reserved.
> *
> * Authors: Shlomi Gridish <gridish@freescale.com>
> * Li Yang <leoli@freescale.com>
> @@ -240,6 +241,12 @@ enum qe_clock qe_clock_source(const char *source)
> if (strcasecmp(source, "none") == 0)
> return QE_CLK_NONE;
>
> + if (strcasecmp(source, "tsync_pin") == 0)
> + return QE_TSYNC_PIN;
> +
> + if (strcasecmp(source, "rsync_pin") == 0)
> + return QE_RSYNC_PIN;
> +
Binding update?
> @@ -210,3 +210,774 @@ int ucc_set_qe_mux_rxtx(unsigned int ucc_num, enum qe_clock clock,
>
> return 0;
> }
> +
> +/* tdm_num: TDM A-H port num is 0-7 */
> +int ucc_set_tdm_rxtx_clk(u32 tdm_num, enum qe_clock clock,
> + enum comm_dir mode)
> +{
> + u32 clock_bits, shift;
> + struct qe_mux *qe_mux_reg;
> + __be32 __iomem *cmxs1cr;
> +
> + clock_bits = 0;
> + qe_mux_reg = &qe_immr->qmx;
> +
> + if ((tdm_num > 7 || tdm_num < 0))
> + return -EINVAL;
> +
> + /* The communications direction must be RX or TX */
> + if (!((mode == COMM_DIR_RX) || (mode == COMM_DIR_TX)))
> + return -EINVAL;
Unnecessary parentheses.
tdm_num cannot be < 0 as it is unsigned.
Use a symbolic name rather than "7".
> + switch (mode) {
> + case COMM_DIR_RX:
> + switch (tdm_num) {
> + case 0:
> + switch (clock) {
> + case QE_BRG3:
> + clock_bits = 1;
> + break;
> + case QE_BRG4:
> + clock_bits = 2;
> + break;
> + case QE_CLK1:
> + clock_bits = 4;
> + break;
> + case QE_CLK2:
> + clock_bits = 5;
> + break;
> + case QE_CLK3:
> + clock_bits = 6;
> + break;
> + case QE_CLK8:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 28;
> + break;
> + case 1:
> + switch (clock) {
> + case QE_BRG3:
> + clock_bits = 1;
> + break;
> + case QE_BRG4:
> + clock_bits = 2;
> + break;
> + case QE_CLK1:
> + clock_bits = 4;
> + break;
> + case QE_CLK2:
> + clock_bits = 5;
> + break;
> + case QE_CLK5:
> + clock_bits = 6;
> + break;
> + case QE_CLK10:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 24;
> + break;
> + case 2:
> + switch (clock) {
> + case QE_BRG3:
> + clock_bits = 1;
> + break;
> + case QE_BRG4:
> + clock_bits = 2;
> + break;
> + case QE_CLK1:
> + clock_bits = 4;
> + break;
> + case QE_CLK2:
> + clock_bits = 5;
> + break;
> + case QE_CLK7:
> + clock_bits = 6;
> + break;
> + case QE_CLK12:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 20;
> + break;
> + case 3:
> + switch (clock) {
> + case QE_BRG3:
> + clock_bits = 1;
> + break;
> + case QE_BRG4:
> + clock_bits = 2;
> + break;
> + case QE_CLK1:
> + clock_bits = 4;
> + break;
> + case QE_CLK2:
> + clock_bits = 5;
> + break;
> + case QE_CLK9:
> + clock_bits = 6;
> + break;
> + case QE_CLK14:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 16;
> + break;
> + case 4:
> + switch (clock) {
> + case QE_BRG12:
> + clock_bits = 1;
> + break;
> + case QE_BRG13:
> + clock_bits = 2;
> + break;
> + case QE_CLK23:
> + clock_bits = 4;
> + break;
> + case QE_CLK24:
> + clock_bits = 5;
> + break;
> + case QE_CLK11:
> + clock_bits = 6;
> + break;
> + case QE_CLK16:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 28;
> + break;
> + case 5:
> + switch (clock) {
> + case QE_BRG12:
> + clock_bits = 1;
> + break;
> + case QE_BRG13:
> + clock_bits = 2;
> + break;
> + case QE_CLK23:
> + clock_bits = 4;
> + break;
> + case QE_CLK24:
> + clock_bits = 5;
> + break;
> + case QE_CLK13:
> + clock_bits = 6;
> + break;
> + case QE_CLK18:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 24;
> + break;
> + case 6:
> + switch (clock) {
> + case QE_BRG12:
> + clock_bits = 1;
> + break;
> + case QE_BRG13:
> + clock_bits = 2;
> + break;
> + case QE_CLK23:
> + clock_bits = 4;
> + break;
> + case QE_CLK24:
> + clock_bits = 5;
> + break;
> + case QE_CLK15:
> + clock_bits = 6;
> + break;
> + case QE_CLK20:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 20;
> + break;
> + case 7:
> + switch (clock) {
> + case QE_BRG12:
> + clock_bits = 1;
> + break;
> + case QE_BRG13:
> + clock_bits = 2;
> + break;
> + case QE_CLK23:
> + clock_bits = 4;
> + break;
> + case QE_CLK24:
> + clock_bits = 5;
> + break;
> + case QE_CLK17:
> + clock_bits = 6;
> + break;
> + case QE_CLK22:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 16;
> + break;
> + default:
> + break;
> + }
> + break;
> + case COMM_DIR_TX:
> + switch (tdm_num) {
> + case 0:
> + switch (clock) {
> + case QE_BRG3:
> + clock_bits = 1;
> + break;
> + case QE_BRG4:
> + clock_bits = 2;
> + break;
> + case QE_CLK1:
> + clock_bits = 4;
> + break;
> + case QE_CLK2:
> + clock_bits = 5;
> + break;
> + case QE_CLK4:
> + clock_bits = 6;
> + break;
> + case QE_CLK9:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 12;
> + break;
> + case 1:
> + switch (clock) {
> + case QE_BRG3:
> + clock_bits = 1;
> + break;
> + case QE_BRG4:
> + clock_bits = 2;
> + break;
> + case QE_CLK1:
> + clock_bits = 4;
> + break;
> + case QE_CLK2:
> + clock_bits = 5;
> + break;
> + case QE_CLK6:
> + clock_bits = 6;
> + break;
> + case QE_CLK11:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 8;
> + break;
> + case 2:
> + switch (clock) {
> + case QE_BRG3:
> + clock_bits = 1;
> + break;
> + case QE_BRG4:
> + clock_bits = 2;
> + break;
> + case QE_CLK1:
> + clock_bits = 4;
> + break;
> + case QE_CLK2:
> + clock_bits = 5;
> + break;
> + case QE_CLK8:
> + clock_bits = 6;
> + break;
> + case QE_CLK13:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 4;
> + break;
> + case 3:
> + switch (clock) {
> + case QE_BRG3:
> + clock_bits = 1;
> + break;
> + case QE_BRG4:
> + clock_bits = 2;
> + break;
> + case QE_CLK1:
> + clock_bits = 4;
> + break;
> + case QE_CLK2:
> + clock_bits = 5;
> + break;
> + case QE_CLK10:
> + clock_bits = 6;
> + break;
> + case QE_CLK15:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 0;
> + break;
> + case 4:
> + switch (clock) {
> + case QE_BRG12:
> + clock_bits = 1;
> + break;
> + case QE_BRG13:
> + clock_bits = 2;
> + break;
> + case QE_CLK23:
> + clock_bits = 4;
> + break;
> + case QE_CLK24:
> + clock_bits = 5;
> + break;
> + case QE_CLK12:
> + clock_bits = 6;
> + break;
> + case QE_CLK17:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 12;
> + break;
> + case 5:
> + switch (clock) {
> + case QE_BRG12:
> + clock_bits = 1;
> + break;
> + case QE_BRG13:
> + clock_bits = 2;
> + break;
> + case QE_CLK23:
> + clock_bits = 4;
> + break;
> + case QE_CLK24:
> + clock_bits = 5;
> + break;
> + case QE_CLK14:
> + clock_bits = 6;
> + break;
> + case QE_CLK19:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 8;
> + break;
> + case 6:
> + switch (clock) {
> + case QE_BRG12:
> + clock_bits = 1;
> + break;
> + case QE_BRG13:
> + clock_bits = 2;
> + break;
> + case QE_CLK23:
> + clock_bits = 4;
> + break;
> + case QE_CLK24:
> + clock_bits = 5;
> + break;
> + case QE_CLK16:
> + clock_bits = 6;
> + break;
> + case QE_CLK21:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 4;
> + break;
> + case 7:
> + switch (clock) {
> + case QE_BRG12:
> + clock_bits = 1;
> + break;
> + case QE_BRG13:
> + clock_bits = 2;
> + break;
> + case QE_CLK23:
> + clock_bits = 4;
> + break;
> + case QE_CLK24:
> + clock_bits = 5;
> + break;
> + case QE_CLK18:
> + clock_bits = 6;
> + break;
> + case QE_CLK3:
> + clock_bits = 7;
> + break;
> + default:
> + break;
> + }
> + shift = 0;
> + break;
> + default:
> + break;
> + }
> + break;
> + default:
> + break;
> + }
Unnecessary "default"s.
Please consider reformatting this data into an array.
> + if (!clock_bits)
> + return -ENOENT;
> +
> + cmxs1cr = (tdm_num < 4) ? (&qe_mux_reg->cmxsi1cr_l) :
> + (&qe_mux_reg->cmxsi1cr_h);
Unnecessary parentheses.
> +int ucc_set_tdm_rxtx_sync(u32 tdm_num, enum qe_clock clock,
> + enum comm_dir mode)
Similar comments as the clock function above.
> + clock_bits = (u32) source;
Unnecessary cast.
> +#ifdef CONFIG_FSL_UCC_TDM
> + } else {
> + /* tdm Rx clock routing */
> + if ((uf_info->rx_clock != QE_CLK_NONE) &&
> + ucc_set_tdm_rxtx_clk(uf_info->tdm_num,
> + uf_info->rx_clock, COMM_DIR_RX)) {
> + pr_err("%s: illegal value for RX clock", __func__);
> + ucc_fast_free(uccf);
> + return -EINVAL;
> + }
> +
> + /* tdm Tx clock routing */
> + if ((uf_info->tx_clock != QE_CLK_NONE) &&
> + ucc_set_tdm_rxtx_clk(uf_info->tdm_num,
> + uf_info->tx_clock, COMM_DIR_TX)) {
> + pr_err("%s:illegal value for TX clock", __func__);
> + ucc_fast_free(uccf);
> + return -EINVAL;
> + }
> +
> + /* tdm Rx sync clock routing */
> + if ((uf_info->rx_sync != QE_CLK_NONE) &&
> + ucc_set_tdm_rxtx_sync(uf_info->tdm_num,
> + uf_info->rx_sync, COMM_DIR_RX)) {
> + pr_err("%s:illegal value for TX clock", __func__);
> + ucc_fast_free(uccf);
> + return -EINVAL;
> + }
> +
> + /* tdm Tx sync clock routing */
> + if ((uf_info->tx_sync != QE_CLK_NONE) &&
> + ucc_set_tdm_rxtx_sync(uf_info->tdm_num,
> + uf_info->tx_sync, COMM_DIR_TX)) {
> + pr_err("%s:illegal value for TX clock", __func__);
> + ucc_fast_free(uccf);
> + return -EINVAL;
> + }
Please be consistent with error formatting (space after colon), and
either make the error messages distinctive, or if it isn't worthwhile,
factor out the error code to the end and use goto. You should probably
do that anyway, even if you print a distinctive error message first.
Also you should probably provide more info in the print regarding the
particular values and subdevices involved.
-Scott
^ permalink raw reply
* Re: [PATCH v3 3/3] powerpc/mpc85xx: add support for Keymile's kmcoge4 board
From: Scott Wood @ 2014-04-09 0:47 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1395754915-14534-4-git-send-email-valentin.longchamp@keymile.com>
On Tue, 2014-03-25 at 14:41 +0100, Valentin Longchamp wrote:
> + lbc: localbus@ffe124000 {
> + reg = <0xf 0xfe124000 0 0x1000>;
> + ranges = <0 0 0xf 0xffa00000 0x00040000 /* LB 0 */
> + 1 0 0xf 0xfb000000 0x00010000 /* LB 1 */
> + 2 0 0xf 0xd0000000 0x10000000 /* LB 2 */
> + 3 0 0xf 0xe0000000 0x10000000>; /* LB 3 */
> +
> + nand@0,0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "fsl,elbc-fcm-nand";
> + reg = <0 0 0x40000>;
> +
> + partition@0 {
> + label = "ubi0";
> + reg = <0x0 0x10000000>;
> + };
Putting partition info in the dts file is a bad habit and (as I've told
others) I don't think we should continue doing so in new dts files.
In this case it looks like you're just making the entire chip into one
partition, so I'm not sure what the point is of partitioning at all.
-Scott
^ permalink raw reply
* Re: [PATCH v3 2/3] devcietree: bindings: add some MFD Keymile FPGAs
From: Scott Wood @ 2014-04-09 0:44 UTC (permalink / raw)
To: Valentin Longchamp; +Cc: devicetree, linuxppc-dev
In-Reply-To: <1395754915-14534-3-git-send-email-valentin.longchamp@keymile.com>
On Tue, 2014-03-25 at 14:41 +0100, Valentin Longchamp wrote:
> These are the bindings for 2 MFD devices used on some of the Keymile boards.
> The first one is the chassis managmenet bfticu FPGA.
> The second one is the board controller (reset, LEDs, GPIOs) QRIO CPDL.
> These FPGAs are used in the kmcoge4 board.
>
> This patch also add KEYMILE to the vendor-prefixes.
>
> Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
>
> ---
> Changes in v3:
> - add a patch with the bindings for the KEYMILE FPGAs
>
> Changes in v2: None
>
> Documentation/devicetree/bindings/mfd/bfticu.txt | 26 ++++++++++++++++++++++
> Documentation/devicetree/bindings/mfd/qriox.txt | 17 ++++++++++++++
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> 3 files changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/bfticu.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/qriox.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt b/Documentation/devicetree/bindings/mfd/bfticu.txt
> new file mode 100644
> index 0000000..92de32e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
> @@ -0,0 +1,26 @@
> +KEYMILE bfticu Chassis Management FPGA
> +
> +The bfticu is a multifunction device that manages the whole chassis.
> +Its main functionality is to collect IRQs from the whole chassis and signals
> +them to a single controller.
> +
> +Required properties:
> +- compatible: "keymile,bfticu"
> +- interrupt-controller: the bfticu FPGA is an interrupt controller
> +- interrupts: the main IRQ line to signal the collected IRQs
> +- #interrupt-cells : is 2
> + - The 1st cell is the local IRQ number on the bfticu
> + - The 2nd cell is the type of the IRQ (IRQ_TYPE_xxx)
Device tree bindings should not depend on the content of Linux headers.
One is stable ABI, and the other isn't.
If you want you can make the values the same for convenience, as is done
by IPIC, CPM PIC, etc -- but the values need to be explicitly stated in
the binding. It'll still break if the Linux values change (so it may
not be a good idea to try to keep the values the same), but at least the
fix would be in Linux code rather than an ABI change.
> diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt b/Documentation/devicetree/bindings/mfd/qriox.txt
> new file mode 100644
> index 0000000..f301e2d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/qriox.txt
> @@ -0,0 +1,17 @@
> +KEYMILE qrio Board Control CPLD
> +
> +The qrio is a multifunction device that controls the KEYMILE boards based on
> +the kmp204x design.
> +It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable
> +GPIO blocks.
> +
> +Required properties:
> +- compatible: "keymile,qriox"
> +- reg: access on the parent local bus (chip select, offset in chip select, size)
> +
> +Example:
> +
> + board-control@1,0 {
> + compatible = "keymile,qriox";
> + reg = <1 0 0x80>;
> + };
If it has GPIO blocks, shouldn't it be using the GPIO binding?
-Scott
^ permalink raw reply
* Re: [1/2,v9] powerpc/mpc85xx:Add initial device tree support of T104x
From: Scott Wood @ 2014-04-09 0:08 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Varun Sethi, Poonam Aggrwal, linuxppc-dev, Priyanka Jain
In-Reply-To: <53415417.3010802@freescale.com>
On Sun, 2014-04-06 at 18:48 +0530, Prabhakar Kushwaha wrote:
> On 3/20/2014 4:03 AM, Scott Wood wrote:
> > On Sat, Jan 25, 2014 at 05:10:59PM +0530, Prabhakar Kushwaha wrote:
> >> + clockgen: global-utilities@e1000 {
> >> + compatible = "fsl,t1040-clockgen", "fsl,qoriq-clockgen-2.0",
> >> + "fixed-clock";
> >> + ranges = <0x0 0xe1000 0x1000>;
> >> + clock-frequency = <100000000>;
> > Why is clock-frequency hardcoded here rather than supplied by U-Boot?
> > Especially since this is an SoC file, not a board file.
>
> Your are correct.
> Means, clock-frequency should be added to clockgen in board device tree ??
Usually it gets patched in by U-Boot.
-Scott
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Fix Bit Clock Polarity configurations
From: Mark Brown @ 2014-04-08 11:50 UTC (permalink / raw)
To: Nicolin Chen; +Cc: alsa-devel, linuxppc-dev, linux-kernel
In-Reply-To: <20140408110738.GA10745@MrMyself>
[-- Attachment #1: Type: text/plain, Size: 216 bytes --]
On Tue, Apr 08, 2014 at 07:07:40PM +0800, Nicolin Chen wrote:
> Sir, I can't find this patch on any of the remote branches: for-next,
> topic/fsl-sai and fix/fsl-sai. Where could I find it?
It's in the fix branch.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_sai: Fix Bit Clock Polarity configurations
From: Nicolin Chen @ 2014-04-08 11:07 UTC (permalink / raw)
To: Mark Brown; +Cc: alsa-devel, linuxppc-dev, linux-kernel
In-Reply-To: <20140404100532.GN14763@sirena.org.uk>
On Fri, Apr 04, 2014 at 11:05:32AM +0100, Mark Brown wrote:
> On Fri, Apr 04, 2014 at 03:09:47PM +0800, Nicolin Chen wrote:
> > The BCP bit in TCR4/RCR4 register rules as followings:
> > 0 Bit clock is active high with drive outputs on rising edge
> > and sample inputs on falling edge.
> > 1 Bit clock is active low with drive outputs on falling edge
> > and sample inputs on rising edge.
>
> Applied, thanks.
Sir, I can't find this patch on any of the remote branches: for-next,
topic/fsl-sai and fix/fsl-sai. Where could I find it?
Thank you,
Nicolin
^ permalink raw reply
* Re: cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/
From: Neil Horman @ 2014-04-08 10:49 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Yann Droneaud, linux-kernel, Neil Horman, Anton Blanchard,
Hans-Bernhard Broeker, linuxppc-dev, Hans-Bernhard Bröker
In-Reply-To: <20140408075610.GJ11339@book.gsilab.sittig.org>
On Tue, Apr 08, 2014 at 09:56:10AM +0200, Gerhard Sittig wrote:
> [ removed cscope-devel from Cc:, non-subscriber mails get blocked anyway ]
>
> On Mon, 2014-04-07 at 14:42 +0200, Gerhard Sittig wrote:
> >
> > On Mon, 2014-04-07 at 06:42 -0400, Neil Horman wrote:
> > >
> > > On Thu, Apr 03, 2014 at 03:16:15PM +0200, Yann Droneaud wrote:
> > > >
> > > > [ ... ]
> > > >
> > > > cscope reports error when generating the cross-reference database:
> > > >
> > > > $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
> > > > GEN cscope
> > > > cscope: cannot find
> > > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
> > > > cscope: cannot find
> > > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
> > > > cscope: cannot find
> > > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
> > > > cscope: cannot find
> > > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
> > > >
> > > > And when calling cscope from ./obj-cscope/ directory, it reports errors
> > > > too.
> > > >
> > > > Hopefully it doesn't stop it from working, so I'm still able to use
> > > > cscope to browse kernel sources.
> > > >
> > > No, it won't stop it from working, it just won't search those files. I don't
> > > recall exactly the reason, but IIRC there was a big discussion long ago about
> > > symlinks and our ability to support them (around version 1.94 I think). We
> > > decided to not handle symlinks, as they would either point outside our search
> > > tree, which we didn't want to include, or would point to another file in the
> > > search tree, which made loading them pointless (as we would cover the search in
> > > the pointed file).
> >
> > So there are valid reasons to not process those filesystem
> > entries. Would it be useful to not emit the warnings then? Or
> > to silent those warnings when the user knows it's perfectly legal
> > to skip those filesytem entries? Like what you can do with the
> > ctags(1) command and its --links option.
>
> For the record: I got a response "off list" (actually to the
> cscope list only which is closed for non-subscribers, while the
> Linux related recipients were removed despite the fact that the
> issue appears to be in Linux), see
> http://article.gmane.org/gmane.comp.programming.tools.cscope.devel/105
>
I don't agree with Hans here. He's right in that the Linux makefiles could
exclude the symlinks from the index file that it builds, but if cscope were left
to its own devices it would also exclude the assembly files and other code that
it doesn't officially parse, but does more or less ok with. We can argue all
day weather its ok for Linux to do that, but the facts of the matter is that
people use cscope to search the linux source tree asm files and all, and while
we could propose that the cscope makefile target filter out symlinks, it seems
IMHO to be more difficult than its worth. Adding code to silence db build
warnings would be good.
> This reponse suggests that the issue is not in cscope(1) itself,
> but instead is in how the cscope(1) command got invoked. Which
> translates into "the Linux infrastructure does something wrong".
>
> A quick search identifies ./scripts/tags.sh:all_target_sources()
> as the spot where symlinks should get filtered out. Where both
> paths of all_target_sources() end up calling all_sources().
>
>
> virtually yours
> Gerhard Sittig
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
>
^ permalink raw reply
* Re: [PATCH v2] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
From: Srivatsa S. Bhat @ 2014-04-08 8:24 UTC (permalink / raw)
To: Michael wang
Cc: sfr, LKML, paulus, alistair, nfont, Andrew Morton, rcj,
linuxppc-dev
In-Reply-To: <53436AC8.5020705@linux.vnet.ibm.com>
On 04/08/2014 08:49 AM, Michael wang wrote:
> Since v1:
> Edited the comment according to Srivatsa's suggestion.
>
> During the testing, we encounter below WARN followed by Oops:
>
> WARNING: at kernel/sched/core.c:6218
> ...
> NIP [c000000000101660] .build_sched_domains+0x11d0/0x1200
> LR [c000000000101358] .build_sched_domains+0xec8/0x1200
> PACATMSCRATCH [800000000000f032]
> Call Trace:
> [c00000001b103850] [c000000000101358] .build_sched_domains+0xec8/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
> Oops: Kernel access of bad area, sig: 11 [#1]
> ...
> NIP [c00000000045c000] .__bitmap_weight+0x60/0xf0
> LR [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> PACATMSCRATCH [8000000000029032]
> Call Trace:
> [c00000001b1037a0] [c000000000288ff4] .kmem_cache_alloc_node_trace+0x184/0x3a0
> [c00000001b103850] [c00000000010132c] .build_sched_domains+0xe9c/0x1200
> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
> ...
>
> This was caused by that 'sd->groups == NULL' after building groups, which
> was caused by the empty 'sd->span'.
>
> The cpu's domain contained nothing because the cpu was assigned to a wrong
> node, due to the following unfortunate sequence of events:
>
> 1. The hypervisor sent a topology update to the guest OS, to notify changes
> to the cpu-node mapping. However, the update was actually redundant - i.e.,
> the "new" mapping was exactly the same as the old one.
>
> 2. Due to this, the 'updated_cpus' mask turned out to be empty after exiting
> the 'for-loop' in arch_update_cpu_topology().
>
> 3. So we ended up calling stop-machine() with an empty cpumask list, which made
> stop-machine internally elect cpumask_first(cpu_online_mask), i.e., CPU0 as
> the cpu to run the payload (the update_cpu_topology() function).
>
> 4. This causes update_cpu_topology() to be run by CPU0. And since 'updates'
> is kzalloc()'ed inside arch_update_cpu_topology(), update_cpu_topology()
> finds update->cpu as well as update->new_nid to be 0. In other words, we
> end up assigning CPU0 (and eventually its siblings) to node 0, incorrectly.
>
> Along with the following wrong updating, it causes the sched-domain rebuild
> code to break and crash the system.
>
> Fix this by skipping the topology update in cases where we find that
> the topology has not actually changed in reality (ie., spurious updates).
>
> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> CC: Paul Mackerras <paulus@samba.org>
> CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> CC: Stephen Rothwell <sfr@canb.auug.org.au>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Robert Jennings <rcj@linux.vnet.ibm.com>
> CC: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
> CC: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> CC: Alistair Popple <alistair@popple.id.au>
> Suggested-by: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
> ---
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Regards,
Srivatsa S. Bhat
> arch/powerpc/mm/numa.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index 30a42e2..4ebbb9e 100644
> --- a/arch/powerpc/mm/numa.c
> +++ b/arch/powerpc/mm/numa.c
> @@ -1591,6 +1591,20 @@ int arch_update_cpu_topology(void)
> cpu = cpu_last_thread_sibling(cpu);
> }
>
> + /*
> + * In cases where we have nothing to update (because the updates list
> + * is too short or because the new topology is same as the old one),
> + * skip invoking update_cpu_topology() via stop-machine(). This is
> + * necessary (and not just a fast-path optimization) since stop-machine
> + * can end up electing a random CPU to run update_cpu_topology(), and
> + * thus trick us into setting up incorrect cpu-node mappings (since
> + * 'updates' is kzalloc()'ed).
> + *
> + * And for the similar reason, we will skip all the following updating.
> + */
> + if (!cpumask_weight(&updated_cpus))
> + goto out;
> +
> stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
>
> /*
> @@ -1612,6 +1626,7 @@ int arch_update_cpu_topology(void)
> changed = 1;
> }
>
> +out:
> kfree(updates);
> return changed;
> }
>
^ permalink raw reply
* Re: cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/
From: Gerhard Sittig @ 2014-04-08 7:56 UTC (permalink / raw)
To: Neil Horman
Cc: Yann Droneaud, linux-kernel, Neil Horman, Anton Blanchard,
Hans-Bernhard Broeker, linuxppc-dev, Hans-Bernhard Bröker
In-Reply-To: <20140407124259.GZ11339@book.gsilab.sittig.org>
[ removed cscope-devel from Cc:, non-subscriber mails get blocked anyway ]
On Mon, 2014-04-07 at 14:42 +0200, Gerhard Sittig wrote:
>
> On Mon, 2014-04-07 at 06:42 -0400, Neil Horman wrote:
> >
> > On Thu, Apr 03, 2014 at 03:16:15PM +0200, Yann Droneaud wrote:
> > >
> > > [ ... ]
> > >
> > > cscope reports error when generating the cross-reference database:
> > >
> > > $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
> > > GEN cscope
> > > cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
> > > cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
> > > cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
> > > cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
> > >
> > > And when calling cscope from ./obj-cscope/ directory, it reports errors
> > > too.
> > >
> > > Hopefully it doesn't stop it from working, so I'm still able to use
> > > cscope to browse kernel sources.
> > >
> > No, it won't stop it from working, it just won't search those files. I don't
> > recall exactly the reason, but IIRC there was a big discussion long ago about
> > symlinks and our ability to support them (around version 1.94 I think). We
> > decided to not handle symlinks, as they would either point outside our search
> > tree, which we didn't want to include, or would point to another file in the
> > search tree, which made loading them pointless (as we would cover the search in
> > the pointed file).
>
> So there are valid reasons to not process those filesystem
> entries. Would it be useful to not emit the warnings then? Or
> to silent those warnings when the user knows it's perfectly legal
> to skip those filesytem entries? Like what you can do with the
> ctags(1) command and its --links option.
For the record: I got a response "off list" (actually to the
cscope list only which is closed for non-subscribers, while the
Linux related recipients were removed despite the fact that the
issue appears to be in Linux), see
http://article.gmane.org/gmane.comp.programming.tools.cscope.devel/105
This reponse suggests that the issue is not in cscope(1) itself,
but instead is in how the cscope(1) command got invoked. Which
translates into "the Linux infrastructure does something wrong".
A quick search identifies ./scripts/tags.sh:all_target_sources()
as the spot where symlinks should get filtered out. Where both
paths of all_target_sources() end up calling all_sources().
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* [PATCH] powerpc/le: Fix module build error
From: Anton Blanchard @ 2014-04-08 7:20 UTC (permalink / raw)
To: benh; +Cc: Stewart Smith, Tony Breeds, linuxppc-dev
I made a cleanup suggestion on 27143b9a0 (powerpc/le: Avoid creatng
R_PPC64_TOCSAVE relocations for modules) that had a stupid typo. Fix
it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a9f814a..4c0cedf 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -74,7 +74,7 @@ override CROSS32AS += -mlittle-endian
LDEMULATION := lppc
GNUTARGET := powerpcle
MULTIPLEWORD := -mno-multiple
-KBUILD_CFLAGS_MODULE += $(call cc-option-yn,-mno-save-toc-indirect)
+KBUILD_CFLAGS_MODULE += $(call cc-option,-mno-save-toc-indirect)
else
ifeq ($(call cc-option-yn,-mbig-endian),y)
override CC += -mbig-endian
^ permalink raw reply related
* [PATCH] powerpc/4xx: Fix section mismatch in ppc4xx_pci.c
From: Alistair Popple @ 2014-04-08 4:20 UTC (permalink / raw)
To: benh; +Cc: Alistair Popple, linuxppc-dev
This patch fixes this section mismatch:
WARNING: vmlinux.o(.text+0x1efc4): Section mismatch in reference from
the function apm821xx_pciex_init_port_hw() to the function
.init.text:ppc4xx_pciex_wait_on_sdr.isra.9()
The function apm821xx_pciex_init_port_hw() references the function
__init ppc4xx_pciex_wait_on_sdr.isra.9(). This is often because
apm821xx_pciex_init_port_hw lacks a __init annotation or the
annotation of ppc4xx_pciex_wait_on_sdr.isra.9 is wrong.
apm821xx_pciex_init_port_hw is only referenced by a struct in
__initdata, so it should be safe to add __init to
apm821xx_pciex_init_port_hw.
Signed-off-by: Alistair Popple <alistair@popple.id.au>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index 64603a1..4914fd3 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -1058,7 +1058,7 @@ static int __init apm821xx_pciex_core_init(struct device_node *np)
return 1;
}
-static int apm821xx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
+static int __init apm821xx_pciex_init_port_hw(struct ppc4xx_pciex_port *port)
{
u32 val;
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
From: Michael wang @ 2014-04-08 3:19 UTC (permalink / raw)
To: linuxppc-dev, LKML, benh, paulus, nfont, sfr, Andrew Morton, rcj,
jlarrew, srivatsa.bhat, alistair
In-Reply-To: <533B8431.8090507@linux.vnet.ibm.com>
Since v1:
Edited the comment according to Srivatsa's suggestion.
During the testing, we encounter below WARN followed by Oops:
WARNING: at kernel/sched/core.c:6218
...
NIP [c000000000101660] .build_sched_domains+0x11d0/0x1200
LR [c000000000101358] .build_sched_domains+0xec8/0x1200
PACATMSCRATCH [800000000000f032]
Call Trace:
[c00000001b103850] [c000000000101358] .build_sched_domains+0xec8/0x1200
[c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
[c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
[c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
...
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP [c00000000045c000] .__bitmap_weight+0x60/0xf0
LR [c00000000010132c] .build_sched_domains+0xe9c/0x1200
PACATMSCRATCH [8000000000029032]
Call Trace:
[c00000001b1037a0] [c000000000288ff4] .kmem_cache_alloc_node_trace+0x184/0x3a0
[c00000001b103850] [c00000000010132c] .build_sched_domains+0xe9c/0x1200
[c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
[c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
[c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
...
This was caused by that 'sd->groups == NULL' after building groups, which
was caused by the empty 'sd->span'.
The cpu's domain contained nothing because the cpu was assigned to a wrong
node, due to the following unfortunate sequence of events:
1. The hypervisor sent a topology update to the guest OS, to notify changes
to the cpu-node mapping. However, the update was actually redundant - i.e.,
the "new" mapping was exactly the same as the old one.
2. Due to this, the 'updated_cpus' mask turned out to be empty after exiting
the 'for-loop' in arch_update_cpu_topology().
3. So we ended up calling stop-machine() with an empty cpumask list, which made
stop-machine internally elect cpumask_first(cpu_online_mask), i.e., CPU0 as
the cpu to run the payload (the update_cpu_topology() function).
4. This causes update_cpu_topology() to be run by CPU0. And since 'updates'
is kzalloc()'ed inside arch_update_cpu_topology(), update_cpu_topology()
finds update->cpu as well as update->new_nid to be 0. In other words, we
end up assigning CPU0 (and eventually its siblings) to node 0, incorrectly.
Along with the following wrong updating, it causes the sched-domain rebuild
code to break and crash the system.
Fix this by skipping the topology update in cases where we find that
the topology has not actually changed in reality (ie., spurious updates).
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
CC: Stephen Rothwell <sfr@canb.auug.org.au>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Robert Jennings <rcj@linux.vnet.ibm.com>
CC: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
CC: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
CC: Alistair Popple <alistair@popple.id.au>
Suggested-by: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
---
arch/powerpc/mm/numa.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 30a42e2..4ebbb9e 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1591,6 +1591,20 @@ int arch_update_cpu_topology(void)
cpu = cpu_last_thread_sibling(cpu);
}
+ /*
+ * In cases where we have nothing to update (because the updates list
+ * is too short or because the new topology is same as the old one),
+ * skip invoking update_cpu_topology() via stop-machine(). This is
+ * necessary (and not just a fast-path optimization) since stop-machine
+ * can end up electing a random CPU to run update_cpu_topology(), and
+ * thus trick us into setting up incorrect cpu-node mappings (since
+ * 'updates' is kzalloc()'ed).
+ *
+ * And for the similar reason, we will skip all the following updating.
+ */
+ if (!cpumask_weight(&updated_cpus))
+ goto out;
+
stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
/*
@@ -1612,6 +1626,7 @@ int arch_update_cpu_topology(void)
changed = 1;
}
+out:
kfree(updates);
return changed;
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2] powerpc/le: enable RTAS events support
From: Nathan Fontenot @ 2014-04-08 2:47 UTC (permalink / raw)
To: Greg Kurz, benh; +Cc: linux-kernel, paulus, anton, geert, linuxppc-dev
In-Reply-To: <20140404072750.20016.18969.stgit@bahia.local>
On 04/04/2014 02:35 AM, Greg Kurz wrote:
> The current kernel code assumes big endian and parses RTAS events all
> wrong. The most visible effect is that we cannot honor EPOW events,
> meaning, for example, we cannot shut down a guest properly from the
> hypervisor.
>
> This new patch is largely inspired by Nathan's work: we get rid of all
> the bit fields in the RTAS event structures (even the unused ones, for
> consistency). We also introduce endian safe accessors for the fields used
> by the kernel (trivial rtas_error_type() accessor added for consistency).
>
> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Looks good, thanks for getting this done Greg.
-Nathan
^ permalink raw reply
* Re: [PATCH] power, sched: stop updating inside arch_update_cpu_topology() when nothing to be update
From: Michael wang @ 2014-04-08 2:39 UTC (permalink / raw)
To: Srivatsa S. Bhat
Cc: sfr, LKML, paulus, alistair, nfont, Andrew Morton, rcj,
linuxppc-dev
In-Reply-To: <53427AC1.9010801@linux.vnet.ibm.com>
Hi, Srivatsa
It's nice to have you confirmed the fix, and thanks for the well-writing
comments, will apply them and send out the new patch later :)
Regards,
Michael Wang
On 04/07/2014 06:15 PM, Srivatsa S. Bhat wrote:
> Hi Michael,
>
> On 04/02/2014 08:59 AM, Michael wang wrote:
>> During the testing, we encounter below WARN followed by Oops:
>>
>> WARNING: at kernel/sched/core.c:6218
>> ...
>> NIP [c000000000101660] .build_sched_domains+0x11d0/0x1200
>> LR [c000000000101358] .build_sched_domains+0xec8/0x1200
>> PACATMSCRATCH [800000000000f032]
>> Call Trace:
>> [c00000001b103850] [c000000000101358] .build_sched_domains+0xec8/0x1200
>> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
>> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
>> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
>> ...
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> ...
>> NIP [c00000000045c000] .__bitmap_weight+0x60/0xf0
>> LR [c00000000010132c] .build_sched_domains+0xe9c/0x1200
>> PACATMSCRATCH [8000000000029032]
>> Call Trace:
>> [c00000001b1037a0] [c000000000288ff4] .kmem_cache_alloc_node_trace+0x184/0x3a0
>> [c00000001b103850] [c00000000010132c] .build_sched_domains+0xe9c/0x1200
>> [c00000001b1039a0] [c00000000010aad4] .partition_sched_domains+0x484/0x510
>> [c00000001b103aa0] [c00000000016d0a8] .rebuild_sched_domains+0x68/0xa0
>> [c00000001b103b30] [c00000000005cbf0] .topology_work_fn+0x10/0x30
>> ...
>>
>> This was caused by that 'sd->groups == NULL' after building groups, which
>> was caused by the empty 'sd->span'.
>>
>> The cpu's domain contain nothing because the cpu was assigned to wrong
>> node inside arch_update_cpu_topology() by calling update_lookup_table()
>> with the uninitialized param, in the case when there is nothing to be
>> update.
>>
>
> Can you reword the above paragraph to something like this:
>
> The cpu's domain contained nothing because the cpu was assigned to a wrong
> node, due to the following unfortunate sequence of events:
>
> 1. The hypervisor sent a topology update to the guest OS, to notify changes
> to the cpu-node mapping. However, the update was actually redundant - i.e.,
> the "new" mapping was exactly the same as the old one.
>
> 2. Due to this, the 'updated_cpus' mask turned out to be empty after exiting
> the 'for-loop' in arch_update_cpu_topology().
>
> 3. So we ended up calling stop-machine() with an empty cpumask list, which made
> stop-machine internally elect cpumask_first(cpu_online_mask), i.e., CPU0 as
> the cpu to run the payload (the update_cpu_topology() function).
>
> 4. This causes update_cpu_topology() to be run by CPU0. And since 'updates'
> is kzalloc()'ed inside arch_update_cpu_topology(), update_cpu_topology()
> finds update->cpu as well as update->new_nid to be 0. In other words, we
> end up assigning CPU0 (and eventually its siblings) to node 0, incorrectly.
>
> This causes the sched-domain rebuild code to break and crash the system.
>
>
>> Thus we should stop the updating in such cases, this patch will achieve
>> this and fix the issue.
>>
>
> We can reword this part as:
>
> Fix this by skipping the topology update in cases where we find that
> the topology has not actually changed in reality (ie., spurious updates).
>
>> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> CC: Paul Mackerras <paulus@samba.org>
>> CC: Nathan Fontenot <nfont@linux.vnet.ibm.com>
>> CC: Stephen Rothwell <sfr@canb.auug.org.au>
>> CC: Andrew Morton <akpm@linux-foundation.org>
>> CC: Robert Jennings <rcj@linux.vnet.ibm.com>
>> CC: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>> CC: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
>> CC: Alistair Popple <alistair@popple.id.au>
>> Signed-off-by: Michael Wang <wangyun@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/mm/numa.c | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index 30a42e2..6757690 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -1591,6 +1591,14 @@ int arch_update_cpu_topology(void)
>> cpu = cpu_last_thread_sibling(cpu);
>> }
>>
>> + /*
>> + * The 'cpu_associativity_changes_mask' could be cleared if
>> + * all the cpus it indicates won't change their node, in
>> + * which case the 'updated_cpus' will be empty.
>> + */
>
> How about rewording the comment like this:
>
> In cases where we have nothing to update (because the updates list
> is too short or because the new topology is same as the old one),
> skip invoking update_cpu_topology() via stop-machine(). This is
> necessary (and not just a fast-path optimization) because stop-machine
> can end up electing a random CPU to run update_cpu_topology(), and
> thus trick us into setting up incorrect cpu-node mappings (since
> 'updates' is kzalloc()'ed).
>
> Regards,
> Srivatsa S. Bhat
>
>> + if (!cpumask_weight(&updated_cpus))
>> + goto out;
>> +
>> stop_machine(update_cpu_topology, &updates[0], &updated_cpus);
>>
>> /*
>> @@ -1612,6 +1620,7 @@ int arch_update_cpu_topology(void)
>> changed = 1;
>> }
>>
>> +out:
>> kfree(updates);
>> return changed;
>> }
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH v2] powerpc/le: enable RTAS events support
From: Stewart Smith @ 2014-04-07 23:21 UTC (permalink / raw)
To: Greg Kurz, benh; +Cc: linux-kernel, paulus, anton, nfont, geert, linuxppc-dev
In-Reply-To: <20140404072750.20016.18969.stgit@bahia.local>
Greg Kurz <gkurz@linux.vnet.ibm.com> writes:
> The current kernel code assumes big endian and parses RTAS events all
> wrong. The most visible effect is that we cannot honor EPOW events,
> meaning, for example, we cannot shut down a guest properly from the
> hypervisor.
>
> This new patch is largely inspired by Nathan's work: we get rid of all
> the bit fields in the RTAS event structures (even the unused ones, for
> consistency). We also introduce endian safe accessors for the fields used
> by the kernel (trivial rtas_error_type() accessor added for consistency).
>
> Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Acked-by: Stewart Smith <stewart@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH] powerpc/opal: Add missing include
From: Benjamin Herrenschmidt @ 2014-04-07 22:07 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Stephen Rothwell, Michael Neuling, Linux-Next, Linux PPC dev
In-Reply-To: <CAMuHMdV7BuSMu5gyhBcxY_8v+u3KnVStDgvC-JSN=hX3VZw3+g@mail.gmail.com>
On Mon, 2014-04-07 at 23:03 +0200, Geert Uytterhoeven wrote:
> On Tue, Mar 25, 2014 at 1:43 AM, Michael Neuling <mikey@neuling.org> wrote:
> > next-20140324 currently fails compiling celleb_defconfig with:
> >
> > arch/powerpc/include/asm/opal.h:894:42: error: 'struct notifier_block' declared inside parameter list [-Werror]
> > arch/powerpc/include/asm/opal.h:894:42: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
> > arch/powerpc/include/asm/opal.h:896:14: error: 'struct notifier_block' declared inside parameter list [-Werror]
> >
> > This is due to a missing include which is added here.
>
> This build issue has now been in mainline since a few days.
It's in my tree, I will send the patch upstream in the next couple of
days (having a medical procedure today).
Ben.
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
> >
> > diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> > index fe2aa0b..f57fb58 100644
> > --- a/arch/powerpc/include/asm/opal.h
> > +++ b/arch/powerpc/include/asm/opal.h
> > @@ -177,6 +177,8 @@ extern int opal_enter_rtas(struct rtas_args *args,
> >
> > #ifndef __ASSEMBLY__
> >
> > +#include <linux/notifier.h>
> > +
> > /* Other enums */
> > enum OpalVendorApiTokens {
> > OPAL_START_VENDOR_API_RANGE = 1000, OPAL_END_VENDOR_API_RANGE = 1999
>
> 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
* Re: [PATCH] powerpc/opal: Add missing include
From: Geert Uytterhoeven @ 2014-04-07 21:03 UTC (permalink / raw)
To: Michael Neuling; +Cc: Linux PPC dev, Linux-Next, Stephen Rothwell
In-Reply-To: <13762.1395708188@ale.ozlabs.ibm.com>
On Tue, Mar 25, 2014 at 1:43 AM, Michael Neuling <mikey@neuling.org> wrote:
> next-20140324 currently fails compiling celleb_defconfig with:
>
> arch/powerpc/include/asm/opal.h:894:42: error: 'struct notifier_block' declared inside parameter list [-Werror]
> arch/powerpc/include/asm/opal.h:894:42: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
> arch/powerpc/include/asm/opal.h:896:14: error: 'struct notifier_block' declared inside parameter list [-Werror]
>
> This is due to a missing include which is added here.
This build issue has now been in mainline since a few days.
> Signed-off-by: Michael Neuling <mikey@neuling.org>
>
> diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
> index fe2aa0b..f57fb58 100644
> --- a/arch/powerpc/include/asm/opal.h
> +++ b/arch/powerpc/include/asm/opal.h
> @@ -177,6 +177,8 @@ extern int opal_enter_rtas(struct rtas_args *args,
>
> #ifndef __ASSEMBLY__
>
> +#include <linux/notifier.h>
> +
> /* Other enums */
> enum OpalVendorApiTokens {
> OPAL_START_VENDOR_API_RANGE = 1000, OPAL_END_VENDOR_API_RANGE = 1999
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
* tools/testing/selftests/ptrace/peeksiginfo.c bug
From: Thierry FAUCK @ 2014-04-07 20:09 UTC (permalink / raw)
To: linuxppc-dev
Hello,
Here is a fix to allow compilation of
tools/testing/selftests/ptrace/peeksiginfo.c on ppc64/ppc64el.
Canonical is waiting for the patch to be upstream.
Thanks
Thierry
>From 48a9a9834377a74b603be12dcc76cda24105e33c Mon Sep 17 00:00:00 2001
From: Thierry Fauck <thierry@linux.vnet.ibm.com>
Date: Fri, 28 Feb 2014 16:17:50 +0100
Subject: [PATCH] power: PAGE_SIZE may not be defined
Some systems have a dynamic PAGE_SIZE value and do not add a definition
for PAGE_SIZE. This value will have to be retrieved using getpagesize()
or sysconf().
Signed-off-by: Thierry Fauck <thierry@linux.vnet.ibm.com>
---
tools/testing/selftests/ptrace/peeksiginfo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ptrace/peeksiginfo.c
b/tools/testing/selftests/ptrace/peeksiginfo.c
index d46558b..f2ccbbd 100644
--- a/tools/testing/selftests/ptrace/peeksiginfo.c
+++ b/tools/testing/selftests/ptrace/peeksiginfo.c
@@ -35,7 +35,9 @@ static int sys_ptrace(int request, pid_t pid, void
*addr, void *data)
fprintf(stderr, \
"Error (%s:%d): " fmt, \
__FILE__, __LINE__, ##__VA_ARGS__)
-
+#ifndef PAGE_SIZE
+#define PAGE_SIZE sysconf(_SC_PAGESIZE)
+#endif
static int check_error_paths(pid_t child)
{
struct ptrace_peeksiginfo_args arg;
--
1.9.0
^ permalink raw reply related
* Re: [1/2,v9] powerpc/mpc85xx:Add initial device tree support of T104x
From: Scott Wood @ 2014-04-07 18:22 UTC (permalink / raw)
To: Prabhakar Kushwaha
Cc: Varun Sethi, Poonam Aggrwal, linuxppc-dev, Priyanka Jain
In-Reply-To: <53415417.3010802@freescale.com>
On Sun, 2014-04-06 at 18:48 +0530, Prabhakar Kushwaha wrote:
> On 3/20/2014 4:03 AM, Scott Wood wrote:
> > On Sat, Jan 25, 2014 at 05:10:59PM +0530, Prabhakar Kushwaha wrote:
> >> + display@180000 {
> >> + compatible = "fsl,t1040-diu", "fsl,diu";
> >> + reg = <0x180000 1000>;
> >> + interrupts = <74 2 0 0>;
> >> + };
> >> +
> >> +/include/ "qoriq-sata2-0.dtsi"
> >> +sata@220000 {
> >> + fsl,iommu-parent = <&pamu0>;
> >> + fsl,liodn-reg = <&guts 0x550>; /* SATA1LIODNR */
> >> +};
> >> +/include/ "qoriq-sata2-1.dtsi"
> >> +sata@221000 {
> >> + fsl,iommu-parent = <&pamu0>;
> >> + fsl,liodn-reg = <&guts 0x554>; /* SATA2LIODNR */
> >> +};
> >> +/include/ "qoriq-sec5.0-0.dtsi"
> >> +};
> > Whitespace
> >
> >
> i did not find this whitespace :(
Add a tab to the sata nodes' name and braces, and remove a tab from the
sata nodes' content.
-Scott
^ permalink raw reply
* Re: cscope: issue with symlinks in tools/testing/selftests/powerpc/copyloops/
From: Neil Horman @ 2014-04-07 15:36 UTC (permalink / raw)
To: Gerhard Sittig
Cc: Yann Droneaud, linux-kernel, Neil Horman, cscope-devel,
Anton Blanchard, Hans-Bernhard Broeker, linuxppc-dev,
Hans-Bernhard Bröker
In-Reply-To: <20140407124259.GZ11339@book.gsilab.sittig.org>
On Mon, Apr 07, 2014 at 02:42:59PM +0200, Gerhard Sittig wrote:
> On Mon, 2014-04-07 at 06:42 -0400, Neil Horman wrote:
> >
> > On Thu, Apr 03, 2014 at 03:16:15PM +0200, Yann Droneaud wrote:
> > >
> > > [ ... ]
> > >
> > > cscope reports error when generating the cross-reference database:
> > >
> > > $ make ALLSOURCE_ARCHS=all O=./obj-cscope/ cscope
> > > GEN cscope
> > > cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_power7.S
> > > cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_64.S
> > > cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/memcpy_power7.S
> > > cscope: cannot find
> > > file /home/ydroneaud/src/linux/tools/testing/selftests/powerpc/copyloops/copyuser_64.S
> > >
> > > And when calling cscope from ./obj-cscope/ directory, it reports errors
> > > too.
> > >
> > > Hopefully it doesn't stop it from working, so I'm still able to use
> > > cscope to browse kernel sources.
> > >
> > No, it won't stop it from working, it just won't search those files. I don't
> > recall exactly the reason, but IIRC there was a big discussion long ago about
> > symlinks and our ability to support them (around version 1.94 I think). We
> > decided to not handle symlinks, as they would either point outside our search
> > tree, which we didn't want to include, or would point to another file in the
> > search tree, which made loading them pointless (as we would cover the search in
> > the pointed file).
>
> So there are valid reasons to not process those filesystem
> entries. Would it be useful to not emit the warnings then? Or
> to silent those warnings when the user knows it's perfectly legal
> to skip those filesytem entries? Like what you can do with the
> ctags(1) command and its --links option.
>
I would see no problem with an option to do that. I'd like to make it opt-in,
so that people who want to know about symlink issues will still see them, but
I'd be supportive of an option to quiet them
Neil
>
> virtually yours
> Gerhard Sittig
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
>
^ 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