Merging the mmu and non-mmu directories we ended up with duplicate
implementations of memcpy(). One is a little more optimized for the
>= 68020 case, but that can easily be inserted into a single
implementation of memcpy(). Clean up the exporting of this symbol
too, otherwise we end up exporting it twice on a no-mmu build.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Merging the mmu and non-mmu directories we ended up with duplicate
implementations of memset(). One is a little more optimized for the
>= 68020 case, but that can easily be inserted into a single
implementation of memset(). Clean up the exporting of this symbol
too, otherwise we end up exporting it twice on a no-mmu build.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Merging the mmu and non-mmu directories we ended up with duplicate
(and identical) implementations of memmove(). Remove one of them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
We can easily support the slight differences in libs needed by the
mmu and non-mmu builds in a single Makefile, so merge them back into
a single file again.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
The implementation of gcc's muldi3 support function differs only in
the use of the machine's 64 bit sized mul or not. (It isn't based
on using an MMU or not). Merge the current mmu and non-mmu versions
of arc/m68k/lib/muldi3 and use the appropriate pre-processor
conditionals to get the right version for all m68k processor types.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (39 commits)
b43: fix comment typo reqest -> request
Haavard Skinnemoen has left Atmel
cris: typo in mach-fs Makefile
Kconfig: fix copy/paste-ism for dell-wmi-aio driver
doc: timers-howto: fix a typo ("unsgined")
perf: Only include annotate.h once in tools/perf/util/ui/browsers/annotate.c
md, raid5: Fix spelling error in comment ('Ofcourse' --> 'Of course').
treewide: fix a few typos in comments
regulator: change debug statement be consistent with the style of the rest
Revert "arm: mach-u300/gpio: Fix mem_region resource size miscalculations"
audit: acquire creds selectively to reduce atomic op overhead
rtlwifi: don't touch with treewide double semicolon removal
treewide: cleanup continuations and remove logging message whitespace
ath9k_hw: don't touch with treewide double semicolon removal
include/linux/leds-regulator.h: fix syntax in example code
tty: fix typo in descripton of tty_termios_encode_baud_rate
xtensa: remove obsolete BKL kernel option from defconfig
m68k: fix comment typo 'occcured'
arch:Kconfig.locks Remove unused config option.
treewide: remove extra semicolons
...
A new utility function (core_kernel_data()) is used to determine if a
passed in address is part of core kernel data or not. It may or may not
return true for RO data, but this utility must work for RW data.
Thus both _sdata and _edata must be defined and continuous,
without .init sections that may later be freed and replaced by
volatile memory (memory that can be freed).
This utility function is used to determine if data is safe from
ever being freed. Thus it should return true for all RW global
data that is not in a module or has been allocated, or false
otherwise.
Also change core_kernel_data() back to the more precise _sdata condition
and document the function.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Hirokazu Takata <takata@linux-m32r.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: linux-m68k@lists.linux-m68k.org
Cc: Kyle McMartin <kyle@mcmartin.ca>
Cc: Helge Deller <deller@gmx.de>
Cc: JamesE.J.Bottomley <jejb@parisc-linux.org>
Link: http://lkml.kernel.org/r/1305855298.1465.19.camel@gandalf.stny.rr.com
Signed-off-by: Ingo Molnar <mingo@elte.hu>
----
arch/alpha/kernel/vmlinux.lds.S | 1 +
arch/m32r/kernel/vmlinux.lds.S | 1 +
arch/m68k/kernel/vmlinux-std.lds | 2 ++
arch/m68k/kernel/vmlinux-sun3.lds | 1 +
arch/mips/kernel/vmlinux.lds.S | 1 +
arch/parisc/kernel/vmlinux.lds.S | 3 +++
kernel/extable.c | 12 +++++++++++-
7 files changed, 20 insertions(+), 1 deletion(-)
The Atari keyboard driver calls atari_mouse_interrupt_hook if it's set, not
atari_input_mouse_interrupt_hook. Fix below.
[geert] Killed off atari_mouse_interrupt_hook completely, after fixing another
incorrect assignment in atarimouse.c.
Signed-off-by: Michael Schmitz <schmitz@debian.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
It may trigger a warning in fs/proc/generic.c:__xlate_proc_name() when
trying to add an entry for the interrupt handler to sysfs.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
We reserved the numbers a long time ago, but never wired them up in the
syscall table as they need TIF_RESTORE_SIGMASK, which we only got last year
in commit cb6831d5d3099e772a510eb3e1ed0760ccffb45e ("m68k: Switch to saner
sigsuspend()")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: stable@kernel.org
Impact for nommu:
- Store table in .rodata instead of .text,
- Let kernel/sys_ni.c handle the stubbing of MMU-only syscalls,
- Implement sys_mremap and sys_nfsservct,
- Remove unused padding at the end of the table.
Impact for mmu:
- Store table in .rodata instead of .data.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Greg Ungerer <gerg@uclinux.org>
find_next bitops on m68k (find_next_zero_bit, find_next_bit, and
find_next_bit_le) may cause out of bounds memory access
when the bitmap size in bits % 32 != 0 and offset (the bitnumber
to start searching at) is very close to the bitmap size.
For example,
unsigned long bitmap[2] = { 0, 0 };
find_next_bit(bitmap, 63, 62);
1. find_next_bit() tries to find any set bits in bitmap[1],
but no bits set.
2. Then find_first_bit(bimap + 2, -1)
3. Unfortunately find_first_bit() takes unsigned int as the size argument.
4. find_first_bit will access bitmap[2~] until it find any set bits.
Add missing tests for stepping beyond the end of the bitmap to all
find_{first,next}_*() functions, and make sure they never return a value
larger than the bitmap size.
Reported-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Hence use "offset" in find_next_{,zero_}bit(), like is already done for
find_next_{,zero_}bit_le()
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
For m68k, N_NORMAL_MEMORY represents all nodes that have present memory
since it does not support HIGHMEM. This patch sets the bit at the time
node_present_pages has been set by free_area_init_node.
At the time the node is brought online, the node state would have to be
done unconditionally since information about present memory has not yet
been recorded.
If N_NORMAL_MEMORY is not accurate, slub may encounter errors since it
uses this nodemask to setup per-cache kmem_cache_node data structures.
This pach is an alternative to the one proposed by David Rientjes
<rientjes@google.com> attempting to set node state immediately when
bringing the node online.
Signed-off-by: Michael Schmitz <schmitz@debian.org>
Tested-by: Thorsten Glaser <tg@debian.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
CC: stable@kernel.org
The patch below changes a typo occcured to occurred in two comments.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
There is a lot of common code that could be shared between the m68k
and m68knommu arch branches. It makes sense to merge the two branches
into a single directory structure so that we can more easily share
that common code.
This is a brute force merge, based on a script from Stephen King
<sfking@fdwdc.com>, which was originally written by Arnd Bergmann
<arnd@arndb.de>.
> The script was inspired by the script Sam Ravnborg used to merge the
> includes from m68knommu. For those files common to both arches but
> differing in content, the m68k version of the file is renamed to
> <file>_mm.<ext> and the m68knommu version of the file is moved into the
> corresponding m68k directory and renamed <file>_no.<ext> and a small
> wrapper file <file>.<ext> is used to select between the two version. Files
> that are common to both but don't differ are removed from the m68knommu
> tree and files and directories that are unique to the m68knommu tree are
> moved to the m68k tree. Finally, the arch/m68knommu tree is removed.
>
> To select between the the versions of the files, the wrapper uses
>
> #ifdef CONFIG_MMU
> #include <file>_mm.<ext>
> #else
> #include <file>_no.<ext>
> #endif
On top of this file merge I have done a simplistic merge of m68k and
m68knommu Kconfig, which primarily attempts to keep existing options and
menus in place. Other than a handful of options being moved it produces
identical .config outputs on m68k and m68knommu targets I tested it on.
With this in place there is now quite a bit of scope for merge cleanups
in future patches.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
There is no user now.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: David Miller <davem@davemloft.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Matt Turner <mattst88@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
minix bit operations are only used by minix filesystem and useless by
other modules. Because byte order of inode and block bitmaps is different
on each architecture like below:
m68k:
big-endian 16bit indexed bitmaps
h8300, microblaze, s390, sparc, m68knommu:
big-endian 32 or 64bit indexed bitmaps
m32r, mips, sh, xtensa:
big-endian 32 or 64bit indexed bitmaps for big-endian mode
little-endian bitmaps for little-endian mode
Others:
little-endian bitmaps
In order to move minix bit operations from asm/bitops.h to architecture
independent code in minix filesystem, this provides two config options.
CONFIG_MINIX_FS_BIG_ENDIAN_16BIT_INDEXED is only selected by m68k.
CONFIG_MINIX_FS_NATIVE_ENDIAN is selected by the architectures which use
native byte order bitmaps (h8300, microblaze, s390, sparc, m68knommu,
m32r, mips, sh, xtensa). The architectures which always use little-endian
bitmaps do not select these options.
Finally, we can remove minix bit operations from asm/bitops.h for all
architectures.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Michal Simek <monstr@monstr.eu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Hirokazu Takata <takata@linux-m32r.org>
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Cc: Chris Zankel <chris@zankel.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As a preparation for moving minix bit operations from asm/bitops.h to
architecture independent code in minix filesystem, this removes inline asm
from minix_find_first_zero_bit() for m68k.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As the result of conversions, there are no users of ext2 non-atomic bit
operations except for ext2 filesystem itself. Now we can put them into
architecture independent code in ext2 filesystem, and remove from
asm/bitops.h for all architectures.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Introduce little-endian bit operations by renaming native ext2 bit
operations. The ext2 bit operations are kept as wrapper macros using
little-endian bit operations to maintain bisectability until the
conversions are finished.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Introduce little-endian bit operations by renaming native ext2 bit
operations and changing find_*_bit_le() to take a "void *". The ext2 bit
operations are kept as wrapper macros using little-endian bit operations
to maintain bisectability until the conversions are finished.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Schwab <schwab@linux-m68k.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
All architectures can use the common dma_addr_t typedef now. We can
remove the arch specific dma_addr_t.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Matt Turner <mattst88@gmail.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k/block: amiflop - Remove superfluous amiga_chip_alloc() cast
m68k/atari: ARAnyM - Add support for network access
m68k/atari: ARAnyM - Add support for console access
m68k/atari: ARAnyM - Add support for block access
m68k/atari: Initial ARAnyM support
m68k: Kconfig - Remove unneeded "default n"
m68k: Makefiles - Change to new flags variables
m68k/amiga: Reclaim Chip RAM for PPC exception handlers
m68k: Allow all kernel traps to be handled via exception fixups
m68k: Use base_trap_init() to initialize vectors
m68k: Add helper function handle_kernel_fault()
* 'tty-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6: (76 commits)
pch_uart: reference clock on CM-iTC
pch_phub: add new device ML7213
n_gsm: fix UIH control byte : P bit should be 0
n_gsm: add a documentation
serial: msm_serial_hs: Add MSM high speed UART driver
tty_audit: fix tty_audit_add_data live lock on audit disabled
tty: move cd1865.h to drivers/staging/tty/
Staging: tty: fix build with epca.c driver
pcmcia: synclink_cs: fix prototype for mgslpc_ioctl()
Staging: generic_serial: fix double locking bug
nozomi: don't use flush_scheduled_work()
tty/serial: Relax the device_type restriction from of_serial
MAINTAINERS: Update HVC file patterns
tty: phase out of ioctl file pointer for tty3270 as well
tty: forgot to remove ipwireless from drivers/char/pcmcia/Makefile
pch_uart: Fix DMA channel miss-setting issue.
pch_uart: fix exclusive access issue
pch_uart: fix auto flow control miss-setting issue
pch_uart: fix uart clock setting issue
pch_uart : Use dev_xxx not pr_xxx
...
Fix up trivial conflicts in drivers/misc/pch_phub.c (same patch applied
twice, then changes to the same area in one branch)
Add improved support for running under the ARAnyM emulator
(Atari Running on Any Machine - http://aranym.org/).
[michael, geert: Cleanups and updates]
Signed-off-by: Petr Stehlik <pstehlik@sophics.cz>
Signed-off-by: Michael Schmitz <schmitz@debian.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
Signed-off-by: matt mooney <mfm@muteddisk.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
On m68k, it doesn't make sense to reserve memory for the PPC exception
handlers, and APUS support is dead.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
This will be needed by the ARAnyM Native Feature initialization code.
Also document that the VEC_TRACE check is needed for 68020/30.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
So basic initialization is all in one place.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Add helper function handle_kernel_fault() in signal.c, so frame_extra_sizes
can become static, and to avoid future code duplication.
Signed-off-by: Roman Zippel <zippel@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
* 'timers-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: (62 commits)
posix-clocks: Check write permissions in posix syscalls
hrtimer: Remove empty hrtimer_init_hres_timer()
hrtimer: Update hrtimer->state documentation
hrtimer: Update base[CLOCK_BOOTTIME].offset correctly
timers: Export CLOCK_BOOTTIME via the posix timers interface
timers: Add CLOCK_BOOTTIME hrtimer base
time: Extend get_xtime_and_monotonic_offset() to also return sleep
time: Introduce get_monotonic_boottime and ktime_get_boottime
hrtimers: extend hrtimer base code to handle more then 2 clockids
ntp: Remove redundant and incorrect parameter check
mn10300: Switch do_timer() to xtimer_update()
posix clocks: Introduce dynamic clocks
posix-timers: Cleanup namespace
posix-timers: Add support for fd based clocks
x86: Add clock_adjtime for x86
posix-timers: Introduce a syscall for clock tuning.
time: Splitout compat timex accessors
ntp: Add ADJ_SETOFFSET mode bit
time: Introduce timekeeping_inject_offset
posix-timer: Update comment
...
Fix up new system-call-related conflicts in
arch/x86/ia32/ia32entry.S
arch/x86/include/asm/unistd_32.h
arch/x86/include/asm/unistd_64.h
arch/x86/kernel/syscall_table_32.S
(name_to_handle_at()/open_by_handle_at() vs clock_adjtime()), and some
due to movement of get_jiffies_64() in:
kernel/time.c
The EDGE Port module of some ColdFire parts using the intc-simr interrupt
controller provides support for 7 external interrupts. These interrupts
go off-chip (that is they are not for internal peripherals). They need
some special handling and have some extra setup registers. Add code to
support them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The EDGE Port module of some ColdFire parts using the intc-2 interrupt
controller provides support for 7 external interrupts. These interrupts
go off-chip (that is they are not for internal peripherals). They need
some special handling and have some extra setup registers. Add code to
support them.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The reality is that you do not need the abiltity to configure the
clock divider for ColdFire CPUs. It is a fixed ratio on any given
ColdFire family member. It is not the same for all ColdFire parts,
but it is always the same in a model range. So hard define the divider
for each supported ColdFire CPU type and remove the Kconfig option.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Most ColdFire CPUs have an internal peripheral set that can be mapped at
a user selectable address. Different ColdFire parts either use an MBAR
register of an IPSBAR register to map the peripheral region. Most boards
use the Freescale default mappings - but not all.
Make the setting of the MBAR or IPSBAR register configurable. And only make
the selection available on the appropriate ColdFire CPU types.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Different ColdFire CPUs have different ways of defining where their
internal peripheral registers sit in their address space. Some use an
MBAR register, some use and IPSBAR register, some have a fixed mapping.
Now that most of the peripheral address definitions have been cleaned up
we can clean up the setting of the MBAR and IPSBAR defines to limit them
to just where they are needed (and where they actually exist).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
In some of the RAM size autodetection code on ColdFire CPU startup
we reference DRAM registers relative to the MBAR register. Not all of
the supported ColdFire CPUs have an MBAR, and currently this works
because we fake an MBAR address on those registers. In an effort to
clean this up, and eventually remove the fake MBAR setting make the
DRAM register address definitions actually contain the MBAR (or IPSBAR
as appropriate) value as required.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Not all ColdFire CPUs that use the old style timer hardware module use
an MBAR set peripheral region. Move the TIMER base address defines to the
per-CPU header files where we can set it correctly based on how the
peripherals are mapped - instead of using a fake MBAR for some platforms.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The base addresses of the ColdFire DMA unit registers belong with
all the other address definitions in the per-cpu headers. The current
definitions assume they are relative to an MBAR register. Not all
ColdFire CPUs have an MBAR register. A clean address define can only
be acheived in the per-cpu headers along with all the other chips
peripheral base addresses.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 528x family of CPUs does not have an MBAR register, so don't
define its peripheral addresses relative to one. Its internal peripherals
are relative to the IPSBAR register, so make sure to use that.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 527x family of CPUs does not have an MBAR register, so don't
define its peripheral addresses relative to one. Its internal peripherals
are relative to the IPSBAR register, so make sure to use that.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 523x family of CPUs does not have an MBAR register, so don't
define its peripheral addresses relative to one. Its internal peripherals
are relative to the IPSBAR register, so make sure to use that.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 5207 and 5208 CPUs have fixed peripheral addresses.
They do not use the setable peripheral address registers like the MBAR
and IPSBAR used on many other ColdFire parts. Don't use fake values
of MBAR and IPSBAR when using peripheral addresses for them, there
is no need to.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The PIT hardware timer module used in some ColdFire CPU's is not always
addressed relative to an IPSBAR register. Parts like the ColdFire 5207 and
5208 have fixed peripheral addresses. So lets not define the register
addresses of the PIT relative to an IPSBAR definition. Move the base
address definitions into the per-part headers. This is a lot more consistent
since all the other peripheral base addresses are defined in the per-part
header files already.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Remove the bogus definition of the MBAR register for the ColdFire 532x
family. It doesn't have an MBAR register, its peripheral registers are
at fixed addresses and are not relative to a settable base.
All the code that relyed on this definition existing has been cleaned
up. The register address definitions now include the base as required.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 54xx family shares the same interrupt controller used
on the 523x, 527x and 528x ColdFire parts, but it isn't offset
relative to the IPSBAR register. The 54xx doesn't have an IPSBAR
register.
By including the base address of the peripheral registers in the register
definitions (MCFICM_INTC0 and MCFICM_INTC1 in this case) we can avoid
having to define a fake IPSBAR for the 54xx. And this makes the register
address definitions of these more consistent, the majority of the other
register address defines include the peripheral base address already.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The MBAR2 register is only used on the ColdFire 5249 part, so move its
definition out of the common coldfire.h and into the 5249 support header.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
As planned by Arnd Bergmann, this moves the following drivers to the
drivers/staging/tty/ directory where they will be removed after 2.6.41
if no one steps up to claim them.
epca
epca
ip2
istallion
riscom8
serial167
specialix
stallion
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add an m68k/coldfire optimized memmove() function for the m68knommu arch.
This is the same function as used by m68k. Simple speed tests show this
is faster once buffers are larger than 4 bytes, and significantly faster
on much larger buffers (4 times faster above about 100 bytes).
This also goes part of the way to fixing a regression caused by commit
ea61bc461d ("m68k/m68knommu: merge MMU and
non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is
the 68x328 and 68360 families). They currently have no memmove() fucntion
defined, since there was none in the m68knommu/lib functions.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The m68k arch implements its own memcmp() function. It is not optimized
in any way (it is the most strait forward coding of memcmp you can get).
Remove it and use the kernels standard memcmp() implementation.
This also goes part of the way to fixing a regression caused by commit
ea61bc461d ("m68k/m68knommu: merge MMU and
non-MMU string.h"), which breaks non-coldfire non-mmu builds (which is
the 68x328 and 68360 families). They currently have no memcmp() function
defined, since there is none in the m68knommu/lib functions.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
`debug=mem' on Amiga has been broken for a while.
early_param() processing is done very/too early, i.e. before
amiga_identify() / amiga_chip_init(), causing amiga_savekmsg_setup() not
to find any Chip RAM.
As we don't plan to free this memory anyway, just steal it from the initial
Chip RAM memory block instead.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
It's a way too generic name for a global #define and conflicts with a variable
with the same name, causing build errors like:
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c: In function ‘_si_clkctl_cc’:
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1364: error: expected identifier or ‘(’ before ‘volatile’
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1364: error: expected ‘)’ before ‘(’ token
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1421: error: incompatible types in assignment
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1422: error: invalid operands to binary &
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1423: error: invalid operands to binary &
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1424: error: invalid operands to binary |
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: aggregate value used where an integer was expected
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1425: error: incompatible type for argument 4 of ‘bcmsdh_reg_write’
| drivers/staging/brcm80211/brcmfmac/../util/siutils.c:1428: error: invalid operands to binary &
| make[8]: *** [drivers/staging/brcm80211/brcmfmac/../util/siutils.o] Error 1
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Some versions of gcc replace calls to strstr() with single-character
"needle" string parameters by calls to strchr() behind our back.
If strchr() is defined as an inline function, this causes linking errors
like
ERROR: "strchr" [drivers/target/target_core_mod.ko] undefined!
As m68k is the only architecture that has an inline strchr() and this
inline version is not an optimized asm version, uninline strchr() and use
the standard out-of-line C version in lib/string.c instead.
This also decreases the defconfig/allmodconfig kernel image sizes by a few
hundred bytes.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu: (25 commits)
m68knommu: fix broken setting of irq_chip and handler
m68knommu: switch to using -mcpu= flags for ColdFire targets
m68knommu: arch/m68knommu/Kconfig whitespace cleanup
m68knommu: create optimal separate instruction and data cache for ColdFire
m68knommu: support ColdFire caches that do copyback and write-through
m68knommu: support version 2 ColdFire split cache
m68knommu: make cache push code ColdFire generic
m68knommu: clean up ColdFire cache control code
m68knommu: move inclusion of ColdFire v4 cache registers
m68knommu: merge bit definitions for version 3 ColdFire cache controller
m68knommu: create bit definitions for the version 2 ColdFire cache controller
m68knommu: remove empty __iounmap() it is no used
m68knommu: remove kernel_map() code, it is not used
m68knommu: remove do_page_fault(), it is not used
m68knommu: use user stack pointer hardware on some ColdFire cores
m68knommu: remove command line printing DEBUG
m68knommu: remove fasthandler interrupt code
m68knommu: move UART addressing to part specific includes
m68knommu: fix clock rate value reported for ColdFire 54xx parts
m68knommu: move ColdFire CPU names into their headers
...
* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
watchdog: Add MCF548x watchdog driver.
watchdog: add driver for the Atheros AR71XX/AR724X/AR913X SoCs
watchdog: Add TCO support for nVidia chipsets
watchdog: Add support for sp5100 chipset TCO
watchdog: f71808e_wdt: add F71862FG, F71869 to Kconfig
watchdog: iTCO_wdt: TCO Watchdog patch for Intel DH89xxCC PCH
watchdog: iTCO_wdt: TCO Watchdog patch for Intel NM10 DeviceIDs
watchdog: ks8695_wdt: include mach/hardware.h instead of mach/timex.h.
watchdog: Propagate Book E WDT period changes to all cores
watchdog: add CONFIG_WATCHDOG_NOWAYOUT support to PowerPC Book-E watchdog driver
watchdog: alim7101_wdt: fix compiler warning on alim7101_pci_tbl
watchdog: alim1535_wdt: fix compiler warning on ali_pci_tbl
watchdog: Fix reboot on W83627ehf chipset.
watchdog: Add watchdog support for W83627DHG chip
watchdog: f71808e_wdt: Add Fintek F71869 watchdog
watchdog: add f71862fg support
watchdog: clean-up f71808e_wdt.c
If we leave sigreturn via ret_from_signal, we end up with syscall
trace only on entry, leading to very unhappy strace, among other
things. Note that this means different behaviours for signals
delivered while we were in pagefault and for ones delivered while
we were in interrupt...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
a) we should hold modifying regs->format until we know we *will* be
doing stack expansion; otherwise attacker can modify sigframe to
have wrong ->sc_formatvec and install SIGSEGV handler.
b) we should *not* mix copying saved extra stuff from userland with
expanding the stack; once we'd done that manual memmove, we'd better
not return to C, so cleanup is very hard to do. The easiest way
is to copy it on stack first, making sure we won't overwrite on stack
expansion. Fortunately that's easy to do...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Same principle as with the previous patch - do not destroy the
state if sigframe setup fails. Incidentally, it's actually
_less_ work - we don't need to go through adjust_stack dance
on failure if we don't touch regs->stkadj until we know we'd
written sigframe out.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
If we'd failed in setup_frame(), we've no place to store
the original sigmask. It's not an unrecoverable situation -
we raise SIGSEGV, but that SIGSEGV might be successfully
handled (e.g. on altstack). In that case we really don't
want sa_mask of original signal permanently slapped on
the set of blocked signals.
Standard solution: have setup_frame()/setup_rt_frame()
report failure and don't mess with the signal-related
state if that has happened...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Instead of checking the return value of do_signal() we can just do
the work (raise SIGTRAP and clear SR.T1) directly in handle_signal(),
when setting the sigframe up. Simplifies the assembler glue and is
closer to the way we do it on other targets.
Note that do_delayed_trace does *not* disappear; it's still needed
to deal with single-stepping through syscall, since 68040 doesn't
raise the trace exception at all if the trap exception is pending.
We hit it after returning from sys_...() if TIF_DELAYED_TRACE is
set; all that has changed is that we don't reuse it for "single-step
into the handler" codepath.
As the result, do_signal() doesn't need to return anything anymore.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
and saner do_signal() arguments, while we are at it
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
... and had been such since the introduction of get_signal_to_deliver()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Since commit 31c911329e ("mm: check the argument
of kunmap on architectures without highmem"), we get lots of warnings like
arch/m68k/kernel/sys_m68k.c:508: warning: passing argument 1 of ‘kunmap’ from incompatible pointer type
As m68k doesn't support highmem anyway, open code the calls to kmap() and
kunmap() (the latter is a no-op) to kill the warnings, like is done on most
other architectures without CONFIG_HIGHPTE.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Sam Creasey <sammy@sammy.net>
Create separate functions to deal with instruction and data cache flushing.
This way we can optimize them for the vairous cache types and arrangements
used across the ColdFire family.
For example the unified caches in the version 3 cores means we don't
need to flush the instruction cache. For the version 2 cores that do
not do data cacheing (or where we choose instruction cache only) we
don't need to do any data flushing.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The version 3 and version 4 ColdFire cache controllers support both
write-through and copy-back modes on the data cache. Allow for Kconfig
time configuration of this, and set the cache mode appropriately.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The newer version 2 ColdFire CPU cores support a configurable cache
arrangement. The cache memory can be used as all instruction cache, all
data cache, or split in half for both instruction and data caching.
Support this setup via a Kconfig time menu that allows a kernel builder
to choose the arrangement they want to use.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Currently the code to push cache lines is only available to version 4
cores. Version 3 cores may also need to use this if we support copy-
back caches on them. Move this code to make it more generic, and
useful for all version ColdFire cores.
With this in place we can now have a single cache_flush_all() code
path that does all the right things on all version cores.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The cache control code for the ColdFire CPU's is a big ugly mess
of "#ifdef"ery liberally coated with bit constants. Clean it up.
The cache controllers in the various ColdFire parts are actually quite
similar. Just differing in some bit flags and options supported. Using
the header defines now in place it is pretty easy to factor out the
small differences and use common setup and flush/invalidate code.
I have preserved the cache setups as they where in the old code
(except where obviously wrong - like in the case of the 5249). Following
from this it should be easy now to extend the possible setups used on
the CACHE controllers that support split cacheing or copy-back or
write through options.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Move the inclusion of the version 4 cache controller registers so that
it is with all the other register bit flag definitions. This makes it
consistent with the other version core inclusion points, and means we
don't need "#ifdef"ery in odd-ball places for these definitions.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
All version 3 based ColdFire CPU cores have a similar cache controller.
Merge all the exitsing definitions into a single file, and make them
similar in style and naming to the existing version 2 and version 4
cache controller definitions.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The version 2 ColdFire CPU based cores all contain a similar cache
controller unit. Create a set of bit flag definitions for the supporting
registers.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The more modern ColdFire parts (even if based on older version cores)
have separate user and supervisor stack pointers (a7 register).
Modify the ColdFire CPU setup and exception code to enable and use
this on parts that have it.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire UART base addresses varies between the different ColdFire
family members. Instead of keeping the base addresses with the UART
definitions keep them with the other addresses definitions for each
ColdFire part.
The motivation for this move is so that when we add new ColdFire
part definitions, they are all in a single file (and we shouldn't
normally need to modify the UART definitions in mcfuart.h at all).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The instruction timings of the ColdFire 54xx family parts are
different to other version 4 parts (or version 2 or 3 parts for
that matter too).
Move the instruction timing setting into the ColdFire part
specific headers, and set the 54xx value appropriately.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Move the ColdFire CPU names out of setup.c and into their repsective
headers. That way when we add new ones we won't need to modify
setup.c any more.
Add the missing 548x CPU name.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The ColdFire 547x family of processors is very similar to the ColdFire
548x series. Almost all of the support for them is the same. Make the
code supporting the 548x more gneric, so it will be capable of
supporting both families.
For the most part this is a renaming excerise to make the support
code more obviously apply to both families.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Now that we have meaningfull symbolic constants for bit definitions
of the cache registers of m5407 and m548x chips, use them to
improve readability, portability and efficiency of the cache operations.
This also fixes __flush_cache_all for m548x chips : implicit
DCACHE_SIZE was exact for m5407, but wrong for m548x.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
__flush_cache_all for m54xx is intrinsically related to the bit
definitions in m54xxacr.h. Move it there from cacheflush_no.h,
for easier maintenance.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The MCF548x have the same cache control registers as the MCF5407.
Extract the bit definitions for the ACR and CACR registers from m5407sim.h
and move them to a new file m54xxacr.h. Those definitions are not used
anywhere yet, so no other file is involved. This is a preparation for
m54xx cache support cleanup.
Signed-off-by: Philippe De Muyter <phdm@macqel.be>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
The below patch fixes a typo "diable" to "disable". Please let me know if this
is correct or not.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
