ARM: tlbflush: remove ARMv3 support

We no longer support any ARMv3 platforms, so remove the old tlbflushing
code.

Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: cache: remove ARMv3 support code

This is only used by 740t, which is a v4 core and (by my reading of the
datasheet for the CPU) ignores CRm for the cp15 cache flush operation,
making the v4 cache implementation in cache-v4.S sufficient for this
CPU.

Tested with 740T core-tile on Integrator/AP baseboard.

Acked-by: Hyok S. Choi <hyok.choi@samsung.com>
Acked-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: mm: fix numerous hideous errors in proc-arm740.S

The setup code in proc-arm740.S is completely broken and, as far as I
can tell, always has been. I was >this< close to ripping it out, when a
740t core-tile materialised in the office, so I've had a crack at fixing
things up:

	- Fix the ram/flash area calculations so that we actually set
	  the condition flags before testing them...
	- Fix the proc_info structure so that __cpu_io_mmu_flags are
	  defined as 0, placing the __cpu_flush pointer at the correct
	  offset
	- Re-number the registers used during __arm740_setup so that
	  we don't clobber the machine ID et al
	- Advertise Thumb support via the hwcaps, since 740T is the only
	  740 implementation.

Acked-by: Hyok S. Choi <hyok.choi@samsung.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: mm: remove broken condition check for v4 flushing

There's no point having a conditional cache flush if we don't know the
state of the condition beforehand.

This patch makes the cacheflush in v4_flush_user_cache_range
unconditional.

signed-off-by: will deacon <will.deacon@arm.com>
ARM: modules: don't export cpu_set_pte_ext when !MMU

cpu_set_pte_ext is only guaranteed to be defined when CONFIG_MMU, so
don't export it to modules otherwise.

Signed-off-by: Will Deacon <will.deacon@arm.com>
openvswitch: Preallocate reply skb in ovs_vport_cmd_set().

Allocation of the Netlink notification skb can potentially fail
after changing vport configuration.  In general, we try to avoid
this by undoing any change we made but that is difficult for existing
objects.  This avoids the problem by preallocating the buffer (which
is fixed size).

Signed-off-by: Jesse Gross <jesse@nicira.com>
openvswitch: correct an invalid BUG_ON

table->count is uint32_t

Signed-off-by: Hong Zhiguo <honkiko@gmail.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
sparc:remove unused declaration smp_boot_cpus()

smp_boot_cpus() was replaced smp_prepare_cpus() long ago, and it no
longer needed, so delete it.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
sparc/srmmu: clear trailing edge of bitmap properly

srmmu_nocache_bitmap is cleared by bit_map_init().  But bit_map_init()
attempts to clear by memset(), so it can't clear the trailing edge of
bitmap properly on big-endian architecture if the number of bits is not
a multiple of BITS_PER_LONG.

Actually, the number of bits in srmmu_nocache_bitmap is not always
a multiple of BITS_PER_LONG.  It is calculated as below:

        bitmap_bits = srmmu_nocache_size >> SRMMU_NOCACHE_BITMAP_SHIFT;

srmmu_nocache_size is decided proportionally by the amount of system RAM
and it is rounded to a multiple of PAGE_SIZE.  SRMMU_NOCACHE_BITMAP_SHIFT
is defined as (PAGE_SHIFT - 4).  So it can only be said that bitmap_bits
is a multiple of 16.

This fixes the problem by using bitmap_clear() instead of memset()
in bit_map_init() and this also uses BITS_TO_LONGS() to calculate correct
size at bitmap allocation time.

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
sparc/iommu: fix typo s/265KB/256KB/

IOMMU_NPTES is 64K PTEs, so the size is 256KB (= 64K * sizeof(iopte_t))

Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
sparc:cleanup unused code in smp_32.h

After genirq and generic clockevent support at sparc32,
smp4m_irq_rotate(), prof_multiplier() and prof_counter()
are no longer used and should be removed.

Find more info from commit 6baa9b20 & 62f08283.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
sparc: use generic headers

Use "generic-y" to add generic headers where possible

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
bbc_i2c: fix section mismatch warning

Fix following warning:

WARNING: drivers/sbus/char/bbc.o(.text+0x674): Section mismatch in reference from the function bbc_i2c_probe() to the function .init.text:T.463()
The function bbc_i2c_probe() references the function __init T.463().
This is often because bbc_i2c_probe lacks a __init
annotation or the annotation of T.463 is wrong.

bbc_i2c_probe() referenced the inlined attach_one_i2c().
As probe may be called after init drop __init annotations
on all functions used by bbc_i2c_probe()

The warning was seen with a sparc64 defconfig build

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
sparc: use asm-generic version of types.h

In sparc headers we use the following pattern:

    #if defined(__sparc__) && defined(__arch64__)

    sparc64 specific stuff

    #else

    sparc32 specific stuff

    #endif

In types.h this pattern was not followed and here
we only checked for __sparc__ for no good reason.
It was a left-over from long time ago.

I checked other architectures - and most of them
do not have any such checks. And all the recently
merged versions uses the asm-generic version.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
mac80211: fix LED in idle handling

feng xiangjun reports that my

commit 382a103b2b528a3085cde4ac56fc69d92a828b72
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Fri Mar 22 22:30:09 2013 +0100

    mac80211: fix idle handling sequence

broke the wireless status LED. The reason is that
we now call ieee80211_idle_off() when the channel
context is assigned, and that doesn't recalculate
the LED state. Fix this by making that function a
wrapper around most of idle recalculation while
forcing active.

Reported-by: feng xiangjun <fengxj325@gmail.com>
Tested-by: feng xiangjun <fengxj325@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
ath9k: fix DFS detector called in softirq context

Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath9k_htc: accept 1.x firmware newer than 1.3

Since the firmware has been open sourced, the minor version has been
bumped to 1.4 and the API/ABI will stay compatible across further 1.x
releases.

Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmfmac: remove advertising P2P device support

For v3.9 kernel the P2P functionality was merged, but it does
not fully support the P2P_DEVICE interface type. This patch
removes advertising that support.

Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
brcmsmac: request firmware in .start() callback

The firmware is requested from user-space. To assure the request
is handled it is recommended to do the request upon IFF_UP. For
a mac80211 driver the .start() callback can be considered the
equivalent.

Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Piotr Haber <phaber@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>