linux.git/arch/arm/include/asm, branch v2.6.28

[ARM] 5340/1: fix stack placement after noexecstack changes

2008-12-06T08:32:02+00:00

Commit 8ec53663d2698076468b3e1edc4e1b418bd54de3 ("[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: Nicolas Pitre 

Signed-off-by: Lennert Buytenhek 
Signed-off-by: Russell King

[ARM] 5339/1: fix __fls() on ARM

2008-12-04T09:21:55+00:00

Commit 0c65f459ce6c 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: Nicolas Pitre 
Signed-off-by: Russell King

Merge master.kernel.org:/home/rmk/linux-2.6-arm

2008-11-13T19:30:25+00:00

* master.kernel.org:/home/rmk/linux-2.6-arm:
  [ARM] cdb89712: avoid namespace clashes with SRAM_ and BOOTROM_ constants
  [ARM] cdb89712,clps7500,h720x: avoid namespace clash for FLASH_* constants
  [ARM] integrator,realview,versatile: remove FLASH_* and EPROM_* constants
  [ARM] dma-mapping: fix compiler warning
  [ARM] iop: iop3xx needs registers mapped uncached+unbuffered
  [ARM] versatile: correct MMC clock rate
  [ARM] realview: correct MMC clock rate
  [ARM] 5329/1: Feroceon: fix feroceon_l2_inv_range

[ARM] dma-mapping: fix compiler warning

2008-11-13T14:33:51+00:00

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: Russell King

iop-adma: use iop_paranoia() for debug BUG_ONs

2008-11-11T20:12:33+00:00

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: Dan Williams

[ARM] iop: iop3xx needs registers mapped uncached+unbuffered

2008-11-09T11:18:36+00:00

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: Russell King

[ARM] mm: fix page table initialization

2008-11-06T17:45:32+00:00

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: Tony Lindgren 
Tested-by: Robert Jarzmik 
Tested-by: Mike Rapoport 
Tested-by: Ben Dooks 
Tested-by: Anders Grafström 
Signed-off-by: Russell King

[ARM] fix naming of MODULE_START / MODULE_END

2008-11-06T17:13:47+00:00

As of 73bdf0a60e607f4b8ecc5aec597105976565a84f, 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: Russell King

Merge commit 'v2.6.28-rc2' into tracing/urgent

2008-10-27T09:50:54+00:00

[ARM] 5320/1: fix assembly constraints in implementation of do_div()

2008-10-23T11:53:32+00:00

Those inline assembly segments using the umlal instruction must have
the & modifier so to be sure that a purely input register won't alias
one of the registers used as input+output.  In most cases, the inputs
are still used after the outputs are touched, and most binutil versions
insist on "rdhi, rdlo and rm must all be different" even for ARMv6+.

Signed-off-by: Nicolas Pitre 
Signed-off-by: Russell King