Skip to content
  1. Oct 13, 2015
  3. Sep 25, 2015
  5. Sep 24, 2015
    • Russell King's avatar
      ARM: alignment: fix alignment handling for uaccess changes · 274e91b8
      Russell King authored 
      

Jonathan Liu reports that the recent addition of CPU_SW_DOMAIN_PAN
causes wpa_supplicant to die due to the following kernel oops:

Unhandled fault: page domain fault (0x81b) at 0x001017a2
pgd = ee1b8000
[001017a2] *pgd=6ebee831, *pte=6c35475f, *ppte=6c354c7f
Internal error: : 81b [#1] SMP ARM
Modules linked in: rt2800usb rt2x00usb rt2800librt2x00lib crc_ccitt mac80211
CPU: 1 PID: 202 Comm: wpa_supplicant Not tainted 4.3.0-rc2 #1
Hardware name: Allwinner sun7i (A20) Family
task: ec872f80 ti: ee364000 task.ti: ee364000
PC is at do_alignment_ldmstm+0x1d4/0x238
LR is at 0x0
pc : [<c001d1d8>]    lr : [<00000000>]    psr: 600c0113
sp : ee365e18  ip : 00000000  fp : 00000002
r10: 001017a2  r9 : 00000002  r8 : 001017aa
r7 : ee365fb0  r6 : e8820018  r5 : 001017a2  r4 : 00000003
r3 : d49e30e0  r2 : 00000000  r1 : ee365fbc  r0 : 00000000
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none[   34.393106] Control: 10c5387d  Table: 6e1b806a  DAC: 00000051
Process wpa_supplicant (pid: 202, stack limit = 0xee364210)
Stack: (0xee365e18 to 0xee366000)
...
[<c001d1d8>] (do_alignment_ldmstm) from [<c001d510>] (do_alignment+0x1f0/0x904)
[<c001d510>] (do_alignment) from [<c00092a0>] (do_DataAbort+0x38/0xb4)
[<c00092a0>] (do_DataAbort) from [<c0013d7c>] (__dabt_usr+0x3c/0x40)
Exception stack(0xee365fb0 to 0xee365ff8)
5fa0:                                     00000000 56c728c0 001017a2 d49e30e0
5fc0: 775448d2 597d4e74 00200800 7a9e1625 00802001 00000021 b6deec84 00000100
5fe0: 08020200 be9f4f20 0c0b0d0a b6d9b3e0 600c0010 ffffffff
Code: e1a0a005 e1a0000c 1affffe8 e5913000 (e4ea3001)
---[ end trace 0acd3882fcfdf9dd ]---

This is caused by the alignment handler not being fixed up for the
uaccess changes, and userspace issuing an unaligned LDM instruction.
So, fix the problem by adding the necessary fixups.

Reported-by: default avatarJonathan Liu <net147@gmail.com>
Tested-by: default avatarJonathan Liu <net147@gmail.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      274e91b8
  7. Sep 22, 2015
  9. Sep 17, 2015
    • Ming Lei's avatar
      arm/arm64: KVM: Remove 'config KVM_ARM_MAX_VCPUS' · ef748917
      Ming Lei authored 
      

This patch removes config option of KVM_ARM_MAX_VCPUS,
and like other ARCHs, just choose the maximum allowed
value from hardware, and follows the reasons:

1) from distribution view, the option has to be
defined as the max allowed value because it need to
meet all kinds of virtulization applications and
need to support most of SoCs;

2) using a bigger value doesn't introduce extra memory
consumption, and the help text in Kconfig isn't accurate
because kvm_vpu structure isn't allocated until request
of creating VCPU is sent from QEMU;

3) the main effect is that the field of vcpus[] in 'struct kvm'
becomes a bit bigger(sizeof(void *) per vcpu) and need more cache
lines to hold the structure, but 'struct kvm' is one generic struct,
and it has worked well on other ARCHs already in this way. Also,
the world switch frequecy is often low, for example, it is ~2000
when running kernel building load in VM from APM xgene KVM host,
so the effect is very small, and the difference can't be observed
in my test at all.

Cc: Dann Frazier <dann.frazier@canonical.com>
Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
Reviewed-by: default avatarChristoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      ef748917
    • Marc Zyngier's avatar
      arm: KVM: Disable virtual timer even if the guest is not using it · 688bc577
      Marc Zyngier authored 
      

When running a guest with the architected timer disabled (with QEMU and
the kernel_irqchip=off option, for example), it is important to make
sure the timer gets turned off. Otherwise, the guest may try to
enable it anyway, leading to a screaming HW interrupt.

The fix is to unconditionally turn off the virtual timer on guest
exit.

Cc: stable@vger.kernel.org
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      688bc577
    • Roger Quadros's avatar
      ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2 · 84ad1bab
      Roger Quadros authored 
      

