Impact: change calling convention of existing clock_event APIs

struct clock_event_timer's cpumask field gets changed to take pointer,
as does the ->broadcast function.

Another single-patch change.  For safety, we BUG_ON() in
clockevents_register_device() if it's not set.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Cc: Ingo Molnar <mingo@elte.hu>

Impact: change existing irq_chip API

Not much point with gentle transition here: the struct irq_chip's
setaffinity method signature needs to change.

Fortunately, not widely used code, but hits a few architectures.

Note: In irq_select_affinity() I save a temporary in by mangling
irq_desc[irq].affinity directly.  Ingo, does this break anything?

(Folded in fix from KOSAKI Motohiro)
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Signed-off-by: NMike Travis <travis@sgi.com>
Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
Acked-by: NIngo Molnar <mingo@redhat.com>
Cc: ralf@linux-mips.org
Cc: grundler@parisc-linux.org
Cc: jeremy@xensource.com
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>

Impact: cleanup

Each SMP arch defines these themselves.  Move them to a central
location.

Twists:
1) Some archs (m32, parisc, s390) set possible_map to all 1, so we add a
   CONFIG_INIT_ALL_POSSIBLE for this rather than break them.

2) mips and sparc32 '#define cpu_possible_map phys_cpu_present_map'.
   Those archs simply have phys_cpu_present_map replaced everywhere.

3) Alpha defined cpu_possible_map to cpu_present_map; this is tricky
   so I just manipulate them both in sync.

4) IA64, cris and m32r have gratuitous 'extern cpumask_t cpu_possible_map'
   declarations.
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
Reviewed-by: NGrant Grundler <grundler@parisc-linux.org>
Tested-by: NTony Luck <tony.luck@intel.com>
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: Mike Travis <travis@sgi.com>
Cc: ink@jurassic.park.msu.ru
Cc: rmk@arm.linux.org.uk
Cc: starvik@axis.com
Cc: tony.luck@intel.com
Cc: takata@linux-m32r.org
Cc: ralf@linux-mips.org
Cc: grundler@parisc-linux.org
Cc: paulus@samba.org
Cc: schwidefsky@de.ibm.com
Cc: lethal@linux-sh.org
Cc: wli@holomorphy.com
Cc: davem@davemloft.net
Cc: jdike@addtoit.com
Cc: mingo@redhat.com

On ARMv6 and later CPUs, it is possible for userspace processes to
get stuck on a misaligned load or store due to the "ignore fault"
setting; unlike previous CPUs, retrying the instruction without
the 'A' bit set does not always cause the load to succeed.

