regulator: palmas: fix the n_voltages for smps to 122

With the following change
---------
commit ad02e846878ca35e9d3fa584be8ee770e9e14fce
Author: Axel Lin <axel.lin@ingics.com>

    regulator: palmas: Return raw register values as the selectors in [get|set]_voltage_sel

    Don't adjust the selector in [get|set]_voltage_sel, fix it in list_voltage() instead.

    For smps*(except smps10), the vsel reg-value and voltage mapping as below:
----------
The list_voltage() takes the true value of selector which is
programmed in the register.  As per smsp voltage table
    reg-value       volt (uV) ( Assume RANGE is x1 )
    0               0
    1               500000
    2               500000
    3               500000
    4               500000
    5               500000
    6               500000 (0.49V + 1 * 0.01V) * RANGE
    7               510000 (0.49V + 2 * 0.01V) * RANGE
    8               520000 (0.49V + 3 * 0.01V) * RANGE
    9               530000 (0.49V + 4 * 0.01V) * RANGE
    ....
    121            1650000 (0.49V + 116 * 0.1) * RANGE

Hence making n_voltages for smps to 122.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: palmas: configure enable time for LDOs

As per datasheet (Referred TPS65913), the on-time for LDO is
500micro second. If LDO6 is in vibrator mode then the on-time
is 2000us.

Set the enable_time on regulator descriptor accordingly.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: da9063: Fix PTR_ERR/ERR_PTR mismatch

If CONFIG_OF=n:

drivers/regulator/da9063-regulator.c: In function ‘da9063_parse_regulators_dt’:
drivers/regulator/da9063-regulator.c:712: warning: passing argument 1 of ‘PTR_ERR’ makes pointer from integer without a cast
drivers/regulator/da9063-regulator.c:712: warning: return makes pointer from integer without a cast

Use ERR_PTR() to encode an error code in a pointer.
PTR_ERR() is meant to decode an error code from a pointer.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: palmas: Remove wrong comment for the equation calculating num_voltages

Current equation on the comment is wrong.
For linear mapping starting from 0, the equation is (maxV-minV)/stepV + 1.
Since the linear mapping for PALMAS is not all starting from 0, the equation
on the comment is not useful and misleading. Thus remove it.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: fix fatal kernel-doc error

Fix fatal kernel-doc error in <linux/regulator/driver.h>:

Error(include/linux/regulator/driver.h:52): cannot understand prototype: 'struct regulator_linear_range '

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
[Rewrote first line -- broonie]
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: wm8350: correct the max_uV of LDO

As per datasheet, voltage range for LDOs are as follows:

	0000 = 0.9V
		...(50mV steps)
	01111 = 1.65V
	10000 = 1.8V
		... (100mV stepns)
	11111 = 3.3V

So, there is no  selector for 1.65V to 1.8V.
Correcting the range for max_uV for selector between 0 to 15.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
regulator: wm831x-ldo: Fix max_uV for gp_ldo and aldo linear range settings

Fix the linear range settings in commit 5ff26a14c3331
"regulator: wm831x-ldo: Convert to use linear ranges".

For wm831x_gp_ldo:
We have below equations for list voltage before converting to linear ranges:

sel <= 0xe:
        volt = 0.9-1.6V in 50mV steps
sel <= 0x1f:
        volt = 1.7-3.3V in 100mV steps

max_uV for the first linear range should be 1600000 rather than 1650000. Fix it.

For wm831x_aldo:
We have below equations for list voltage before converting to linear ranges:

sel <= 0xc:
        volt = 1-1.6V in 50mV steps
sel <= 0x1f
        volt = 1.7-3.5V in 100mV steps

max_uV for the first linear range should be 1600000 rather than 1650000. Fix it.

Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Score: The commit is for compiling successfully.
	The modifications include:
	1. Kconfig of Score: we don't support ioremap
	2. Missed headfile including
	3. There are some errors in other people's commit not checked by us, we fix it now
	3.1 arch/score/kernel/entry.S: wrong instructions
	3.2 arch/score/kernel/process.c : just some typos

	Signed-off-by: Lennox Wu <lennox.wu@gmail.com>
Score: Implement the function csum_ipv6_magic

Signed-off-by: Lennox Wu <lennox.wu@gmail.com>
Score: Modify the Makefile of Score, remove -mlong-calls for compiling

Signed-off-by: Lennox Wu <lennox.wu@gmail.com>
Score: Update the information of Score maintaners

Signed-off-by: Lennox Wu <lennox.wu@gmail.com>
NFSv4: Honour the 'opened' parameter in the atomic_open() filesystem method

Determine if we've created a new file by examining the directory change
attribute and/or the O_EXCL flag.

This fixes a regression when doing a non-exclusive create of a new file.
If the FILE_CREATED flag is not set, the atomic_open() command will
perform full file access permissions checks instead of just checking
for MAY_OPEN.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
ARC: Handle zero-overhead-loop in unaligned access handler