The VBUS line of USB2 is connected to VBUS detect logic on
the PMIC. Use the palmas-usb driver to report VBUS events
to the USB driver.

As the palmas-usb driver supports GPIO based ID reporting
provide the GPIO for ID pin as well.

Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      84ad1bab
    • Grazvydas Ignotas's avatar
      ARM: omap2plus_defconfig: enable GPIO_PCA953X · f4746176
      Grazvydas Ignotas authored 
      

This enables tca6424a GPIO expander driver that in turn enables
TPD12S015 HDMI ESD protection and level shifter on OMAP5 uevm.
In other words, it makes HDMI work on OMAP5 uevm.

Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      f4746176
    • Grazvydas Ignotas's avatar
      ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets · 1dbdad75
      Grazvydas Ignotas authored 
      The i2c5 pinctrl offsets are wrong. If the bootloader doesn't set the
pins up, communication with tca6424a doesn't work (controller timeouts)
and it is not possible to enable HDMI.

Fixes: 9be495c4

 ("ARM: dts: omap5-evm: Add I2c pinctrl data")
Signed-off-by: default avatarGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      1dbdad75
    • Dave Gerlach's avatar
      ARM: OMAP2+: AM43XX: Enable autoidle for clks in am43xx_init_late · 08224a7d
      Dave Gerlach authored 
      

Add omap2_clk_enable_autoidle_all to am43xx_init_late otherwise the call
to omap2_clk_disable_autoidle_all in am43xx_init_early may cause some
clocks to always stay active and prevent low power mode transitions.

Signed-off-by: default avatarDave Gerlach <d-gerlach@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      08224a7d
    • Nishanth Menon's avatar
      ARM: dts: am57xx-beagle-x15: Update Phy supplies · 5005296e
      Nishanth Menon authored 
      

Originally, all the SoC PHY rails were supplied by LDO3. However, as a
result of characterization, it was determined that this posed a risk in
extreme load  conditions. Hence the PHY rails are split between two
different LDOs. Update the related node as a result

LDO3/VDDA_1V8_PHYA supplies vdda_usb1, vdda_usb2, vdda_sata, vdda_usb3
LDO4/VDDA_1V8_PHYB supplies vdda_pcie1, vdda_pcie0, vdda_hdmi, vdda_pcie

NOTE: We break compatibility with pre-production boards with this change
since, the PMIC LDO4 is disabled at OTP level.

The new configuration is the plan of record and all pre-production
boards are supposed to be replaced with the latest boards matching the
mentioned configuration.

Some very few 10 something boards have been created and
stopped production till the latest modifications were done (PMIC USB
interrupt, LDO4 etc) - and all of those boards are now getting
scrapped.. If there are any (as per tracking information, there should
not be any), TI should be contacted to have them replaced.

Signed-off-by: default avatarNishanth Menon <nm@ti.com>
[tony@atomide.com: updated commit about these being TI internal protos]
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      5005296e
    • Doug Anderson's avatar
      ARM: 8425/1: kgdb: Don't try to stop the machine when setting breakpoints · 7ae85dc7
      Doug Anderson authored 
      In (23a4e405 arm: kgdb: Handle read-only text / modules) we moved to
using patch_text() to set breakpoints so that we could handle the case
when we had CONFIG_DEBUG_RODATA.  That patch used patch_text().
Unfortunately, patch_text() assumes that we're not in atomic context
when it runs since it needs to grab a mutex and also wait for other
CPUs to stop (which it does with a completion).

This would result in a stack crawl if you had
CONFIG_DEBUG_ATOMIC_SLEEP and tried to set a breakpoint in kgdb.  The
crawl looked something like:

 BUG: scheduling while atomic: swapper/0/0/0x00010007
 CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-00133-geb63b34 #1073
 Hardware name: Rockchip (Device Tree)
  (unwind_backtrace) from [<c00133d4>] (show_stack+0x20/0x24)
  (show_stack) from [<c05400e8>] (dump_stack+0x84/0xb8)
  (dump_stack) from [<c004913c>] (__schedule_bug+0x54/0x6c)
  (__schedule_bug) from [<c054065c>] (__schedule+0x80/0x668)
  (__schedule) from [<c0540cfc>] (schedule+0xb8/0xd4)
  (schedule) from [<c0543a3c>] (schedule_timeout+0x2c/0x234)
  (schedule_timeout) from [<c05417c0>] (wait_for_common+0xf4/0x188)
  (wait_for_common) from [<c0541874>] (wait_for_completion+0x20/0x24)
  (wait_for_completion) from [<c00a0104>] (__stop_cpus+0x58/0x70)
  (__stop_cpus) from [<c00a0580>] (stop_cpus+0x3c/0x54)
  (stop_cpus) from [<c00a06c4>] (__stop_machine+0xcc/0xe8)
  (__stop_machine) from [<c00a0714>] (stop_machine+0x34/0x44)
  (stop_machine) from [<c00173e8>] (patch_text+0x28/0x34)
  (patch_text) from [<c001733c>] (kgdb_arch_set_breakpoint+0x40/0x4c)
  (kgdb_arch_set_breakpoint) from [<c00a0d68>] (kgdb_validate_break_address+0x2c/0x60)
  (kgdb_validate_break_address) from [<c00a0e90>] (dbg_set_sw_break+0x1c/0xdc)
  (dbg_set_sw_break) from [<c00a2e88>] (gdb_serial_stub+0x9c4/0xba4)
  (gdb_serial_stub) from [<c00a11cc>] (kgdb_cpu_enter+0x1f8/0x60c)
  (kgdb_cpu_enter) from [<c00a18cc>] (kgdb_handle_exception+0x19c/0x1d0)
  (kgdb_handle_exception) from [<c0016f7c>] (kgdb_compiled_brk_fn+0x30/0x3c)
  (kgdb_compiled_brk_fn) from [<c00091a4>] (do_undefinstr+0x1a4/0x20c)
  (do_undefinstr) from [<c001400c>] (__und_svc_finish+0x0/0x34)

