Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

Simplify the UART setup code so that it no longer loops for each UART
present. Just make it do all the work it needs in a single function.
This will make the code easier to share when we move to a single set
of platform data for ColdFire UARTs.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 54xx UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5407 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 532x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 528x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5307 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 527x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5272 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5249 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 523x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 520x UART addressing so that:

. UARTs are numbered from 0 up
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

If we make all UART addressing consistent across all ColdFire family members
then we will be able to remove the duplicated plaform data and use a single
setup for all.

So modify the ColdFire 5206 UART addressing so that:

. UARTs are numbered from 0 up
. base addresses are absolute (not relative to MBAR peripheral register)
. use a common name for IRQs used
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The MMU and non-MMU varients of the m68k arch process.c code are pretty
much the same. Only a few minor details differ between the two. The
majority of the difference is to deal with having or wanting hardware FPU
support. So merge them back into a single process.c file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The classic m68k code has always supported an FPU (although it may have
been a software emulated one). The non-MMU m68k code has never supported FPU
hardware. To help in merging common code create a configation setting that
signifies if we are builing in FPU support or not.

This switch, CONFIG_FPU, is set as per the current use cases. So it is
always enabled if CONFIG_MMU is set, and disabled otherwise. With a little
extra code it will be possible to disable it on the classic m68k platforms
as well, and to enable it on non-MMU platforms that do have hardware FPU.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Most of the code in the non-mmu ptrace_no.c file is the same as the mmu
version ptrace_mm.c. So merge them back into a single file.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The set_rtc_mmss() function is defined "static inline" but is never used
in this file. Remove it.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

There is only trivial differences between the mmu time_mm.c and non-mmu
time_no.c files. Merge them back into a single time.c.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>

The CONFIG_GENERIC_CMOS_UPDATE switch is always enabled for the non-MMU
m68k case. But the underlying code to support it, update_persistent_clock(),
doesn't end up doing anything on the currently supported non-MMU platforms.
No platforms supply the necessary function support for writing back the RTC.

So lets remove this option and support code. This also brings m68knommu
in line with the m68k, which doesn't enabled this switch either.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

With a few small changes we can make the m68knommu timer init code the
same as the m68k code. By using the mach_sched_init function pointer
and reworking the current timer initializers to keep track of the common
m68k timer_interrupt() handler we end up with almost identical code for
m68knommu.

This will allow us to more easily merge the mmu and non-mmu m68k time.c
in future patches.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The read_persistent_clock() code is different on m68knommu, for really no
reason. With a few changes to support function names and some code
re-organization the code can be made the same.

This will make it easier to merge the arch/m68k/kernel/time.c for m68k and
m68knommu in a future patch.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The base of the real RAM resident hardware vectors, _ramvec, is declared in
our asm/traps.h. No need to have local declarations spread around in other
files that use this. So remove them.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

There is a lot of years of collected cruft in the m68knommu linker script.
Clean it all up and use the well defined linker script support macros.

Support is maintained for building both ROM/FLASH based and RAM based setups.
No major changes to section layouts, though the rodata section is now lumped
in with the read/write data section.
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

The ColdFire MBAR register that holds the mapping of the peripheral region
on some ColdFire CPUs is configurable. It can be configured at some address
different to that of the bootloader that loaded the kernel. So hard set
the MBAR register mapping at kernel startup time.
Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NGreg Ungerer <gerg@uclinux.org>

SCSI fixes from James Bottomley:
 "There's just a single fix in here: the osd max device number fix."

* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
  [SCSI] osd_uld: Bump MAX_OSD_DEVICES from 64 to 1,048,576

PARISC fixes from James Bottomley:
 "This is a set of build fixes to get the cross compiled architecture
  testbeds building again"

* tag 'parisc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.6:
  [PARISC] don't unconditionally override CROSS_COMPILE for 64 bit.
  [PARISC] include <linux/prefetch.h> in drivers/parisc/iommu-helpers.h
  [PARISC] fix compile break caused by iomap: make IOPORT/PCI mapping functions conditional

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  perf/x86/kvm: Fix Host-Only/Guest-Only counting with SVM disabled

Pull from Herbert Xu:
  "This push fixes a bug in mv_cesa that causes all hash operations
   that supply data on a final operation to fail."

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: mv_cesa - fix final callback not ignoring input data

Commit 5707c87f "vfs: uninline full_name_hash()" broke the modular
build, because it needs exporting now that it isn't inlined any more.
Reported-by: NTetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

hhwmon fixes for 3.3-rc6 from Guenter Roeck:

These patches are necessary for correct operation and management of
F75387.

* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (f75375s) Catch some attempts to write to r/o registers
  hwmon: (f75375s) Properly map the F75387 automatic modes to pwm_enable
  hwmon: (f75375s) Make pwm*_mode writable for the F75387
  hwmon: (f75375s) Fix writes to the pwm* attribute for the F75387

fbdev fixes for 3.3 from Florian Tobias Schandinat

It includes:
 - two fixes for OMAP HDMI
 - one fix to make new OMAP functions behave as they are supposed to
 - one Kconfig dependency fix
 - two fixes for viafb for modesetting on VX900 hardware

* tag 'fbdev-fixes-for-3.3-2' of git://github.com/schandinat/linux-2.6:
  OMAPDSS: APPLY: make ovl_enable/disable synchronous
  OMAPDSS: panel-dvi: Add Kconfig dependency on I2C
  viafb: fix IGA1 modesetting on VX900
  viafb: select HW scaling on VX900 for IGA2
  OMAPDSS: HDMI: hot plug detect fix
  OMAPDSS: HACK: Ensure DSS clock domain gets out of idle when HDMI is enabled

sound fixes for 3.3-rc6 from Takashi Iwai

This contains again regression fixes for various HD-audio and ASoC
regarding SSI and dapm shutdown path.  In addition, a minor azt3328
fix and the correction of the new jack-notification strings in HD-audio.

* tag 'sound-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Kill hyphenated names
  ALSA: hda - Add a fake mute feature
  ALSA: hda - Always set HP pin in unsol handler for STAC/IDT codecs
  ALSA: azt3328 - Fix NULL ptr dereference on cards without OPL3
  ALSA: hda/realtek - Fix resume of multiple input sources
  ASoC: i.MX SSI: Fix DSP_A format.
  ASoC: dapm: Check for bias level when powering down

The code in link_path_walk() that finds out the length and the hash of
the next path component is some of the hottest code in the kernel.  And
I have a version of it that does things at the full width of the CPU
wordsize at a time, but that means that we *really* want to split it up
into a separate helper function.

So this re-organizes the code a bit and splits the hashing part into a
helper function called "hash_name()".  It returns the length of the
pathname component, while at the same time computing and writing the
hash to the appropriate location.

The code generation is slightly changed by this patch, but generally for
the better - and the added abstraction actually makes the code easier to
read too.  And the new interface is well suited for replacing just the
"hash_name()" function with alternative implementations.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It did some odd things for unclear reasons.  As this is one of the
functions that gets changed when doing word-at-a-time compares, this is
yet another of the "don't change any semantics, but clean things up so
that subsequent patches don't get obscured by the cleanups".
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>