Commit 8bd26e3a7 (arm: delete __cpuinit/__CPUINIT usage from all ARM
users) caused some code to leak into sections which are discarded
through the removal of __CPUINIT annotations. Add appropriate .text
annotations to bring these back into the kernel text.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If one process calls sys_reboot and that process then stops other
CPUs while those CPUs are within a spin_lock() region we can
potentially encounter a deadlock scenario like below.
CPU 0 CPU 1
----- -----
spin_lock(my_lock)
smp_send_stop()
<send IPI> handle_IPI()
disable_preemption/irqs
while(1);
<PREEMPT>
spin_lock(my_lock) <--- Waits forever
We shouldn't attempt to run any other tasks after we send a stop
IPI to a CPU so disable preemption so that this task runs to
completion. We use local_irq_disable() here for cross-arch
consistency with x86.
Reported-by: Sundarajan Srinivasan <sundaraj@codeaurora.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
If kuser helpers are not provided by the kernel, disable user access to
the vectors page. With the kuser helpers gone, there is no reason for
this page to be visible to userspace.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Move the signal handlers into a VDSO page rather than keeping them in
the vectors page. This allows us to place them randomly within this
page, and also map the page at a random location within userspace
further protecting these code fragments from ROP attacks. The new
VDSO page is also poisoned in the same way as the vector page.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Provide a kernel configuration option to allow the kernel user helpers
to be removed from the vector page, thereby preventing their use with
ROP (return orientated programming) attacks. This option is only
visible for CPU architectures which natively support all the operations
which kernel user helpers would normally provide, and must be enabled
with caution.
Cc: <stable@vger.kernel.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
FIQ should no longer copy the FIQ code into the user visible vector
page. Instead, it should use the hidden page. This change makes
that happen.
Cc: <stable@vger.kernel.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Use linker magic to create the vectors and vector stubs: we can tell the
linker to place them at an appropriate VMA, but keep the LMA within the
kernel. This gets rid of some unnecessary symbol manipulation, and
have the linker calculate the relocations appropriately.
Cc: <stable@vger.kernel.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Move the machine vector stubs into the page above the vector page,
which we can prevent from being visible to userspace. Also move
the reset stub, and place the swi vector at a location that the
'ldr' can get to it.
This hides pointers into the kernel which could give valuable
information to attackers, and reduces the number of exploitable
instructions at a fixed address.
Cc: <stable@vger.kernel.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Poison the memory between each kuser helper. This ensures that any
branch between the kuser helpers will be appropriately trapped.
Cc: <stable@vger.kernel.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Fill the empty regions of the vectors page with an exception generating
instruction. This ensures that any inappropriate branch to the vector
page is appropriately trapped, rather than just encountering some code
to execute. (The vectors page was filled with zero before, which
corresponds with the "andeq r0, r0, r0" instruction - a no-op.)
Cc: <stable@vger.kernel.org>
Acked-by Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 621a0147d5c921f4cc33636ccd0602ad5d7cbfbc ("ARM: 7757/1: mm:
don't flush icache in switch_mm with hardware broadcasting") breaks
the boot on OMAP2430SDP with omap2plus_defconfig. Tracked to an
undefined instruction abort from the CP15 read in
cache_ops_need_broadcast(). It turns out that gcc 4.5 reorders the
extended CP15 read above the is_smp() test. This breaks ARM1136 r0
cores, since they don't support several CP15 registers that later ARM
cores do. ARM1136JF-S TRM section 3.2.1 "Register allocation" has the
details.
So mark the extended CP15 read as clobbering memory, which prevents
the compiler from reordering it before the is_smp() test. Russell
states that the code generated from this approach is preferable to
marking the inline asm as volatile. Remove the existing condition
code clobber as it's obsolete, per Nico's post:
http://www.spinics.net/lists/arm-kernel/msg261208.html
This patch is a collaboration with Will Deacon and Russell King.
Comments from Paul Walmsley:
Russell, if you accept this one, might you also add Will's ack from the lists:
Comments from Paul Walmsley:
I'd also be obliged if you could add a Cc: line for Jonathan Austin, since he helped test:
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Jonathan Austin <jonathan.austin@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The name changed in response to review comments for the nvic irqchip
driver when the original name was already accepted into Russell King's
tree.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When the gpio-keys device is registered using
platform_device_register_data() the platform data argument,
lager_keys_pdata is duplicated and thus should be marked as __initdata
to avoid wasting memory. However, this is not true of gpio_buttons,
a reference to it rather than its value is duplicated when lager_keys_pdata
is duplicated.
This avoids accessing freed memory if gpio-key events occur
after unused kernel memory is freed late in the kernel's boot.
This but was added when support for gpio-keys was added to lager
in c3842e4fcbb7664276443b79187b7808c2e80a35
("ARM: shmobile: lager: support GPIO switches") which was included
in v3.11-rc1.
Tested-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The following message is printed on the BOCK-W kernel bootup:
sh-pfc pfc-r8a7778: invalid group "sdhi0" for function "sdhi0"
In addition, SD card cannot be detected. The reason is apparently that commit
ca7bb309485e4ec89a9addd47bea (ARM: shmobile: bockw: add SDHI0 support) matched
the previous version of commit 564617d2f92473031d035deb273da5 (sh-pfc: r8a7778:
add SDHI support).
Add the missing pin groups according to the BOCK-W board schematics.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Register target address to be used for cpgmac is the second device
address space. By default, hwmod picks first address space (0th index)
for register target.
With removal of address space from hwmod and using DT instead, cpgmac
is getting wrong address space for register target.
Fix it by indicating the address space to be used for register target.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Address space is being removed from hwmod database and DT information
in <reg> property is being used. Currently the 0th index of device
address space is used to map for register target address. This is not
always true, eg. cpgmac has it's sysconfig in second address space.
Handle it by specifying index of device address space to be used for
register target. As default value of this field would be zero with
static initialization, existing behaviour of using first address space
for register target while using DT would be kept as such.
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
[paul@pwsan.com: use u8 rather than int to save memory]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some hwmods which are marked with HWMOD_INIT_NO_IDLE are left in enabled
state post setup(). When a omap_device gets created for such hwmods
make sure the omap_device and pm_runtime states are also in sync for such
hwmods by doing a omap_device_enable() and pm_runtime_set_active() for the
device.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.
Even if they have drivers missing, avoid idling them as part of
omap_device_late_idle()
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
With commit '82702ea11ddfe0e43382e1fa5b66d807d8114916' "ARM: OMAP2+:
Fix serial init for device tree based booting" stubbing out
omap_serial_early_init() for Device tree based booting, there was a
crash observed on AM335x based devices when hwmod does a
_setup_reset() early at boot.
This was rootcaused to hwmod trying to reset console uart while
earlycon was using it. The way to tell hwmod not to do this is to
specify the HWMOD_INIT_NO_RESET flag, which were infact set by the
omap_serial_early_init() function by parsing the cmdline to identify
the console device.
Parsing the cmdline to identify the uart used by earlycon itself seems
broken as there is nothing preventing earlycon to use a different one.
This patch, instead, attempts to populate the requiste flags for hwmod
based on the CONFIG_DEBUG_OMAPxUARTy FLAGS. This gets rid of the need
for cmdline parsing in the DT as well as non-DT cases to identify the
uart used by earlycon.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Reported-by: Mark Jackson <mpfj-list@newflow.co.uk>
Reported-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
The following optional/unused regulators can be updated:
- SMPS9 supplies TWL6040 over VDDA_2v1_AUD. This regulator needs to be
enabled only when audio is active. Since it does not come active by
default, it does not require "always-on" or "boot-on".
- LDO2 and LDO8 do not go to any peripheral or connector on the board.
Further, these unused regulators should have been 2.8V for LDO2 and
3.0V for LDO8. Mark these LDOs as disabled in the dts until needed.
Reported-by: Marc Jüttner <m-juettner@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: J Keerthy <j-keerthy@ti.com>
Acked-by: Benoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, The regulator information is based on an older temporary
pre-production board variant and does not reflect production board
750-2628-XXX boards.
The following fixes are hence mandatory to ensure right voltage is
supplied to key OMAP5 SoC voltage rails:
- LDO1 supplies VDDAPHY_CAM which is OMAP5's vdda_csiporta/b/c. This
can only be supplied at 1.5V or 1.8V and we currently supply 2.8V.
To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.
Remove 'always-on' and 'boot-on' settings here as it is
a 'on need' supply to SoC IP and is not enabled by PMIC by
default at boot.
- LDO3 supplies Low Latency Interface(LLI) hardware module which is a
special hardware to communicate with Modem. However since uEVM is
not setup by default for this communication, this should be disabled
by default.
Further, vdda_lli is supposed to be 1.5V and not 3V.
- LDO4 supplies VDDAPHY_DISP which is vdda_dsiporta/c/vdda_hdmi
This can only be supplied at 1.5V or 1.8V and we currently
supply 2.2V.
To prevent any potential device damage risk, use the specified
1.5V-1.8V supply.
Remove 'always-on' and 'boot-on' settings here as it is a 'on need'
supply to SoC IP and is not enabled by PMIC by default at boot.
- LDO6 supplies the board specified VDDS_1V2_WKUP supply going to
ldo_emu_wkup/vdds_hsic. To stay within the SoC specification supply
1.2V instead of 1.5V.
- LDO7 supplies VDD_VPP which is vpp1. This is currently configured for
1.5V which as per data manual "A pulse width of 1000 ns and an amplitude
of 2V is required to program each eFuse bit. Otherwise, VPP1 must not
be supplied".
So, fix the voltage to 2V. and disable the supply since we have no plans
of programming efuse bits - it can only be done once - in factory.
Further it is not enabled by default by PMIC so, 'boot-on' must be
removed, and the 'always-on' needs to be removed to achieve pulsing
if efuse needs to be programmed.
- LDO9 supplies the board specified vdds_sdcard supply going within SoC
specification of 1.8V or 3.0V. Further the supply is controlled by
switch enabled by REGEN3. So, introduce REGEN3 and map sdcard slot to
be powered by LDO9. Remove 'always-on' allowing the LDO to be disabled
on need basis.
Reported-by: Marc Jüttner <m-juettner@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: J Keerthy <j-keerthy@ti.com>
Acked-by: Benoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
commit e00c27ef3b4c23e39d0a77b7c8e5be44c28001c7
(ARM: dts: OMAP5: Add Palmas MFD node and regulator nodes)
introduced regulator entries for OMAP5uEVM.
However, currently we use the Palmas regulator names which is used for
different purposes on uEVM. Document the same based on 750-2628-XXX
boards - which is meant to be supported by this dts.
Reported-by: Marc Jüttner <m-juettner@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: J Keerthy <j-keerthy@ti.com>
Acked-by: Benoit Cousson <benoit.cousson@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Since commit 7ed76e08 (ARM: EXYNOS: Fix low level debug support)
map_io() is not needed for exynos5440 so need to fix to lookup
cpu which using map_io(). Without this, kernel boot log complains
'CPU EXYNOS5440 support not enabled' on exynos5440 and panic().
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
- Driver fixes for AM33xx, SIRF and PFC pin controllers.
- Fix a compile warning from the pinctrl single-register
driver.
- Fix a little nasty memory leak.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJR9YhoAAoJEEEQszewGV1zfl8P/jk2VjlRE0P4LRLSRn3Rt7yj
Wz7IyZTol+mFnaY0yKQS9rToK+GqtJQHA1zuNP8iQnJbQh+UromAZwBd58dP7cnu
mYSi2QS4osYT5RjvVtB2yYy9sRrc4iTb+qJFekanA4IcHt0zKDZysyN8moU5JxmN
TVr+cauFm7qimkjps2Dns94UhVGpgB7A6Y8yC3SYtPv1GPdWQgSaDabWqMYq0bn1
ARUaz3XcbjMAGbPi8kDEFsP/SkM2OcMXpjX23G6ifgO9pyEKeum5+FWtllVeeAzb
LmymMJYVcTPLFw0yj+9lkRBew2K9JKmPp8rAUBvbDn53vbguMkDJTczM3IUZ279h
lRvR+w9F2M1rqIfwSa0/ZqTYKXbsF/IASYMXL/awNywnss+caPUxiN4EWRuKDssS
Wh6veS9l4roMupaez6GU7gQ8UgNnFTQg2BYzeFYbAg1jJ1b/U+E0MK/9yUzewXQw
phlcFFibYce+1qhJhQ3lIYb6O512vw+2Xk+G6JBZVuwzMVvUUJwJqfGRKCoobxZz
DRBIQJ9U4DRMethjfp5mP0H6nH7/fwKqvftKlsnOb9SXZregpcLV+ymrkkmW/Ey2
XuEHQqUbmD0zoPHvFgoUmAYlzmhxtmHK5uJDSH1aZ4b9IOzr2mV1RSt0xwo3BpTS
gwtDvmutV/JQ8RZMLLvw
=URtB
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
- Driver fixes for AM33xx, SIRF and PFC pin controllers
- Fix a compile warning from the pinctrl single-register driver
- Fix a little nasty memory leak
* tag 'pinctrl-for-v3.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: fix a memleak when freeing maps
pinctrl: pinctrl-single: fix compile warning when no CONFIG_PM
pinctrl: sh-pfc: fix SDHI0 VccQ regulator on sh73a0 with DT
arm/dts: sirf: fix the pingroup name mismatch between drivers and dts
pinctrl: sirf: add usp0_uart_nostreamctrl pin group for usp-uart without flowctrl
pinctrl: sirf: fix the pin number and mux bit for usp0
pinctrl: am33xx dt binding: correct include path
So, there's a comment I put at the top of this, which people seem to
fail to read. So let's fix it for them instead.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Msm gpiomux can be used only for 7x30 and 8x50.
Prevent compilation and fix build issues on 7X00, 8X60 and 8960.
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
a.out support on ARM requires that argc, argv and envp are passed in
r0-r2 respectively, which requires hacking load_aout_binary to
prevent argc being clobbered by the return code. Whilst mainline kernels
do set the registers up in start_thread, the aout loader has never
carried the hack in mainline.
Initialising the registers in this way actually goes against the libc
expectations for ELF binaries, where argc, argv and envp are passed on
the stack, with r0 being used to hold a pointer to an exit function for
cleaning up after the dynamic linker if required. If the pointer is
NULL, then it is ignored. When execing an ELF binary, Linux currently
zeroes r0, then sets it to argc and then finally clobbers it with the
return value of the execve syscall, so we actually end up with:
r0 = 0
stack[0] = argc
r1 = stack[1] = argv
r2 = stack[2] = envp
libc treats r1 and r2 as undefined. The clobbering of r0 by sys_execve
works for user-spawned threads, but when executing an ELF binary from a
kernel thread (via call_usermodehelper), the execve is performed on the
ret_from_fork path, which restores r0 from the saved pt_regs, resulting
in argc being presented to the C library. This has horrible consequences
when the application exits, since we have an exit function registered
using argc, resulting in a jump to hyperspace.
This patch solves the problem by removing the partial a.out support from
arch/arm/ altogether.
Cc: <stable@vger.kernel.org>
Cc: Ashish Sangwan <ashishsangwan2@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
As of commit b9d4d42ad9 (ARM: Remove __ARCH_WANT_INTERRUPTS_ON_CTXSW on
pre-ARMv6 CPUs), the mm switching on VIVT processors is done in the
finish_arch_post_lock_switch() function to avoid whole cache flushing
with interrupts disabled. The need for deferred mm switch is stored as a
thread flag (TIF_SWITCH_MM). However, with preemption enabled, we can
have another thread switch before finish_arch_post_lock_switch(). If the
new thread has the same mm as the previous 'next' thread, the scheduler
will not call switch_mm() and the TIF_SWITCH_MM flag won't be set for
the new thread.
This patch moves the switch pending flag to the mm_context_t structure
since this is specific to the mm rather than thread.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Marc Kleine-Budde <mkl@pengutronix.de>
Tested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: <stable@vger.kernel.org> # 3.5+
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Commit 93dc688 (ARM: 7684/1: errata: Workaround for Cortex-A15 erratum 798181 (TLBI/DSB operations)) causes the following undefined instruction error on a mx53 (Cortex-A8):
Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
CPU: 0 PID: 275 Comm: modprobe Not tainted 3.11.0-rc2-next-20130722-00009-g9b0f371 #881
task: df46cc00 ti: df48e000 task.ti: df48e000
PC is at check_and_switch_context+0x17c/0x4d0
LR is at check_and_switch_context+0xdc/0x4d0
This problem happens because check_and_switch_context() calls dummy_flush_tlb_a15_erratum() without checking if we are really running on a Cortex-A15 or not.
To avoid this issue, only call dummy_flush_tlb_a15_erratum() inside
check_and_switch_context() if erratum_a15_798181() returns true, which means that we are really running on a Cortex-A15.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Secondary CPUs write to __boot_cpu_mode with caches disabled, and thus a
cached value of __boot_cpu_mode may be incoherent with that in memory.
This could lead to a failure to detect mismatched boot modes.
This patch adds flushing to ensure that writes by secondaries to
__boot_cpu_mode are made visible before we test against it.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <cdall@cs.columbia.edu>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
89ae7b5bbd3e65bc6ab7a577ca5ec18569589c8c
(ARM: shmobile: armadillo800eva: Register pinctrl mapping for INTC)
mistakenly requests GPIO 166 in board code,
most probably due to a wrong merge conflict resolution.
As the GPIO is passed to the st1232 driver through platform
data and requested by the driver,
there's no need to request it in board code. Fix it.
Tested by: Cao Minh Hiep <cm-hiep@jinso.co.jp>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
- fix kernel booting on exynos5440
skip pm which is not supported
update regarding LPAE features
- fix s3c2440 uart with adding clkdev entries
- fix compilatioin for Samsung SoCs with selecting pm
- update ARCH_NR_GPIO to support exynos4412 has more gpios
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJR8AZBAAoJEA0Cl+kVi2xqSNIP/iBgogT3O18Aj2dclg9QDh7L
YTnT60p7VsoevAb+mVS0rcxpgFGIvuM6TII65VGMNQNeHgwOJzrFT2rWe0NQ0kCw
DUE3717+sHcqiGDxnsyffeJL+7THSZiZUzkgxmKSb22yTzb1uO1gDrF2uT/njAgh
6lsthqKZjKhi8KL9qXGEeh1HgxNaQWGUrTcpEWFGYxpF+wyrQuFjOJoRQJc7dKsp
JdlSiR+R5mTWvo5HAiT0QH97JzT5xuk5p8lMrxbmkwfEmewKeM89uIv1bjrOl3qa
O4OY5fZ5oamQBjETTfeQtgJxciKrogg3uyCjsVsX2PX0s1u/vcukJnn52wY9gb64
y6Ge6qlwnzWkhvPEJeH9GEGDQcUPr9OgZABSBxNTja6rJdTjHJKgImU38BvLOopp
nedsmDn63kTi7Vr4NDP8iRcMenEZMeaGuscVvU4TfdBOX95RJOu4SI3fT/VCSuvm
hHvjfGfLUF15P0qdAthvmj8W4ZbNr0KViP12kaEF4MeU+MqOiZb8JlHP9ebPp7ao
FtO47Mic1FIdA4mL6GEbJxK43N1klNQ6q/xobOattPA2TPZ4sk4nCB3lqtXS2ZFJ
51yToCMv23oY5AynP95qAMnYYJCP1UyPHlsV7n8jMgm3ZzePC2pv1WAZr4ZsPWu3
zBJom5YPKZUaoDN7xl7z
=ygWA
-----END PGP SIGNATURE-----
Merge tag 'samsung-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung into fixes
From Kukjin Kim:
Samsung fixes for v3.11
- fix kernel booting on exynos5440
skip pm which is not supported
update regarding LPAE features
- fix s3c2440 uart with adding clkdev entries
- fix compilatioin for Samsung SoCs with selecting pm
- update ARCH_NR_GPIO to support exynos4412 has more gpios
* tag 'samsung-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Update CONFIG_ARCH_NR_GPIO for Exynos
ARM: EXYNOS: Fix low level debug support
ARM: SAMSUNG: Save/restore only selected uart's registers
ARM: SAMSUNG: Add SAMSUNG_PM config option to select pm
ARM: S3C24XX: Add missing clkdev entries for s3c2440 UART
ARM: EXYNOS: Enable 64-bit DMA for EXYNOS5440 if LPAE is enabled
ARM: EXYNOS: change the PHYSMEM_BITS and SECTION_SIZE
ARM: EXYNOS: skip pm support on exynos5440
Signed-off-by: Olof Johansson <olof@lixom.net>
Avoids the following warning when SMP is off:
warning: (ARCH_KEYSTONE && SOC_OMAP5) selects ARM_ERRATA_798181 which
has unmet direct dependencies (CPU_V7 && SMP)
Reported-by: Emilio López <emilio@elopez.com.ar>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
On some PAE architectures, the entire range of physical memory could reside
outside the 32-bit limit. These systems need the ability to specify the
initrd location using 64-bit numbers.
This patch globally modifies the early_init_dt_setup_initrd_arch() function to
use 64-bit numbers instead of the current unsigned long.
There has been quite a bit of debate about whether to use u64 or phys_addr_t.
It was concluded to stick to u64 to be consistent with rest of the device
tree code. As summarized by Geert, "The address to load the initrd is decided
by the bootloader/user and set at that point later in time. The dtb should not
be tied to the kernel you are booting"
More details on the discussion can be found here:
https://lkml.org/lkml/2013/6/20/690https://lkml.org/lkml/2012/9/13/544
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>
With the recent cleanup in Exynos platform code notably commits
17859bec ("ARM: EXYNOS: Do not select legacy Kconfig symbols any
more") and b9222210 ("ARM: EXYNOS: Remove mach/gpio.h"), the definition
of ARCH_NR_GPIOS got removed. This started causing problems on SoCs like
Exynos4412 which have more than the default number of GPIOs. Thus define
this number in KConfig file which takes care of current SoC requirements
and provides scope for GPIO expanders. Without this patch we get the
following errors during boot:
gpiochip_add: gpios 251..258 (gpv0) failed to register
samsung-pinctrl 106e0000.pinctrl: failed to register gpio_chip gpv0, error code: -22
samsung-pinctrl: probe of 106e0000.pinctrl failed with error -22
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Tomasz Figa <t.figa@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Presently, using exynos_defconfig with CONFIG_DEBUG_LL and CONFIG_EARLY_PRIN
on, kernel is not booting, we are getting following:
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] kernel BUG at mm/vmalloc.c:1134!
[ 0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc1 #633
[ 0.000000] task: c052ec48 ti: c0524000 task.ti: c0524000
[ 0.000000] PC is at vm_area_add_early+0x54/0x94
[ 0.000000] LR is at add_static_vm_early+0xc/0x60
Its because exynos[4/5]_map_io() function ioremaps a single 512KB memory
size for all the four uart ports which envelopes the mapping created by
debug_ll_io_init(), called earlier in exynos_init_io().
This patch removes iodesc entries for UART controller for all Samsung SoC's,
since now the Samsung uart driver does a ioremap during probe and any needed
iomapping for earlyprintk will be handled by debug_ll_io_init().
Tested on smdk4412 and smdk5250.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Basically this code gets executed only during debugging i.e when
DEBUG_LL & SAMSUNG_PM_DEBUG is on, so required only for UART used
for debugging. Since we are removing static iodesc entries for UARTs,
so now only the selected (CONFIG_DEBUG_S3C_UART) UART will be
ioremapped by the debug_ll_io_init() for DEBUG_LL, so save/restore
uart registers only for selected uart.
Signed-off-by: Yadwinder Singh Brar <yadi.brar@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch enables the selection of samsung pm related stuffs
when SAMSUNG_PM config is enabled and not just when generic PM
config is enabled. Power management for s3c64XX and s3c24XX
is enabled by default and for other platform depends on S5P_PM.
This patch also fixes the following compilation error's when compiling
a platform like exynos5440 which does not select pm stuffs.
arch/arm/mach-exynos/built-in.o: In function '__virt_to_phys':
linux/arch/arm/include/asm/memory.h:175: undefined reference to 's3c_cpu_resume'
linux/arch/arm/include/asm/memory.h:175: undefined reference to 's3c_cpu_resume'
linux/arch/arm/include/asm/memory.h:175: undefined reference to 's3c_cpu_resume'
linux/arch/arm/include/asm/memory.h:175: undefined reference to 's3c_cpu_resume'
arch/arm/mach-exynos/built-in.o: In function 'exynos5_init_irq':
linux/arch/arm/mach-exynos/common.c:492: undefined reference to 's3c_irq_wake'
linux/arch/arm/mach-exynos/common.c:492: undefined reference to 's3c_irq_wake'
arch/arm/mach-exynos/built-in.o: In function 'exynos4_init_irq':
linux/arch/arm/mach-exynos/common.c:476: undefined reference to 's3c_irq_wake'
linux/arch/arm/mach-exynos/common.c:476: undefined reference to 's3c_irq_wake'
arch/arm/plat-samsung/built-in.o: In function 's3c_irqext_wake':
linux/arch/arm/plat-samsung/pm.c:144: undefined reference to 's3c_irqwake_eintallow'
linux/arch/arm/plat-samsung/pm.c:144: undefined reference to 's3c_irqwake_eintallow'
arch/arm/plat-samsung/built-in.o: In function 's3c_pm_enter':
linux/arch/arm/plat-samsung/pm.c:263: undefined reference to 's3c_irqwake_intallow'
linux/arch/arm/plat-samsung/pm.c:263: undefined reference to 's3c_irqwake_intallow'
linux/arch/arm/plat-samsung/pm.c:264: undefined reference to 's3c_irqwake_eintallow'
linux/arch/arm/plat-samsung/pm.c:264: undefined reference to 's3c_irqwake_eintallow'
linux/arch/arm/plat-samsung/pm.c:275: undefined reference to 's3c_pm_save_core'
linux/arch/arm/plat-samsung/pm.c:279: undefined reference to 's3c_pm_configure_extint'
linux/arch/arm/plat-samsung/pm.c:310: undefined reference to 's3c_pm_restore_core'
make: *** [vmlinux] Error 1
Signed-off-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This patch restores serial port operation which has been broken since
commit 60e93575476f ("serial: samsung: enable clock before clearing
pending interrupts during init")
That commit only uncovered the real issue which was missing clkdev
entries for the "uart" clocks on S3C2440. It went unnoticed so far
because return value of clk API calls were not being checked at all
in the samsung serial port driver.
This patch should be backported to at least 3.10 stable kernel, since
the serial port has not been working on s3c2440 since 3.10-rc5.
Cc: Chander Kashyap <chander.kashyap@linaro.org>
Signed-off-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
[on S3C2440 SoC based Mini2440 board]
Tested-by: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Tested-by: Juergen Beisert <jbe@pengutronix.de>
Cc: <stable@vger.kernel.org> [3.10]
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
CONFIG_USB_EHCI_MXC selects the old i.mx USB driver, which does not support
device tree.
Select the USB chipidea driver instead, so that USB can be functional on i.mx.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
The em_x270_mci_setpower() and em_x270_usb_hub_init() functions
call regulator_enable(), which may return an error that must
be checked.
This changes the em_x270_usb_hub_init() function to bail out
if it fails, and changes the pxamci_platform_data->setpower
callback so that the a failed em_x270_mci_setpower call
can be propagated by the pxamci driver into the mmc core.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mike Rapoport <mike@compulab.co.il>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Acked-by: Chris Ball <cjb@laptop.org>
[olof: fixed order of regulator_enable() and test in em_x270_usb_hub_init]
Signed-off-by: Olof Johansson <olof@lixom.net>
Fix the following compilation warning:
arch/arm/mach-zynq/common.c:110:2: warning: initialization from incompatible pointer type [enabled by default]
arch/arm/mach-zynq/common.c:110:2: warning: (near initialization for ‘__mach_desc_XILINX_EP107.restart’) [enabled by default]
Signed-off-by: Vincent Stehlé <vincent.stehle@freescale.com>
Cc: Robin Holt <holt@sgi.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: trivial@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
Fix the following compilation warning:
arch/arm/mach-keystone/keystone.c:74:2: warning: initialization from incompatible pointer type [enabled by default]
arch/arm/mach-keystone/keystone.c:74:2: warning: (near initialization for ‘__mach_desc_KEYSTONE.restart’) [enabled by default]
Signed-off-by: Vincent Stehlé <vincent.stehle@freescale.com>
Cc: Robin Holt <holt@sgi.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: trivial@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
Commit 7b6d864b48d9 (reboot: arm: change reboot_mode to use enum
reboot_mode) and ff701306cd49 (arm64: use common reboot infrastructure)
change the prototype of arm_pm_restart on arm and arm64.
Update xen_restart accordingly.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Midway adds new register fields to the coherency control registers, so
writing absolute values will break on Midway. Change the register
accesses to only modify the necessary and common fields in order to
support both Midway and Highbank.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
- Update the baseline so we need not rely on make
oldconfig so much
- MMC defconfig updates
- Activate NO_HZ_IDLE and HRTIMERS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
iQIcBAABAgAGBQJR6nLiAAoJEEEQszewGV1zD30P/RNnwy0kmxq0VrtxVcP67mwd
3Ck+Kb3xKNgi3e5yObPdXS5o/ujmDL1siPoinSJ2I2ryoEDag4FIE2YCjDojL3qW
DdCfwA6dmDkdyOZvZFGQQvOO/INoKQwoFsTMHPb+nQQPN96uPSrjwmr29yuBc7Qh
3Yike3P9r9ilrJw7xIp3FN/9XoPpQKpsN5FDc4oWzOuyqcUEjlX4eOFbdXrcT8gV
iYGwCQJP4BSROOmBzjSXvPl6jdqUBt9lWILC0sgwiNl2xq7AkboYEdHXiE1TiW92
DW8glF8cnCBTvaMDNWiV6LZIZcCMTyqGYI6mH/hQHokfy2NFwB5H9OSpUPtYanlW
bpblAJwuSAeMjWLbAVn9Bqw1qXD0uQBglSr7j1hpwEWsSlVjCVoLQ6VIMuB3f+m7
CyZaKAaN8TuODQ1b4YHK9S9NsCQFieZesjJf1YIlaSQh7vhttZenlcjBG+fKTYkJ
zn6SXnVYTQsBq2/1v6z41xiKaMiBu2cMJvH1JrDh8OX2IGgmAa/aOdYefbNCyGTD
3vMg+uk6lTq1jOq8Qh8vGFYIcMPzhtEvnuLFktzrQU2DZPOLBLwp7qUU0dgr8m46
PAt+NIrhbNE2GMVPH/L1vj0bvgrkvmYlZwTbtMgl7kxmgeFxq1cEz/gA7R0A0TO3
XnBtICM1MwOEP9ylfr0G
=XGIF
-----END PGP SIGNATURE-----
Merge tag 'nomadik-defconfig-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik into fixes
From Linus Walleij:
This updates the Nomadik defconfig post-v3.11-rc1:
- Update the baseline so we need not rely on make
oldconfig so much
- MMC defconfig updates
- Activate NO_HZ_IDLE and HRTIMERS
* tag 'nomadik-defconfig-for-arm-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik:
ARM: nomadik: configure for NO_HZ and HRTIMERS
ARM: nomadik: update defconfig base
ARM: nomadik: Update MMC defconfigs
Signed-off-by: Olof Johansson <olof@lixom.net>
Commit 8ef6e6201b26cb9fde79c1baa08145af6aca2815 (ARM: footbridge: use
fixed PCI i/o mapping) broke booting on my netwinder. Before that,
everything boots fine. Since then, it crashes on boot.
With earlyprintk, I see it BUG-ing like so:
kernel BUG at lib/ioremap.c:27!
Internal error: Oops - BUG: 0 [#1] ARM
...
[<c0139b54>] (ioremap_page_range+0x128/0x154) from [<c02e6a6c>] (dc21285_setup+0xd0/0x114)
[<c02e6a6c>] (dc21285_setup+0xd0/0x114) from [<c02e4874>] (pci_common_init+0xa0/0x298)
[<c02e4874>] (pci_common_init+0xa0/0x298) from [<c02e793c>] (netwinder_pci_init+0xc/0x18)
[<c02e793c>] (netwinder_pci_init+0xc/0x18) from [<c02e27d0>] (do_one_initcall+0xb4/0x180)
...
Russell points out it's because of overlapping PCI mappings that was
added with the aforementioned commit. Rob thought the code would re-use
the static mapping, but that turns out to not be the case and instead
hits the BUG further down.
After deleting this hunk as suggested by Russel, the system boots up fine
again and all my PCI devices work (IDE, ethernet, the DC21285).
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Cc: stable@vger.kernel.org # v3.5+
Signed-off-by: Olof Johansson <olof@lixom.net>
* A few device tree source fixes regarding pinctrl, clock, and pwm
backlight.
* Fixes imx28 and imx51 audio driver failure caused by sgtl5000 codec
driver change by supplying the correct clock for codec.
* imx6q emi_sel clock muxing and imx6q-iomuxc-gpr macro fixes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAABAgAGBQJR5B55AAoJEFBXWFqHsHzOEGoH/2DesLDZkQbUCn+w7Z3H7HYi
QAPeG1F/Ke3cBSaT+v/Z+46MgmU2gyQkxk08GRtPuVAZwCuWxSUN1H6+yakeBdHb
XGXR25RbbASIpYdYnC37eKiU2itiBmD7CRbWJ5xPHEluAgr47vr3OKfls6laii3b
nSM4sKz45PxBJ55M0qcE+A6oVdf9c+G0vm0aX14xEiLEUghB/U0KNKWp+B63hwfh
tg11gNwr2dO8jv51xpwJXH17juoZ46srOzmxERJm3j08JSz/tJSvIQajSsg54aLT
pAxToPAeuGGga5+7AanGT+repzZdd74Lp3U/lGw6WpaxLOpFf5Am3841O8qqCLw=
=q0LM
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into fixes
From Shawn Guo, imx fixes for 3.11:
- A few device tree source fixes regarding pinctrl, clock, and pwm
backlight.
- Fixes imx28 and imx51 audio driver failure caused by sgtl5000 codec
driver change by supplying the correct clock for codec.
- imx6q emi_sel clock muxing and imx6q-iomuxc-gpr macro fixes
* tag 'imx-fixes-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6:
ARM: dts: imx51-babbage: Pass a real clock to the codec
ARM i.MX53: mba53: Fix PWM backlight DT node
ARM: imx: fix vf610 enet module clock selection
ARM: mxs: saif0 is the clock provider to sgtl5000
ARM: i.MX6Q: correct emi_sel clock muxing
ARM i.MX6Q: Fix IOMUXC GPR1 defines for ENET_CLK_SEL and IPU1/2_MUX
ARM: i.MX27: Typo fix
ARM: imx27: Fix documentation for SPLL clock
ARM i.MX53: Fix UART pad configuration
