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>
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
apparmor: Use shash crypto API interface for profile hashes

Use the shash interface, rather than the hash interface, when hashing
AppArmor profiles. The shash interface does not use scatterlists and it
is a better fit for what AppArmor needs.

This fixes a kernel paging BUG when aa_calc_profile_hash() is passed a
buffer from vmalloc(). The hash interface requires callers to handle
vmalloc() buffers differently than what AppArmor was doing. Due to
vmalloc() memory not being physically contiguous, each individual page
behind the buffer must be assigned to a scatterlist with sg_set_page()
and then the scatterlist passed to crypto_hash_update().

The shash interface does not have that limitation and allows vmalloc()
and kmalloc() buffers to be handled in the same manner.

BugLink: https://launchpad.net/bugs/1216294/
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=62261

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Seth Arnold <seth.arnold@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
apparmor: fix suspicious RCU usage warning in policy.c/policy.h

The recent 3.12 pull request for apparmor was missing a couple rcu _protected
access modifiers. Resulting in the follow suspicious RCU usage

 [   29.804534] [ INFO: suspicious RCU usage. ]
 [   29.804539] 3.11.0+ #5 Not tainted
 [   29.804541] -------------------------------
 [   29.804545] security/apparmor/include/policy.h:363 suspicious rcu_dereference_check() usage!
 [   29.804548]
 [   29.804548] other info that might help us debug this:
 [   29.804548]
 [   29.804553]
 [   29.804553] rcu_scheduler_active = 1, debug_locks = 1
 [   29.804558] 2 locks held by apparmor_parser/1268:
 [   29.804560]  #0:  (sb_writers#9){.+.+.+}, at: [<ffffffff81120a4c>] file_start_write+0x27/0x29
 [   29.804576]  #1:  (&ns->lock){+.+.+.}, at: [<ffffffff811f5d88>] aa_replace_profiles+0x166/0x57c
 [   29.804589]
 [   29.804589] stack backtrace:
 [   29.804595] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5
 [   29.804599] Hardware name: ASUSTeK Computer Inc.         UL50VT          /UL50VT    , BIOS 217     03/01/2010
 [   29.804602]  0000000000000000 ffff8800b95a1d90 ffffffff8144eb9b ffff8800b94db540
 [   29.804611]  ffff8800b95a1dc0 ffffffff81087439 ffff880138cc3a18 ffff880138cc3a18
 [   29.804619]  ffff8800b9464a90 ffff880138cc3a38 ffff8800b95a1df0 ffffffff811f5084
 [   29.804628] Call Trace:
 [   29.804636]  [<ffffffff8144eb9b>] dump_stack+0x4e/0x82
 [   29.804642]  [<ffffffff81087439>] lockdep_rcu_suspicious+0xfc/0x105
 [   29.804649]  [<ffffffff811f5084>] __aa_update_replacedby+0x53/0x7f
 [   29.804655]  [<ffffffff811f5408>] __replace_profile+0x11f/0x1ed
 [   29.804661]  [<ffffffff811f6032>] aa_replace_profiles+0x410/0x57c
 [   29.804668]  [<ffffffff811f16d4>] profile_replace+0x35/0x4c
 [   29.804674]  [<ffffffff81120fa3>] vfs_write+0xad/0x113
 [   29.804680]  [<ffffffff81121609>] SyS_write+0x44/0x7a
 [   29.804687]  [<ffffffff8145bfd2>] system_call_fastpath+0x16/0x1b
 [   29.804691]
 [   29.804694] ===============================
 [   29.804697] [ INFO: suspicious RCU usage. ]
 [   29.804700] 3.11.0+ #5 Not tainted
 [   29.804703] -------------------------------
 [   29.804706] security/apparmor/policy.c:566 suspicious rcu_dereference_check() usage!
 [   29.804709]
 [   29.804709] other info that might help us debug this:
 [   29.804709]
 [   29.804714]
 [   29.804714] rcu_scheduler_active = 1, debug_locks = 1
 [   29.804718] 2 locks held by apparmor_parser/1268:
 [   29.804721]  #0:  (sb_writers#9){.+.+.+}, at: [<ffffffff81120a4c>] file_start_write+0x27/0x29
 [   29.804733]  #1:  (&ns->lock){+.+.+.}, at: [<ffffffff811f5d88>] aa_replace_profiles+0x166/0x57c
 [   29.804744]
 [   29.804744] stack backtrace:
 [   29.804750] CPU: 0 PID: 1268 Comm: apparmor_parser Not tainted 3.11.0+ #5
 [   29.804753] Hardware name: ASUSTeK Computer Inc.         UL50VT          /UL50VT    , BIOS 217     03/01/2010
 [   29.804756]  0000000000000000 ffff8800b95a1d80 ffffffff8144eb9b ffff8800b94db540
 [   29.804764]  ffff8800b95a1db0 ffffffff81087439 ffff8800b95b02b0 0000000000000000
 [   29.804772]  ffff8800b9efba08 ffff880138cc3a38 ffff8800b95a1dd0 ffffffff811f4f94
 [   29.804779] Call Trace:
 [   29.804786]  [<ffffffff8144eb9b>] dump_stack+0x4e/0x82
 [   29.804791]  [<ffffffff81087439>] lockdep_rcu_suspicious+0xfc/0x105
 [   29.804798]  [<ffffffff811f4f94>] aa_free_replacedby_kref+0x4d/0x62
 [   29.804804]  [<ffffffff811f4f47>] ? aa_put_namespace+0x17/0x17
 [   29.804810]  [<ffffffff811f4f0b>] kref_put+0x36/0x40
 [   29.804816]  [<ffffffff811f5423>] __replace_profile+0x13a/0x1ed
 [   29.804822]  [<ffffffff811f6032>] aa_replace_profiles+0x410/0x57c
 [   29.804829]  [<ffffffff811f16d4>] profile_replace+0x35/0x4c
 [   29.804835]  [<ffffffff81120fa3>] vfs_write+0xad/0x113
 [   29.804840]  [<ffffffff81121609>] SyS_write+0x44/0x7a
 [   29.804847]  [<ffffffff8145bfd2>] system_call_fastpath+0x16/0x1b

Reported-by: miles.lane@gmail.com
CC: paulmck@linux.vnet.ibm.com
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
sysv: Add forgotten superblock lock init for v7 fs

Superblock lock was replaced with (un)lock_super() removal, but left
uninitialized for Seventh Edition UNIX filesystem in the following commit (3.7):
c07cb01 sysv: drop lock/unlock super

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
ocfs2: needs ->d_lock to poke in ->d_parent->d_inode from ->d_revalidate()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
afs: dget_parent() can't return a negative dentry

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Merge remote-tracking branch 'regulator/fix/da9063' into regulator-linus
Merge remote-tracking branch 'regulator/fix/doc' into regulator-linus
Merge remote-tracking branch 'regulator/fix/palmas' into regulator-linus
Merge remote-tracking branch 'regulator/fix/ti-abb' into regulator-linus
Merge remote-tracking branch 'regulator/fix/wm831x' into regulator-linus
Merge remote-tracking branch 'regulator/fix/wm8350' into regulator-linus
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

Pull assorted vfs fixes from Al Viro:
 "A couple of bug fixes + removal of dead code in afs ->d_revalidate()"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  afs: dget_parent() can't return a negative dentry
  ocfs2: needs ->d_lock to poke in ->d_parent->d_inode from ->d_revalidate()
  sysv: Add forgotten superblock lock init for v7 fs