linux.git/arch/arm/vfp, branch v3.11

ARM: 7729/1: vfp: ensure VFP_arch is non-zero when VFP is not supported

2013-05-22T21:01:37+00:00

Commit d3f79584a8b5 ("ARM: cleanup undefined instruction entry code")
improved the register scheduling when handling undefined instructions.
A side effect of this is that r5 is now used as a temporary, whilst the
VFP probing code relies on r5 containing a non-zero value when VFP is
not supported.

This patch fixes the VFP detection code so that we don't rely on the
contents of r5. Without this patch, Linux dies loudly on CPUs without
VFP support.

Signed-off-by: Will Deacon 
Signed-off-by: Russell King

ARM: Fix broken commit 0cc41e4a21d43 corrupting kernel messages

2013-03-01T21:09:59+00:00

Commit 0cc41e4a21d43 (arch: remove direct definitions of KERN_
uses) is broken - not enough thought was put into changing:

	.asciz	"string"

to

	.asciz	"string1" "string2"

The problem is that each string gets _separately_ NUL terminated, so
the result is a string containing:

	"string1\0string2\0"

rather than:

	"string1string2\0"

With our new printk levels, this ends up as - eg, KERN_DEBUG "string":

	0x01 0x00 0x07 0x00 "string" 0x00

which produces lots of \x01 in the kernel log.

Signed-off-by: Russell King

ARM: VFP: fix emulation of second VFP instruction

2013-02-25T16:09:12+00:00

Martin Storsjö reports that the sequence:

        ee312ac1        vsub.f32        s4, s3, s2
        ee702ac0        vsub.f32        s5, s1, s0
        e59f0028        ldr             r0, [pc, #40]
        ee111a90        vmov            r1, s3

on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5)
where s3 is a denormal and s2 is zero results in incorrect behaviour -
the instruction "vsub.f32 s5, s1, s0" is not executed:

        VFP: bounce: trigger ee111a90 fpexc d0000780
        VFP: emulate: INST=0xee312ac1 SCR=0x00000000
        ...

As we can see, the instruction triggering the exception is the "vmov"
instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to
properly take account of the FPEXC_FP2V flag in FPEXC.  This is because
the test for the second instruction register being valid is bogus, and
will always skip emulation of the second instruction.

Cc: 
Reported-by: Martin Storsjö 
Tested-by: Martin Storsjö 
Signed-off-by: Russell King

ARM: 7627/1: Predicate preempt logic on PREEMP_COUNT not PREEMPT alone

2013-01-16T16:51:10+00:00

Patrik Kluba reports that the preempt count becomes invalid due
to the preempt_enable() call being unbalanced with a
preempt_disable() call in the vfp assembly routines. This happens
because preempt_enable() and preempt_disable() update preempt
counts under PREEMPT_COUNT=y but the vfp assembly routines do so
under PREEMPT=y. In a configuration where PREEMPT=n and
DEBUG_ATOMIC_SLEEP=y, PREEMPT_COUNT=y and so the preempt_enable()
call in VFP_bounce() keeps subtracting from the preempt count
until it goes negative.

Fix this by always using PREEMPT_COUNT to decided when to update
preempt counts in the ARM assembly code.

Signed-off-by: Stephen Boyd 
Reported-by: Patrik Kluba 
Tested-by: Patrik Kluba 
Cc:  # 2.6.30
Signed-off-by: Russell King

ARM: 7566/1: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set

2012-10-29T10:04:05+00:00

After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
started crashing during boot with omap2plus_defconfig:

