summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2017-08-26regulator: tps65023: Fix inverted core enable logic.Richard Cochran
commit c90722b54a4f5e21ac59301ed9a6dbaa439bdb16 upstream. Commit 43530b69d758328d3ffe6ab98fd640463e8e3667 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly") intended to replace working inline helper functions with standard regmap calls. However, it also inverted the set/clear logic of the "CORE ADJ Allowed" bit. That patch was clearly never tested, since without that bit cleared, the core VDCDC1 voltage output does not react to I2C configuration changes. This patch fixes the issue by clearing the bit as in the original, correct implementation. Note for stable back porting that, due to subsequent driver churn, this patch will not apply on every kernel version. Fixes: 43530b69d758 ("regulator: Use regmap_read/write(), regmap_update_bits functions directly") Signed-off-by: Richard Cochran <rcochran@linutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-07-02regulator: core: Fix regualtor_ena_gpio_free not to access pin after freeingSeung-Woo Kim
commit 60a2362f769cf549dc466134efe71c8bf9fbaaba upstream. After freeing pin from regulator_ena_gpio_free, loop can access the pin. So this patch fixes not to access pin after freeing. Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-03-16regulator: stw481x-vmmc: fix ages old enable errorLinus Walleij
commit 295070e9aa015abb9b92cccfbb1e43954e938133 upstream. The regulator has never been properly enabled, it has been dormant all the time. It's strange that MMC was working at all, but it likely worked by the signals going through the levelshifter and reaching the card anyways. Fixes: 3615a34ea1a6 ("regulator: add STw481x VMMC driver") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2017-02-23regulator: tps65910: Work around silicon erratum SWCZ010Jan Remmet
commit 8f9165c981fed187bb483de84caf9adf835aefda upstream. http://www.ti.com/lit/pdf/SWCZ010: DCDC o/p voltage can go higher than programmed value Impact: VDDI, VDD2, and VIO output programmed voltage level can go higher than expected or crash, when coming out of PFM to PWM mode or using DVFS. Description: When DCDC CLK SYNC bits are 11/01: * VIO 3-MHz oscillator is the source clock of the digital core and input clock of VDD1 and VDD2 * Turn-on of VDD1 and VDD2 HSD PFETis synchronized or at a constant phase shift * Current pulled though VCC1+VCC2 is Iload(VDD1) + Iload(VDD2) * The 3 HSD PFET will be turned-on at the same time, causing the highest possible switching noise on the application. This noise level depends on the layout, the VBAT level, and the load current. The noise level increases with improper layout. When DCDC CLK SYNC bits are 00: * VIO 3-MHz oscillator is the source clock of digital core * VDD1 and VDD2 are running on their own 3-MHz oscillator * Current pulled though VCC1+VCC2 average of Iload(VDD1) + Iload(VDD2) * The switching noise of the 3 SMPS will be randomly spread over time, causing lower overall switching noise. Workaround: Set DCDCCTRL_REG[1:0]= 00. Signed-off-by: Jan Remmet <j.remmet@phytec.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2016-06-15regulator: s2mps11: Fix invalid selector mask and voltages for buck9Krzysztof Kozlowski
commit 3b672623079bb3e5685b8549e514f2dfaa564406 upstream. The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff instead of 0x1f) thus reading entire register as buck9's voltage. This effectively caused regulator core to interpret values as higher voltages than they were and then to set real voltage much lower than intended. The buck9 provides power to other regulators, including LDO13 and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower voltage caused SD card detection errors on Odroid XU3/XU4: mmc1: card never left busy state mmc1: error -110 whilst initialising SD card During driver probe the regulator core was checking whether initial voltage matches the constraints. With incorrect vsel_mask of 0xff and default value of 0x50, the core interpreted this as 5 V which is outside of constraints (3-3.775 V). Then the regulator core was adjusting the voltage to match the constraints. With incorrect vsel_mask this new voltage mapped to a vere low voltage in the driver. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> [bwh: Backported to 3.16: s2mps11_buck9_ops was never combined with other macros here, so just change the n_voltages and vsel_mask fields] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2016-05-01regulator: s5m8767: fix get_register() error handlingArnd Bergmann
commit e07ff9434167981c993a26d2edbbcb8e13801dbb upstream. The s5m8767_pmic_probe() function calls s5m8767_get_register() to read data without checking the return code, which produces a compile-time warning when that data is accessed: drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe': drivers/regulator/s5m8767.c:924:7: error: 'enable_reg' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/regulator/s5m8767.c:944:30: error: 'enable_val' may be used uninitialized in this function [-Werror=maybe-uninitialized] This changes the s5m8767_get_register() function to return a -EINVAL not just for an invalid register number but also for an invalid regulator number, as both would result in returning uninitialized data. The s5m8767_pmic_probe() function is then changed accordingly to fail on a read error, as all the other callers of s5m8767_get_register() already do. In practice this probably cannot happen, as we don't call s5m8767_get_register() with invalid arguments, but the gcc warning seems valid in principle, in terms writing safe error checking. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 9c4c60554acf ("regulator: s5m8767: Convert to use regulator_[enable|disable|is_enabled]_regmap") Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
2015-09-28regulator: pbias: Fix broken pbias disable functionalityKishon Vijay Abraham I
commit c329061be51bef655f28c9296093984c977aff85 upstream. regulator_disable of pbias always writes '0' to the enable_reg. However actual disable value of pbias regulator is not always '0'. Fix it by populating the disable_val in pbias_reg_info for the various platforms and assign it to the disable_val of pbias regulator descriptor. This will be used by regulator_disable_regmap while disabling pbias regulator. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2015-07-15regulator: core: fix constraints output bufferStefan Wahren
commit a7068e3932eee8268c4ce4e080a338ee7b8a27bf upstream. The buffer for condtraints debug isn't big enough to hold the output in all cases. So fix this issue by increasing the buffer. Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2015-03-30regulator: core: Fix enable GPIO reference countingDoug Anderson
commit 29d62ec5f87fbeec8413e2215ddad12e7f972e4c upstream. Normally _regulator_do_enable() isn't called on an already-enabled rdev. That's because the main caller, _regulator_enable() always calls _regulator_is_enabled() and only calls _regulator_do_enable() if the rdev was not already enabled. However, there is one caller of _regulator_do_enable() that doesn't check: regulator_suspend_finish(). While we might want to make regulator_suspend_finish() behave more like _regulator_enable(), it's probably also a good idea to make _regulator_do_enable() robust if it is called on an already enabled rdev. At the moment, _regulator_do_enable() is _not_ robust for already enabled rdevs if we're using an ena_pin. Each time _regulator_do_enable() is called for an rdev using an ena_pin the reference count of the ena_pin is incremented even if the rdev was already enabled. This is not as intended because the ena_pin is for something else: for keeping track of how many active rdevs there are sharing the same ena_pin. Here's how the reference counting works here: * Each time _regulator_enable() is called we increment rdev->use_count, so _regulator_enable() calls need to be balanced with _regulator_disable() calls. * There is no explicit reference counting in _regulator_do_enable() which is normally just a warapper around rdev->desc->ops->enable() with code for supporting delays. It's not expected that the "ops->enable()" call do reference counting. * Since regulator_ena_gpio_ctrl() does have reference counting (handling the sharing of the pin amongst multiple rdevs), we shouldn't call it if the current rdev is already enabled. Note that as part of this we cleanup (remove) the initting of ena_gpio_state in regulator_register(). In _regulator_do_enable(), _regulator_do_disable() and _regulator_is_enabled() is is clear that ena_gpio_state should be the state of whether this particular rdev has requested the GPIO be enabled. regulator_register() was initting it as the actual state of the pin. Fixes: 967cfb18c0e3 ("regulator: core: manage enable GPIO list") Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2015-03-30regulator: Only enable disabled regulators on resumeJavier Martinez Canillas
commit 0548bf4f5ad6fc3bd93c4940fa48078b34609682 upstream. The _regulator_do_enable() call ought to be a no-op when called on an already-enabled regulator. However, as an optimization _regulator_enable() doesn't call _regulator_do_enable() on an already enabled regulator. That means we never test the case of calling _regulator_do_enable() during normal usage and there may be hidden bugs or warnings. We have seen warnings issued by the tps65090 driver and bugs when using the GPIO enable pin. Let's match the same optimization that _regulator_enable() in regulator_suspend_finish(). That may speed up suspend/resume and also avoids exposing hidden bugs. [Use much clearer commit message from Doug Anderson] Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2015-02-04regulator: core: fix race condition in regulator_put()Ashay Jaiswal
commit 83b0302d347a49f951e904184afe57ac3723476e upstream. The regulator framework maintains a list of consumer regulators for a regulator device and protects it from concurrent access using the regulator device's mutex lock. In the case of regulator_put() the consumer is removed and regulator device's parameters are updated without holding the regulator device's mutex. This would lead to a race condition between the regulator_put() and any function which traverses the consumer list or modifies regulator device's parameters. Fix this race condition by holding the regulator device's mutex in case of regulator_put. Signed-off-by: Ashay Jaiswal <ashayj@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2015-01-05regulator: anatop: Set default voltage selector for vddpuMarkus Pargmann
commit fe08be3ec8672ed92b3ed1b85810df9fa0f98931 upstream. The code reads the default voltage selector from its register. If the bootloader disables the regulator, the default voltage selector will be 0 which results in faulty behaviour of this regulator driver. This patch sets a default voltage selector for vddpu if it is not set in the register. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2014-11-14regulator: max77693: Fix use of uninitialized regulator configKrzysztof Kozlowski
commit ca0c37a0b489bb14bf3e1549e7a8d0c9a17f4919 upstream. Driver allocated on stack struct regulator_config but didn't initialize it fully. Few fields (driver_data, ena_gpio) were left untouched. This lead to using random ena_gpio values as GPIOs for max77693 regulators. On occasion these values could match real GPIO numbers leading to interfering with other drivers and to unsuccessful enable/disable of regulator. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 80b022e29bfd ("regulator: max77693: Add max77693 regualtor driver.") Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
2014-10-30regulator: ltc3589: fix broken voltage transitionsSteffen Trumtrar
commit c5bb725ac2d1a13e9e766bf9a16bac986ade17cd upstream. VCCR is used as a trigger to start voltage transitions, so we need to mark it volatile in order to make sure it gets written to hardware every time we set a new voltage. Fixes regulator voltage being stuck at the first voltage set after driver load. [lst: reworded commit message] Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17regulator: tps65218: fix DCDC4 linear voltage rangeFelipe Balbi
commit 42ab0f3915f22728f54bb1f3c0dcf38ab2335b5b upstream. The second range of this particular regulator, starts at 1.60V, not as 1.55V as it was originally implied by code. Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-17regulator: arizona-ldo1: remove bypass functionalityNikesh Oswal
commit 5b919f3ebb533cbe400664837e24f66a0836b907 upstream. WM5110/8280 devices do not support bypass mode for LDO1 so remove the bypass callbacks registered with regulator core. Signed-off-by: Nikesh Oswal <nikesh@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-06-28Merge remote-tracking branches 'regulator/fix/bcm590xx', ↵Mark Brown
'regulator/fix/palmas' and 'regulator/fix/tps65218' into regulator-linus
2014-06-24regulator: tps65218: Correct the the config register for LDO1Keerthy
Correct the the config register for LDO1. Fixes: 90e7d5262796 (regulator: tps65218: Add Regulator driver for TPS65218 PMIC) Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: <stable@vger.kernel.org> # v3.15
2014-06-24regulator: tps65218: Add the missing of_node assignment in probeKeerthy
Add the missing of_node assignment in probe. Fixes: 90e7d5262796 (regulator: tps65218: Add Regulator driver for TPS65218 PMIC) Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: <stable@vger.kernel.org> # v3.15
2014-06-24regulator: palmas: fix typo in enable_reg calculationStephen Warren
When setting up .enable_reg for an SMPS regulator, presumably we should call PALMAS_BASE_TO_REG(PALMAS_SMPS_BASE, ...) rather than using LDO_BASE. This change makes the LCD panel and HDMI work again on the NVIDIA Dalmore board anyway. Fixes: 318dbb02b50c ("regulator: palmas: Fix SMPS enable/disable/is_enabled") Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Nishanth Menon <nm@ti.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-22regulator: bcm590xx: fix vbus nameGraham Williams
The vbus regulator was not getting its name set. This results in the sysfs entry being empty. The lack of a bcm590xx_regs[] table entry also upsets Coverity runs. Add the table entry so the name gets set properly. Signed-off-by: Graham Williams <graham.williams@linaro.org> Acked-by: Matt Porter <mporter@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-21regulator: palmas: Fix SMPS enable/disable/is_enabledNishanth Menon
We use regmap regulator ops to enable/disable and check if regulator is enabled for various SMPS. However, these depend on valid enable_reg, enable_mask and enable_value in regulator descriptor. Currently we do not populate these for SMPS other than SMPS10, this results in spurious results as regmap assumes that the values are valid and ends up reading register 0x0 RTC:SECONDS_REG on Palmas variants that do have RTC! To fix this, we update proper parameters for the descriptor fields. Further, we want to ensure the behavior consistent with logic prior to commit dbabd624d4eec50b6, where, once you do a set_mode, enable/disable ensure the logic remains consistent and configures Palmas to the configuration that we set with set_mode (since the configuration register is common). To do this, we can rely on the regulator core's regulator_register behavior where the regulator descriptor pointer provided by the regulator driver is stored. (no reallocation and copy is done). This lets us update the enable_value post registration, to remain consistent with the mode we configure as part of set_mode. Fixes: dbabd624d4eec50b6 ("regulator: palmas: Reemove open coded functions with helper functions") Reported-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Nishanth Menon <nm@ti.com> Tested-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-16Merge remote-tracking branches 'regulator/fix/as3722', ↵Mark Brown
'regulator/fix/ltc3589' and 'regulator/fix/palmas' into regulator-linus
2014-06-16regulator: ltc3589: Use of_get_child_by_nameAxel Lin
of_find_node_by_name() walks the allnodes list, and can thus walk outside of the parent node. Use of_get_child_by_name() instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-11Merge tag 'modules-next-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull module updates from Rusty Russell: "Most of this is cleaning up various driver sysfs permissions so we can re-add the perm check (we unified the module param and sysfs checks, but the module ones were stronger so we weakened them temporarily). Param parsing gets documented, and also "--" now forces args to be handed to init (and ignored by the kernel). Module NX/RO protections get tightened: we now set them before calling parse_args()" * tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: module: set nx before marking module MODULE_STATE_COMING. samples/kobject/: avoid world-writable sysfs files. drivers/hid/hid-picolcd_fb: avoid world-writable sysfs files. drivers/staging/speakup/: avoid world-writable sysfs files. drivers/regulator/virtual: avoid world-writable sysfs files. drivers/scsi/pm8001/pm8001_ctl.c: avoid world-writable sysfs files. drivers/hid/hid-lg4ff.c: avoid world-writable sysfs files. drivers/video/fbdev/sm501fb.c: avoid world-writable sysfs files. drivers/mtd/devices/docg3.c: avoid world-writable sysfs files. speakup: fix incorrect perms on speakup_acntsa.c cpumask.h: silence warning with -Wsign-compare Documentation: Update kernel-parameters.tx param: hand arguments after -- straight to init modpost: Fix resource leak in read_dump()
2014-06-05regulator: palmas: Fix SMPS list for 0VNishanth Menon
get_voltage_sel reads from SMPS register - if the read selector value is 0, the SMPS is actually disabled - So, this is in addition to the ctrl_register that may also be used to enable/disable the SMPS. The original logic(prior to commit dbabd624d4eec50b6) used to be: static int palmas_map_voltage_smps(struct regulator_dev *rdev, int min_uV, int max_uV) <snip> if (min_uV == 0) return 0; To handle this scenario, with the transition to regulator_list implementation, we seem to have missed the data necessary to mark as one of the valid entries as "0" 'disabled regulator' which results in 0 volts - So, stick with pre-existing logic. Without this added to the list, palmas regulator driver, on probe, attempts to setup constraints and in the case of OMAP5uEVM, SMPS9 (which is mapped for 2v1 audio supply) fails in regulator_list_voltage_linear_range mapping of '0', and as a fall back of constraints not being applied, the entire regulator list is not enumerated due to assumption that something system wide has gone bad on with the PMIC. Fixes: dbabd624d4eec50b6 ("regulator: palmas: Reemove open coded functions with helper functions") Reported-by: Olof Johansson <olof@lixom.net> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-03Merge tag 'regulator-v3.16' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into next Pull regulator updates from Mark Brown: "The bulk of the changes for this release are a few new drivers however there are a couple of noticable core changes and the usual stream of cleanups and fixes: - move disable of unused regulators later in init so it comes after deferred probe has iterated making startup smoother. - fixes to reference counting of the DT nodes for constraints from Charles Keepax. This has little practical impact since all real users of the regulator bindings use FDT which doesn't need the reference counting. - lots of cleanups, especially to the Samsung drivers. - support for Linear Technologies LTC3589, Texas Instruments TPS658640 and X-Powers AXP20x" * tag 'regulator-v3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (64 commits) regulator: pbias: remove unnecessary OOM messages regulator: max8649: remove unnecessary OOM messages regulator: core: Fix the init of DT defined fixed regulators regulator: core: Disable unused regulators after deferred probing is done regulator: Don't disable unused regulators we don't have permission for regulator: axp20x: Use regulator_map_voltage_ascend for LDO4 regulator: use of_property_read_{bool|u32}() regulator: Fix regulator_get_{optional,exclusive}() documentation regulators: Add definition of regulator_set_voltage_time() for !CONFIG_REGULATOR regulator: arizona-ldo1: add missing #include regulator: pfuze100: Support enable/disable for fixed regulator regulator: ltc3589: Remove ltc3589_list_voltage_fixed function regulator: ltc3589: Fix module dependency regulator: tps6586x: Remove unused to_tps6586x_dev() function regulator: tps65218: Convert to use regulator_set_voltage_time_sel regulator: tps6586x: Add support for the TPS658640 regulator: tps6586x: Prepare supporting fixed regulators regulator: pfuze100: Don't allocate an invalid gpio regulator: pfuze100: Support SWB enable/disable regulator: fixed: use of_property_read_{bool|u32}() ...
2014-06-03regulator: as3722: Make 0 a valid selectorThierry Reding
As of commit 064d5cd110f9 (regulator: core: Fix the init of DT defined fixed regulators) the regulator core tries to query the current voltage of a regulator when applying constraints. This exposes a bug in the AS3722 regulator driver which fails to read the voltage of disabled regulators. The reason is that the hardware is programmed to a selector of 0, but none of the voltage tables include 0 as a valid selector. The datasheets indicate that 0 is a valid selector when the regulators are powered off. To fix this, add a range including selector 0 to the voltage tables. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-03Merge tag 'char-misc-3.16-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc into next Pull char/misc driver patches from Greg KH: "Here is the big char / misc driver update for 3.16-rc1. Lots of different driver updates for a variety of different drivers and minor driver subsystems. All have been in linux-next with no reported issues" * tag 'char-misc-3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (79 commits) hv: use correct order when freeing monitor_pages spmi: of: fixup generic SPMI devicetree binding example applicom: dereferencing NULL on error path misc: genwqe: fix uninitialized return value in genwqe_free_sync_sgl() miscdevice.h: Simple syntax fix to make pointers consistent. MAINTAINERS: Add miscdevice.h to file list for char/misc drivers. mcb: Add support for shared PCI IRQs drivers: Remove duplicate conditionally included subdirs misc: atmel_pwm: only build for supported platforms mei: me: move probe quirk to cfg structure mei: add per device configuration mei: me: read H_CSR after asserting reset mei: me: drop harmful wait optimization mei: me: fix hw ready reset flow mei: fix memory leak of mei_clients array uio: fix vma io range check in mmap drivers: uio_dmem_genirq: Fix memory leak in uio_dmem_genirq_probe() w1: do not unlock unheld list_mutex in __w1_remove_master_device() w1: optional bundling of netlink kernel replies connector: allow multiple messages to be sent in one packet ...
2014-06-02Merge remote-tracking branch 'regulator/topic/tps6586x' into regulator-nextMark Brown
2014-06-02Merge remote-tracking branches 'regulator/topic/s5m8767', ↵Mark Brown
'regulator/topic/stub', 'regulator/topic/tps65090', 'regulator/topic/tps65217' and 'regulator/topic/tps65218' into regulator-next
2014-06-02Merge remote-tracking branches 'regulator/topic/palmas', ↵Mark Brown
'regulator/topic/pbias', 'regulator/topic/pfuze100', 'regulator/topic/s2mpa01' and 'regulator/topic/s2mps11' into regulator-next
2014-06-02Merge remote-tracking branches 'regulator/topic/fixed', ↵Mark Brown
'regulator/topic/id-const', 'regulator/topic/ltc3589', 'regulator/topic/max8649' and 'regulator/topic/of' into regulator-next
2014-06-02Merge remote-tracking branches 'regulator/topic/arizona', ↵Mark Brown
'regulator/topic/axp20' and 'regulator/topic/bcm590xx' into regulator-next
2014-06-02Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2014-06-02Merge remote-tracking branch 'regulator/topic/constraints' into regulator-nextMark Brown
2014-06-02Merge remote-tracking branch 'regulator/fix/s2mpa01' into regulator-linusMark Brown
2014-06-02regulator: pbias: remove unnecessary OOM messagesJingoo Han
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-02regulator: max8649: remove unnecessary OOM messagesJingoo Han
The site-specific OOM messages are unnecessary, because they duplicate the MM subsystem generic OOM message. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-01regulator: core: Fix the init of DT defined fixed regulatorsAlban Bedel
When a regulator is defined using DT and it has a single voltage the regulator init always tries to apply this voltage. However it fails if the regulator isn't settable because it is using an internal low level function. To overcome this we now first query the regulator and only set it if needed. Signed-off-by: Alban Bedel <alban.bedel@avionic-design.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-01regulator: core: Disable unused regulators after deferred probing is doneSaravana Kannan
regulator_init_complete does a scan of regulators which dont have always-on or consumers are automatically disabled as being unused. However, with deferred probing, late_initcall() is too soon to declare a regulator as unused as the regulator itself might not have registered due to defferal - Example: A regulator deffered due to i2bus not available which in turn is deffered due to pinctrl availability. Since deferred probing is done in late_initcall(), do the cleanup of unused regulators by regulator_init_complete in late_initcall_sync instead of late_initcall. Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Saravana Kannan <skannan@codeaurora.org> [nm@ti.com: minor rewording] Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-01regulator: Don't disable unused regulators we don't have permission forMark Brown
In the spirit of conservatism that governs our general approach to permissions it is better if we don't touch regulators we weren't explicitly given permissions to control. This avoids the need to explicitly specify unknown regulators in DT as always on, if a regulator is not otherwise involved in software control it can be omitted from the DT. Regulators explicitly given constraints in DT still need to have an always on constraint specified as before. Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-01regulator: axp20x: Use regulator_map_voltage_ascend for LDO4Axel Lin
The voltages in axp20x_ldo4_data table are in ascendant order, so use regulator_map_voltage_ascend. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-06-01regulator: use of_property_read_{bool|u32}()Sergei Shtylyov
Use more compact of_property_read_{bool|u32}() calls instead of the of_{find|get}_property() calls in of_get_regulation_constraints() where possible (note that of_property_read_{bool|u32}() were already used to read some properties). Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-05-28regulator: Fix regulator_get_{optional,exclusive}() documentationStephen Boyd
regulator_get_optional() doesn't hold an exclusive reference to the regulator. Fix the documentation and reword the exclusive documentation to fix the grammatical error "this reference is held". Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-05-27regulator: arizona-ldo1: add missing #includeArnd Bergmann
commit 2cce4be9e6b8 "regulator: arizona-ldo1: Add processing of init_data from device tree" added a call to of_get_child_by_name() but did not add an #include to the header file declaring that function. I got a build error when doing randconfig testing on this, which is fixed by this patch to include of.h. drivers/regulator/arizona-ldo1.c:192:2: error: implicit declaration of function 'of_get_child_by_name' [-Werror=implicit-function-declaration] drivers/regulator/arizona-ldo1.c:193:2: error: implicit declaration of function 'of_parse_phandle' [-Werror=implicit-function-declaration] drivers/regulator/arizona-ldo1.c:213:2: error: implicit declaration of function 'of_node_put' [-Werror=implicit-function-declaration] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-05-27regulator: pfuze100: Support enable/disable for fixed regulatorAxel Lin
Current code has .enable_reg and .enable_mask settings, but the implementation for corresponding callbacks are missing. Fix it. Signed-off-by: Axel Lin <axel.lin@ingics.com> Tested-by: Robin Gong <b38343@freescale.com> Acked-by: Robin Gong <b38343@freescale.com> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-05-27regulator: ltc3589: Remove ltc3589_list_voltage_fixed functionAxel Lin
When fixed_uV is set and n_voltage is 1, regulator core will return rdev->desc->fixed_uV in regulator_get_voltage() and regulator_list_voltage(). Rename ltc3589_standby_regulator_ops to ltc3589_fixed_standby_regulator_ops, this makes the code clear that the ops is for fixed voltage regulator. Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-05-27regulator: ltc3589: Fix module dependencyAxel Lin
Make this driver depend on I2C and select REGMAP_I2C to fix build failure. Also allows this driver to be built as module. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Axel Lin <axel.lin@ingics.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org>
2014-05-27regulator: tps6586x: Remove unused to_tps6586x_dev() functionAxel Lin
Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@linaro.org>