| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Useful to be able to dump the kernel hash page table to check
which pages are hashed along with their sizes and other details.
Add a debugfs file to check the hash page table. If radix is enabled
(and so there is no hash page table) then this file doesn't exist. To
use this the PPC_PTDUMP config option must be selected.
Signed-off-by: Rashmica Gupta <rashmicy@gmail.com>
[mpe: Fix build with SPARSEMEM_VMEMMAP=n & PSERIES=n]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Useful to be able to dump the kernels page tables to check permissions
and memory types - derived from arm64's implementation.
Add a debugfs file to check the page tables. To use this the PPC_PTDUMP
config option must be selected.
Signed-off-by: Rashmica Gupta <rashmicy@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Currently there's some CMO (Cooperative Memory Overcommit) code, in
plpar_wrappers.h. Some of it is #ifdef CONFIG_PSERIES and some of it
isn't. The end result being if a file includes plpar_wrappers.h it won't
build with CONFIG_PSERIES=n.
Fix it by moving the CMO code into platforms/pseries. The two hcall
wrappers can just be moved into their only caller, cmm.c, and the
accessors can go in pseries.h.
Note we need the accessors because cmm.c can be built as a module, so
there needs to be a split between the built-in code vs the module, and
that's achieved by using those accessors.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Rename "sift" to "shift".
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts storcenter_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts pseries_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts ppc6xx_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts ppc64e_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts ppc64_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts pmac32_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
This patch disables deprecated IDE subsystem in pasemi_defconfig
(no IDE host drivers are selected in this config so there is no valid
reason to enable IDE subsystem itself).
Cc: Olof Johansson <olof@lixom.net>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts maple_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts g5_defconfig to use libata PATA drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts chrp32_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts cell_defconfig to use libata PATA drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
IDE subsystem has been deprecated since 2009 and the majority
(if not all) of Linux distributions have switched to use
libata for ATA support exclusively. However there are still
some users (mostly old or/and embedded non-x86 systems) that
have not converted from using IDE subsystem to libata PATA
drivers. This doesn't seem to be good thing in the long-term
for Linux as while there is less and less PATA systems left
in use:
* testing efforts are divided between two subsystems
* having duplicate drivers for same hardware confuses users
This patch converts amigaone_defconfig to use libata PATA
drivers.
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
|
|
Add comment clarifying that vio_find_node() takes a reference to the
embedded struct device which needs to be dropped after use.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Make sure to drop any reference taken by bus_find_device() when creating
devices during init and driver registration.
Fixes: 55347cc9962f ("[POWERPC] ibmebus: Add device creation and bus probing based on of_device")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Make sure to drop any reference taken by bus_find_device() in the sysfs
callbacks that are used to create and destroy devices based on
device-tree entries.
Fixes: 6bccf755ff53 ("[POWERPC] ibmebus: dynamic addition/removal of adapters, some code cleanup")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
This condenses the opal node searching into a single function that finds
all compatible nodes, instead of just searching the ibm,opal children,
for ipmi, flash, and prd similar to how opal-i2c nodes are found.
Signed-off-by: Jack Miller <jack@codezen.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Load monitored is no longer supported on POWER9 so let's remove the
code.
This reverts commit bd3ea317fddf ("powerpc: Load Monitor Register
Support").
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
No one uses reiserfs much these days, or is likely to in future. So drop
it from pseries and powernv defconfigs to save time and space. It's
still enabled in ppc64_defconfig so we get some build coverage.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
In ISA v2.05, the tlbiel instruction takes two arguments, RB and L:
tlbiel RB,L
+---------+---------+----+---------+---------+---------+----+
| 31 | / | L | / | RB | 274 | / |
| 31 - 26 | 25 - 22 | 21 | 20 - 16 | 15 - 11 | 10 - 1 | 0 |
+---------+---------+----+---------+---------+---------+----+
In ISA v2.06 tlbiel takes only one argument, RB:
tlbiel RB
+---------+---------+---------+---------+---------+----+
| 31 | / | / | RB | 274 | / |
| 31 - 26 | 25 - 21 | 20 - 16 | 15 - 11 | 10 - 1 | 0 |
+---------+---------+---------+---------+---------+----+
And in ISA v3.00 tlbiel takes five arguments:
tlbiel RB,RS,RIC,PRS,R
+---------+---------+----+---------+----+----+---------+---------+----+
| 31 | RS | / | RIC |PRS | R | RB | 274 | / |
| 31 - 26 | 25 - 21 | 20 | 19 - 18 | 17 | 16 | 15 - 11 | 10 - 1 | 0 |
+---------+---------+----+---------+----+----+---------+---------+----+
However the assembler also accepts "tlbiel RB", and generates
"tlbiel RB,r0,0,0,0".
As you can see above the L field from the v2.05 encoding overlaps with the
reserved field of the v2.06 encoding, and the low bit of the RS field of the
v3.00 encoding.
Currently in __tlbiel() we generate two tlbiel instructions manually using hex
constants. In the first case, for MMU_PAGE_4K, we generate "tlbiel RB,0", which
is safe in all cases, because the L bit is zero.
However in the default case we generate "tlbiel RB,1", therefore setting bit 21
to 1.
This is not an actual bug on v2.06 processors, because the CPU ignores the value
of the reserved field. However software is supposed to encode the reserved
fields as zero to enable forward compatibility.
On v3.00 processors setting bit 21 to 1 and no other bits of RS, means we are
using r1 for the value of RS.
Although it's not obvious, the code sets the IS field (bits 10-11) to 0 (by
omission), and L=1, in the va value, which is passed as RB. We also pass R=0 in
the instruction.
The combination of IS=0, L=1 and R=0 means the value of RS is not used, so even
on ISA v3.00 there is no actual bug.
We should still fix it, as setting a reserved bit on v2.06 is naughty, and we
are only avoiding a bug on v3.00 by accident rather than design. Use
ASM_FTR_IFSET() to generate the single argument form on ISA v2.06 and later, and
the two argument form on pre v2.06.
Although there may be very old toolchains which don't understand tlbiel, we have
other code in the tree which has been using tlbiel for over five years, and no
one has reported any build failures, so just let the assembler generate the
instructions.
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
[mpe: Rewrite change log, use IFSET instead of IFCLR]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
When we're not compiling for a specific CPU, ie. none of the
CONFIG_POWERx_CPU options are set, and CONFIG_GENERIC_CPU *is* set, we
currently don't pass any -mcpu option to the compiler. This means the
compiler builds for a "generic" Power CPU.
But back in 2014 we dropped support for pre power4 CPUs in commit
468a33028edd ("powerpc: Drop support for pre-POWER4 cpus").
Given that, there's no point in building the kernel to run on pre power4
cpus. So update the flags we pass to the compiler when
CONFIG_GENERIC_CPU is set, to specify -mcpu=power4.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
This adds a config option that can help exercise the case when
the kernel is not running at PAGE_OFFSET.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
An hcall was recently added that does exactly what we need during kexec
- it clears the entire MMU hash table, ignoring any VRMA mappings.
Try it and fall back to the old method if we get a failure.
On a POWER8 box with 5TB of memory, this reduces the time it takes to
kexec a new kernel from from 4 minutes to 1 minute.
Signed-off-by: Anton Blanchard <anton@samba.org>
Tested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
[mpe: Split into separate functions and tweak function naming]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
That's unclear why lockdep shows the following warning but adding a
lockdep class to struct pmac_i2c_bus solves it
[ 20.507795] ======================================================
[ 20.507796] [ INFO: possible circular locking dependency detected ]
[ 20.507800] 4.8.0-rc7-00037-gd2ffb01 #21 Not tainted
[ 20.507801] -------------------------------------------------------
[ 20.507803] swapper/0/1 is trying to acquire lock:
[ 20.507818] (&bus->mutex){+.+.+.}, at: [<c000000000052830>] .pmac_i2c_open+0x30/0x100
[ 20.507819]
[ 20.507819] but task is already holding lock:
[ 20.507829] (&policy->rwsem){+.+.+.}, at: [<c00000000068adcc>] .cpufreq_online+0x1ac/0x9d0
[ 20.507830]
[ 20.507830] which lock already depends on the new lock.
[ 20.507830]
[ 20.507832]
[ 20.507832] the existing dependency chain (in reverse order) is:
[ 20.507837]
[ 20.507837] -> #4 (&policy->rwsem){+.+.+.}:
[ 20.507844] [<c00000000082385c>] .down_write+0x6c/0x110
[ 20.507849] [<c00000000068adcc>] .cpufreq_online+0x1ac/0x9d0
[ 20.507855] [<c0000000004d76d8>] .subsys_interface_register+0xb8/0x110
[ 20.507860] [<c000000000689bb0>] .cpufreq_register_driver+0x1d0/0x250
[ 20.507866] [<c000000000b4f8f4>] .g5_cpufreq_init+0x9cc/0xa28
[ 20.507872] [<c00000000000a98c>] .do_one_initcall+0x5c/0x1d0
[ 20.507878] [<c000000000b0f86c>] .kernel_init_freeable+0x1ac/0x28c
[ 20.507883] [<c00000000000b3bc>] .kernel_init+0x1c/0x140
[ 20.507887] [<c0000000000098f4>] .ret_from_kernel_thread+0x58/0x64
[ 20.507894]
[ 20.507894] -> #3 (subsys mutex#2){+.+.+.}:
[ 20.507899] [<c000000000820448>] .mutex_lock_nested+0xa8/0x590
[ 20.507903] [<c0000000004d7f24>] .bus_probe_device+0x44/0xe0
[ 20.507907] [<c0000000004d5208>] .device_add+0x508/0x730
[ 20.507911] [<c0000000004dd528>] .register_cpu+0x118/0x190
[ 20.507916] [<c000000000b14450>] .topology_init+0x148/0x248
[ 20.507921] [<c00000000000a98c>] .do_one_initcall+0x5c/0x1d0
[ 20.507925] [<c000000000b0f86c>] .kernel_init_freeable+0x1ac/0x28c
[ 20.507929] [<c00000000000b3bc>] .kernel_init+0x1c/0x140
[ 20.507934] [<c0000000000098f4>] .ret_from_kernel_thread+0x58/0x64
[ 20.507939]
[ 20.507939] -> #2 (cpu_add_remove_lock){+.+.+.}:
[ 20.507944] [<c000000000820448>] .mutex_lock_nested+0xa8/0x590
[ 20.507950] [<c000000000087a9c>] .register_cpu_notifier+0x2c/0x70
[ 20.507955] [<c000000000b267e0>] .spawn_ksoftirqd+0x18/0x4c
[ 20.507959] [<c00000000000a98c>] .do_one_initcall+0x5c/0x1d0
[ 20.507964] [<c000000000b0f770>] .kernel_init_freeable+0xb0/0x28c
[ 20.507968] [<c00000000000b3bc>] .kernel_init+0x1c/0x140
[ 20.507972] [<c0000000000098f4>] .ret_from_kernel_thread+0x58/0x64
[ 20.507978]
[ 20.507978] -> #1 (&host->mutex){+.+.+.}:
[ 20.507982] [<c000000000820448>] .mutex_lock_nested+0xa8/0x590
[ 20.507987] [<c0000000000527e8>] .kw_i2c_open+0x18/0x30
[ 20.507991] [<c000000000052894>] .pmac_i2c_open+0x94/0x100
[ 20.507995] [<c000000000b220a0>] .smp_core99_probe+0x260/0x410
[ 20.507999] [<c000000000b185bc>] .smp_prepare_cpus+0x280/0x2ac
[ 20.508003] [<c000000000b0f748>] .kernel_init_freeable+0x88/0x28c
[ 20.508008] [<c00000000000b3bc>] .kernel_init+0x1c/0x140
[ 20.508012] [<c0000000000098f4>] .ret_from_kernel_thread+0x58/0x64
[ 20.508018]
[ 20.508018] -> #0 (&bus->mutex){+.+.+.}:
[ 20.508023] [<c0000000000ed5b4>] .lock_acquire+0x84/0x100
[ 20.508027] [<c000000000820448>] .mutex_lock_nested+0xa8/0x590
[ 20.508032] [<c000000000052830>] .pmac_i2c_open+0x30/0x100
[ 20.508037] [<c000000000052e14>] .pmac_i2c_do_begin+0x34/0x120
[ 20.508040] [<c000000000056bc0>] .pmf_call_one+0x50/0xd0
[ 20.508045] [<c00000000068ff1c>] .g5_pfunc_switch_volt+0x2c/0xc0
[ 20.508050] [<c00000000068fecc>] .g5_pfunc_switch_freq+0x1cc/0x1f0
[ 20.508054] [<c00000000068fc2c>] .g5_cpufreq_target+0x2c/0x40
[ 20.508058] [<c0000000006873ec>] .__cpufreq_driver_target+0x23c/0x840
[ 20.508062] [<c00000000068c798>] .cpufreq_gov_performance_limits+0x18/0x30
[ 20.508067] [<c00000000068915c>] .cpufreq_start_governor+0xac/0x100
[ 20.508071] [<c00000000068a788>] .cpufreq_set_policy+0x208/0x260
[ 20.508076] [<c00000000068abdc>] .cpufreq_init_policy+0x6c/0xb0
[ 20.508081] [<c00000000068ae70>] .cpufreq_online+0x250/0x9d0
[ 20.508085] [<c0000000004d76d8>] .subsys_interface_register+0xb8/0x110
[ 20.508090] [<c000000000689bb0>] .cpufreq_register_driver+0x1d0/0x250
[ 20.508094] [<c000000000b4f8f4>] .g5_cpufreq_init+0x9cc/0xa28
[ 20.508099] [<c00000000000a98c>] .do_one_initcall+0x5c/0x1d0
[ 20.508103] [<c000000000b0f86c>] .kernel_init_freeable+0x1ac/0x28c
[ 20.508107] [<c00000000000b3bc>] .kernel_init+0x1c/0x140
[ 20.508112] [<c0000000000098f4>] .ret_from_kernel_thread+0x58/0x64
[ 20.508113]
[ 20.508113] other info that might help us debug this:
[ 20.508113]
[ 20.508121] Chain exists of:
[ 20.508121] &bus->mutex --> subsys mutex#2 --> &policy->rwsem
[ 20.508121]
[ 20.508123] Possible unsafe locking scenario:
[ 20.508123]
[ 20.508124] CPU0 CPU1
[ 20.508125] ---- ----
[ 20.508128] lock(&policy->rwsem);
[ 20.508132] lock(subsys mutex#2);
[ 20.508135] lock(&policy->rwsem);
[ 20.508138] lock(&bus->mutex);
[ 20.508139]
[ 20.508139] *** DEADLOCK ***
[ 20.508139]
[ 20.508141] 3 locks held by swapper/0/1:
[ 20.508150] #0: (cpu_hotplug.lock){++++++}, at: [<c000000000087838>] .get_online_cpus+0x48/0xc0
[ 20.508159] #1: (subsys mutex#2){+.+.+.}, at: [<c0000000004d7670>] .subsys_interface_register+0x50/0x110
[ 20.508168] #2: (&policy->rwsem){+.+.+.}, at: [<c00000000068adcc>] .cpufreq_online+0x1ac/0x9d0
[ 20.508169]
[ 20.508169] stack backtrace:
[ 20.508173] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.8.0-rc7-00037-gd2ffb01 #21
[ 20.508175] Call Trace:
[ 20.508180] [c0000000790c2b90] [c00000000082cc70] .dump_stack+0xe0/0x14c (unreliable)
[ 20.508184] [c0000000790c2c20] [c000000000828c88] .print_circular_bug+0x350/0x388
[ 20.508188] [c0000000790c2cd0] [c0000000000ecb0c] .__lock_acquire+0x196c/0x1d30
[ 20.508192] [c0000000790c2e50] [c0000000000ed5b4] .lock_acquire+0x84/0x100
[ 20.508196] [c0000000790c2f20] [c000000000820448] .mutex_lock_nested+0xa8/0x590
[ 20.508201] [c0000000790c3030] [c000000000052830] .pmac_i2c_open+0x30/0x100
[ 20.508206] [c0000000790c30c0] [c000000000052e14] .pmac_i2c_do_begin+0x34/0x120
[ 20.508209] [c0000000790c3150] [c000000000056bc0] .pmf_call_one+0x50/0xd0
[ 20.508213] [c0000000790c31e0] [c00000000068ff1c] .g5_pfunc_switch_volt+0x2c/0xc0
[ 20.508217] [c0000000790c3250] [c00000000068fecc] .g5_pfunc_switch_freq+0x1cc/0x1f0
[ 20.508221] [c0000000790c3320] [c00000000068fc2c] .g5_cpufreq_target+0x2c/0x40
[ 20.508226] [c0000000790c3390] [c0000000006873ec] .__cpufreq_driver_target+0x23c/0x840
[ 20.508230] [c0000000790c3440] [c00000000068c798] .cpufreq_gov_performance_limits+0x18/0x30
[ 20.508235] [c0000000790c34b0] [c00000000068915c] .cpufreq_start_governor+0xac/0x100
[ 20.508239] [c0000000790c3530] [c00000000068a788] .cpufreq_set_policy+0x208/0x260
[ 20.508244] [c0000000790c35d0] [c00000000068abdc] .cpufreq_init_policy+0x6c/0xb0
[ 20.508249] [c0000000790c3940] [c00000000068ae70] .cpufreq_online+0x250/0x9d0
[ 20.508253] [c0000000790c3a30] [c0000000004d76d8] .subsys_interface_register+0xb8/0x110
[ 20.508258] [c0000000790c3ad0] [c000000000689bb0] .cpufreq_register_driver+0x1d0/0x250
[ 20.508262] [c0000000790c3b60] [c000000000b4f8f4] .g5_cpufreq_init+0x9cc/0xa28
[ 20.508267] [c0000000790c3c20] [c00000000000a98c] .do_one_initcall+0x5c/0x1d0
[ 20.508271] [c0000000790c3d00] [c000000000b0f86c] .kernel_init_freeable+0x1ac/0x28c
[ 20.508276] [c0000000790c3db0] [c00000000000b3bc] .kernel_init+0x1c/0x140
[ 20.508280] [c0000000790c3e30] [c0000000000098f4] .ret_from_kernel_thread+0x58/0x64
Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
This halves the exception table size on 64-bit builds, and it allows
build-time sorting of exception tables to work on relocated kernels.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
[mpe: Minor asm fixups and bits to keep the selftests working]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
This macro is taken from s390, and allows more flexibility in
changing exception table format.
mpe: Put it in ppc_asm.h and only define one version using
stringinfy_in_c(). Add some empty definitions and headers to keep the
selftests happy.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
We haven't seen these before, but the soon to be merged relative
exception tables support causes them to be generated.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
There's no reason to #error if we include ppc_asm.h in asm files, the
ifdef already prevents any problems.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Exception handlers are aligned to 128 bytes (L1 cache) on 64s, which is
overkill. It can reduce the icache footprint of any individual exception
path. However taken as a whole, the expansion in icache footprint seems
likely to be counter-productive and cause more total misses.
Create IFETCH_ALIGN_SHIFT/BYTES, which should give optimal ifetch
alignment with much more reasonable alignment. This saves 1792 bytes
from head_64.o text with an allmodconfig build.
Other subarchitectures should define appropriate IFETCH_ALIGN_SHIFT
values if this becomes more widely used.
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
There are three #ifdef CONFIG_PPC_BOOK3E sections in nohash/64/pgtable.h.
And there should be no configurations possible which use nohash/64/pgtable.h
but don't also enable CONFIG_PPC_BOOK3E.
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Rui Teng <rui.teng@linux.vnet.ibm.com>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
Pull KVM fixes from Paolo Bonzini:
"ARM fixes. There are a couple pending x86 patches but they'll have to
wait for next week"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: arm/arm64: vgic: Kick VCPUs when queueing already pending IRQs
KVM: arm/arm64: vgic: Prevent access to invalid SPIs
arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU
|
|
Pull ARC fixes from Vineet Gupta:
- mmap handler for dma ops as generic handler no longer works for us
[Alexey]
- Fixes for EZChip platform [Noam]
- Fix RTC clocksource driver build issue
- ARC IRQ handling fixes [Yuriy]
- Revert a recent makefile change which doesn't go well with oldish
tools out in the wild
* tag 'arc-4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARCv2: MCIP: Use IDU_M_DISTRI_DEST mode if there is only 1 destination core
ARC: IRQ: Do not use hwirq as virq and vice versa
ARC: [plat-eznps] set default baud for early console
ARC: [plat-eznps] remove IPI clear from SMP operations
Revert "ARC: build: retire old toggles"
ARC: timer: rtc: implement read loop in "C" vs. inline asm
ARC: change return value of userspace cmpxchg assist syscall
arc: Implement arch-specific dma_map_ops.mmap
ARC: [SMP] avoid overriding present cpumask
ARC: Enable PERF_EVENTS in nSIM driven platforms
|
|
Pull PCI fixes from Bjorn Helgaas:
- Update MAINTAINERS for Intel VMD driver filename
- Update Rockchip rk3399 host bridge driver DTS and resets
- Fix ROM shadow problem that made some video device initialization
fail
* tag 'pci-v4.9-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: VMD: Update filename to reflect move
arm64: dts: rockchip: add three new resets for rk3399 PCIe controller
PCI: rockchip: Add three new resets as required properties
PCI: Don't attempt to claim shadow copies of ROM
|
|
Merge fixes for -Wmaybe-uninitialized from Arnd Bergmann:
"It took a while for some patches to make it into mainline through
maintainer trees, but the 28-patch series is now reduced to 10, with
one tiny patch added at the end.
Aside from patches that are no longer required, I did these changes
compared to version 1:
- Dropped "iio: maxim_thermocouple: detect invalid storage size in
read()", which is currently in linux-next as commit 32cb7d27e65d.
This is the only remaining warning I see for a couple of corner
cases (kbuild bot reports it on blackfin, kernelci bot and arm-soc
bot both report it on arm64)
- Dropped "brcmfmac: avoid maybe-uninitialized warning in
brcmf_cfg80211_start_ap", which is currently in net/master merge
pending.
- Dropped two x86 patches, "x86: math-emu: possible uninitialized
variable use" and "x86: mark target address as output in 'insb'
asm" as they do not seem to trigger for a default build, and I got
no feedback on them. Both of these are ancient issues and seem
harmless, I will send them again to the x86 maintainers once the
rest is merged.
- Dropped "rbd: false-postive gcc-4.9 -Wmaybe-uninitialized" based on
feedback from Ilya Dryomov, who already has a different fix queued
up for v4.10. The kbuild bot reports this as a warning for xtensa.
- Replaced "crypto: aesni: avoid -Wmaybe-uninitialized warning" with
a simpler patch, this one always triggers but my first solution
would not be safe for linux-4.9 any more at this point. I'll follow
up with the larger patch as a cleanup for 4.10.
- Replaced "dib0700: fix nec repeat handling" with a better one,
contributed by Sean Young"
* -Wmaybe-uninitialized fixes:
Kbuild: enable -Wmaybe-uninitialized warnings by default
pcmcia: fix return value of soc_pcmcia_regulator_set
infiniband: shut up a maybe-uninitialized warning
crypto: aesni: shut up -Wmaybe-uninitialized warning
rc: print correct variable for z8f0811
dib0700: fix nec repeat handling
s390: pci: don't print uninitialized data for debugging
nios2: fix timer initcall return value
x86: apm: avoid uninitialized data
NFSv4.1: work around -Wmaybe-uninitialized warning
Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"
|
|
The rfc4106 encrypy/decrypt helper functions cause an annoying
false-positive warning in allmodconfig if we turn on
-Wmaybe-uninitialized warnings again:
arch/x86/crypto/aesni-intel_glue.c: In function ‘helper_rfc4106_decrypt’:
include/linux/scatterlist.h:67:31: warning: ‘dst_sg_walk.sg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
The problem seems to be that the compiler doesn't track the state of the
'one_entry_in_sg' variable across the kernel_fpu_begin/kernel_fpu_end
section.
This takes the easy way out by adding a bogus initialization, which
should be harmless enough to get the patch into v4.9 so we can turn on
this warning again by default without producing useless output. A
follow-up patch for v4.10 rearranges the code to make the warning go
away.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
gcc correctly warns about an incorrect use of the 'pa' variable in case
we pass an empty scatterlist to __s390_dma_map_sg:
arch/s390/pci/pci_dma.c: In function '__s390_dma_map_sg':
arch/s390/pci/pci_dma.c:309:13: warning: 'pa' may be used uninitialized in this function [-Wmaybe-uninitialized]
This adds a bogus initialization to the function to sanitize the debug
output. I would have preferred a solution without the initialization,
but I only got the report from the kbuild bot after turning on the
warning again, and didn't manage to reproduce it myself.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
When called more than twice, the nios2_time_init() function return an
uninitialized value, as detected by gcc -Wmaybe-uninitialized
arch/nios2/kernel/time.c: warning: 'ret' may be used uninitialized in this function
This makes it return '0' here, matching the comment above the function.
Acked-by: Ley Foon Tan <lftan@altera.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
apm_bios_call() can fail, and return a status in its argument structure.
If that status however is zero during a call from
apm_get_power_status(), we end up using data that may have never been
set, as reported by "gcc -Wmaybe-uninitialized":
arch/x86/kernel/apm_32.c: In function ‘apm’:
arch/x86/kernel/apm_32.c:1729:17: error: ‘bx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1835:5: error: ‘cx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1730:17: note: ‘cx’ was declared here
arch/x86/kernel/apm_32.c:1842:27: error: ‘dx’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
arch/x86/kernel/apm_32.c:1731:17: note: ‘dx’ was declared here
This changes the function to return "APM_NO_ERROR" here, which makes the
code more robust to broken BIOS versions, and avoids the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].
Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.
With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.
However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then. This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle. Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.
I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.
This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives. A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Limit the number of kmemleak false positives by including
.data.ro_after_init in memory scanning. To achieve this we need to add
symbols for start and end of the section to the linker scripts.
The problem was been uncovered by commit 56989f6d8568 ("genetlink: mark
families as __ro_after_init").
Link: http://lkml.kernel.org/r/1478274173-15218-1-git-send-email-jakub.kicinski@netronome.com
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
KVM/ARM updates for v4.9-rc4
- Kick the vcpu when a pending interrupt becomes pending again
- Prevent access to invalid interrupt registers
- Invalid TLBs when two vcpus from the same VM share a CPU
|
|
pm_rst, aclk_rst and pclk_rst should be controlled by driver, so we
need to add these three resets for PCIe controller.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Heiko Stuebner <heiko@sntech.de>
|
|
Pull s390 fixes from Martin Schwidefsky:
"Two bug fixes
- a memory alignment fix in the s390 only hypfs code
- a fix for the generic percpu code that caused ftrace to break on
s390. This is not relevant for x86 but for all architectures that
use the generic percpu code"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
percpu: use notrace variant of preempt_disable/preempt_enable
s390/hypfs: Use get_free_page() instead of kmalloc to ensure page alignment
|
|
ARC linux uses 2 distribution modes for common interrupts: round robin
mode (IDU_M_DISTRI_RR) and a simple destination mode (IDU_M_DISTRI_DEST).
The first one is used when more than 1 cores may handle a common interrupt
and the second one is used when only 1 core may handle a common interrupt.
However idu_irq_set_affinity() always sets IDU_M_DISTRI_RR for all affinity
values. But there is no sense in setting of such mode if only 1 core must
handle a common interrupt.
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
This came up when reviewing code to address missing IRQ affinity
setting in AXS103 platform and/or implementing hierarchical IRQ domains
- smp_ipi_irq_setup() callers pass hwirq but in turn calls
request_percpu_irq() which expects a linux virq. So invoke
irq_find_mapping() to do the conversion
(also explicitify this in code by renaming the args appropriately)
- idu_of_init()/idu_cascade_isr() were similarly using linux virq where
hwirq is expected, so do the conversion using irqd_to_hwirq() helper
Signed-off-by: Yuriy Kolerov <yuriy.kolerov@synopsys.com>
[vgupta: made changelog a bit concise a bit]
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
Rashmica Gupta
Michael Ellerman
Balbir Singh
Bartlomiej Zolnierkiewicz
Johan Hovold
Jack Miller
Michael Neuling
Nicholas Piggin
Anton Blanchard
Denis Kirjanov
Rui Teng
Linus Torvalds
Arnd Bergmann
Jakub Kicinski
Paolo Bonzini
Shawn Lin
Yuriy Kolerov