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>
Bluetooth: Add a new PID/VID 0cf3/e005 for AR3012.

usb device info:

T:  Bus=06 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 15 Spd=12   MxCh= 0
D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0cf3 ProdID=e005 Rev= 0.02
C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms

Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Peng Chen <pengchen@qca.qualcomm.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Fix security level for peripheral role

While playing the peripheral role, the host gets a LE Long Term Key
Request Event from the controller when a connection is established
with a bonded device. The host then informs the LTK which should be
used for the connection. Once the link is encrypted, the host gets
an Encryption Change Event.

Therefore we should set conn->pending_sec_level instead of conn->
sec_level in hci_le_ltk_request_evt. This way, conn->sec_level is
properly updated in hci_encrypt_change_evt.

Moreover, since we have a LTK associated to the device, we have at
least BT_SECURITY_MEDIUM security level.

Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Fix encryption key size for peripheral role

This patch fixes the connection encryption key size information when
the host is playing the peripheral role. We should set conn->enc_key_
size in hci_le_ltk_request_evt, otherwise it is left uninitialized.

Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Add support for BCM20702A0 [0b05, 17cb]

Yet another vendor specific ID for this chipset; this one for the ASUS
USB-BT400 Bluetooth 4.0 adapter.

T:  Bus=03 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#=  6 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0b05 ProdID=17cb Rev=01.12
S:  Manufacturer=Broadcom Corp
S:  Product=BCM20702A0
S:  SerialNumber=000272C64400
C:  #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I:  If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)

Cc: stable@vger.kernel.org
Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Fix ACL alive for long in case of non pariable devices

For certain devices (ex: HID mouse), support for authentication,
pairing and bonding is optional. For such devices, the ACL alive
for too long after the L2CAP disconnection.

To avoid the ACL alive for too long after L2CAP disconnection, reset the
ACL disconnect timeout back to HCI_DISCONN_TIMEOUT during L2CAP connect.

While merging the commit id:a9ea3ed9b71cc3271dd59e76f65748adcaa76422
this issue might have introduced.

Hcidump info:
sh-4.1# /opt/hcidump -Xt
2013-08-05 16:49:00.894129 < ACL data: handle 12 flags 0x00 dlen 12
    L2CAP(s): Disconn req: dcid 0x004a scid 0x0041
2013-08-05 16:49:00.894195 < HCI Command: Exit Sniff Mode (0x02|0x0004)
    plen 2
    handle 12
2013-08-05 16:49:00.894269 < ACL data: handle 12 flags 0x00 dlen 12
    L2CAP(s): Disconn req: dcid 0x0049 scid 0x0040
2013-08-05 16:49:00.895645 > HCI Event: Command Status (0x0f) plen 4
    Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
2013-08-05 16:49:00.934391 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x00 interval 0
    Mode: Active
2013-08-05 16:49:00.936592 > HCI Event: Number of Completed Packets
    (0x13) plen 5
    handle 12 packets 2
2013-08-05 16:49:00.951577 > ACL data: handle 12 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x004a scid 0x0041
2013-08-05 16:49:00.952820 > ACL data: handle 12 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0049 scid 0x0040
2013-08-05 16:49:00.969165 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x02 interval 50
    Mode: Sniff

2013-08-05 16:49:48.175533 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x00 interval 0
    Mode: Active
2013-08-05 16:49:48.219045 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x02 interval 108
    Mode: Sniff

2013-08-05 16:51:00.968209 < HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 12 reason 0x13
    Reason: Remote User Terminated Connection
2013-08-05 16:51:00.969056 > HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
2013-08-05 16:51:01.013495 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x00 interval 0
    Mode: Active
2013-08-05 16:51:01.073777 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 12 reason 0x16
    Reason: Connection Terminated by Local Host

============================ After  fix ================================

2013-08-05 16:57:35.986648 < ACL data: handle 11 flags 0x00 dlen 12
    L2CAP(s): Disconn req: dcid 0x004c scid 0x0041
2013-08-05 16:57:35.986713 < HCI Command: Exit Sniff Mode (0x02|0x0004)
    plen 2
    handle 11
2013-08-05 16:57:35.986785 < ACL data: handle 11 flags 0x00 dlen 12
    L2CAP(s): Disconn req: dcid 0x004b scid 0x0040
2013-08-05 16:57:35.988110 > HCI Event: Command Status (0x0f) plen 4
    Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
2013-08-05 16:57:36.030714 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x00 interval 0
    Mode: Active
2013-08-05 16:57:36.032950 > HCI Event: Number of Completed Packets
    (0x13) plen 5
    handle 11 packets 2
2013-08-05 16:57:36.047926 > ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x004c scid 0x0041
2013-08-05 16:57:36.049200 > ACL data: handle 11 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x004b scid 0x0040
2013-08-05 16:57:36.065509 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x02 interval 50
    Mode: Sniff

2013-08-05 16:57:40.052006 < HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 11 reason 0x13
    Reason: Remote User Terminated Connection
2013-08-05 16:57:40.052869 > HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
2013-08-05 16:57:40.104731 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 11 mode 0x00 interval 0
    Mode: Active
2013-08-05 16:57:40.146935 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 11 reason 0x16
    Reason: Connection Terminated by Local Host

