summaryrefslogtreecommitdiff
path: root/drivers/regulator
AgeCommit message (Collapse)Author
2018-05-17regulator: core: Parse coupled regulators propertiesMaciej Purski
On Odroid XU3/4 and other Exynos5422 based boards there is a case, that different devices on the board are supplied by different regulators with non-fixed voltages. If one of these devices temporarily requires higher voltage, there might occur a situation that the spread between devices' voltages is so high, that there is a risk of changing 'high' and 'low' states on the interconnection between devices powered by those regulators. Add new structure "coupling_desc" to regulator_dev, which contains pointers to all coupled regulators including the owner of the structure, number of coupled regulators and counter of currently resolved regulators. Add of_functions to parse all data needed in regulator coupling. Provide method to check DTS data consistency. Check if each coupled regulator's max_spread is equal and if their lists of regulators match. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-17regulator: core: Make locks re-entrantMaciej Purski
Setting voltage, enabling/disabling regulators requires operations on all regulators related with the regulator being changed. Therefore, all of them should be locked for the whole operation. With the current locking implementation, adding additional dependency (regulators coupling) causes deadlocks in some cases. Introduce a possibility to attempt to lock a mutex multiple times by the same task without waiting on a mutex. This should handle all reasonable coupling-supplying combinations, especially when two coupled regulators share common supplies. The only situation that should be forbidden is simultaneous coupling and supplying between a pair of regulators. The idea is based on clk core. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-17regulator: s2mps11: Pass descriptor instead of GPIO numberLinus Walleij
Instead of passing a global GPIO number for the enable GPIO, pass a descriptor looked up with the standard devm_gpiod_get_optional() call. This regulator supports passing platform data, but enable/sleep regulators are looked up from the device tree exclusively, so we can need not touch other files. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-17regulator: max77686: Pass descriptor instead of GPIO numberLinus Walleij
Instead of passing a global GPIO number, pass a descriptor looked up from the device tree configuration node. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-17regulator: arizona-ldo1: Look up a descriptor and pass to the coreLinus Walleij
Instead of passing a global GPIO number, pass a descriptor looked up with the standard devm_gpiod_get_optional() call. We have augmented the GPIO core to look up the regulator special GPIO "wlf,ldoena" in commit 6a537d48461d "gpio: of: Support regulator nonstandard GPIO properties". Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-17regulator: max8998: Fix platform data retrieval.Paweł Chmiel
Since the max8998 MFD driver supports instantiation by DT, platform data retrieval is handled in MFD probe and cell drivers should get use the pdata field of max8998_dev struct to obtain them. Fixes: ee999fb3f17f ("mfd: max8998: Add support for Device Tree") Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-17regulator: of: add support for allowed modes configurationDavid Collins
Add support for configuring the machine constraints valid_modes_mask element based on a list of allowed modes specified via a device tree property. Signed-off-by: David Collins <collinsd@codeaurora.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-17regulator: core: Allow for regulators that can't be read at bootupDouglas Anderson
Regulators attached via RPMh on Qualcomm sdm845 apparently are write-only. Specifically you can send a request for a certain voltage but you can't read back to see what voltage you've requested. What this means is that at bootup we have absolutely no idea what voltage we could be at. As discussed in the patches to try to support the RPMh regulators [1], the fact that regulators are write-only means that its driver's get_voltage_sel() should return an error code if it's called before any calls to set_voltage_sel(). This causes problems in machine_constraints_voltage() when trying to apply the constraints. A proposed fix was to come up with an error code that could be returned by get_voltage_sel() which would cause the regulator framework to simply try setting the voltage with the current constraints. In this patch I propose the error code -ENOTRECOVERABLE. In errno.h this error is described as "State not recoverable". Though the error code was originally intended "for robust mutexes", the description of the error code seems to apply here because we can't read the state of the regulator. Also note that the only existing user of this error code in the regulator framework is tps65090-regulator.c which returns this error code from the enable() call (not get_voltage() or get_voltage_sel()), so there should be no existing regulators that might accidentally get the new behavior. (Side note is that tps65090 seems to interpret this error code to mean an error that you can't recover from rather than some data that can't be recovered). [1] https://patchwork.kernel.org/patch/10340897/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-09regulator: add support for SY8106A regulatorOndrej Jirman
SY8106A is an I2C attached single output regulator made by Silergy Corp, which is used on several Allwinner H3/H5 SBCs to control the power supply of the ARM cores. Add a driver for it. Signed-off-by: Ondrej Jirman <megous@megous.com> [Icenowy: Change commit message, remove enable/disable code, add default ramp_delay, add comment for go bit, add code for fixed mode voltage] Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-05regulator: add dummy function of_find_regulator_by_nodeChangbin Du
If device tree is not enabled, of_find_regulator_by_node() should have a dummy function since the function call is still there. This is to fix build error after CONFIG_NO_AUTO_INLINE is introduced. If this option is enabled, GCC will not auto-inline functions that are not explicitly marked as inline. In this case (no CONFIG_OF), the copmiler will report error in function regulator_dev_lookup(). W/O NO_AUTO_INLINE, function of_get_regulator() is auto-inlined and then the call to of_find_regulator_by_node() is optimized out since of_get_regulator() always return NULL. W/ NO_AUTO_INLINE, the return value of of_get_regulator() is a variable so the call to of_find_regulator_by_node() cannot be optimized out. So we need a stub of_find_regulator_by_node(). static struct regulator_dev *regulator_dev_lookup(struct device *dev, const char *supply) { struct regulator_dev *r = NULL; struct device_node *node; struct regulator_map *map; const char *devname = NULL; regulator_supply_alias(&dev, &supply); /* first do a dt based lookup */ if (dev && dev->of_node) { node = of_get_regulator(dev, supply); if (node) { r = of_find_regulator_by_node(node); if (r) return r; ... Signed-off-by: Changbin Du <changbin.du@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-02regulator: ltc3676: Assure PGOOD mask is set before changing voltageMarek Vasut
Make sure the DVBxB bit 5, PGOOD mask, is set before changing voltage on the buck converters. If the PGOOD mask bit is not set, the PMIC may deassert the PGOOD signal during the voltage transition. On systems that use the PGOOD signal as a power OK indication for the board or SoC, which should be the case on correct designs, deasserting the PGOOD signal will lead to system reset or shutdown, which is not the expected behavior when changing PMIC buck converter voltage. Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-02Merge branch 'topic/bd9571mwv' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-4.18
2018-04-23regulator: bd9571mwv: Add support for backup modeGeert Uytterhoeven
The BD9571MWV PMIC supports backup mode, which keeps one or more DDR rails powered while the main SoC is powered down. Which DDR rails are to be kept powered is board-specific, and controlled using the optional "rohm,ddr-backup-power" DT property. In the absence of this property, backup mode is not available. Backup mode can be enabled or disabled by the user using the standard "wakeup" virtual file in sysfs, e.g. to enable: echo enabled > /sys/devices/platform/soc/e60b0000.i2c/i2c-7/7-0030/bd9571mwv-regulator.2.auto/power/wakeup When the PMIC is configured for backup mode, the role of the accessory power switch changes from a power switch to a wake-up switch. Two types of switches (or signals) can be used: A. With a momentary power switch (or pulse signal), the PMIC is configured for backup mode in the PMIC driver's suspend callback, during system suspend. Backup mode is enabled by default, as there is no further impact during normal system operation. B. With a toggle power switch (or level signal), the following steps must be followed exactly: 1. Configure PMIC for backup mode, 2. Switch accessory power switch off, to prepare for system suspend, which is a manual step not controlled by software, 3. Suspend system. This mode is not yet supported by the driver. As the switch type is board-specific, and cannot be determined automatically, it is obtained from the presence of one of the "rohm,rstbmode-*" properties in DT. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-23regulator: axp20x: add drivevbus support for axp803Jagan Teki
Like axp221, axp223, axp813 the axp803 is also supporting external regulator to drive the OTG VBus through N_VBUSEN PMIC pin. Add support for it. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Rob Herring <robh@kernel.org> Reviewed-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-23regulator: wm8350: fix missing increment of loop index iColin Ian King
It seems that the loop index i is not being incremented and hence potentially the while loop could spin forever. Fortunately with the data being used this does not appear to happen at the moment. Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-20regulator: Don't return or expect -errno from of_map_mode()Douglas Anderson
In of_get_regulation_constraints() we were taking the result of of_map_mode() (an unsigned int) and assigning it to an int. We were then checking whether this value was -EINVAL. Some implementers of of_map_mode() were returning -EINVAL (even though the return type of their function needed to be unsigned int) because they needed to signal an error back to of_get_regulation_constraints(). In general in the regulator framework the mode is always referred to as an unsigned int. While we could fix this to be a signed int (the highest value we store in there right now is 0x8), it's actually pretty clean to just define the regulator mode 0x0 (the lack of any bits set) as an invalid mode. Let's do that. Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and suspend modes") Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-20regulator: tps6586x: Add support for TPS658624ryang
This version is exists in the Samsung Galaxy Tab 10.1 which is based on the Nvidia Tegra 2 board. The TPS658624 has the same SM2 voltage table as TPS658623. Signed-off-by: ryang <decatf@gmail.com> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-18regulator: pfuze100: update voltage setting for pfuze3000 sw1aAnson Huang
pfuze3000 datasheet(Rev.9.0) from: https://www.nxp.com/docs/en/data-sheet/PF3000.pdf updates sw1a's voltage range, the settings for 1.450V and 1.475V are replaced with 1.8V and 3.3V: 5b'11110 1.450 (SW1B), 1.8 (SW1A/SW1AB) 5b'11111 1.475 (SW1B), 3.3 (SW1A/SW1AB) the voltage calculation using steps is NOT available for sw1a now, use voltage table instead. Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Robin Gong <yibin.gong@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-17regulator: lp87565: Enable LP87565_BUCK_CTRL_1_FPWM_MP_0_2Keerthy
Buck10 is a multi(dual) phase regulator. So as part of enabling it turn on the LP87565_BUCK_CTRL_1_FPWM_MP_0_2 bit which forces it to operate always in multiphase and forced-PWM operation mode. This helps improve the transient voltage response while switching OPP. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-17regulator: lp87565: Add margin while populating ramp_delayKeerthy
The slew rate might need a +/- 15% margin as per the latest data manual: http://www.ti.com/lit/ds/snvsb22/snvsb22.pdf Hence take a conservative approach to program 85% of the original hardware slew rate so that the software accommodates the margin delay while voltage switching. Hence reduce the default ramp_delay populated in the descriptors also by 15%. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-16regulator: ab8500: Drop AB8540/9540 supportLinus Walleij
The AB8540 was an evolved version of the AB8500, but it was never mass produced or put into products, only reference designs exist. The upstream support was never completed and it is unlikely that this will happen so drop the support for now to simplify maintenance of the AB8500. Cc: Loic Pallardy <loic.pallardy@st.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-28Merge remote-tracking branches 'regulator/topic/88pg86x', ↵Mark Brown
'regulator/topic/dt', 'regulator/topic/formatting' and 'regulator/topic/gpio' into regulator-next
2018-03-28Merge remote-tracking branch 'regulator/topic/qcom_smd' into regulator-nextMark Brown
2018-03-28Merge remote-tracking branch 'regulator/topic/qcom' into regulator-nextMark Brown
2018-03-28Merge remote-tracking branch 'regulator/topic/core' into regulator-nextMark Brown
2018-03-28regulator: qcom: smd: Add pm8998 and pmi8998 regulatorsBjorn Andersson
Add the pm8998 and pmi8998 regulators as used in the MSM8998 platform. Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-22regulator: core: Add missing blank line between functionsMark Brown
Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-22regulator: qcom_smd: Drop regulator/{machine,of_regulator} includesStephen Boyd
These seem to be leftovers from previous developments of the driver but they never got removed. Dropping them still allows the code to compile so everything must be fine. Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-20regulator: giving regulator controlling gpios a non-empty label when used ↵Nicholas Lowell
through the devicetree. When the label is empty, it causes missing information and limits diagnostics for instances such as 'cat /sys/kernel/debug/gpio' Setting the label to the regulator supply_name will point to the device using the gpio(s). Signed-off-by: Nicholas Lowell <nlowell@lexmark.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-14regulator: gpio: Fix some error handling paths in 'gpio_regulator_probe()'Christophe Jaillet
Re-order error handling code and gotos to avoid leaks in error handling paths. Fixes: 9f946099fe19 ("regulator: gpio: fix parsing of gpio list") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-09regulator: 88pg86x: new i2c dual regulator chipAlexander Monakov
This chip is found on Google Chromecast and Valve Steam Link devices. It provides two DC regulators with I2C voltage control, separate GPIO enable pins and one sleep mode pin. This driver does not expose GPIO functionality, but supports voltage control in 1.0-2.2V range, based on I2C register information given in Chromecast kernel driver by Jisheng Zhang. Cc: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Alexander Monakov <amonakov@ispras.ru> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07Merge remote-tracking branches 'regulator/fix/resume' and ↵Mark Brown
'regulator/fix/stm32-vfrefbuf' into regulator-linus
2018-02-20regulator: Fix resume from suspend to idleGeert Uytterhoeven
When resuming from idle with the new suspend mode configuration support we go through the resume callbacks with a state of PM_SUSPEND_TO_IDLE which we don't have regulator constraints for, causing an error: dpm_run_callback(): regulator_resume_early+0x0/0x64 returns -22 PM: Device regulator.0 failed to resume early: error -22 Avoid this and similar errors by treating missing constraints as a noop. See also commit 57a0dd187956ea04 ("regulator: Fix suspend to idle"), which fixed the suspend part. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-16regulator: da9211: Pass descriptors instead of GPIO numbersLinus Walleij
This augments the DA9211 regulator driver to fetch its GPIO descriptors directly from the device tree using the newly exported devm_get_gpiod_from_child(). Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-16regulator: da9055: Pass descriptor instead of GPIO numberLinus Walleij
When setting up a fixed regulator on the DA9055, pass a descriptor instead of a global GPIO number. This facility is not used in the kernel so we can easily just say that this should be a descriptor if/when put to use. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-16regulator: core: Support passing an initialized GPIO enable descriptorLinus Walleij
We are currently passing a GPIO number from the global GPIO numberspace into the regulator core for handling enable GPIOs. This is not good since it ties into the global GPIO numberspace and uses gpio_to_desc() to overcome this. Start supporting passing an already initialized GPIO descriptor to the core instead: leaf drivers pick their descriptors, associated directly with the device node (or from ACPI or from a board descriptor table) and use that directly without any roundtrip over the global GPIO numberspace. This looks messy since it adds a bunch of extra code in the core, but at the end of the patch series we will delete the handling of the GPIO number and only deal with descriptors so things end up neat. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-12regulator: of: Add a missing 'of_node_put()' in an error handling path of ↵Christophe JAILLET
'of_regulator_match()' If an unlikely failure in 'of_get_regulator_init_data()' occurs, we must release the reference on the current 'child' node before returning. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-08regulator: stm32-vrefbuf: fix check on ready flagFabrice Gasnier
stm32_vrefbuf_enable() wrongly checks VRR bit: 0 stands for not ready, 1 for ready. It currently checks the opposite. This makes enable routine to exit immediately without waiting for ready flag. Fixes: 0cdbf481e927 ("regulator: Add support for stm32-vrefbuf") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2018-01-30regulator: Fix suspend to idleMark Brown
When suspending to idle with the new suspend mode configuration support we go through the suspend callbacks with a state of PM_SUSPEND_TO_IDLE which we don't have regulator constraints for, causing an error. Avoid this and similar errors by treating missing constraints as a noop. Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26Merge remote-tracking branch 'regulator/topic/tps65218' into regulator-nextMark Brown
2018-01-26Merge remote-tracking branches 'regulator/topic/doc' and ↵Mark Brown
'regulator/topic/sc2731' into regulator-next
2018-01-26Merge remote-tracking branch 'regulator/topic/qcom_spmi' into regulator-nextMark Brown
2018-01-26regulator: Fix build errorMark Brown
3d67fe950707 (regulator: core: Refactor regulator_list_voltage()) missed one user of regulator_list_voltage(), update for that. Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26Merge branch 'topic/suspend' of ↵Mark Brown
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-core
2018-01-26regulator: core: Refactor regulator_list_voltage()Maciej Purski
Change _regulator_list_voltage() argument from regulator to regulator_dev in order to provide better separation of core layers. Allow calling _regulator_list_voltage() from functions, with regulator_dev argument. This refactoring is needed in order to implement setting voltage of coupled regulators. Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26regulator: core: Move of_find_regulator_by_node() to of_regulator.cMaciej Purski
As of_find_regulator_by_node() is an of function it should be moved from core.c to of_regulator.c. It provides better separation of device tree functions from the core and allows other of_functions in of_regulator.c to resolve device_node to regulator_dev. This will be useful for implementation of parsing coupled regulators properties. Declare of_find_regulator_by_node() function in internal.h as well as regulator_class and dev_to_rdev(), as they are needed by of_find_regulator_by_node(). Signed-off-by: Maciej Purski <m.purski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26regulator: add PM suspend and resume hooksChunyan Zhang
In this patch, consumers are allowed to set suspend voltage, and this actually just set the "uV" in constraint::regulator_state, when the regulator_suspend_late() was called by PM core through callback when the system is entering into suspend, the regulator device would act suspend activity then. And it assumes that if any consumer set suspend voltage, the regulator device should be enabled in the suspend state. And if the suspend voltage of a regulator device for all consumers was set zero, the regulator device would be off in the suspend state. This patch also provides a new function hook to regulator devices for resuming from suspend states. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26regulator: empty the old suspend functionsChunyan Zhang
Regualtor suspend/resume functions should only be called by PM suspend core via registering dev_pm_ops, and regulator devices should implement the callback functions. Thus, any regulator consumer shouldn't call the regulator suspend/resume functions directly. In order to avoid compile errors, two empty functions with the same name still be left for the time being. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26regulator: leave one item to record whether regulator is enabledChunyan Zhang
The items "disabled" and "enabled" are a little redundant, since only one of them would be set to record if the regulator device should keep on or be switched to off in suspend states. So in this patch, the "disabled" was removed, only leave the "enabled": - enabled == 1 for regulator-on-in-suspend - enabled == 0 for regulator-off-in-suspend - enabled == -1 means do nothing when entering suspend mode. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-01-26regulator: make regulator voltage be an array to support more statesChunyan Zhang
Some regulator consumers would like to make the regulator device keeping a voltage range output when the system entering into suspend states. Making regulator voltage be an array can allow consumers to set voltage for normal state as well as for suspend states through the same code. Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org> Signed-off-by: Mark Brown <broonie@kernel.org>