summaryrefslogtreecommitdiffstats
path: root/drivers/regulator
AgeCommit message (Collapse)AuthorFilesLines
2015-04-14Merge tag 'mfd-for-linus-4.1' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Changes to existing drivers: - Rename child driver [axp288_battery => axp288_fuel_gauge]; axp20x - Rename child driver [max77693-flash => max77693-led]; max77693 - Error handling fixes; intel_soc_pmic - GPIO tweaking; intel_soc_pmic - Remove non-DT code; vexpress-sysreg, tc3589x - Remove unused/legacy code; ti_am335x_tscadc, rts5249, rtsx_gops, rtsx_pcr, rtc-s5m, sec-core, max77693, menelaus, wm5102-tables - Trivial fixups; rtsx_pci, da9150-core, sec-core, max7769, max77693, mc13xxx-core, dln2, hi6421-pmic-core, rk808, twl4030-power, lpc_ich, menelaus, twl6040 - Update register/address values; rts5227, rts5249 - DT and/or binding document fixups; arizona, da9150, mt6397, axp20x, qcom-rpm, qcom-spmi-pmic - Couple of trivial core Kconfig fixups - Remove use of seq_printf return value; ab8500-debugfs - Remove __exit markups; menelaus, tps65010 - Fix platform-device name collisions; mfd-core New drivers/supported devices: - Add support for wm8280/wm8281 into arizona - Add support for COMe-cBL6 into kempld-core - Add support for rts524a and rts525a into rts5249 - Add support for ipq8064 into qcom_rpm - Add support for extcon into axp20x - New MediaTek MT6397 PMIC driver - New Maxim MAX77843 PMIC dirver - New Intel Quark X1000 I2C-GPIO driver - New Skyworks SKY81452 driver" * tag 'mfd-for-linus-4.1' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (76 commits) mfd: sec: Fix RTC alarm interrupt number on S2MPS11 mfd: wm5102: Remove registers for output 3R from readable list mfd: tps65010: Remove incorrect __exit markups mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes mfd: axp20x: Add support for extcon cell mfd: lpc_ich: Sort IDs mfd: twl6040: Remove wrong and unneeded "platform:twl6040" modalias mfd: qcom-spmi-pmic: Add specific compatible strings for Qualcomm's SPMI PMIC's mfd: axp20x: Fix duplicate const for model names mfd: menelaus: Use macro for magic number mfd: menelaus: Drop support for SW controller VCORE mfd: menelaus: Delete omap_has_menelaus mfd: arizona: Correct type of gpio_defaults mfd: lpc_ich: Sort IDs mfd: Fix a typo in Kconfig mfd: qcom_rpm: Add support for IPQ8064 mfd: devicetree: qcom_rpm: Document IPQ8064 resources mfd: core: Fix platform-device name collisions mfd: intel_quark_i2c_gpio: Don't crash if !DMI dt-bindings: Add vendor-prefix for X-Powers ...
2015-04-10Merge remote-tracking branch 'regulator/topic/wm8350' into regulator-nextMark Brown1-3/+2
2015-04-10Merge remote-tracking branches 'regulator/topic/mode', ↵Mark Brown5-107/+295
'regulator/topic/notifier', 'regulator/topic/palmas', 'regulator/topic/qcom' and 'regulator/topic/stw481x' into regulator-next
2015-04-10Merge remote-tracking branches 'regulator/topic/dbx500', ↵Mark Brown5-127/+76
'regulator/topic/load-op', 'regulator/topic/max77693' and 'regulator/topic/max8660' into regulator-next
2015-04-10Merge remote-tracking branches 'regulator/topic/act8865', ↵Mark Brown4-30/+149
'regulator/topic/arizona-ldo1', 'regulator/topic/arizona-micsupp' and 'regulator/topic/da9211' into regulator-next
2015-04-10Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown1-37/+175
2015-04-10Merge branch 'topic/debugfs' of ↵Mark Brown1-1/+119
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core
2015-04-10regulator: max8660: Handle empty regulator dataMarkus Pargmann1-3/+3
It is not necessary to have regulator init data for a regulator. This patch removes the necessity of this data and handles a NULL pointer properly. Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-10regulator: output current-limit for all regulators in summaryHeiko Stübner1-19/+5
Voltage regulators can have (unregulated) current limits too, so we should probably output both voltage and current for all regulators. Holding the rdev->mutex actually conflicts with _regulator_get_current_limit but also is not really necessary, as the global regulator_list_mutex already protects us from the regulator vanishing while we go through the list. On the rk3288-firefly the summary now looks like: regulator use open bypass voltage current min max ------------------------------------------------------------------------------- vcc_sys 0 12 0 5000mV 0mA 5000mV 5000mV vcc_lan 1 1 0 3300mV 0mA 3300mV 3300mV ff290000.ethernet 0mV 0mV vcca_33 0 0 0 3300mV 0mA 3300mV 3300mV vcca_18 0 0 0 1800mV 0mA 1800mV 1800mV vdd10_lcd 0 0 0 1000mV 0mA 1000mV 1000mV [...] Suggested-by: Mark Brown <broonie@kernel.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-10regulator: add a summary tree in debugfsHeiko Stübner1-0/+121
On modern systems the regulator hierarchy can get quite long and nested with regulators supplying other regulators. In some cases when debugging it might be nice to get a tree of these regulators, their consumers and the regulation constraints in one go. To achieve this add a regulator_summary sysfs node, similar to clk_summary in the common clock framework, that walks the regulator list and creates a tree out of the regulators, their consumers and core per-regulator settings. On a rk3288-firefly the regulator_summary would for example look something like: regulator use open bypass value min max ----------------------------------------------------------------------- vcc_sys 0 12 0 5000mV 5000mV 5000mV vcc_lan 1 1 0 3300mV 3300mV 3300mV ff290000.ethernet 0mV 0mV vcca_33 0 0 0 3300mV 3300mV 3300mV vcca_18 0 0 0 1800mV 1800mV 1800mV vdd10_lcd 0 0 0 1000mV 1000mV 1000mV vccio_sd 0 0 0 3300mV 3300mV 3300mV vcc_20 0 3 0 2000mV 2000mV 2000mV vcc18_lcd 0 0 0 1800mV 1800mV 1800mV vcc_18 0 2 0 1800mV 1800mV 1800mV ff100000.saradc 0mV 0mV ff0d0000.dwmmc 1650mV 1950mV vdd_10 0 0 0 1000mV 1000mV 1000mV vdd_log 0 0 0 1100mV 1100mV 1100mV vcc_io 0 3 0 3300mV 3300mV 3300mV ff0f0000.dwmmc 3300mV 3400mV vcc_flash 1 1 0 1800mV 1800mV 1800mV ff0f0000.dwmmc 1700mV 1950mV vcc_sd 1 1 0 3300mV 3300mV 3300mV ff0c0000.dwmmc 3300mV 3400mV vcc_ddr 0 0 0 1200mV 1200mV 1200mV vdd_gpu 0 0 0 1000mV 850mV 1350mV vdd_cpu 0 1 0 900mV 850mV 1350mV cpu0 900mV 900mV vcc_5v 0 2 0 5000mV 5000mV 5000mV vcc_otg_5v 0 0 0 5000mV 5000mV 5000mV vcc_host_5v 0 0 0 5000mV 5000mV 5000mV regulator-dummy 0 0 0 0mV 0mV 0mV Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-08regulator: qcom: Tidy up probe()Bjorn Andersson1-10/+11
Tidy up error reporting and move rpm reference retrieval out of the for loop for improved readability. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-08regulator: qcom: Rework to single platform deviceBjorn Andersson1-83/+161
Modeling the individual RPM resources as platform devices consumes at least 12-15kb of RAM, just to hold the platform_device structs. Rework this to instead have one device per pmic exposed by the RPM. With this representation we can more accurately define the input pins on the pmic and have the supply description match the data sheet. Suggested-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-08regulator: qcom: Refactor of-parsing codeBjorn Andersson1-60/+81
Refactor out all custom property parsing code from the probe function into a function suitable for regulator_desc->of_parse_cb usage. Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-08regulator: qcom: Don't enable DRMS in driverBjorn Andersson1-4/+0
The driver itself should not flag regulators as being DRMS compatible, this should come from board or dt files. Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-08regulator: max8660: fix assignment of pdata to data that becomes deadColin Ian King1-2/+1
pdata is assigned to &pdata_of, however, pdata_of becomes dead (when it goes out of scope) so pdata effectively becomes a dead pointer to the out of scope object. This is detected by static analysis: [drivers/regulator/max8660.c:411]: (error) Dead pointer usage. Pointer 'pdata' is dead if it has been assigned '&pdata_of' at line 404. Move declaration of pdata_of so it is always in scope. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-04-01regulator: Defer lookup of supply to regulator_getBjorn Andersson1-36/+56
Instead of resolving regulator supplies during registration move this to the time of a consumer retrieving a handle. The benefit is that it's possible for one driver to register regulators with internal dependencies out of order. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-29regulator: max77693: Let core parse DT and drop board files supportKrzysztof Kozlowski1-84/+9
Simplify the driver by removing board file support and letting regulator core to parse DT. The max77693 regulator driver is used only on Exynos based boards which are DT-only. Board files for Exynos are not supported. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-27regulator: Ensure unique regulator debugfs directory namesGuenter Roeck1-1/+12
If multiple regulator devices of the same type exist in a system, the regulator driver assigns generic names for the regulators it provides, and debugfs is enabled, the regulator subsystem attempts to create multiple entries with the same name in the regulator debugfs directory. This fails for all but the first regulator, resulting in multiple "Failed to create debugfs directory" log entries. To avoid the problem, prepend the debugfs directory name for a regulator with its parent device name if available, but only if no explicit regulator name was provided. Cc: Alan Tull <atull@opensource.altera.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-23Merge remote-tracking branches 'regulator/fix/doc' and ↵Mark Brown1-0/+4
'regulator/fix/palmas' into regulator-linus
2015-03-21regulator: stw481x: Remove unused fields from struct stw481xAxel Lin1-4/+4
The mutex lock is not used at all, remove it. The *vmmc_regulator is not necessary, use a local variable in stw481x_vmmc_regulator_probe() instead. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-17regulator: palmas: Add has_regen3 check for TPS659038Keerthy1-1/+8
Palmas driver is used to cater to even TPS659038 but TPS659038 does not have REGEN3 resource. Adding another field in the driver data to check on that. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-17Merge branch 'fix/palmas' of ↵Mark Brown1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-palmas
2015-03-17regulator: palmas: Correct TPS659038 register definition for REGEN2Keerthy1-0/+4
The register offset for REGEN2_CTRL in different for TPS659038 chip as when compared with other Palmas family PMICs. In the case of TPS659038 the wrong offset pointed to PLLEN_CTRL and was causing a hang. Correcting the same. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-03-17regulator: constify of_device_id arrayFabian Frederick1-1/+1
of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-16Merge remote-tracking branches 'regulator/fix/gpio-enable' and ↵Mark Brown2-17/+18
'regulator/fix/tps65910' into regulator-linus
2015-03-16regulator: tps65910: Add missing #include <linux/of.h>Geert Uytterhoeven1-0/+1
drivers/regulator/tps65910-regulator.c: In function ‘tps65910_parse_dt_reg_data’: drivers/regulator/tps65910-regulator.c:1018: error: implicit declaration of function ‘of_get_child_by_name’ drivers/regulator/tps65910-regulator.c:1018: warning: assignment makes pointer from integer without a cast drivers/regulator/tps65910-regulator.c:1034: error: implicit declaration of function ‘of_node_put’ drivers/regulator/tps65910-regulator.c:1056: error: implicit declaration of function ‘of_property_read_u32’ Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-09regulator: Rename regulator_set_optimum_modeBjorn Andersson1-4/+4
Rename the regulator_set_optimum_mode() function regulator_set_load() to better represent what's going on. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-08regulator: core: Fix enable GPIO reference countingDoug Anderson1-14/+12
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> Cc: stable@vger.kernel.org
2015-03-08regulator: Only enable disabled regulators on resumeJavier Martinez Canillas1-3/+5
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> Cc: stable@vger.kernel.org
2015-03-07regulator: act8865: add input supply handlingHeiko Stuebner1-27/+28
The act88600/act8846/act8865 regulators have a number of input supplies supplying the individual regulators. This may even be recursively like on most Rockchip boards using the act8846 where REG4 is most of the time connected to the inl1-supply. Therefore add the ability to specify the input supplies for the individual inputs. The input-names are taken from the datasheets of act8600, act8846 and act8865. On the act8600 some regulators do not have separate input supplies. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-06Merge remote-tracking branches 'regulator/fix/da9210' and ↵Mark Brown2-0/+17
'regulator/fix/rk808' into regulator-linus
2015-03-06regulator: act8865: Add act8600 supportZubair Lutfullah Kakakhel1-1/+119
This patch adds act8600 support to the act8865 driver. VBUS and USB charger supported by this chip can be added later Tested on MIPS Creator CI20 Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-05regulator: wm8350: Remove unused variableFabio Estevam1-1/+0
Commit 8f45acb5f9f34eab ("regulator: wm8350: Pass NULL data with REGULATION_OUT and UNDER_VOLTAGE events") introduced the following build warning: drivers/regulator/wm8350-regulator.c: In function 'pmic_uv_handler': drivers/regulator/wm8350-regulator.c:1154:17: warning: unused variable 'wm8350' [-Wunused-variable] Remove 'wm8350' as it is unused now. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-05regulator: core: Add devres versions of notifier registrationCharles Keepax1-0/+85
Add devm_regulator_register_notifier, this adds the resource against the device for the consumer supply we are registering the notifier for. There seem to be few use-cases where this wouldn't be the users intention and this ensures the notifiers will always be removed at the correct time. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-03-04regulator: Fix regression due to NULL constraints checkTakashi Iwai1-7/+0
The commit [39f802d6b6d9: 'regulator: Build sysfs entries with static attribute groups'] converted the sysfs entry creation to static attribute groups, but this resulted in a regression due to the NULL check of rdev->constraints. At the point where the device is registered, rdev->constraints isn't set, so the attributes depending on it are missing. We may fix it by shuffling the code order in regulator_register(), but a quicker fix is to just remove this NULL check. rdev->constraints is in anyway always set to non-NULL in set_machine_constraints(), thus the check there is basically superfluous. Fixes: 39f802d6b6d9 ('regulator: Build sysfs entries with static attribute groups') Signed-off-by: Takashi Iwai <tiwai@suse.de> Reportded-by: Steve Twiss <stwiss.opensource@diasemi.com> Tested-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-26regulator: arizona-micsupp: Add support for WM8280/WM8281Richard Fitzgerald1-0/+1
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2015-02-24regulator: da9211: Pass NULL data with OVER_CURRENT eventGeert Uytterhoeven1-4/+2
According to the documentation, no data is passed with the OVER_CURRENT regulator notifier event. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: James Ban <james.ban.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-24regulator: da9211: Fix wrong register name in error messageGeert Uytterhoeven1-1/+1
We tried to read the CONFIG_E register, not the CONTROL_E register. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: James Ban <james.ban.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-24regulator: dbx500: Remove use of seq_puts/seq_printf return valueJoe Perches1-23/+9
The seq_puts/seq_printf return value, because it's frequently misused, will eventually be converted to void. See: commit 1f33c41c03da ("seq_file: Rename seq_overflow() to seq_has_overflowed() and make public") Miscellanea: o Remove unnecessary dev_err("seq_<foo> overflow\n") messages Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-24regulator: wm8350: Pass NULL data with REGULATION_OUT and UNDER_VOLTAGE eventsGeert Uytterhoeven1-2/+2
According to the documentation, no data is passed with the REGULATION_OUT and UNDER_VOLTAGE regulator notifier events. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-23regulator: qcom-rpm: Implement set_load and enable drmsBjorn Andersson1-0/+30
Pass the requested load directly to the rpm. Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-23regulator: core: Introduce set_load opBjorn Andersson1-15/+24
Expose the requested load directly to the regulator implementation for hardware that does not support the normal enum based set_mode(). Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-21regulator: rk808: Set the enable time for LDOsDoug Anderson1-0/+8
The LDOs are documented in the rk808 datasheet to have a soft start time of 400us. Add that to the driver. If this time takes longer on a certain board the device tree should be able to override with "regulator-enable-ramp-delay". This fixes some dw_mmc probing problems (together with other patches posted to the mmc maiing lists) on rk3288. Signed-off-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2015-02-21regulator: arizona-micsupp: Drop OF node reference on error pathCharles Keepax1-2/+3
We were not calling of_node_put if the regulator failed to register this patch fixes this. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-21regulator: arizona-ldo1: Drop OF node reference on error pathCharles Keepax1-2/+3
We were not calling of_node_put if the regulator failed to register this patch fixes this. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-18Merge tag 'mfd-for-linus-3.20' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "Changes to existing drivers: - fixr platform device collision; da9052, wm8994-core - regmap configuration amendments; tps65218 - fix runtime PM deadlock; rtsx_usb - remove unused/superfluous code; db8500-prcmu, omap-usb-host - enable watchdog timer; lpc_sch - add start/stop RX URBs helpers; dln2 - remove platform device (DT only); max77686, max77802 - support suspend and resume; dln2 - add Device Tree support; da9063 - extra error checking; intel_soc_pmic - const'ify all the things; 88pm860x, hi6421-pmic, intel_soc_pmic, max77686, lm3533, retu, pcf50633, davinci_voicecodec, smsc-ece1099, tps65218, mc13xxx, tps65217, twl-core, twl6040 New drivers/supported devices: - new driver for Richtek RT5033 - new driver for DA9150 Charger and FuelGauge - new driver for Qualcomm Resource Power Manager (RPM) - add support for the ir-clk into sun6i-prcm - add support for FuelGauge into axp20x" * tag 'mfd-for-linus-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (32 commits) mfd: intel_soc_pmic: Add missing error check for devm_kzalloc mfd: rtsx_usb: Defer autosuspend while card exists mfd: devicetree: Add bindings for DA9063 mfd: da9063: Add device tree support regulator: qcom-rpm: Add missing state flag in call to RPM mfd: qcom-rpm: Driver for the Qualcomm RPM mfd: devicetree: bindings: Add Qualcomm RPM DT binding mfd: max77686/802: Remove support for board files mfd: omap-usb-host: Remove some unused functions mfd: twl6040: Constify struct regmap_config and reg_default array mfd: twl-core: Constify struct regmap_config and reg_default array mfd: tps65217: Constify struct regmap_config mfd: mc13xxx: i2c/spi: Constify struct regmap_config mfd: tps65218: Constify struct regmap_config mfd: smsc-ece1099: Constify struct regmap_config mfd: davinci_voicecodec: Constify struct regmap_config mfd: pcf50633: Constify struct regmap_config mfd: retu: Constify struct regmap_config mfd: lm3533: Constify struct regmap_config mfd: max77686: Constify struct regmap_config ...
2015-02-17regulator: da9210: Mask all interrupt sources to deassert interrupt lineGeert Uytterhoeven1-0/+9
After boot-up, some events may be set, and cause the da9210 interrupt line to be asserted. As the da9210 driver doesn't have interrupt support yet, this causes havoc on systems where the interrupt line is shared among multiple devices. This is the case on e.g. r8a7791/koelsch, where the interrupt line is shared with a da9063 regulator, and the following events are set: EVENT_A = 0x00000011 (GPI0 | GPI4) EVENT_B = 0x00000002 (NPWRGOOD) Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-02-08Merge remote-tracking branches 'regulator/topic/rk808', ↵Mark Brown4-11/+21
'regulator/topic/rpm', 'regulator/topic/rt5033' and 'regulator/topic/tps65023' into regulator-next
2015-02-08Merge remote-tracking branches 'regulator/topic/max8649', ↵Mark Brown7-88/+505
'regulator/topic/mode', 'regulator/topic/mt6397', 'regulator/topic/pfuze100' and 'regulator/topic/qcom-rpm' into regulator-next
2015-02-08Merge remote-tracking branches 'regulator/topic/isl9305', ↵Mark Brown7-74/+324
'regulator/topic/lp872x', 'regulator/topic/max14577', 'regulator/topic/max7686' and 'regulator/topic/max77843' into regulator-next
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-18 15:13:41 +0000