Skip to content
  1. Nov 12, 2014
  3. Nov 10, 2014
  5. Nov 04, 2014
    • Tony Lindgren's avatar
      ARM: dts: Fix missing GPMC NAND device width for omap3 boards · 24f284af
      Tony Lindgren authored 
      

Looks like we have some GPMC NAND timings missing device
width. This fixes "gpmc_cs_program_settings: invalid width 0!"
errors during boot.

Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      24f284af
    • Tony Lindgren's avatar
      ARM: dts: Use better omap GPMC timings for LAN9220 · 13aec8e4
      Tony Lindgren authored 
      

With the GPMC warnings now enabled, I noticed the LAN9220 timings
can overflow the GPMC registers with 200MHz L3 speed. Earlier we
were just skipping the bad timings and would continue with the
bootloader timings. Now we no longer allow to continue with bad
timings as we have the timings in the .dts files.

We could start using the GPMC clock divider, but let's instead
use the u-boot timings that are known to be working and a bit
faster. These are basically the u-boot NET_GPMC_CONFIG[1-6]
defines deciphered. Except that we don't set gpmc,burst-length
as that's only partially configured and does not seem to work
if fully enabled.

[tony@atomide.com: updated to remove gpmc,burst-length]
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      13aec8e4
  7. Oct 30, 2014
    • Tony Lindgren's avatar
      ARM: dts: Add GPMC timings for omap zoom serial port · b5399ea8
      Tony Lindgren authored 
      

The four port serial port on the zoom debug board uses a TL16CP754C
with a single interrupt and GPMC chip select. The serial ports each
use a 8 bytes for IO registers, and are 256 bytes apart on the GPMC
line.

Let's add timings for all four ports so we can remove the GPMC
workarounds for using bootloader timings.

Not caused by this patch, but looks like u-boot only properly
initializes the fifo on the first serial port. Currently the other
ports produce garbage at least with my version of u-boot. I suspect
that TL16CP754C needs non-standard initialization added to 8250
driver to properly fix this issue.

Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      b5399ea8
    • Tony Lindgren's avatar
      ARM: dts: Add smc91x GPMC configuration for 2430sdp · 1bb37404
      Tony Lindgren authored 
      

Let's use the bootloader values except for the partially configured
wait-pin that does not seem to work.

Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      1bb37404
    • Tony Lindgren's avatar
      ARM: dts: Fix wrong GPMC size mappings for omaps · e2c5eb78
      Tony Lindgren authored 
      

The GPMC binding is obviously very confusing as the values
are all over the place. People seem to confuse the GPMC partition
size for the chip select, and the device IO size within the GPMC
partition easily.

The ranges entry contains the GPMC partition size. And the
reg entry contains the size of the IO registers of the
device connected to the GPMC.

Let's fix the issue according to the following table:

Device          GPMC partition size     Device IO size
connected       in the ranges entry     in the reg entry

NAND            0x01000000 (16MB)       4
16550           0x01000000 (16MB)       8
smc91x          0x01000000 (16MB)       0xf
smc911x         0x01000000 (16MB)       0xff
OneNAND         0x01000000 (16MB)       0x20000 (128KB)
16MB NOR        0x01000000 (16MB)       0x01000000 (16MB)
32MB NOR        0x02000000 (32MB)       0x02000000 (32MB)
64MB NOR        0x04000000 (64MB)       0x04000000 (64MB)
128MB NOR       0x08000000 (128MB)      0x08000000 (128MB)
256MB NOR       0x10000000 (256MB)      0x10000000 (256MB)

Let's also add comments to the fixed entries while at it.

Acked-by: default avatarRoger Quadros <rogerq@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      e2c5eb78
    • Tony Lindgren's avatar
      ARM: dts: Fix bootloader version dependencies by muxing n900 smc91x pins · 9a894953
      Tony Lindgren authored 
      

Apparently some versions of nolo don't mux the all the necessary GPMC
pins for the smc91x probe to work properly. Let's fix this issue
by adding mux support for GPMC to the kernel.

Note that GPMC clk needs input enabled for OnenNAND to work.

Cc: Kevin Hilman <khilman@kernel.org>
Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      9a894953
  9. Oct 25, 2014
  11. Oct 24, 2014
    • Catalin Marinas's avatar
      arm64: Fix memblock current_limit with 64K pages and 48-bit VA · 3dec0fe4
      Catalin Marinas authored 
      

