Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 7
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 05 2月, 2012 2 次提交
  3. 03 2月, 2012 7 次提交
    • W
      ARM: 7314/1: kuser: consistently use usr_ret for returning from helpers · 5a97d0ae
      由 Will Deacon 提交于 
      __kuser_cmpxchg64 has a return path using bx lr to get back to the caller.
This is actually ok since the code in question is predicated on
CONFIG_CPU_32v6K, but for the sake of consistency using the usr_ret
macro is probably better.
Acked-by: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5a97d0ae
    • C
      ARM: 7302/1: Add TLB flushing for both entries in a PMD · 6d3ec1ae
      由 Catalin Marinas 提交于 
      Linux uses two PMD entries for a PTE with the classic page table format,
covering 2MB range. However, the __pte_free_tlb() function only adds a
single TLB flush corresponding to 1MB range covering 'addr'. On
Cortex-A15, level 1 entries can be cached by the TLB independently of
the level 2 entries and without additional flushing a PMD entry would be
left pointing at the wrong PTE. The patch limits the TLB flushing range
to two 4KB pages around the 1MB boundary within PMD.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      6d3ec1ae
    • W
      ARM: 7303/1: perf: add empty NODE event definitions for Cortex-A5 and Cortex-A15 · 91756acb
      由 Will Deacon 提交于 
      Commit 89d6c0b5 ("perf, arch: Add generic NODE cache events") added
empty NODE event definitions for the ARM PMU implementations. This was
merged along with Cortex-A5 and Cortex-A15 PMU support, so they missed
out on the original patch.

This patch adds the empty definitions to Cortex-A5 and Cortex-A15.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      91756acb
    • W
      ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers · 8130b9d7
      由 Will Deacon 提交于 
      If we are context switched whilst copying into a thread's