We have no real option but to default to fixing up alignment faults
on these CPUs, and having the CPU fix up those misaligned accesses
which it can.
Reported-by: NWolfgang Grandegger <wg@grandegger.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 8ec53663 ("[ARM] Improve
non-executable support") added support for detecting non-executable
stack binaries.  One of the things it does is to make READ_IMPLIES_EXEC
be set in ->personality if we are running on a CPU that doesn't support
the XN ("Execute Never") page table bit or if we are running a binary
that needs an executable stack.

This exposed a latent bug in ARM's asm/processor.h due to which we'll
end up placing the stack at a very low address, where it will bump into
the heap on any application that uses significant amount of stack or
heap or both, causing many interesting crashes.

Fix this by testing the ADDR_LIMIT_32BIT bit in ->personality instead
of testing for equality against PER_LINUX_32BIT.
Reviewed-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 0c65f459 intended to fix truncation issues with fls() on
ARMv5+ by renaming it to __fls() and wrapping it into a C function.
However that didn't take into account the fact that __fls() already
already had different semantics in the kernel.

Let's move the __fls() code into fls() function directly, and redefine
__fls() with the appropriate semantics.  While at it, bring a generic
__fls() definition for pre ARMv5 too.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The function field is 3 bits.
Signed-off-by: NSaeed Bishara <saeed@marvell.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>

The spi master driver must have num_chipselect set to allow the bus to
initialise.  Pass this through the platform data.
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch fixes a number of sillies, from missing 'const' to using
'return' in void functions, to functions with no arguments not even
'void' and a cast which isn't required.
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Use the correct wake-up enable register, and make it
work with 34xx also.
Signed-off-by: NTero Kristo <tero.kristo@nokia.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NEric Miao <eric.miao@marvell.com>

0 is a valid GPIO number, use a negative number to specify, that this camera
doesn't have a GPIO for bus-width switching.
Signed-off-by: NGuennadi Liakhovetski <lg@denx.de>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

The second clk_deny_idle instance should be clk_allow_idle instead.
Signed-off-by: NAmit Kucheria <amit.kucheria@verdurent.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The G3IPL expects the value at RAM address 0xa020b020 to be
exactly 1 to setup the bluetooth GPIOs properly. The actual
code got a value from gpio_get_value() which was not 1, but
a "not equal to 0" integer.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

In the resume bootstrap, the early disable address is wrong.
Fix it to RAM address 0xa020b000 instead of 0xa0200000, and
make it consistent with RESUME_ENABLE_ADDR in mioa701.c.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

This patch makes do_hw_reset the default reboot behavior when nothing
else matches. This restores reboot functionality on gumstix basix
devices where reboot=cold is the default boot argument.
Signed-off-by: NJaya Kumar <jayakumar.lkml@gmail.com>
Acked-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The original incorrect configuration caused GPIO79_nCS_3 being overriden,
thus resulted in the NAND flash not being detected. The real PSKTSEL pin
is on GPIO104 instead of GPIO79.
Signed-off-by: NEric Miao <eric.miao@marvell.com>
Cc: Richard Purdie <rpurdie@rpsys.net>

Signed-off-by: NEric Miao <eric.miao@marvell.com>
Cc: Richard Purdie <rpurdie@rpsys.net>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

FLASH_* and EPROM_* constants are unused, and clash with drivers:

drivers/atm/ambassador.h:257:1: warning: "FLASH_BASE" redefined
drivers/atm/ambassador.h:258:1: warning: "FLASH_SIZE" redefined
drivers/atm/iphase.h:332:1: warning: "EPROM_SIZE" redefined

so remove them.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

arch/arm/mm/dma-mapping.c: In function `dma_sync_sg_for_cpu':
arch/arm/mm/dma-mapping.c:588: warning: statement with no effect
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Now that the critical read back to flush the next descriptor address is
fixed we can downgrade some BUG_ONs that need only be enabled when testing
changes to the driver.
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Mikael Pettersson reported:

   The 2.6.28-rc kernels fail to detect PCI device 0000:00:01.0
   (the first ethernet port) on my Thecus n2100 XScale box.

   There is however still a strange "ghost" device that gets partially
   detected in 2.6.28-rc2 vanilla.

The IOP321 manual says:

  The user designates the memory region containing the OCCDR as
  non-cacheable and non-bufferable from the IntelR XScaleTM core.
  This guarantees that all load/stores to the OCCDR are only of
  DWORD quantities.

Ensure that the OCCDR is so mapped.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The MMC clock source is actually 24MHz, not 33MHz.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The MMC clock source is actually 24MHz, not 33MHz.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Same fix as commit c7cf72dc: when 'start' and 'end' are less than a
cacheline apart and 'start' is unaligned we are done after cleaning and
invalidating the first cacheline.

Cc: <stable@kernel.org>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When 'start' and 'end' are less than a cacheline apart and 'start' is
unaligned we are done after cleaning and invalidating the first
cacheline.  So check for (start < end) which will not walk off into
invalid address ranges when (start > end).

This issue was caught by drivers/dma/dmatest.

2.6.27 is susceptible.

Cc: <stable@kernel.org>
Cc: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
Cc: Lothar WaÃ<9f>mann <LW@KARO-electronics.de>
Cc: Lennert Buytenhek <buytenh@marvell.com>
Cc: Eric Miao <eric.miao@marvell.com>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

As a result of the ptebits changes, we ended up marking device mappings
as normal memory on ARMv7 CPUs, resulting in undesirable behaviour with
serial ports and the like.  While reviewing the section mapping table
entries, other errors in the memory type settings for devices were
detected and confirmed to prevent Xscale3 platforms booting.

Tested on:
	OMAP34xx (ARMv7),
	OMAP24xx (ARMv6),
	OMAP16xx (ARM926T, ARMv5),
	PXA311 (Xscale3),
	PXA272 (Xscale),
	PXA255 (Xscale),
	IXP42x (Xscale),
	S3C2410 (ARM920T, ARMv4T),
	ARM720T (ARMv4T)
	StrongARM-110 (ARMv4)
Acked-by: NTony Lindgren <tony@atomide.com>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Tested-by: NMike Rapoport <mike@compulab.co.il>
Tested-by: NBen Dooks <ben-linux@fluff.org>
Tested-by: NAnders Grafström <grfstrm@users.sourceforge.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As of 73bdf0a6, the kernel needs
to know where modules are located in the virtual address space.
On ARM, we located this region between MODULE_START and MODULE_END.
Unfortunately, everyone else calls it MODULES_VADDR and MODULES_END.
Update ARM to use the same naming, so is_vmalloc_or_module_addr()
can work properly.  Also update the comment on mm/vmalloc.c to
reflect that ARM also places modules in a separate region from the
vmalloc space.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Otherwise twl4030 gpios won't work.
Signed-off-by: NTony Lindgren <tony@atomide.com>

On omap24xx, INTCPS_SIR_IRQ_OFFSET bits [6:0] contains the current
active interrupt number.

However, on 34xx INTCPS_SIR_IRQ_OFFSET bits [31:7] also contains the
SPURIOUSIRQFLAG, which gets set if the interrupt sorting information
is invalid.

If the SPURIOUSIRQFLAG bits are not ignored, the interrupt code will
occasionally produce a bunch of confusing errors:

irq -33, desc: c02ddcc8, depth: 0, count: 0, unhandled: 0
->handle_irq():  c006f23c, handle_bad_irq+0x0/0x22c
->chip(): 00000000, 0x0
->action(): 00000000

Fix this by masking out only the ACTIVEIRQ bits. Also fix a
confusing comment.
Signed-off-by: NTony Lindgren <tony@atomide.com>

debugfs_create_*() returns NULL if an error occurs, returns -ENODEV
when debugfs is not enabled in the kernel.

Comparing to PATCH v1, because clk_debugfs_init is included in
"#if defined CONFIG_DEBUG_FS", we only need to check NULL return.
Thanks Li Zefan <lizf@cn.fujitsu.com>

debugfs_create_u8() and other function's return value's checking method are
also fixed in this patch.
Signed-off-by: NZhao Lei <zhaolei@cn.fujitsu.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Fix these compiler warnings:

gpmc.c: In function 'gpmc_init':
gpmc.c:432: warning: 'return' with a value, in function returning void
gpmc.c:439: warning: 'return' with a value, in function returning void
Signed-off-by: NSanjeev Premi <premi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

2.6.28-rc tightened up the ELF architecture checks on ARM.  For
non-EABI it only allows VFP if the hardware supports it.  However,
the kernel fails to also inspect the soft-float flag, so it
incorrectly rejects binaries using soft-VFP.

The fix is simple: also check that EF_ARM_SOFT_FLOAT isn't set
before rejecting VFP binaries on non-VFP hardware.
Acked-by: NMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

i2c_board_info array was filled incorrectly.
Due to circumstances, the way it is filled works.
This patch fills array properly.
Signed-off-by: NSergey Lapin <slapin@ossfans.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

mx31ads_defconfig compilation failed with

arch/arm/mach-mx3/mx31ads.c: In function 'mxc_init_imx_uart':
arch/arm/mach-mx3/mx31ads.c:102: error: 'mxc_uart_device0' undeclared (first use in this function)
arch/arm/mach-mx3/mx31ads.c:102: error: (Each undeclared identifier is reported only once
arch/arm/mach-mx3/mx31ads.c:102: error: for each function it appears in.)
make[1]: *** [arch/arm/mach-mx3/mx31ads.o] Error 1

Add missing include
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>

The Data register holds the value we have written to a gpio. To
get the input value we must read the Pad Status Register MX3 (or Sample
Status register in MX1/2 terms)
Signed-off-by: NDarius Augulis <augulis.darius@gmail.com>
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>