MIPS: compat: Return same error ENOSYS as native for invalid operation.

The pains for multiplexed syscalls.

Noticed by Al Viro <viro@zeniv.linux.org.uk>.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Use CONFIG_CPU_MIPSR2 in csum_partial.S

The csum_partial implementation contain optimalizations for the MIPS R2
instruction set. This optimization is never enabled however because the
if directive uses the CPU_MIPSR2 constant which is not defined anywhere.

Use the CONFIG_CPU_MIPSR2 constant instead.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4971/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Fix logic errors in bitops.c

commit 92d11594f6 (MIPS: Remove irqflags.h dependency from bitops.h)
factored some of the bitops code out into a separate file
(arch/mips/lib/bitops.c).  Unfortunately the logic converting a bit
mask into a boolean result was lost in some of the functions.  We had:

   int res;
   unsigned long shifted_result_bit;
   .
   .
   .
   res = shifted_result_bit;
   return res;

Which truncates off the high 32 bits (thus yielding an incorrect
value) on 64-bit systems.

The manifestation of this is that a non-SMP 64-bit kernel will not
boot as the bitmap operations in bootmem.c are all screwed up.

Signed-off-by: David Daney <david.daney@cavium.com>
Cc:  linux-mips@linux-mips.org
Cc: Jim Quinlan <jim2101024@gmail.com>
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/4965/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: VR4133: Fix probe for LL/SC.

Signed-off-by: Yoichi Yuasa <yuasa@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4963/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Add dependencies for HAVE_ARCH_TRANSPARENT_HUGEPAGE

The MIPS implementation of transparent huge-pages (THP) is 64-bit only,
and of course also requires that the CPU supports huge-pages.

Currently it's entirely possible to enable THP in other configurations,
which then fail to build due to pfn_pmd() not being defined.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: linux-mips@linux-mips.org
Acked-by: David Daney <david.daney@cavium.com>
Patchwork: https://patchwork.linux-mips.org/patch/4972/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: Get rid of CONFIG_CPU_HAS_LLSC again