vfp_hard_struct then the partial copy may be corrupted by the VFP
context switching code (see "ARM: vfp: flush thread hwstate before
restoring context from sigframe").

This patch updates the ptrace VFP set code so that the thread state is
flushed before the copy, therefore disabling VFP and preventing
corruption from occurring.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8130b9d7
    • D
      ARM: 7307/1: vfp: fix ptrace regset modification race · 247f4993
      由 Dave Martin 提交于 
      In a preemptible kernel, vfp_set() can be preempted, causing the
hardware VFP context to be switched while the thread vfp state is
being read and modified.  This leads to a race condition which can
cause the thread vfp state to become corrupted if lazy VFP context
save occurs due to preemption in between the time thread->vfpstate
is read and the time the modified state is written back.

This may occur if preemption occurs during the execution of a
ptrace() call which modifies the VFP register state of a thread.
Such instances should be very rare in most realistic scenarios --
none has been reported, so far as I am aware.  Only uniprocessor
systems should be affected, since VFP context save is not currently
lazy in SMP kernels.

The problem was introduced by my earlier patch migrating to use
regsets to implement ptrace.

This patch does a vfp_sync_hwstate() before reading
thread->vfpstate, to make sure that the thread's VFP state is not
live in the hardware registers while the registers are modified.

Thanks to Will Deacon for spotting this.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: NDave Martin <dave.martin@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      247f4993
    • W
      ARM: 7306/1: vfp: flush thread hwstate before restoring context from sigframe · 2af276df
      由 Will Deacon 提交于 
      Following execution of a signal handler, we currently restore the VFP
context from the ucontext in the signal frame. This involves copying
from the user stack into the current thread's vfp_hard_struct and then
flushing the new data out to the hardware registers.

This is problematic when using a preemptible kernel because we could be
context switched whilst updating the vfp_hard_struct. If the current
thread has made use of VFP since the last context switch, the VFP
notifier will copy from the hardware registers into the vfp_hard_struct,
overwriting any data that had been partially copied by the signal code.

Disabling preemption across copy_from_user calls is a terrible idea, so
instead we move the VFP thread flush *before* we update the
vfp_hard_struct. Since the flushing is performed lazily, this has the
effect of disabling VFP and clearing the CPU's VFP state pointer,
therefore preventing the thread from being updated with stale data on
the next context switch.

Cc: stable <stable@vger.kernel.org>
Tested-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      2af276df
    • R
      Revert "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping" · 97f10409
      由 Russell King 提交于 
      This reverts commit 3c424f35.

Joachim Eastwood reports:
| "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
| Commit: 3c424f35 in Linus master
|
| Breaks booting on my custom AT91RM9200 board.
| There isn't any error messages or anything that indicates what goes
| wrong it just stops after; Uncompressing Linux... done, booting the
| kernel.
|
| Reverting it makes my board boot again.

and further debugging reveals:

ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
ioremap: found: addr fef74000 => fed73000 => fed73400

Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
0xfffff.  This happens because the changed if statement becomes:

                if (0x00200 > 0xfffff ||
                    0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
and therefore:
                if (0x00200 > 0xfffff ||
                    0x000003ff > 0x00203fff)

The if condition fails, and so we _believe_ that the SRAM mapping fits
our request.  Clearly that's totally bogus.

Moreover, the original premise of the 'fix' patch was wrong:
|    The condition checking boundaries of the requested and existing
|    mappings didn't take in-page offset into consideration though,
|    which lead to obscure and hard to debug problems when requested
|    mapping crossed end of the static one.

as the code immediately above this loop does:

        size = PAGE_ALIGN(offset + size);

so 'size' already contains the requested offset into the page.

So, revert the broken 'fix'.
Acked-by: NNicolas Pitre <nico@linaro.org>
      97f10409
  5. 02 2月, 2012 1 次提交
  7. 28 1月, 2012 2 次提交
  9. 27 1月, 2012 7 次提交
    • J
      ARM: OMAP2+: arch/arm/mach-omap2/smartreflex.c: add missing iounmap · 14ea9601
      由 Julia Lawall 提交于 
      Add missing iounmap in error handling code, in a case where the function
already preforms iounmap on some other execution path.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@@
expression e;
statement S,S1;
int ret;
@@
e = \(ioremap\|ioremap_nocache\)(...)
... when != iounmap(e)
if (<+...e...+>) S
... when any
    when != iounmap(e)
*if (...)
   { ... when != iounmap(e)
     return ...; }
... when any
iounmap(e);
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      14ea9601
    • J
      ARM: OMAP2+: arch/arm/mach-omap2/devices.c: introduce missing kfree · e0feca89
      由 Julia Lawall 提交于 
      pdata needs to be freed before leaving the function in an error case.

A simplified version of the semantic match that finds the problem is as
follows: (http://coccinelle.lip6.fr)

// <smpl>
@r exists@
local idexpression x;
statement S;
identifier f1;
position p1,p2;
expression *ptr != NULL;
@@

x@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
x->f1
...>
(
 return \(0\|<+...x...+>\|ptr\);
|
 return@p2 ...;
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      e0feca89
    • G
      ARM: OMAP: fix MMC2 loopback clock handling · d82e5190
      由 Grazvydas Ignotas 提交于 
      Currently MMC2 setup code can only enable loopback clock and
relies on reset value for boards that need to have it disabled.
This causes a problem with certain bootloaders that always enable
that clock, resulting with unwanted bootloader dependencies.

Fix this by making it disable the clock if board data says so.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      d82e5190
    • G
      ARM: OMAP: fix erroneous mmc2 clock change on mmc3 setup · ffa1e4ed
      由 Grazvydas Ignotas 提交于 
      hsmmc23_before_set_reg() can set MMCSDIO2ADPCLKISEL bit, which
enables internal clock for MMC2. Currently this function is also called
by code handling MMC3, and if .internal_clock is set in platform data
(by default it currently is), it will set MMCSDIO2ADPCLKISEL for MMC2
instead of MMC3 (MMC3 doesn't have such bit so nothing actually needs to
be done). This breaks 2nd SD slot on pandora.

Fix this by changing hsmmc23_before_set_reg() to only handle MMC2.
Note that this removes .remux() call for MMC3, but no board currently
needs it and it's also not called for MMC4 and MMC5.
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>
      ffa1e4ed
    • Y
      ARM: OMAP2+: GPMC: fix device size setup · 8ef5d844
      由 Yegor Yefremov 提交于 
      following statement can only change device size from 8-bit(0) to 16-bit(1),
but not vice versa:

regval |= GPMC_CONFIG1_DEVICESIZE(wval);

so as this field has 1 reserved bit, that could be used in future,
just clear both bits and then OR with the desired value
Signed-off-by: NYegor Yefremov <yegorslists@googlemail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTony Lindgren <tony@atomide.com>
      8ef5d844
    • V
      ARM: OMAP2+: timer: Fix crash due to wrong arg to __omap_dm_timer_read_counter · dbc3982a
      由 Vaibhav Hiremath 提交于 
      Commit 2f0778af (ARM: 7205/2: sched_clock: allow sched_clock to be
selected at runtime) had a typo for the case when CONFIG_OMAP_32K_TIMER
is not set.

In dmtimer_read_sched_clock(), wrong argument was getting passed to
__omap_dm_timer_read_counter() function call; instead of "&clksrc",
we were passing "clksrc.io_base", which results into kernel crash.

To reproduce kernel crash, just disable the CONFIG_OMAP_32K_TIMER config
option (and DEBUG_LL) and build/boot the kernel.
This will use dmtimer as a kernel clocksource and lead to kernel
crash during boot  -

[    0.000000] OMAP clocksource: GPTIMER2 at 26000000 Hz
[    0.000000] sched_clock: 32 bits at 26MHz, resolution 38ns, wraps every
165191ms
[    0.000000] Unable to handle kernel paging request at virtual address
00030ef1
[    0.000000] pgd = c0004000
[    0.000000] [00030ef1] *pgd=00000000
[    0.000000] Internal error: Oops: 5 [#1] SMP
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Not tainted  (3.3.0-rc1-11574-g0c76665-dirty #3)
[    0.000000] PC is at dmtimer_read_sched_clock+0x18/0x4c
[    0.000000] LR is at update_sched_clock+0x10/0x84
[    0.000000] pc : [<c00243b8>]    lr : [<c0018684>]    psr: 200001d3
[    0.000000] sp : c0641f38  ip : c0641e18  fp : 0000000a
[    0.000000] r10: 151c3303  r9 : 00000026  r8 : 76276259
[    0.000000] r7 : 00028547  r6 : c065ac80  r5 : 431bde82  r4 : c0655968
[    0.000000] r3 : 00030ef1  r2 : fb032000  r1 : 00000028  r0 : 00000001
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: NTony Lindgren <tony@atomide.com>
      dbc3982a
    • G
      Revert "tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip" · af681cad
      由 Greg Kroah-Hartman 提交于 
      This reverts commit 43cf7c0b as Paul
wants to redo it.

Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      af681cad
  11. 26 1月, 2012 14 次提交
  13. 25 1月, 2012 4 次提交
    • C
      ARM: 7301/1: Rename the T() macro to TUSER() to avoid namespace conflicts · 4e7682d0
      由 Catalin Marinas 提交于 
      This macro is used to generate unprivileged accesses (LDRT/STRT) to user
space.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4e7682d0
    • R
      ARM: 7299/1: ftrace: clear zero bit in reported IPs for Thumb-2 · d68133b5
      由 Rabin Vincent 提交于 
      The dynamic ftrace ops startup test currently fails on Thumb-2 kernels:

 Testing tracer function: PASSED
 Testing dynamic ftrace: PASSED
 Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED!

This is because while the addresses in the mcount records do not have
the zero bit set, the IP reported by the mcount call does have it set
(because it is copied from the LR).  This mismatch causes the ops
filtering in ftrace_ops_list_func() to not call the relevant tracers.

Fix this by clearing the zero bit before adjusting the LR for the mcount
instruction size.  Also, combine the mov+sub into a single sub
instruction.
Acked-by: NDave Martin <dave.martin@linaro.org>
Signed-off-by: NRabin Vincent <rabin@rab.in>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d68133b5
    • M
      ARM: 7298/1: realview: fix mapping of MPCore private memory region · 34ae6c96
      由 Marc Zyngier 提交于 
      Since commit 0536bdf3 (ARM: move iotable mappings within
the vmalloc region), the RealView PB11MP cannot boot anymore.

This is caused by the way the mappings are described on this
platform (define replaced by hex values for clarity):

{	/* GIC CPU interface mapping */
        .virtual        = IO_ADDRESS(0x1F000100),
        .pfn            = __phys_to_pfn(0x1F000100),
        .length         = SZ_4K,
        .type           = MT_DEVICE,
}, {	/* GIC distributor mapping */
        .virtual        = IO_ADDRESS(0x1F001000),
        .pfn            = __phys_to_pfn(0x1F001000),
        .length         = SZ_4K,
        .type           = MT_DEVICE,
}

The first mapping ends up reserving two pages, and clashes with
the second one, which triggers a BUG_ON in vm_area_add_early().

In order to solve this problem, treat the MPCore private memory
region (containing the SCU, the GIC and the TWD) as a single region,
as described in the TRM:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/CACGDJJC.html

The EB11MP is converted the same way, even if it manages to avoid
the problem.

Tested on both PB11MP and EB11MP.
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      34ae6c96
    • P
      tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the chip · 43cf7c0b
      由 Paul Walmsley 提交于 
      It seems that when the transmit FIFO threshold is reached on OMAP
UARTs, it does not result in a PRCM wakeup.  This appears to be a
silicon bug.  This means that if the MPU powerdomain is in a low-power
state, the MPU will not be awakened to refill the FIFO until the next
interrupt from another device.

The best solution, at least for the short term, would be for the OMAP
serial driver to call a OMAP subarchitecture function to prevent the
MPU powerdomain from entering a low power state while the FIFO has
data to transmit.  However, we no longer have a clean way to do this,
since patches that add platform_data function pointers have been
deprecated by the OMAP maintainer.  So we attempt to work around this
as well.  The workarounds depend on the setting of CONFIG_CPU_IDLE.

When CONFIG_CPU_IDLE=n, the driver will now only transmit one byte at
a time.  This causes the transmit FIFO threshold interrupt to stay
active until there is no more data to be sent.  Thus, the MPU
powerdomain stays on during transmits.  Aside from that energy
consumption penalty, each transmitted byte results in a huge number of
UART interrupts -- about five per byte.  This wastes CPU time and is
quite inefficient, but is probably the most expedient workaround in
this case.

When CONFIG_CPU_IDLE=y, there is a slightly more direct workaround:
the PM QoS constraint can be abused to keep the MPU powerdomain on.
This results in a normal number of interrupts, but, similar to the
above workaround, wastes power by preventing the MPU from entering
WFI.

Future patches are planned for the 3.4 merge window to implement more
efficient, but also more disruptive, workarounds to these problems.

DMA operation is unaffected by this patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Govindraj Raja <govindraj.r@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      43cf7c0b
  15. 23 1月, 2012 3 次提交