linux-toradex.git/arch/m68k/kernel, branch v3.18

m68k: Wire up bpf

2014-10-27T10:02:19+00:00

Signed-off-by: Geert Uytterhoeven 
Acked-by: Alexei Starovoitov

m68k: call find_vma with the mmap_sem held in sys_cacheflush()

2014-10-10T02:26:02+00:00

Performing vma lookups without taking the mm->mmap_sem is asking for
trouble.  While doing the search, the vma in question can be modified or
even removed before returning to the caller.  Take the lock (shared) in
order to avoid races while iterating through the vmacache and/or rbtree.
In addition, this guarantees that the address space will remain intact
during the CPU flushing.

Signed-off-by: Davidlohr Bueso 
Cc: Geert Uytterhoeven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

m68k: Wire up memfd_create

2014-09-01T08:28:00+00:00

Signed-off-by: Geert Uytterhoeven

m68k: Wire up getrandom

2014-09-01T08:28:00+00:00

Signed-off-by: Geert Uytterhoeven

m68k: Use sigsp()

2014-08-06T11:04:09+00:00

Use sigsp() instead of the open coded variant.

Signed-off-by: Richard Weinberger

m68k: Use get_signal() signal_setup_done()

2014-08-06T11:02:15+00:00

Use the more generic functions get_signal() signal_setup_done()
for signal delivery.

Signed-off-by: Richard Weinberger

m68k: Export mach_random_get_entropy to modules

2014-07-11T08:37:53+00:00

When a module calls random_get_entropy():

    ERROR: "mach_random_get_entropy" [crypto/drbg.ko] undefined!
    make[1]: *** [__modpost] Error 1

Signed-off-by: Geert Uytterhoeven

m68k: Fix boot regression on machines with RAM at non-zero

2014-07-10T07:58:26+00:00

My enhancement to store the initial mapping size for later reuse in commit
486df8bc4627bdfc032d11bedcd056cc5343ee62 ("m68k: Increase initial mapping
to 8 or 16 MiB if possible") broke booting on machines where RAM doesn't
start at address zero.

Use pc-relative addressing to fix this.

Reported-by: Andreas Schwab 
Signed-off-by: Geert Uytterhoeven 
Tested-by: Andreas Schwab

Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu into next

2014-06-03T03:00:54+00:00

Pull m68knommu updates from Greg Ungerer:
 "Nothing too big, just a handfull of small changes.

  A couple of dragonball fixes, coldfire qspi cleanup and fixes, and
  some coldfire gpio cleanup, fixes and extensions"

* 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu:
  m68knommu: Implement gpio support for m54xx.
  m68knommu: Make everything thats not exported, static.
  m68knommu: setting the gpio data direction register to output doesn't dependent upon the value to output!
  m68knommu: add to_irq function so we can map gpios to external interrupts.
  m68knommu: qspi declutter.
  m68knommu: Fix the 5249/525x qspi base address.
  m68knommu: Add qspi clk for Coldfire SoCs without real clks.
  m68k: fix a compiler warning when building for DragonBall
  m68knommu: Fix mach_sched_init for EZ and VZ DragonBall chips

m68k: Increase initial mapping to 8 or 16 MiB if possible

2014-05-28T08:11:54+00:00

If the size of the first memory chunk is at least 8 or 16 MiB increase the
initial mapping to 8 resp. 16 MiB instead of 4 MiB.
This makes it possible to
  1. Map more memory in the first node without running out of space for the
     page tables,
  2. Boot kernels that don't fit in 4 MiB (e.g. multi_defconfig).

Signed-off-by: Andreas Schwab 

  - Add support for 8 MiB,
  - Store initial mapping size in head.S for later reuse,
  - Add comment about large kernels.

Signed-off-by: Geert Uytterhoeven