With 48-bit VA space, the 64K page configuration uses 3 levels instead
of 2 and PUD_SIZE != PMD_SIZE. Since with 64K pages we only cover
PMD_SIZE with the initial swapper_pg_dir populated in head.S, the
memblock current_limit needs to be set accordingly in map_mem() to avoid
allocating unmapped memory. The memblock current_limit is progressively
increased as more blocks are mapped.

Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      3dec0fe4
    • David S. Miller's avatar
      sparc64: Implement __get_user_pages_fast(). · 06090e8e
      David S. Miller authored 
      

It is not sufficient to only implement get_user_pages_fast(), you
must also implement the atomic version __get_user_pages_fast()
otherwise you end up using the weak symbol fallback implementation
which simply returns zero.

This is dangerous, because it causes the futex code to loop forever
if transparent hugepages are supported (see get_futex_key()).

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06090e8e
    • David S. Miller's avatar
      sparc64: Fix register corruption in top-most kernel stack frame during boot. · ef3e035c
      David S. Miller authored 
      

Meelis Roos reported that kernels built with gcc-4.9 do not boot, we
eventually narrowed this down to only impacting machines using
UltraSPARC-III and derivitive cpus.

The crash happens right when the first user process is spawned:

[   54.451346] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
[   54.451346]
[   54.571516] CPU: 1 PID: 1 Comm: init Not tainted 3.16.0-rc2-00211-gd7933ab #96
[   54.666431] Call Trace:
[   54.698453]  [0000000000762f8c] panic+0xb0/0x224
[   54.759071]  [000000000045cf68] do_exit+0x948/0x960
[   54.823123]  [000000000042cbc0] fault_in_user_windows+0xe0/0x100
[   54.902036]  [0000000000404ad0] __handle_user_windows+0x0/0x10
[   54.978662] Press Stop-A (L1-A) to return to the boot prom
[   55.050713] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004

Further investigation showed that compiling only per_cpu_patch() with
an older compiler fixes the boot.

Detailed analysis showed that the function is not being miscompiled by
gcc-4.9, but it is using a different register allocation ordering.

With the gcc-4.9 compiled function, something during the code patching
causes some of the %i* input registers to get corrupted.  Perhaps
we have a TLB miss path into the firmware that is deep enough to
cause a register window spill and subsequent restore when we get
back from the TLB miss trap.

Let's plug this up by doing two things:

1) Stop using the firmware stack for client interface calls into
   the firmware.  Just use the kernel's stack.

2) As soon as we can, call into a new function "start_early_boot()"
   to put a one-register-window buffer between the firmware's
   deepest stack frame and the top-most initial kernel one.

Reported-by: default avatarMeelis Roos <mroos@linux.ee>
Tested-by: default avatarMeelis Roos <mroos@linux.ee>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ef3e035c
    • Arun Chandran's avatar
      arm64: ASLR: Don't randomise text when randomise_va_space == 0 · 92980405
      Arun Chandran authored 
      

When user asks to turn off ASLR by writing "0" to
/proc/sys/kernel/randomize_va_space there should not be
any randomization to mmap base, stack, VDSO, libs, text and heap

Currently arm64 violates this behavior by randomising text.
Fix this by defining a constant ELF_ET_DYN_BASE. The randomisation of
mm->mmap_base is done by setup_new_exec -> arch_pick_mmap_layout ->
mmap_base -> mmap_rnd.

Signed-off-by: default avatarArun Chandran <achandran@mvista.com>
Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      92980405
    • Ralf Baechle's avatar
      MIPS: SEAD3: Fix I2C device registration. · 4846f118
      Ralf Baechle authored 
      

This isn't a module and shouldn't be one.

Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      4846f118
    • Nadav Amit's avatar
      KVM: x86: Wrong assertion on paging_tmpl.h · 1715d0dc
      Nadav Amit authored 
      

Even after the recent fix, the assertion on paging_tmpl.h is triggered.
Apparently, the assertion wants to check that the PAE is always set on
long-mode, but does it in incorrect way.  Note that the assertion is not
enabled unless the code is debugged by defining MMU_DEBUG.

Signed-off-by: default avatarNadav Amit <namit@cs.technion.ac.il>
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1715d0dc