Add code to the 54xx ColdFire CPU init to setup memory ready for the m68k
paged memory start up.

Some of the RAM variables that were specific to the non-mmu code paths
now need to be used during this setup, so when CONFIG_MMU is enabled.
Move these out of page_no.h and into page.h.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The 54xx ColdFire CPU family has an internal MMU. Up to now though we
have only supported running on them with the MMU disabled.

Add code to the 54xx ColdFire init sequence to initialize the bootmem
used by the usual MMU m68k code for paging init.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

The ColdFire CPU family, and the original 68000, do not support separate
address spaces like the other 680x0 CPU types. Modify the set_fs()/get_fs()
functions and macros to use a thread_info addr_limit for address space
checking. This is pretty much what all other architectures that do not
support separate setable address spaces do.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Modify the user space access functions to support the ColdFire V4e cores
running with MMU enabled.

The ColdFire processors do not support the "moves" instruction used by
the traditional 680x0 processors for moving data into and out of another
address space. They only support the notion of a single address space,
and you use the usual "move" instruction to access that.

Create a new config symbol (CONFIG_CPU_HAS_ADDRESS_SPACES) to mark the
CPU types that support separate address spaces, and thus also support
the sfc/dfc registers and the "moves" instruction that go along with that.

The code is almost identical for user space access, so lets just use a
define to choose either the "move" or "moves" in the assembler code.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Add appropriate TASK_SIZE and TASK_UNMAPPED_BASE definitions for running
on ColdFire V4e cores with MMU enabled.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

The interrupt handling support defines and code is not so much conditional
on an MMU being present (CONFIG_MMU), as it is on which type of CPU we are
building for. So make the code conditional on the CPU types instead. The
current irq.h is mostly specific to the interrupt code for the 680x0 CPUs,
so it should only be used for them.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Basic register level definitions to support the internal MMU of the
V4e ColdFire cores.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Update the show_cpuinfo() code to display info about ColdFire cores.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Create machine and CPU definitions to support the ColdFire CPU family
members that have a virtual memory management unit.

The ColdFire V4e core contains an MMU, and it is quite different to
any other 68k family members.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: NMatt Waddel <mwaddel@yahoo.com>
Acked-by: NKurt Mahan <kmahan@xmission.com>

Compiling for the m68knommu/68328 Palm/Pilot target you get:

  LD      vmlinux
arch/m68k/platform/68328/head.o: In function `L3':
(.text+0x170): undefined reference to `rom_length'

"rom_length" is not used any longer by any of the m68knommu code.
So remove it from here too.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Compiling for the m68knommu/68328 Palm/Pilot target you get:

  AS      arch/m68k/platform/68328/head-pilot.o
arch/m68k/platform/68328/head-pilot.S:37:23: fatal error: bootlogo.rh: No such file or directory

The build for this target used to do a conversion on a C coded boot logo
and include this in the head assembler code. This got broken by changes to
the local Makefile.

Clean all this up by just including the C coded boot logo struct in the
C code. With the appropriate alignment attribute there is no difference
to the way it can be used.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The merge of m68knommu left the linker scripts a little disorganized.
Some consistent naming and squashing two of scripts that just include
others can simplify things a lot.

So merge the two simple including scripts, and rename the nommu script
to be consistent with the existing m68k linker scripts.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The code that used the anchor.h include file has long been removed from
the kernel. Remove it too.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

There is a race on reading the ColdFire slice timer current count and the
total clock count so far. Interrupts are off, and we may have just missed
getting a new timer wrap event interrupt. Check for this and adjust the
cycle count and current read count accordingly.

Also the slice timer counts down from the terminal count. So in read_clk()
we need take the current clock count away from the terminal count.
Reported-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Disbale the CPU cache really early in the ColdFire startup code. We set
up some variables for RAM sizing and we want to make they stick in RAM.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The traditional 68000 processors and the newer reduced instruction set
ColdFire processors do not support the 32*32->64 multiply or the 64/32->32
divide instructions. This is not a difference based on the presence of
a hardware MMU or not.

Create a new config symbol to mark that a CPU type doesn't support the
longer multiply/divide instructions. Use this then as a basis for using
the fast 64bit based divide (in div64.h) and for linking in the extra
libgcc functions that may be required (mulsi3, divsi3, etc).
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

We have two implementations of the IP checksuming code for the m68k arch.
One uses the more advanced instructions available in 68020 and above
processors, the other uses the simpler instructions available on the
original 68000 processors and the modern ColdFire processors.

This simpler code is pretty much the same as the generic lib implementation
of the IP csum functions. So lets just switch over to using that. That
means we can completely remove the checksum_no.c file, and only have the
local fast code used for the more complex 68k CPU family members.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

There is no reason we can't make the saved fp registers the same for all
m68k types and ColdFire. There is a little wasted space, but the code
consistency and cleanliness is a big win.