Commit f7ade3c168e4f437c11f57be012992bbb0e3075c ("MIPS: Get rid of
CONFIG_CPU_HAS_LLSC") did what it promised to do. But since then that
macro and its Kconfig symbol popped up again. Get rid of those again.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Cc: Jonas Gorski <jogo@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/4978/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: SEAD3: Enable LL/SC.

All synthesizable CPU cores that could be loaded into a SEAD3's FPGA are
MIPS32 or MIPS64 CPUs that have ll/sc.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
regmap: Initialize `map->debugfs' before regcache

In the rbtree code we are exposing statistics relating to the
number of nodes/registers of the rbtree cache for each of the
devices.  Ensure that `map->debugfs' has been initialized before
we attempt to initialize the debugfs entry for the rbtree cache.

Signed-off-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
ARM: OMAP1: fix USB host on 1710

There is a long-standing bug that OHCI USB host controller does
not respond on 1710, because of wrong clock definitions. See e.g.
http://marc.info/?l=linux-omap&m=119634441229321&w=2. All register reads
return just zeroes:

[    1.896606] ohci ohci: OMAP OHCI
[    1.912597] ohci ohci: new USB bus registered, assigned bus number 1
[    1.933776] ohci ohci: irq 38, io mem 0xfffba000
[    2.012573] ohci ohci: init err (00000000 0000)
[    2.030334] ohci ohci: can't start
[    2.046661] ohci ohci: startup error -75
[    2.063201] ohci ohci: USB bus 1 deregistered

After some experiments, it seems that when changing the usb_dc_ck /
SOFT_REQ enable bit from USB_REQ_EN_SHIFT to SOFT_USB_OTG_DPLL_REQ_SHIFT
(like done also on 7XX), the USB appears to work:

[    2.183959] ohci ohci: OMAP OHCI
[    2.198242] ohci ohci: new USB bus registered, assigned bus number 1
[    2.215820] ohci ohci: irq 38, io mem 0xfffba000
[    2.324798] hub 1-0:1.0: USB hub found
[    2.361267] hub 1-0:1.0: 3 ports detected

The patch is tested on Nokia 770.

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: clock data: lock USB DPLL on boot

Some versions of the u-boot bootloader do not lock the USB DPLL and
when the USB DPLL is not locked, then it is observed that the L3INIT
power domain does not transition to retention state during kernel
suspend on OMAP4 devices. Fix this by locking the USB DPLL at 960 MHz
on kernel boot.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb

For some unknown reason, allowing hwmod to control MIDLEMODE causes
core_pwrdm to not hit idle states for musb in DM3730 at least.
I've verified that setting any MIDLEMODE value other than "force
standby" before enabling the device causes subsequent suspend
attempts to fail with core_pwrdm not entering idle states, even
if the driver is unloaded and "force standby" is restored before
suspend attempt. To recover from this, soft reset can be used, but
that's not suitable solution for suspend.

Keeping the register set at force standby (reset value) makes it work
and device still functions properly, as musb has driver-controlled
OTG_FORCESTDBY register that controls MSTANDBY signal.
Note that TI PSP kernels also have similar workarounds.

This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the
actual flag name.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
ARM: OMAP4: PM: fix PM regression introduced by recent clock cleanup

Commit 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb ("ARM: OMAP4:
clock/hwmod data: start to remove some IP block control "clocks"")
introduced a regression preventing the L3INIT clockdomain of OMAP4
systems from entering idle.  This in turn prevented these systems from
entering full chip clock-stop.

The regression was caused by the incorrect removal of a so-called
"optional functional clock" from the OMAP4 clock data.  This wasn't
caught for two reasons.  First, I missed the retention entry failure
in the branch test logs:

http://www.pwsan.com/omap/testlogs/cleanup_a_3.9/20130126014242/pm/4460pandaes/4460pandaes_log.txt

Second, the integration data for the OCP2SCP PHY IP block, added by
commit 0c6688753f9912c6a7013549ec31c8844020bbc1 ("ARM: OMAP4: hwmod
data: add remaining USB-related IP blocks"), should have associated this
clock with the IP block, but did not.

Fix by adding back the so-called "optional" functional clock to the
clock data, and by linking that clock to the OCP2SCP PHY IP block
integration hwmod data.

The problem patch was discovered by J, Keerthy <j-keerthy@ti.com>.

Cc: Keerthy <j-keerthy@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
regmap: cache Fix regcache-rbtree sync

The last register block, which falls into the specified range, is not handled
correctly. The formula which calculates the number of register which should be
synced is inverse (and off by one). E.g. if all registers in that block should
be synced only one is synced, and if only one should be synced all (but one) are
synced. To calculate the number of registers that need to be synced we need to
subtract the number of the first register in the block from the max register
number and add one. This patch updates the code accordingly.

The issue was introduced in commit ac8d91c ("regmap: Supply ranges to the sync
operations").

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@vger.kernel.org
MIPS: Fix inconsistent formatting inside /proc/cpuinfo

There is a missing " " inside /proc/cpuinfo.

The bad commit was:
commit a96102be700f87283f168942cd09a2b30f86f324
Author: Steven J. Hill <sjhill@mips.com>
Date:   Fri Dec 7 04:31:36 2012 +0000
MIPS: Add printing of ISA version in cpuinfo.

Signed-off-by: John Crispin <blogic@openwrt.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/4988/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
ARM: ep93xx: Fix wait for UART FIFO to be empty

Commit 210dce5f "ARM: ep93xx: properly wait for UART FIFO to be empty"

Removed the timeout loop while waiting for the uart transmit fifo to
empty. Some bootloaders leave the uart in a state where there might
be bytes in the uart that are not transmitted when execution is handed
over to the kernel. This results in a deadlocked system while waiting
for the fifo to empty.

Add back the timeout wait to prevent the deadlock.

Increase the wait time to hopefully prevent the decompressor corruption
that lead to commit 210dce5f. This corruption was probably due to a
slow uart baudrate. The 10* increase in the wait time should be enough
for all cases.

Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Acked-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
MIPS: Fix code generation for non-DSP capable CPUs

Commit 32a7ede (MIPS: dsp: Add assembler support for DSP ASEs) has
enabled the use of DSP ASE specific instructions such as rddsp and wrdsp
under the idea that all code path that will make use of these two
instructions are properly checking for cpu_has_dsp to ensure that the
particular CPU we are running on *actually* supports DSP ASE.

This commit actually causes the following oops on QEMU Malta emulating a
MIPS 24Kc without the DSP ASE implemented:

[    7.960000] Reserved instruction in kernel
[    7.960000] Cpu 0
[    7.960000] $ 0   : 00000000 00000000 00000014 00000005
[    7.960000] $ 4   : 8fc2de48 00000001 00000000 8f59ddb0
[    7.960000] $ 8   : 8f5ceec4 00000018 00000c00 00800000
[    7.960000] $12   : 00000100 00000200 00000000 00457b84
[    7.960000] $16   : 00000000 8fc2ba78 8f4ec980 00000001
[    7.960000] $20   : 80418f90 00000000 00000000 000002dd
[    7.960000] $24   : 0000009c 7730d7b8
[    7.960000] $28   : 8f59c000 8f59dd38 00000001 80104248
[    7.960000] Hi    : 0000001d
[    7.960000] Lo    : 0000000b
[    7.960000] epc   : 801041ec thread_saved_pc+0x2c/0x38
[    7.960000]     Not tainted
[    7.960000] ra    : 80104248 get_wchan+0x48/0xac
[    7.960000] Status: 1000b703    KERNEL EXL IE
[    7.960000] Cause : 10800028
[    7.960000] PrId  : 00019300 (MIPS 24Kc)
[    7.960000] Modules linked in:
[    7.960000] Process killall (pid: 1574, threadinfo=8f59c000,
task=8fd14558, tls=773aa440)
[    7.960000] Stack : 8fc2ba78 8012b008 0000000c 0000001d 00000000
00000000 8f58a380
                  8f58a380 8fc2ba78 80202668 8f59de78 8f468600 8f59de28
801b2a3c 8f59df00 8f98ba20 74696e69
                  8f468600 8f59de28 801b7308 0081c007 00000000 00000000
00000000 00000000 00000000 00000000
                  00000000 8fc2bbb4 00000001 0000001d 0000000b 77f038cc
7fe80648 ffffffff ffffffff 00000000
                  00000001 0016e000 00000000 ...
[    7.960000] Call Trace:
[    7.960000] [<801041ec>] thread_saved_pc+0x2c/0x38
[    7.960000] [<80104248>] get_wchan+0x48/0xac

The disassembly of thread_saved_pc points to the following:
000006d0 <thread_saved_pc>:
 6d0:   8c820208        lw      v0,520(a0)
 6d4:   3c030000        lui     v1,0x0
 6d8:   24630000        addiu   v1,v1,0
 6dc:   10430008        beq     v0,v1,700 <thread_saved_pc+0x30>
 6e0:   00000000        nop
 6e4:   3c020000        lui     v0,0x0
 6e8:   8c43000c        lw      v1,12(v0)
 6ec:   04620004        bltzl   v1,700 <thread_saved_pc+0x30>
 6f0:   00001021        move    v0,zero
 6f4:   8c840200        lw      a0,512(a0)
 6f8:   00031080        sll     v0,v1,0x2
 6fc:   7c44100a        lwx     v0,a0(v0)   <------------
 700:   03e00008        jr      ra
 704:   00000000        nop

If we specifically disable -mdsp/-mdspr2 for arch/mips/kernel/process.o,
we get the following (non-crashing) assembly:

00000708 <thread_saved_pc>:
 708:   8c820208        lw      v0,520(a0)
 70c:   3c030000        lui     v1,0x0
 710:   24630000        addiu   v1,v1,0
 714:   10430009        beq     v0,v1,73c <thread_saved_pc+0x34>
 718:   00000000        nop
 71c:   3c020000        lui     v0,0x0
 720:   8c42000c        lw      v0,12(v0)
 724:   04420005        bltzl   v0,73c <thread_saved_pc+0x34>
 728:   00001021        move    v0,zero
 72c:   8c830200        lw      v1,512(a0)
 730:   00021080        sll     v0,v0,0x2
 734:   00431021        addu    v0,v0,v1
 738:   8c420000        lw      v0,0(v0)
 73c:   03e00008        jr      ra
 740:   00000000        nop

The specific line that leads a different assembly being produced is:

unsigned long thread_saved_pc(struct task_struct *tsk)
...
	return ((unsigned long *)t->reg29)[schedule_mfi.pc_offset]; <---

The problem here is that the compiler was given the right to use DSP
instructions with the -mdsp / -mdspr2 command-line switches and
performed some optimization for us and used DSP ASE instructions where
we are not checking that the running CPU actually supports DSP ASE.

This patch fixes the issue by partially reverting commit 32a7ede for
arch/mips/kernel/Makefile in order to remove the -mdsp / -mdspr2
compiler command-line switches such that we are now guaranteed that the
compiler will not optimize using DSP ASE reserved instructions. We also
need to fixup the rddsp/wrdsp and m{t,h}{hi,lo}{0,1,2,3} macros in
arch/mips/include/asm/mipsregs.h to tell the assembler that we are going
to explicitely use DSP ASE reserved instructions. The comment in
arch/mips/kernel/Makefile is also updated to reflect that.

Signed-off-by: Florian Fainelli <florian@openwrt.org>
Acked-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: blogic@openwrt.org
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
MIPS: BCM63XX: Make nvram checksum failure non fatal

Some vendors modify the nvram layout moving the checksum to a different
place or dropping entirely, so reduce the checksum failure to a warning.

Reported-by: Álvaro Fernández Rojas <noltari@gmail.com>
Signed-off-by: Jonas Gorski <jogo@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: John Crispin <blogic@openwrt.org>
Cc: Maxime Bizon <mbizon@freebox.fr>
Cc: Florian Fainelli <florian@openwrt.org>
Cc: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Revert "MIPS: BCM63XX: Call board_register_device from device_initcall()"

This commit causes a race between PCI scan and SSB fallback SPROM handler
registration, causing the wifi to not work on slower systems. The only
subsystem touched from board_register_devices is platform device
registration, which is safe as an arch init call.

This reverts commit d64ed7ada2f689d2c62af1892ca55e47d3653e36 [MIPS:
BCM63XX: Call board_register_device from device_initcall()].

Signed-off-by: Jonas Gorski <jogo@openwrt.org>
To: linux-mips@linux-mips.org
Cc: John Crispin <blogic@openwrt.org>
Cc: Maxime Bizon <mbizon@freebox.fr>
Cc: Florian Fainelli <florian@openwrt.org>
Cc: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix breakage in MIPS siginfo handling

MIPS's siginfo handling has been broken since this commit:

	commit 574c4866e33d648520a8bd5bf6f573ea6e554e88
	Author: Al Viro <viro@zeniv.linux.org.uk>
	Date:   Sun Nov 25 22:24:19 2012 -0500
	consolidate kernel-side struct sigaction declarations

for 64-bit BE MIPS CPUs.

The UAPI variant looks like this:

	struct sigaction {
		unsigned int	sa_flags;
		__sighandler_t	sa_handler;
		sigset_t	sa_mask;
	};

but the core kernel's variant looks like this:

	struct sigaction {
	#ifndef __ARCH_HAS_ODD_SIGACTION
		__sighandler_t	sa_handler;
		unsigned long	sa_flags;
	#else
		unsigned long	sa_flags;
		__sighandler_t	sa_handler;
	#endif
	#ifdef __ARCH_HAS_SA_RESTORER
		__sigrestore_t sa_restorer;
	#endif
		sigset_t	sa_mask;
	};

The problem is that sa_flags has been changed from an unsigned int to an
unsigned long.

Fix this by making sa_flags unsigned int if __ARCH_HAS_ODD_SIGACTION is
defined.

Whilst we're at it, rename __ARCH_HAS_ODD_SIGACTION to
__ARCH_HAS_IRIX_SIGACTION.

Signed-off-by: David Howells <dhowells@redhat.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Merge tag 'omap-fixes-a-for-3.9-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.9-rc3/fixes

Miscellaneous OMAP fixes for v3.9-rc.  These primarily deal with OMAP2+ power
management regressions.  There's also a fix for the OMAP1 OHCI controller.

Basic build, boot, and PM test logs are at:

    http://www.pwsan.com/omap/testlogs/fixes_a_3.9-rc/20130314101856/