If a load or store is the last instruction in a zero-overhead-loop, and
it's misaligned, the loop would execute only once.

This fixes that problem.

Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: Fix 32-bit wrap around in access_ok()

Anton reported

 | LTP tests syscalls/process_vm_readv01 and process_vm_writev01 fail
 | similarly in one testcase test_iov_invalid -> lvec->iov_base.
 | Testcase expects errno EFAULT and return code -1,
 | but it gets return code 1 and ERRNO is 0 what means success.

Essentially test case was passing a pointer of -1 which access_ok()
was not catching. It was doing [@addr + @sz <= TASK_SIZE] which would
pass for @addr == -1

Fixed that by rewriting as [@addr <= TASK_SIZE - @sz]

Reported-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: Workaround spinlock livelock in SMP SystemC simulation

Some ARC SMP systems lack native atomic R-M-W (LLOCK/SCOND) insns and
can only use atomic EX insn (reg with mem) to build higher level R-M-W
primitives. This includes a SystemC based SMP simulation model.

So rwlocks need to use a protecting spinlock for atomic cmp-n-exchange
operation to update reader(s)/writer count.

The spinlock operation itself looks as follows:

	mov reg, 1		; 1=locked, 0=unlocked
retry:
	EX reg, [lock]		; load existing, store 1, atomically
	BREQ reg, 1, rety	; if already locked, retry

In single-threaded simulation, SystemC alternates between the 2 cores
with "N" insn each based scheduling. Additionally for insn with global
side effect, such as EX writing to shared mem, a core switch is
enforced too.

Given that, 2 cores doing a repeated EX on same location, Linux often
got into a livelock e.g. when both cores were fiddling with tasklist
lock (gdbserver / hackbench) for read/write respectively as the
sequence diagram below shows:

           core1                                   core2
         --------                                --------
1. spin lock [EX r=0, w=1] - LOCKED
2. rwlock(Read)            - LOCKED
3. spin unlock  [ST 0]     - UNLOCKED
                                         spin lock [EX r=0,w=1] - LOCKED
                      -- resched core 1----

5. spin lock [EX r=1] - ALREADY-LOCKED

                      -- resched core 2----
6.                                       rwlock(Write) - READER-LOCKED
7.                                       spin unlock [ST 0]
8.                                       rwlock failed, retry again

9.                                       spin lock  [EX r=0, w=1]
                      -- resched core 1----

10  spinlock locked in #9, retry #5
11. spin lock [EX gets 1]
                      -- resched core 2----
...
...

The fix was to unlock using the EX insn too (step 7), to trigger another
SystemC scheduling pass which would let core1 proceed, eliding the
livelock.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
ARC: Use clockevents_config_and_register over clockevents_register_device

clockevents_config_and_register is more clever and correct than doing it
by hand; so use it.

[vgupta: fixed build failure due to missing ; in patch]

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
regulator: ti-abb: Fix bias voltage glitch in transition to bypass mode

As documented in Application Note SWPA117 v2.1(NDA), LDO override has a
requirement that when switching from Bias active + override active
mode(FBB/RBB) to Bypass(nominal) mode, LDO reset must be performed
*after* LDO transitions to Bypass(nominal) mode.

The same rule in reverse applies when switching from a ABB bypass mode
to ABB enabled - LDO override *must* be performed prior to transition to
required ABB mode, if we do not do that, the same glitch takes place.

Currently while transitioning to ABB bypass, we reset the LDO overide
prior to the transition which causes a few milliseconds where ABB LDO
voltage could go all the way to 800mV(based on SoC process node),
during this period, the delta voltage between VDD rail and VBB rail
could cause the system to improperly function.

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
NFSv4.1: nfs4_fl_prepare_ds - fix bugs when the connect attempt fails

- Fix an Oops when nfs4_ds_connect() returns an error.
- Always check the device status after waiting for a connect to complete.

Reported-by: Andy Adamson <andros@netapp.com>
Reported-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: <stable@vger.kernel.org> # v3.10+
NFSv4.1: Ensure memory ordering between nfs4_ds_connect and nfs4_fl_prepare_ds

We need to ensure that the initialisation of the data server nfs_client
structure in nfs4_ds_connect is correctly ordered w.r.t. the read of
ds->ds_clp in nfs4_fl_prepare_ds.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
NFSv4.1: try SECINFO_NO_NAME flavs until one works

Call nfs4_lookup_root_sec for each flavor returned by SECINFO_NO_NAME until
one works.

One example of a situation this fixes:

 - server configured for krb5
 - server principal somehow gets deleted from KDC
 - server still thinking krb is good, sends krb5 as first entry in
    SECINFO_NO_NAME response
 - client tries krb5, but this fails without even sending an RPC because
    gssd's requests to the KDC can't find the server's principal

Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>