sigcontext.h is an exported header, but currently there is no in-mainline
users of the !__uClinux__ and __mcoldfire__ case that this change effects.
Even better this change actually makes this structure consistent with
the out-of-mainline ColdFire/MMU code.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Commit 61619b12 ("m68k: merge mmu and
non-mmu include/asm/entry.h files") made the trap entry code basically
the same for mmu and non-mmu builds. This means we no longer need code
to mark the stack frame as "system-call" type or other in the non-mmu
trap handling entry points. This is done in the SAVE_ALL_INT macro now.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The non-MMU builds of m68k allow a fixed kernel boot command line to
be configured at configure time. Allow this MMU builds as well.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Output a table of the kernel memory regions at boot time.
This is taken directly from the ARM architecture code that does this.
The table looks like this:

Virtual kernel memory layout:
    vector  : 0x00000000 - 0x00000400   (   0 KiB)
    kmap    : 0xd0000000 - 0xe0000000   ( 256 MiB)
    vmalloc : 0xc0000000 - 0xcfffffff   ( 255 MiB)
    lowmem  : 0x00000000 - 0x02000000   (  32 MiB)
      .init : 0x00128000 - 0x00134000   (  48 KiB)
      .text : 0x00020000 - 0x00118d54   ( 996 KiB)
      .data : 0x00118d60 - 0x00126000   (  53 KiB)
      .bss  : 0x00134000 - 0x001413e0   (  53 KiB)

This has been very useful while debugging the ColdFire virtual memory
support code. But in general I think it is nice to know extacly where
the kernel has layed everything out on boot.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The mach_gettod function pointer is only called from the time_no.c
code. So move its actual definition to there too. It is currently in
setup_no.c for no particularly good reason.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The selection of the CONFIG_GENERIC_ATOMIC64 option is not specific to the
MMU being present and enabled. It is a property of certain CPU families.
So select it based on those CPU types being selected.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Currently on m68k we have a comeplete thread_info structure stored inside
of the thread_struct, and we also have it in the initial part of the kernel
stack. Mostly the code currently uses the one inside of the thread_struct,
only using the "task" pointer from the stack based one.

This is wasteful and confusing, we should only have the single instance of
thread_info inside the stack page. And this is the norm for all other
architectures.

This change makes m68k handle thread_info consistently on both MMU enabled
and non-MMU setups.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

We have a duplicate name and definition for the offset of the thread.info
struct within the task struct in our asm-offsets.c code. Remove one of them,
and consolidate to use a single define, TASK_INFO.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The init_task code can be the same for both mmu and non-mmu targets.
None of the alignment carried out in the the current init_task code
is necessary. The linker script takes care of aligning the init_thread
structure to a THREAD SIZE boundary, and that is all we need.

So use the init_task.c code for all target types, that makes m68k
code consistent with what most other architectures do.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The fasthandler code was removed long ago. Remove the now unused
declaration of it.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

gpiolib provides __gpio_to_irq() to map gpiolib gpios to interrupts - hook
that up on m68k.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Updated to merge the valid bits of the two m68k patches.

This converts the m86k clocksources to use clocksource_register_hz/khz

This is untested, so any assistance in testing would be appreciated!

CC: Geert Uytterhoeven <geert@linux-m68k.org>
CC: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  VFS: Fix race between CPU hotplug and lglocks

for linus: writeback reason binary tracing format fix

* tag 'writeback' of git://git.kernel.org/pub/scm/linux/kernel/git/wfg/linux:
  writeback: show writeback reason with __print_symbolic

* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
  kconfig: adapt update-po-config to new UML layout

* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] omap3isp: Fix crash caused by subdevs now having a pointer to devnodes

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: call d_instantiate after all ops are setup
  Btrfs: fix worker lock misuse in find_worker

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
  sparc64: Fix MSIQ HV call ordering in pci_sun4v_msiq_build_irq().

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  netfilter: xt_connbytes: handle negation correctly
  net: relax rcvbuf limits
  rps: fix insufficient bounds checking in store_rps_dev_flow_table_cnt()
  net: introduce DST_NOPEER dst flag
  mqprio: Avoid panic if no options are provided
  bridge: provide a mtu() method for fake_dst_ops

"! --connbytes 23:42" should match if the packet/byte count is not in range.

As there is no explict "invert match" toggle in the match structure,
userspace swaps the from and to arguments
(i.e., as if "--connbytes 42:23" were given).

However, "what <= 23 && what >= 42" will always be false.

Change things so we use "||" in case "from" is larger than "to".

This change may look like it breaks backwards compatibility when "to" is 0.
However, older iptables binaries will refuse "connbytes 42:0",
and current releases treat it to mean "! --connbytes 0:42",
so we should be fine.
Signed-off-by: NFlorian Westphal <fw@strlen.de>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

This closes races where btrfs is calling d_instantiate too soon during
inode creation.  All of the callers of btrfs_add_nondir are updated to
instantiate after the inode is fully setup in memory.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NChris Mason <chris.mason@oracle.com>