[    3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
[    3.915954]  mmcblk0: p1
[    4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
[    4.093719] Modules linked in:
[    4.096954] CPU: 0    Not tainted  (3.6.0-02232-g759e00b #570)
[    4.103149] PC is at vfp_reload_hw+0x1c/0x44
[    4.107666] LR is at __und_usr_fault_32+0x0/0x8

It turns out that the context save/restore fix unmasked a latent bug
in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make
VFPv3 usable on ARMv6").  When CONFIG_VFPv3 is set, but the kernel is
booted on a pre-VFPv3 core, the code attempts to save and restore the
d16-d31 VFP registers.  These are only present on non-D16 VFPv3+, so
this results in an undefined instruction exception.  The code didn't
crash before commit 846a136 because the save and restore code was
only touching d0-d15, present on all VFP.

Fix by implementing a request from Russell King to add a new HWCAP
flag that affirmatively indicates the presence of the d16-d31
registers:

   http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2

and some feedback from Måns to clarify the name of the HWCAP flag.

Signed-off-by: Paul Walmsley 
Cc: Tony Lindgren 
Cc: Catalin Marinas 
Cc: Dave Martin 
Cc: Måns Rullgård 
Signed-off-by: Russell King

ARM: 7483/1: vfp: only advertise VFPv4 in hwcaps if CONFIG_VFPv3 is enabled

2012-08-11T08:15:57+00:00

VFPv4 support depends on the VFPv3 context save/restore code, so only
advertise support in the hwcaps if the kernel can actually handle it.

Cc:  # 3.1+
Signed-off-by: Will Deacon 
Signed-off-by: Russell King

Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm

2012-08-01T23:30:45+00:00

Pull ARM fixes from Russell King:
 "This fixes various issues found during July"

* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
  ARM: 7479/1: mm: avoid NULL dereference when flushing gate_vma with VIVT caches
  ARM: Fix undefined instruction exception handling
  ARM: 7480/1: only call smp_send_stop() on SMP
  ARM: 7478/1: errata: extend workaround for erratum #720789
  ARM: 7477/1: vfp: Always save VFP state in vfp_pm_suspend on UP
  ARM: 7476/1: vfp: only clear vfp state for current cpu in vfp_pm_suspend
  ARM: 7468/1: ftrace: Trace function entry before updating index
  ARM: 7467/1: mutex: use generic xchg-based implementation for ARMv6+
  ARM: 7466/1: disable interrupt before spinning endlessly
  ARM: 7465/1: Handle >4GB memory sizes in device tree and mem=size@start option

ARM: Fix undefined instruction exception handling

2012-07-31T11:04:30+00:00

While trying to get a v3.5 kernel booted on the cubox, I noticed that
VFP does not work correctly with VFP bounce handling.  This is because
of the confusion over 16-bit vs 32-bit instructions, and where PC is
supposed to point to.

The rule is that FP handlers are entered with regs->ARM_pc pointing at
the _next_ instruction to be executed.  However, if the exception is
not handled, regs->ARM_pc points at the faulting instruction.

This is easy for ARM mode, because we know that the next instruction and
previous instructions are separated by four bytes.  This is not true of
Thumb2 though.

Since all FP instructions are 32-bit in Thumb2, it makes things easy.
We just need to select the appropriate adjustment.  Do this by moving
the adjustment out of do_undefinstr() into the assembly code, as only
the assembly code knows whether it's dealing with a 32-bit or 16-bit
instruction.

Cc: 
Acked-by: Will Deacon 
Signed-off-by: Russell King

ARM: 7477/1: vfp: Always save VFP state in vfp_pm_suspend on UP

2012-07-31T09:30:43+00:00

vfp_pm_suspend should save the VFP state in suspend after
any lazy context switch.  If it only saves when the VFP is enabled,
the state can get lost when, on a UP system:
  Thread 1 uses the VFP
  Context switch occurs to thread 2, VFP is disabled but the
     VFP context is not saved
  Thread 2 initiates suspend
  vfp_pm_suspend is called with the VFP disabled, and the unsaved
     VFP context of Thread 1 in the registers

Modify vfp_pm_suspend to save the VFP context whenever
vfp_current_hw_state is not NULL.

Includes a fix from Ido Yariv , who pointed out that on
SMP systems, the state pointer can be pointing to a freed task struct if
a task exited on another cpu, fixed by using #ifndef CONFIG_SMP in the
new if clause.

Cc: Barry Song 
Cc: Catalin Marinas 
Cc: Ido Yariv 
Cc: Daniel Drake 
Cc: Will Deacon 
Cc: stable@vger.kernel.org
Signed-off-by: Colin Cross 
Signed-off-by: Russell King

ARM: 7476/1: vfp: only clear vfp state for current cpu in vfp_pm_suspend

2012-07-31T09:30:42+00:00

vfp_pm_suspend runs on each cpu, only clear the hardware state
pointer for the current cpu.  Prevents a possible crash if one
cpu clears the hw state pointer when another cpu has already
checked if it is valid.

Cc: stable@vger.kernel.org
Signed-off-by: Colin Cross 
Signed-off-by: Russell King