Signed-off-by: Sang-Ki Park <sangki79.park@samsung.com>
Signed-off-by: Chan-yeol Park <chanyeol.park@samsung.com>
Signed-off-by: Jaganath Kanakkassery <jaganath.k@samsung.com>
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
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>
Bluetooth: Introduce a new HCI_RFKILLED flag

This makes it more convenient to check for rfkill (no need to check for
dev->rfkill before calling rfkill_blocked()) and also avoids potential
races if the RFKILL state needs to be checked from within the rfkill
callback.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Bluetooth: Fix rfkill functionality during the HCI setup stage

We need to let the setup stage complete cleanly even when the HCI device
is rfkilled. Otherwise the HCI device will stay in an undefined state
and never get notified to user space through mgmt (even when it gets
unblocked through rfkill).

This patch makes sure that hci_dev_open() can be called in the HCI_SETUP
stage, that blocking the device doesn't abort the setup stage, and that
the device gets proper powered down as soon as the setup stage completes
in case it was blocked meanwhile.

The bug that this patch fixed can be very easily reproduced using e.g.
the rfkill command line too. By running "rfkill block all" before
inserting a Bluetooth dongle the resulting HCI device goes into a state
where it is never announced over mgmt, not even when "rfkill unblock all"
is run.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Cc: stable@vger.kernel.org
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
ipvs: fix overflow on dest weight multiply

Schedulers such as lblc and lblcr require the weight to be as high as the
maximum number of active connections. In commit b552f7e3a9524abcbcdf
("ipvs: unify the formula to estimate the overhead of processing
connections"), the consideration of inactconns and activeconns was cleaned
up to always count activeconns as 256 times more important than inactconns.
In cases where 3000 or more connections are expected, a weight of 3000 *
256 * 3000 connections overflows the 32-bit signed result used to determine
if rescheduling is required.

On amd64, this merely changes the multiply and comparison instructions to
64-bit. On x86, a 64-bit result is already present from imull, so only
a few more comparison instructions are emitted.

Signed-off-by: Simon Kirby <sim@hostway.ca>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
ipvs: make the service replacement more robust

commit 578bc3ef1e473a ("ipvs: reorganize dest trash") added
IP_VS_DEST_STATE_REMOVING flag and RCU callback named
ip_vs_dest_wait_readers() to keep dests and services after
removal for at least a RCU grace period. But we have the
following corner cases:

- we can not reuse the same dest if its service is removed
while IP_VS_DEST_STATE_REMOVING is still set because another dest
removal in the first grace period can not extend this period.
It can happen when ipvsadm -C && ipvsadm -R is used.

- dest->svc can be replaced but ip_vs_in_stats() and
ip_vs_out_stats() have no explicit read memory barriers
when accessing dest->svc. It can happen that dest->svc
was just freed (replaced) while we use it to update
the stats.

We solve the problems as follows:

- IP_VS_DEST_STATE_REMOVING is removed and we ensure a fixed
idle period for the dest (IP_VS_DEST_TRASH_PERIOD). idle_start
will remember when for first time after deletion we noticed
dest->refcnt=0. Later, the connections can grab a reference
while in RCU grace period but if refcnt becomes 0 we can
safely free the dest and its svc.

- dest->svc becomes RCU pointer. As result, we add explicit
RCU locking in ip_vs_in_stats() and ip_vs_out_stats().

- __ip_vs_unbind_svc is renamed to __ip_vs_svc_put(), it
now can free the service immediately or after a RCU grace
period. dest->svc is not set to NULL anymore.

	As result, unlinked dests and their services are
freed always after IP_VS_DEST_TRASH_PERIOD period, unused
services are freed after a RCU grace period.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
ipvs: do not use dest after ip_vs_dest_put in LBLC

commit c2a4ffb70eef39 ("ipvs: convert lblc scheduler to rcu")
allows RCU readers to use dest after calling ip_vs_dest_put().
In the corner case it can race with ip_vs_dest_trash_expire()
which can release the dest while it is being returned to the
RCU readers as scheduling result.

To fix the problem do not allow en->dest to be replaced and
defer the ip_vs_dest_put() call by using RCU callback. Now
en->dest does not need to be RCU pointer.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
ipvs: do not use dest after ip_vs_dest_put in LBLCR

commit c5549571f975ab ("ipvs: convert lblcr scheduler to rcu")
allows RCU readers to use dest after calling ip_vs_dest_put().
In the corner case it can race with ip_vs_dest_trash_expire()
which can release the dest while it is being returned to the
RCU readers as scheduling result.

To fix the problem do not allow e->dest to be replaced and
defer the ip_vs_dest_put() call by using RCU callback. Now
e->dest does not need to be RCU pointer.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
ipvs: stats should not depend on CPU 0

When reading percpu stats we need to properly reset
the sum when CPU 0 is not present in the possible mask.

Signed-off-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
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>
sfc: Wait for MC reboot to complete before scheduling driver reset

Scheduling a reset following an MC reboot event before waiting for
reboot to complete results in a race that can lead to a state where
must_realloc_vis is false in efx_ef10_fini_dmaq() but the VIs have
been destroyed during the MC reboot.

To avoid MC errors when trying to remove VIs that do not exist, wait
for the MC reboot to complete before scheduling the reset.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
sfc: Increase MCDI status timeout to 250ms

The SFC9120 MC firmware often takes longer than 20ms to reboot and
update the warm boot count in BIU_MC_SFT_STATUS_REG.  A timeout of
250ms is very generous for an MC reboot.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>