Trim API and remove unused variables.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
A reference to the rate table is stored inside the
private structure, so there is no need to pass "rate_table"
around.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Remove various local variables that duplicate information
already stored in mac80211.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We're holding the sta_list_spinlock here so we can't sleep.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Call cfg80211_michael_mic_failure() handler when there is a MIC error
event from firmware.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Kiran Divekar <dkiran@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The key length can be 32 bytes for TKIP and 16 bytes for AES_CMAC.
'smatch' warns on memcpy using key_len variable to copy data to
a 16 bytes buffer. Use fixed length to avoid the warning.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We can not assume parallel flash is always present, there are boards
with *serial* flash and probably some without flash at all.
Define some bits by the way.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Reviewed-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
These warnings can be detected by using powerpc64-linux toolchain
(gcc-4.6.3-nolibc).
CC [M] drivers/net/wireless/mwifiex/sta_event.o
drivers/net/wireless/mwifiex/sta_event.c: In function 'mwifiex_process_sta_event':
drivers/net/wireless/mwifiex/sta_event.c:388:4: warning: comparison of distinct pointer types lacks a cast [enabled by default]
CC [M] drivers/net/wireless/mwifiex/uap_event.o
drivers/net/wireless/mwifiex/uap_event.c: In function 'mwifiex_process_uap_event':
drivers/net/wireless/mwifiex/uap_event.c:258:11: warning: comparison of distinct pointer types lacks a cast [enabled by default]
Use min_t() instead of min() to fix the warnings.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There's no need to export the il_pci_suspend
and il_pci_resume functions since they're only
referenced from il_pm_ops. The latter can also
be defined using SIMPLE_DEV_PM_OPS instead of
open-coding it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Put power_level to ah_txpower struct with the rest tx power infos and
also rename it to txp_requested to make more sense.
v2 make sure we don't memset it to zero on reset
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
By using cur_pwr on phy_init we re-use the power level previously set by the
driver, not the one we got from above.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
rates[i] is unsigned but txp_offset can be negative for newer parts
with PDADC table. We cover the case when rates[i] + txp_offset > 63
but we must also cover the case when its < 0 or else rates[i] will overflow.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Make sure we don't store the table offsets for min and cur power levels,
store the 0.25dB values instead. This way we don't clamp the tx power level
to max (because now cur_pwr holds the 0.25dB value, not the table offset) after
re-using cur_pwr on reset.
Signed-off-by: Nick Kossifidis <mickflemm@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The functions and structs are not used in an other file and the
prototypes are in no header file, just make them static so the compiler
is able to optimize them better.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
For the upcoming tpc changes, the driver needs
to provide sensible max output values for each
supported channel.
And while the eeprom always had a output_limit
table, which defines the upper limit for each
frequency and modulation, it was never really
useful for anything... until now.
Note: For anyone wondering about what your card
is calibrated for: check "iw list".
* 2412 MHz [1] (18.0 dBm)
* 2437 MHz [6] (19.0 dBm)
[...]
* 5180 MHz [36] (18.0 dBm)
* 5260 MHz [52] (17.0 dBm) (radar detection)
* 5680 MHz [136] (19.0 dBm) (radar detection)
(for a Dell Wireless 1450 USB Adapter)
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
According to a compiler warning, the tpm_tis_resume() function is not
used for CONFIG_PM_SLEEP unset, so add a #ifdef to prevent it from
being built in that case.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
According to compiler warnings, quite some suspend/resume functions
in platform x86 drivers are not used for CONFIG_PM_SLEEP unset, so
add #ifdefs to prevent them from being built in that case.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
According to compiler warnings, several suspend/resume functions
in ACPI drivers are not used for CONFIG_PM_SLEEP unset, so add
#ifdefs to prevent them from being built in that case.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
ntosd2_init_i2c walks the ntosd2_i2c_info array, which it expects to
be populated with at least one member. gcc correctly warns about
the out-of-bounds access here.
Since this can not possibly work, it's better to disable i2c
support entirely on this board.
Without this patch, building davinci_all_defconfig results in:
arch/arm/mach-davinci/board-neuros-osd2.c: In function 'davinci_ntosd2_init':
arch/arm/mach-davinci/board-neuros-osd2.c:187:20: warning: array subscript is above array bounds [-Warray-bounds]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sekhar Nori <nsekhar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Andrey Porodko <panda@chelcom.ru>
Disabling CONFIG_BUG creates an insane amount of build warnings, which
makes it useless to check for building defconfigs to see if new
warnings show up.
Without this patch, building tct_hammer_defconfig results in:
net/packet/af_packet.c: In function 'tpacket_rcv':
net/packet/af_packet.c:1889:30: warning: 'hdrlen' may be used uninitialized in this function [-Wuninitialized]
net/core/ethtool.c: In function 'ethtool_get_feature_mask':
net/core/ethtool.c:213:1: warning: control reaches end of non-void function [-Wreturn-type]
block/cfq-iosched.c: In function 'cfq_async_queue_prio':
block/cfq-iosched.c:2914:1: warning: control reaches end of non-void function [-Wreturn-type]
mm/bootmem.c: In function 'mark_bootmem':
mm/bootmem.c:352:1: warning: control reaches end of non-void function [-Wreturn-type]
net/core/dev.c: In function 'skb_warn_bad_offload':
net/core/dev.c:1904:33: warning: unused variable 'null_features' [-Wunused-variable]
drivers/mtd/chips/cfi_probe.c: In function 'cfi_chip_setup':
include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
include/linux/mtd/map.h:394:11: note: 'r.x[0]' was declared here
include/linux/mtd/cfi.h:489:3: warning: 'r.x[0]' may be used uninitialized in this function [-Wuninitialized]
(and many more)
The size of vmlinux increases by 1.78% because of this:
size obj-arm/vmlinux.nobug
text data bss dec hex filename
2108474 116916 55352 2280742 22cd26 obj-arm/vmlinux
size obj-arm/vmlinux.bug
text data bss dec hex filename
2150804 116916 53696 2321416 236c08 obj-arm/vmlinux
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
The original code was misported from the X driver,
a) an int went to unsigned int, breaking the downward counting testm code
b) the port did the vco/computed clock bits completely wrong.
This fixes an infinite loop on modprobe on some Dell servers with the G200ER
chipset variant.
Found in internal testing.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Do not leak memory by updating pointer with potentially
NULL realloc return value.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Reviewed-by: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
These patches all fix bugs that were newly introduced in v3.6-rc1
and found because they cause a gcc warning with one of the ARM
defconfigs. Most of them are harmless, but since we're trying
to get rid of all warnings eventually, we can start with the ones
that were not there before.
* testing/new-warnings:
omap-rng: fix use of SIMPLE_DEV_PM_OPS
spi/s3c64xx: improve error handling
mtd/omap2: fix dmaengine_slave_config error handling
gpio: em: do not discard em_gio_irq_domain_cleanup
ARM: exynos: exynos_pm_add_dev_to_genpd may be unused
usb/ohci-omap: remove unused variable
mfd/asic3: fix asic3_mfd_probe return value
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
omap_rng_suspend and omap_rng_resume are unused if CONFIG_PM is enabled
but CONFIG_PM_SLEEP is disabled. I found this while building all defconfig
files on ARM. It's not clear to me if this is the right solution, but
at least it makes the code consistent again.
Without this patch, building omap1_defconfig results in:
drivers/char/hw_random/omap-rng.c:165:12: warning: 'omap_rng_suspend' defined but not used [-Wunused-function]
drivers/char/hw_random/omap-rng.c:171:12: warning: 'omap_rng_resume' defined but not used [-Wunused-function]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Kevin Hilman <khilman@ti.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
When a device tree definition os an s3c64xx SPI master is missing
a "controller-data" subnode, the newly added s3c64xx_get_slave_ctrldata
function might use uninitialized memory in place of that node,
which was correctly reported by gcc.
Without this patch, building s3c6400_defconfig results in:
drivers/spi/spi-s3c64xx.c: In function 's3c64xx_get_slave_ctrldata.isra.25':
drivers/spi/spi-s3c64xx.c:841:5: warning: 'data_np' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Jaswinder Singh <jaswinder.singh@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>
The newly added dmaengine support in the omap2 nand driver
potentially causes an undefined return value from the
omap_nand_probe function when dmaengine_slave_config
reports an error. Let's handle this by returning the
same error back to the caller.
Without this patch, building omap2plus_defconfig results in:
drivers/mtd/nand/omap2.c: In function 'omap_nand_probe':
drivers/mtd/nand/omap2.c:1154:6: warning: 'err' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Grazvydas Ignotas <notasas@gmail.com>
The newly added gpio-em driver marks its em_gio_irq_domain_cleanup
function as __devexit, which would lead to that function being
discarded in case CONFIG_HOTPLUG is disabled. However, the function
is also called by the error handling logic em_gio_probe, which
would cause a jump into a NULL pointer if it was removed from the
kernel or module.
Without this patch, building kzm9d_defconfig results in:
WARNING: drivers/gpio/built-in.o(.devinit.text+0x330): Section mismatch in reference from the function em_gio_probe() to the function .devexit.text:em_gio_irq_domain_cleanup()
The function __devinit em_gio_probe() references
a function __devexit em_gio_irq_domain_cleanup().
This is often seen when error handling in the init function
uses functionality in the exit path.
The fix is often to remove the __devexit annotation of
em_gio_irq_domain_cleanup() so it may be used outside an exit section.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Magnus Damm <damm@opensource.se>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
exynos_pm_add_dev_to_genpd is used if one or more out of a large
number of Kconfig symbols are enabled. However the new
exynos_defconfig selects none of those, so the function becomes
unused. Marking it so lets the compiler automatically discard
it.
Without this patch, building exynos_defconfig results in:
arch/arm/mach-exynos/pm_domains.c:118:123: warning: 'exynos_pm_add_dev_to_genpd' defined but not used [-Wunused-function]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
The higher ptrace restriction levels should be blocking even
PTRACE_TRACEME requests. The comments in the LSM documentation are
misleading about when the checks happen (the parent does not go through
security_ptrace_access_check() on a PTRACE_TRACEME call).
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org # 3.5.x and later
Signed-off-by: James Morris <james.l.morris@oracle.com>
commit be9f4a44e7d41cee (ipv4: tcp: remove per net tcp_sock) added a
selinux regression, reported and bisected by John Stultz
selinux_ip_postroute_compat() expect to find a valid sk->sk_security
pointer, but this field is NULL for unicast_sock
It turns out that unicast_sock are really temporary stuff to be able
to reuse part of IP stack (ip_append_data()/ip_push_pending_frames())
Fact is that frames sent by ip_send_unicast_reply() should be orphaned
to not fool LSM.
Note IPv6 never had this problem, as tcp_v6_send_response() doesnt use a
fake socket at all. I'll probably implement tcp_v4_send_response() to
remove these unicast_sock in linux-3.7
Reported-by: John Stultz <johnstul@us.ibm.com>
Bisected-by: John Stultz <johnstul@us.ibm.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Eric Paris <eparis@parisplace.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
During probe, every function probed clears the recovery registers from
all functions on its path - thus signaling that given a future recovery
event, there will be no need to wait for those functions.
This is a flawed behaviour - each function should only be responsible
for its own bit.
Since this registers are handled during the load/unload routines,
this cleanup is removed altogether.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The existing previous driver unload flow is flawed, causing the probe of
functions reaching the 'uncommon fork' in flr-capable devices to fail.
This patch resolves this, as well as fixing the flow for hypervisors which
disable flr capabilities from functions as they pass them as PDA to VMs,
as we cannot base the flow on the pci configuration space.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is a fix for bug, introduced in 3.4 kernel by commit
1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d ("tun: don't hold network
namespace by tun sockets"), which, among other things, replaced simple
sock_put() by sk_release_kernel(). Below is sequence, which leads to
oops for non-persistent devices:
tun_chr_close()
tun_detach() <== tun->socket.file = NULL
tun_free_netdev()
sk_release_sock()
sock_release(sock->file == NULL)
iput(SOCK_INODE(sock)) <== dereference on NULL pointer
This patch just removes zeroing of socket's file from __tun_detach().
sock_release() will do this.
Cc: stable@vger.kernel.org
Reported-by: Ruan Zhijie <ruanzhijie@hotmail.com>
Tested-by: Ruan Zhijie <ruanzhijie@hotmail.com>
Acked-by: Al Viro <viro@ZenIV.linux.org.uk>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We got a recursive lock in mksubvol because the caller already held
a lock. I think we got into this due to a merge error. Commit a874a63
removed the mnt_want_write call from btrfs_mksubvol and added a
replacement call to mnt_want_write_file in btrfs_ioctl_snap_create_transid.
Commit e7848683 however tried to move all calls to mnt_want_write above
i_mutex. So somewhere while merging this, it got mixed up. The
solution is to remove the mnt_want_write call completely from
mksubvol.
Reported-by: David Sterba <dave@jikos.cz>
Signed-off-by: Alexander Block <ablock84@googlemail.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
It is not currently possible to build the gpmi-nand driver without
also building the mxs-dma driver. Clarify this Kconfig and enable
both in the defconfig file so we can build it again with both enabled.
drivers/built-in.o: In function `gpmi_dma_filter':
clk-fixed-factor.c:(.text+0xafc18): undefined reference to `mxs_dma_is_apbh'
make[1]: *** [vmlinux] Error 1
make: *** [sub-make] Error 2
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Dirk Behme <dirk.behme@de.bosch.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <kernel@pengutronix.de>
Without this patch, building integrator_defconfig results in:
arch/arm/mach-integrator/core.c:150:1: warning: data definition has no type or storage class [enabled by default]
arch/arm/mach-integrator/core.c:150:1: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL' [-Wimplicit-int]
arch/arm/mach-integrator/core.c:150:1: warning: parameter names (without types) in function declaration [enabled by default]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: Russell King <linux@arm.linux.org.uk>
The samsung PWM driver has moved to the new PWM subsystem, which
changed the Kconfig symbol for that driver, but the rx1950 and
gta02 boards still uses the old one.
Without this patch, building s3c2410_defconfig results in:
arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_lcd_power':
arch/arm/mach-s3c24xx/mach-rx1950.c:430: undefined reference to `pwm_config'
arch/arm/mach-s3c24xx/mach-rx1950.c:431: undefined reference to `pwm_disable'
arch/arm/mach-s3c24xx/mach-rx1950.c:437: undefined reference to `pwm_config'
arch/arm/mach-s3c24xx/mach-rx1950.c:438: undefined reference to `pwm_enable'
arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_backlight_exit':
arch/arm/mach-s3c24xx/mach-rx1950.c:504: undefined reference to `pwm_free'
arch/arm/mach-s3c24xx/built-in.o: In function `rx1950_backlight_init':
arch/arm/mach-s3c24xx/mach-rx1950.c:487: undefined reference to `pwm_request'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Tushar Behera <tushar.behera@linaro.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
The sa1100 definition of the io_p2v macro has changed in v3.6, and this one
file stopped working because of that.
Without this patch, building hackkit_defconfig results in:
arch/arm/mach-sa1100/leds-hackkit.c: In function 'hackkit_leds_event':
arch/arm/mach-sa1100/leds-hackkit.c:39:4: error: implicit declaration of function 'IOMEM' [-Werror=implicit-function-declaration]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
The EETI touchscreen asserts its IRQ line as soon as it has data in its
internal buffers. The line is automatically deasserted once all data has
been read via I2C. Hence, the driver has to monitor the GPIO line and
cannot simply rely on the interrupt handler reception.
In the current implementation of the driver, irq_to_gpio() is used to
determine the GPIO number from the i2c_client's IRQ value.
As irq_to_gpio() is not available on all platforms, this patch changes
this and makes the driver ignore the passed in IRQ. Instead, a GPIO is
added to the platform_data struct and gpio_to_irq is used to derive the
IRQ from that GPIO. If this fails, bail out. The driver is only able to
work in environments where the touchscreen GPIO can be mapped to an
IRQ.
Without this patch, building raumfeld_defconfig results in:
drivers/input/touchscreen/eeti_ts.c: In function 'eeti_ts_irq_active':
drivers/input/touchscreen/eeti_ts.c:65:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration]
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: stable@vger.kernel.org (v3.2+)
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Sven Neumann <s.neumann@raumfeld.com>
Cc: linux-input@vger.kernel.org
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
The irq_to_gpio function was removed from the pxa platform
in linux-3.2, and this driver has been broken since.
There is actually no in-tree user of this driver that adds
this platform device, but the driver can and does get enabled
on some platforms.
Without this patch, building ezx_defconfig results in:
drivers/mfd/ezx-pcap.c: In function 'pcap_isr_work':
drivers/mfd/ezx-pcap.c:205:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: stable@vger.kernel.org (v3.2+)
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Daniel Ribeiro <drwyrm@gmail.com>
Commit 3d55c29 "ARM: tegra: harmony: add regulator supply name and its
input supply" was supposed to fix all the problems with regulators on
Harmony. However, it appears that I only tested it when booting using
board files, not when booting using device tree. This change fixes two
problems with regulators when booting using device tree:
1) That patch only created the vdd_sys regulator when booting using a
board file. Since this is the root of the whole regulator tree, this
caused no regulators to successfully initialize when booting using
device tree. The registration of vdd_sys is moved to fix this.
2) When booting use DT, the regulator core sets has_full_constraints,
which in turn causes the core to turn off any regulators not marked
as always on. Some of the affected regulators are required for basic
system operation. To solve this, add always on constraints to all
relevant regulators. This doesn't affect booting using a board file
since nothing sets has_full_constraints in that case.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