It turns out that when we're in kgdb all the CPUs are stopped anyway
so there's no reason we should be calling patch_text().  We can
instead directly call __patch_text() which assumes that CPUs have
already been stopped.

Fixes: 23a4e405

 ("arm: kgdb: Handle read-only text / modules")
Reported-by: default avatarAapo Vienamo <avienamo@nvidia.com>
Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
Acked-by: default avatarKees Cook <keescook@chromium.org>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7ae85dc7
    • Andre Przywara's avatar
      ARM: 8437/1: dma-mapping: fix build warning with new DMA_ERROR_CODE definition · 90cde558
      Andre Przywara authored 
      Commit 96231b26

: ("ARM: 8419/1: dma-mapping: harmonize definition
of DMA_ERROR_CODE") changed the definition of DMA_ERROR_CODE to use
dma_addr_t, which makes the compiler barf on assigning this to an
"int" variable on ARM with LPAE enabled:
*************
In file included from /src/linux/include/linux/dma-mapping.h:86:0,
                 from /src/linux/arch/arm/mm/dma-mapping.c:21:
/src/linux/arch/arm/mm/dma-mapping.c: In function '__iommu_create_mapping':
/src/linux/arch/arm/include/asm/dma-mapping.h:16:24: warning:
overflow in implicit constant conversion [-Woverflow]
 #define DMA_ERROR_CODE (~(dma_addr_t)0x0)
                        ^
/src/linux/arch/arm/mm/dma-mapping.c:1252:15: note: in expansion of
macro DMA_ERROR_CODE'
  int i, ret = DMA_ERROR_CODE;
               ^
*************

Remove the actually unneeded initialization of "ret" in
__iommu_create_mapping() and move the variable declaration inside the
for-loop to make the scope of this variable more clear.

Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      90cde558
    • Russell King's avatar
      ARM: get rid of needless #if in signal handling code · 12fc7306
      Russell King authored 
      

Remove the #if statement which caused trouble for kernels that support
both ARMv6 and ARMv7.  Older architectures do not implement these bits,
so it should be safe to always clear them.

Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      12fc7306
    • Axel Lin's avatar
      ARM: pxa: balloon3: Fix build error · 385877c0
      Axel Lin authored 
      irq_data_get_chip() function does not exist, call irq_desc_get_chip()
instead.

Fixes: 9ec97561

 ("ARM/pxa: Prepare balloon3_irq_handler for irq argument removal")
Signed-off-by: default avatarAxel Lin <axel.lin@ingics.com>
Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      385877c0
    • Pavel Fedin's avatar
      arm/arm64: KVM: vgic: Check for !irqchip_in_kernel() when mapping resources · c2f58514
      Pavel Fedin authored 
      Until b26e5fda ("arm/arm64: KVM: introduce per-VM ops"),
kvm_vgic_map_resources() used to include a check on irqchip_in_kernel(),
and vgic_v2_map_resources() still has it.

But now vm_ops are not initialized until we call kvm_vgic_create().
Therefore kvm_vgic_map_resources() can being called without a VGIC,
and we die because vm_ops.map_resources is NULL.

Fixing this restores QEMU's kernel-irqchip=off option to a working state,
allowing to use GIC emulation in userspace.

Fixes: b26e5fda

 ("arm/arm64: KVM: introduce per-VM ops")
Cc: stable@vger.kernel.org
Signed-off-by: default avatarPavel Fedin <p.fedin@samsung.com>
[maz: reworked commit message]
Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      c2f58514
  11. Sep 16, 2015